Включить журнал

И отключить профилактическую проверку (раз в какой-то интервал и через сколько-то монтирований)

man tune2fs

lYYirbis_alА что она у Вас всё время после отключения питания просит проверится...
Нет, не каждый раз.
В общем, сделал настройку


для корневого раздела, а для других разделов отключил.

Всем спасибо за советы и мысли!Не вижу смысла
Даже если корневой раздел маленький почему именно 100?

Такие вещи очень раздражают, когда нужно уложиться в технологическое окно, ставишь быстренько патчи, перегружаешь и офигиваешь от того, что именно этот раз пришелся на 100 монтирование и оно вдруг решило профилактически проверить файловую систему.

Тебе ведь ничего не мешает запускать самому периодически эту проверку (fsck -nf /) и в удобное для тебя время попытаться полечить, если найдены повторяющиеся ошибки (на открытых файлах вполне могут быть и orphaned inode, и deleted/unused inode, и free blocks/inodes count wrong, и т.п.)

PS. Про журнал-то не забыл?

irbis_altune2fs -i 0 /dev/sda1i -1, насколько помню (хотя, может и 0 срабатывает)lYYВячеслав ЛюбомудровПро журнал-то не забыл?
Про журнал я не понял, он вроде по умолчанию есть?
Где про него почитать?Тот же tune2fs -l покажет тебе featuries

Если бы он у тебя был, то вряд ли fsck после сбоя работал больше пары секунд

МутагенЭто сообщение при старте ОС обозначет, что в ФС такие повреждения, которые fsck в автоматическом режиме исправить не смог. При ручном запуске он задаст вопросы на тему: куда складывать обломки каталогов, предложит очистить сомнительные inode и тп. Всё это потенциально деструктивные действия, поэтому автоматом их не запускают. С журналом автоматическое исправление таких логических повреждений на порядок вероятней
МутагенПричиной таких повреждений при пропадании питания обычно является неверная работа кеша диска на запись - он не записывает данные на физический носитель, а держит их в своём буфере. После отключения питания буфер исчезает. Встроенный в диск кеш не выдерживает очередность записи (пришедшие от хоста блоки ФС могут быть записаны раньше журнала), поэтому журналы ФС оказываются бесполезными.Нарушение очередности записи непосредственно при креше весьма редкая ситуация.
Чаще это просто не запись метаданных (не говоря уже про сами данные)
Опять же, без журнала все еще хужее
МутагенПроверка по числу дней/монтирований вроде открутили в redhat 6 и дальше, так что острота той проблемы снизилась. Как альтернативу можно проверять снапшот LVM через cron: http://www.redhat.com/archives/ext3-users/2008-January/msg00032.html В OL6.4 еще используется
LVM тоже не у всех юзается
Впрочем, к ТС это вообще никаким боком

Да нет
Скорее всего запись журнала криво записалась.
Она хоть и маленькая по размеру, но может занимать несколько дисковых блоков (по 512 байт). Т.е. в дешевых дисках легко возможна ситуация когда один блок записался, а другой нет.

А есть еще и разные режимы журналирования (writeback, например, вполне очевидно допускает некоторое рассоглассование метаданных)

Плюс, файловая система могла быть поломана раньше вследствии, например, какого-нибудь бага (или "шаловливых" ручек). При этом, естественно, никакой накат логов не спасет, а ошибка вылезет только при проверке

Еще раз -- журналы бывают разные
Если это writeback, то никакая очередность даже не закладывается (и что самое прикольное -- часто это бывает достаточно)
Если ordered -- то запись метаданных идет синхронно (O_SYNC), другое дело что диск может подтвердить запись физически ее не произведя. Типо держит в своем внутреннем кеше, пытаясь оптимизировать движение головок. А тут раз -- и кирдык по питанию. Скорее всего Мутаген говорил именно об этом.

Как мне кажется, этим страдают уж совсем простейшие диски (естественно, с претензией на навороченность) -- обычно в сервера втыкают что-то более-менее брендовое, где таких портаков не наблюдается.