Когда fsck опасен?
Недавно я видел, как корневая файловая система компьютера в удаленном центре обработки данных перемонтировалась только для чтения в результате проблем с согласованностью.
При перезагрузке эта ошибка была показана:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
После запуска fsck, как было предложено, и принятия исправлений вручную с помощью Y, ошибки были исправлены, и теперь система исправна.
Теперь я думаю, что было бы интересно, если бы fsck был настроен на автоматический запуск и восстановление всего, так как в некоторых случаях (например, в этом случае) единственной альтернативой является персональное подключение к удаленному центру данных и подключение консоли к зараженной машине.
Мой вопрос: почему fsck по умолчанию запрашивает ручное вмешательство? Как и когда коррекция, выполняемая такой программой, будет небезопасной? В каких случаях системный администратор может захотеть оставить предлагаемое исправление на некоторое время (для выполнения некоторых других операций) или отменить его полностью?
3 ответа
fsck определенно наносит больше вреда, чем пользы, если базовое оборудование каким-то образом повреждено; плохой процессор, плохая оперативная память, умирающий жесткий диск, контроллер диска вышел из строя... в таких случаях больше коррупции неизбежно.
Если вы сомневаетесь, рекомендуется просто сделать снимок поврежденного диска с помощью dd_rescue или другой инструмент, а затем посмотреть, сможете ли вы успешно исправить это изображение. Таким образом, у вас все еще есть оригинальные настройки.
Вы видели один пример, где fsck работал, но я видел более, чем достаточно поврежденных файловых систем, где он не работал вообще. Если он будет работать полностью автоматически, у вас не будет шансов сделать что-то вроде dd дамп диска или что-то подобное, что во многих случаях было бы отличной идеей перед попыткой ремонта.
Никогда, никогда не бывает хорошей идеей попробовать что-то подобное автоматически.
Да, и современные серверы должны иметь удаленные консоли или, по крайней мере, независимые системы спасения, чтобы восстанавливаться после чего-то подобного, не привязывая стойку KVM к серверу.
Прежде всего, вы должны понимать, что с современными (журнализированными) файловыми системами сбой системы не повредит файловую систему, и во время загрузки не потребуется fsck.
Ext3, Ext4, ZFS, btrfs, xfs и все современные FS на 100% согласованы после сбоя или перезагрузки системы.
Не журнализируемые FS, такие как ext2 или vfat, являются большим NOGO для системных rootfs.
Теперь, если ваша система требует fsck во время загрузки, вы должны спросить себя: что было причиной этого в первую очередь?
Вы должны изучить журналы ядра, чтобы узнать, когда и что произошло. Вы должны также вернуться назад во времени в журналах, чтобы найти с тех пор, когда ошибка все-таки началась. Вы должны проверить свои диски с Smartctl. И т.д.... Если вам нужен fsck на журнализированном fs, то практически наверняка произойдет сбой вашего оборудования, если предположить, что fs не был поврежден администратором (с инструментами уровня блока, такими как dd) или ошибкой.
Поэтому глупо использовать fsck, чтобы "исправить" проблему, не исследуя и не устраняя причину (путем замены / обновления неисправного оборудования / прошивки / программного обеспечения).
Делать fsck, завершать загрузку и быть счастливым наивно, если не сказать больше. То, что "у меня работа с fsck больше, чем вы цитируете", заставляет меня задуматься, что вы имеете в виду под "работой fsck". Возможно, fsck вернул ваш fs в согласованное состояние, потеряв при этом некоторые файлы и данные... Вы сравнивали с резервной копией? Многие люди теряют файлы или получают повреждение данных, не замечая...