Недавно я видел, как корневая файловая система машины в удаленном центре обработки данных была перемонтирована только для чтения из-за проблем с согласованностью.
При перезагрузке отображалась эта ошибка:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
После запуска fsck, как предлагается, и принятия исправлений вручную с помощью Y, ошибки были исправлены, и теперь с системой все в порядке.
Теперь я думаю, что было бы интересно, если бы fsck был настроен для автоматического запуска и восстановления всего, поскольку единственная альтернатива в некоторых случаях (например, в этом) - лично обратиться в удаленный центр обработки данных и подключить консоль к затронутой машине.
У меня вопрос: почему fsck по умолчанию требует ручного вмешательства? Как и когда исправление, выполненное такой программой, будет небезопасным? В каких случаях системный администратор может захотеть отложить предложенное исправление на некоторое время (для выполнения некоторых других операций) или полностью отменить его?
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 work». fsck, возможно, вернул вашу fs в согласованное состояние, потеряв при этом некоторые файлы и данные ... Вы сравнивали с резервной копией? Многие люди теряют файлы или получают повреждение файловых данных, не замечая ...