Журналируемость fs... А есть ли необходимость в этом ?..

Рискну показаться слишком категоричным, но выскажусь.

Будем считать, что мы делаем серьезный сервер, а не банальную файлопомойку, информация на которой стОит ровно столько, сколько требуется для ее записи на болванку-другую.

Мы, естественно, позаботимся и о нормальном бесперебойном питании для него (вплоть до дизель-генератора, возможно, и не одного). Все зависит от стоимости информации.

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

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

"Родной" файловой системы (будь то *BSD или Linux) будет нам достаточно.

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

Далее. Никакая "журналируемость" не спасет от краха железа. Стало быть, пишем еще "немного" зеленых на raid. Причем не софт-рейд, а уж тем более не ide-raid, а нормальный scsi-массив.

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

Еще раз повторюсь, что это мое личное мнение, кому-то мОгущее показаться далеким от реальности.

А как изменится картина если учесть, что по ряду пунктов не все оговорки реализуемы. Т. е. с практической точки зрения, когда необходимо работать с тем, что есть ?

Думаю, что журналируемость (если она без ошибок реализована) поможет в случае слета питания (информация окажется в корректном состоянии ДО транзакции, во время которой был сбой), но крах железа (вспомним хотя бы пресловутые Western Digital или сыпящиеся без надлежащего охлаждения IBM DTLA) она в силу понятных причин не переживет.

Так что осмелюсь посоветовать на мой взгляд, наиболее дешевое решение (безотносительно к журналируемости, однако): правильно продуманная стратегия бэкапов сократит вероятные потери до требуемого минимума. И еще UPS или, если совсем уж худо, сетевой фильтр, который защитит железо от падения/всплесков напряжения и различного вида помех и шумов (рядом проезжающий трамвай/троллейбус; лифт; сварщик, почему-то "севший" на Вашу фазу).

Тогда можно предположить, что факт наличия журналируемых fs в Linux - не более чем ответ на пропагандируемые M$ с БГ
во главе доводы о пользе журналируемости fs, и не имеет под собой практической востребованности.

P.S. К первому ответу: Obidos, на длительную работу солярки для дизель-генератора не напасешься, если нет ограничения в
средствах, то в качестве основного резервного источника питания можно и атомную электростанцию поставить. А в качестве
сервера - полную конфигурацию Sun Fire 15K.