Как долго fsck может занять объем 30 ТБ?

В середине ноября перестал отвечать VPS, который я арендую у хостинговой компании. Когда я связался со службой поддержки, они объяснили, что отключение питания в центре обработки данных вызвало принудительную перезагрузку и fsck. В конце концов я спросил, почему это занимает так много времени, и мне ответили, что размер тома составляет 30 ТБ. Последний раз я получал обновления в феврале, и они не ответили на мой последний запрос.

Я понимаю, что fsck может быть очень медленным для некоторых файловых систем, но возможно ли, чтобы fsck занял 6 месяцев при объеме в 30 ТБ, или я должен предположить, что эта хостинговая компания лжет мне, чтобы я продолжал оплачивать свой счет каждый месяц?

fsckСкорость в основном зависит от количества файлов и того, как они распространяются в соответствующем каталоге. Тем не менее, 6 месяцев для a 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 некоторое время назад и не сообщали вам о новой проблеме после ее завершения.