> Да в курсе я успешности ntfs, но её фрагментируемость и активная деградация (особенно, если
> включить какое-нибудь сжатие) не перестают удивлять и сегодня.

ну вот я не наблюдаю какой-то катастрофической деградации на ntfs'ных дисках _десятилетнего_ возраста. Они, разумеется, не забиваются и не забивались под завязку, и да, сжатие я всегда считал дурным выбором (и тем почти спасся от очень малоприятных проблем в zfs - если бы не прозевал что обо мне позаботились и включили его в еще одном месте ;-) - возможно, если бы оно активно использовалось, что-то бы изменилось. (в конце-концов, ms зачем-то сует в планировщик дефрагментатор, хотя у юзеров и немного шансов что он успеет сработать)

К тому же в многозадачной системе не нужно отсутствие фрагментации, ей нужен правильный планировщик io. (а у нас - 12309)

> Там совершенно другие головы, например. К тому же он кешируется в памяти?

так журнал же ж! его нельзя кэшировать, в том и суть.

> Можно подробности? Желательно после 2007 или когда там барьеры подвезли.

когда подвезли, мы уже на xfs перешли (уже не вспомню что именно в той среде мешало нам выключить журнал, а с включенным оно тормозило в самые неподходящие моменты. К тому же про гугля мы тогда не знали, он умел хранить свои секретики). Так что полных крэшей, когда уже проще плюнуть на пропавшие данные и не пытаться ничего выковыривать, наверное, после ~2008го лично я уже не видел, только "massive filesystem corruptions" и "minor silent corruptions", угу. Но эти хотя бы исправлял fsck и md5sum позволял потом выявить испорченное.

Что на фоне моих прошлых пяти лет, прожитых в основном с ufs, все равно выглядело, мягко говоря, бледненько.
То есть вот привычка хранить рядом с крупными файлами их md5 - она у меня примерно тех времен, когда "барьеры подвезли", а данные не портить почему-то все равно не получалось. В начале 2000х у меня такой не было, и как-то обходилось. Может потому что диски были сильно меньше.

Но обратите внимание - ntfs живет с еще более ранних времен, и по сей день.