> Здесь тоже просматривается, если по ссылке пройти.

Я когда-то смотрел на дизайн Reiser4 и идеи в его основе, так что я представляю себе что я увижу. Ну и вообще, общую логику упомянутых операций я понимаю и мне того что вы сказали вполне достаточно. После размышлений я понял что ReiserFS пытается стать чем-то типа "Leechcraft от файловых систем", если допустить что у автора хватит пороху накодить и попытаться это отладить до какого-то вменяемого состояния (к ФС все-таки требования к качеству и стабильности жестче чем к прикладухе, там даже маленький факап отольется в большой дестрой). С текущими ресурсами это выглядит научной фантастикой  на ближайшие 50 лет. Да и вообще, вопрос насколько надо пытаться отлить серебряную пулю. В пингвине есть туева хуча ФС на разные сценарии. Совершенно разных. И не очевидно что вместо этого стоит пихать напрочь разную логику в 1 мегаФС. В конечном итоге, отдельный самолет летает лучше чем гибрид самолета и подводной лодки. Слишком уж разные требования у задач "погружение под воду" и "полет в воздухе". То же самое можно сказать и про "классику" vs "CoW".

> Одни пользователи просили оптимизировать
> reiser4 для SSD - для них сделали COW (txmod=wa).

Тезис о том что CoW достойны только пользователи SSD - достаточно спорный, имхо.

> Пользователи на HDD жаловались на быструю фрагментацию - для них сделали чистое
> журналирование.

...и продолбали все плюсы CoW. Как то недеструктивную запись не в ущерб скорости записи и возможность "отмотать назад" если результат не понравился. Чудес не бывает. Выигрывая в силе - проигрываем в расстоянии.

> Теперь при "txmod=journal" reiser4 фрагментируется не быстрее ext4, reiser3 и др.

Только радости с этого не густо. Ибо плюсов CoW тоже не будет. CoW ведь все бросились использовать не просто так. А потому что он на самом фундаментальном уровне решает большую проблему классики: полное честное журналирование с возможностью полного отката или полного докатывания до финиша - дико тормозит. Потому что сначала надо писать намерения (со всеми данными!!!) в журнал а потом - в основную область диска. Двойная запись - просадка скорости записи. Ну или читерить как в современных ФС, журналя только метаданные. Тогда данным файла при удобном случае совсем крындец будет, когда файл станет наполовину новый и наполовину старый. Как в ext-ах и прочих с журналингом то. В CoW сжульничали, по сути убрав область данных и превратив всю ФС в один большой журнал, так что commit в область данных просто никогда не требуется и достаточно 1 записи. Это заставляет использовать недеструктивную запись и хитрозадую реконструкцию текущего вида. Ну и создает свои проблемы. Но в целом это выглядит имхо симпатичнее того что было. Ибо может настоящий полный журналинг и недеструктивную запись без двукратного продалбывания скорости записи.