Журнал для FS - а нужен ли он?

Как отключал журнал в ext4?

Есть заметная прибавка скорости?

# umount DEVICE
# tune2fs -O ^has_journal DEVICE

Нет заметного истирания места на диске под названием файл журнала :)

Запустите iotop :)

>журнал не спасает от резких выключений питания, паник ядра и пр., ошибки FS _остаются_ в 85% случаев

reiserfs очень здорово реанимируется даже после очень жёстких перезагрузок

на работе юзаю windows + хомяк на ext3 который видится и работает как ext2 (без журнала)
за полтора года никаких нареканий.

Точно, не припомню, чтобы reiserfs слетало.

да, потому я её и использую на корне - её для этого будто доктор прописал

Откуда данные про 85%?

Просто 95% - было бы очень палевно:)

пару раз reset'ните машину во время tar xf linux-2.6.34.tar.bz2 :)

А потом пройдитесь e2fsck, будете удивлены.

Интересно, когда в этой теме вспомнять FreeBSD?

> Интересно, когда в этой теме вспомнять FreeBSD?

я вспомню OpenBSD

Но зачем? Давайте-ка сразу молотком по HDD, тогда точно никакая журналируемая ФС не спасёт.

/home на reiserfs уже несколько лет, питание внезапно обрубалось много раз, проблем из-за этого не замечено. И восстановление по журналу гораздо быстрее проверки / который на ext3.

журнал не спасает от резких выключений питания, паник ядра и пр., ошибки FS _остаются_ в 85% случаев.

А должен спасать? Он только уменьшает вероятность серьёзных повреждений и ускоряет восстановление.

> уменьшает вероятность серьёзных повреждений

Citations needed.

> журнал не спасает от резких выключений питания, паник ядра и пр., ошибки FS _остаются_ в 85% случаев.

надо понимать что мы пишем в журнал. По умолчанию журналируются только мета-данные, но не данные. То есть это защита от появлений файлов с именами типа «&$^%^#&(@!». Подозреваю что у тебя таких файлов после резких выключений питания не появляется. Значит оно работает!

Для сохранности данных надо монтировать с «data=journal» (если не брать экзотику типа reiser4 или brtfs). Но после этого скорость снижается ровно в два раза потому что данные пишутся на диск два раза. У меня подозрение что именно поэтому никто на самом деле журналом в журналируемых FS и не пользуется.

Лучше расскажите существует ли хоть одна ситуация, когда он реально нужен.

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

а что за ядра такие - на 100% сертифицированные ?
с kernel.org насколько процентов будет ?

Когда у вас структура FS развалится - вы вспомните о журнале

Выход: использовать FS, которым журнал не нужен - они всегда в персистентном состоянии

Наконец-то согласен, но fsck всё равно нужен :)

Нисколько, разработчики ядра жутко обожают introduce regressions.

Не приписывай мне того, что я не говорил.

Ну и пускай остаются ошибки ФС. ext3 с опцией data=order может гарантировать сохранность данных, а о корректности служебных структур позаботится fsck. Или вы хотите не только метаданные, но и сами данные тоже угробить?