> Журнал в JFS помогает гарантировать целостность в 100% случаев, не?Во первых в современных ФС обычно журналят только метаданные, поскольку делать абсолютно честные транзакции, вгоняя в журнал еще и данные - в классическом дизайне получается очень медленно: надо записать данные сперва в журнал, обозначив намерения, а потом закоммитить их в основную область, реализовав то что обозначено. Двойная запись и дикая просадка скорости - обеспечены, поэтому обычно идут на компромисс и делают двойную запись только для метаданных. При этом метаданные всегда могут быть быстро приведены в какое либо из валидных состояний, но вот данные моут оказаться в некоем промежуточном состоянии, когда полфайла новые а полфайла старые. Потому что нет сведений о том как довести дело до конца или откатить применительно к данным, раз уж это писалось только для метаданных ФС.
В CoW и похожих по смыслу дизайнах этот момент довольно технично обжулили, превращая файловую систему в один сплошной журнал, сделав запись недеструктивной (вместо перезаписи данных - копирование + дозапись отличий в сторонку). Раз нет основной области фс то и коммитить в нее из журнала ничего не надо, ну а значит и двойной записи данных уже нет, впрочем и метаданных тоже. Удачная транзакция - та которую удалось дописать до конца в журнал. А не удалось - так хвост просто отбрасывается как будто его и небыло :)
Ну и кроме всего прочего - в этой логике нигде не учитывается что будет при вылезании бэда, это все-таки довольно нештатная ситуация. Это не значит что потом не захочется отскрести том от асфальта.
