>>ну да, даже если сбой по питанию привел к появлению bad blocks в
>>районе загрузчика или в суперблоке.
>
>Такое разве может быть?
при падении питания, запросто, на современных дрянных PATA/SATA
дисках, как два пальца, да если еще UFS[1|2]+Softupdates
UFS1 & UFS2 без softupdate гораздо надежней и живучей, хоть и
медленней.
>>#-- force fsck
>>fsck_y_enable="YES"
>Нсчет этого понял - стоит в настройках, сэнкс.
>
>А по поводу вот этого , что это?
>Укажите в мануал, или разьясните плз.
дык man fsck - "по любому" :)
НЕ ЗАПУСКАТЬ fsck в фоновом режиме на боевых серверах, достаточно
попробовать на WKS и посмотреть в работе, допустим на сервере уже
вовсю пошли интенсивные операции I/O (особенно на запись), а fsck
еще в пути. Такую ж...у можно получить...
>>#-- don't use bg-fsck for servers
>>background_fsck="NO"
>>
На предмет force_fsck: fsck by default запускается в preen режиме,
в котором НЕ ВСЕ может поправить & исправить, поэтому во всех Unix'ах,
если fsck при загрузке не может привести FS в порядок, init останавливает
стандартный bootstrap процесс и предлагает ручное выполнение fsck
в single-user режиме - те администратор может принять решение КАК
стартовать fsck.
В случае fsck_y_enable="YES" - обратной дороги НЕТ, никакого решения
администратор уже принять не сможет, а будет иметь принудительный
fsck -y, ну можно еще -F