LINUX.ORG.RU
ФорумTalks

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


0

0

Можно флеймить сутками, я говорю про факт, который я вынес для себя долгим опытом общения с ext3/4/KillerFSv3/XFS/NTFS: журнал не спасает от резких выключений питания, паник ядра и пр., ошибки FS _остаются_ в 85% случаев.

Лучше расскажите существует ли хоть одна ситуация, когда он реально нужен. Не стоит вспоминать про хранилища на > 10TB - такие вещи _обязаны_ работать с UPSx2, под 100% сертифицированными ядрами.

PS Дома сижу сейчас на ext4 _без_ журнала (/ 15GB > 400 000 файлов, home > 10 000 файлов 30GB) - проверка обоих занимает полторы минуты.

Ответ на: комментарий от ls-h

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

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

tempuser002 ()

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

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

Fracta1L ()

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

k0l0b0k ★★ ()
Ответ на: комментарий от emaxx

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

Fracta1L ()
Ответ на: комментарий от bbk123

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

я вспомню OpenBSD

nerfur ★★★ ()
Ответ на: комментарий от tempuser002

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

Lighting ★★★★★ ()

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

amaora ★★ ()

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

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

Deleted ()

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

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

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

pupok ★★ ()

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

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

iZEN ★★★★★ ()

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

x905 ★★★★★ ()

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

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

namezys ★★★★ ()
Ответ на: комментарий от tempuser002

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

iZEN ★★★★★ ()

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

GotF ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.