В середине ноября VPS, который я арендую у хостинговой компании, перестал отвечать. Когда я связался со службой поддержки, они объяснили, что отключение электроэнергии в центре обработки данных вызвало принудительную перезагрузку и fsck. В конце концов я спросил, почему это занимает так много времени, и мне сказали, что размер тома составляет 30 ТБ. Последний раз я получал обновление в феврале, и они не ответили на мой последний запрос.
Я понимаю, что fsck может быть очень медленным для некоторых файловых систем, но возможно ли, чтобы fsck занимал 6 месяцев на томе 30 ТБ, или я должен предположить, что эта хостинговая компания лжет мне, чтобы я продолжал оплачивать свой счет каждый раз месяц?
fsck скорость в основном зависит от количества файлов и их распределения в соответствующем каталоге. Тем не менее, 6 месяцев для fsck Абсурдно: он должен был завершиться самое большее за несколько часов, особенно если использовать xfs который имеет быстрый xfs_repair утилита. Вот вы можете найти некоторые fsck бегать в масштабе - все выполняется менее чем за час (3600 сек). Итак, невозможно, чтобы ваш fsck все еще работает.
В любом случае неожиданная потеря мощности не вызвать полномасштабный удар fsck, скорее только очень быстрое (несколько секунд) воспроизведение журнала. Однако, если некоторые ключевые файлы были повреждены, ОС может не загрузиться.
Но они, вероятно, просто солгали вам. Вам следует немедленно прекратить платить, попросить объяснений и подать заявку на полное возмещение.
Гипотеза: их система использует RAID без BBU / FBWC (или даже программный RAID) со всеми возможными кэшами записи (включая их в самих жестких дисках), настроенными на их наиболее агрессивные настройки, чтобы получить максимальную производительность при минимальных затратах. Резкое отключение питания при такой настройке может привести к тому, что файловая система журналирования окажется в состоянии, когда журналу нельзя доверять и который не может быть использован для восстановления. Проблема в том, что такая система агрессивно переупорядочивает и откладывает записи, а это означает, что запись журнала может быть записана с эффектом потери действия с данными ... или потери записи журнала в результате действия с данными, которое было последующим.
Восстановление такой системы после сбоя в наихудшем случае может означать, что вам придется выполнить "медленную" fsck / repair, которая фактически проверяет все структуры файловой системы, как они есть, что действительно может занять день или два для 30 ТБ ... и это вполне вероятно, что вам придется выполнять несколько циклов ремонта. Добавьте к этому, что персонал может быть не всегда доступен для наблюдения за этим, вы легко можете сократить до одного fsck в неделю. Вероятно, они сдались и забыли.
Для большинства файловых систем это будет намного быстрее, даже при наличии ошибок, поскольку обычно проверяются только метаданные.
В худшем случае он может прочитать весь диск, (например что-то вроде fsck.ext4 -cc /dev/sda, который выполняет неразрушающий тест записи для каждого блока), что может занять несколько дней для 30 ТБ. Если вы знаете скорость приводов, вы можете рассчитать размер / скорость. Для потребительского жесткого диска с 100 МБ / с копирование нескольких ТБ может занять больше часов, чем ожидает большинство людей.
Если бы это был ваш сервер, у вас могла бы быть проблема, что он загружается, а затем зависает, когда fsck спрашивает, хотите ли вы исправить ошибку. Но администратор центра обработки данных не оставит fsck висит 6 месяцев, пока все VPS отключены.
Значит, они либо вам лгут, либо возникает огромное недоразумение. Или они запускали fsck некоторое время назад и не сообщали вам о новой проблеме после ее завершения.