When is fsck dangerous?
Recently I've seen the root filesystem of a machine in a remote datacenter get remounted read-only, as a result of consistency issues.
On reboot, this error was shown:
UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)
After running fsck as suggested, and accepting the corrections manually with Y, the errors were corrected and the system is now fine.
Now, I think that it would be interesting if fsck was configured to run and repair everything automatically, since the only alternative in some cases (like this one) is going in person to the remote datacenter and attach a console to the affected machine.
My question is: why does fsck by default ask for manual intervention? How and when a correction performed by such program would be unsafe? Which are the cases when the sysadmin might want to leave a suggested correction aside for some time (to perform some other operations) or abort it alltogether?
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 в согласованное состояние, потеряв при этом некоторые файлы и данные ... Вы сравнивали с резервной копией? Многие люди теряют файлы или получают повреждение файловых данных, не замечая ...