> С чего бы вдруг? Вы же намеренно отключаете CoW у Btrfs. (Чуть
> ли не в каждом посте о достоинствах Btrfs приводите это как
> полезную фичу :)

Это полезная фича для очень нишевых применений. Которые сами себя журналят и потому клещатся с CoW.

> Заметьте, я не предлагаю повсеместно вырубать проверку чексумм
> на ZFS, хотя в тестах ZFS с традиционными ФС это делать забывают. ;) )

Я думаю что на этом сильно много не выиграешь. Оно упирается в обсчет чексумм только на дистрофическом процессоре и очень высоких скоростях. В бенчах тоже никто CoW не отключает. Это точечная ситуационная мера для адресных применений когда логика CoW не стыкуется с логикой работы с журналируемой структурой типа БД.

> Ну да, только традиционные линуксовых ФС это делается на уровне метаданных с
> помощью журналирования, а мусор из противоречивых данных подчищается в процессе fsck.

Может и не вычиститься. Это на классике технически невозможно при случае когда крах случился в середине записи а журналинг был только для метаданных. Нет данных для докатывания транзакции до конца или откатывания. А полный журналинг тормозит т.к. 2 раза приходится все писать. В cow сделали финт ушами и обошли эту проблему сбоку. По сути сделав ФС одним большим журналом.

> Включение журналирования всего и вся приводит к ощутимым тормозам. А вот
> в UFS2 это всё делается прозрачно благодяря технологии Soft-updates, а включение
> журналирования на томе с UFS2+SU позволяет привести ФС и данные в
> непротиворечивое состояние без продолжжительной проверки fsck — этим и отличаются
> новые технологии от устаревших,

К конкретно этому элементу UFS у меня особых претензий нет. А вот общая архаичность устройства дисковых структур и потому общая тормозливость дизайна - никуда не делась. Вот смотри: у меня десктоп подперт упсой. Ноут сам себе упс. Когда я видел в последний раз кернел паник - я и не помню даже. Несколько лет назад, очевидно. Т.е. в общем то крахов то как раз и не происходит. Неоткуда. Т.е. злободневность проблемы сильно снижена иными техническими мерами. А вот тормозливость файловой системы я могу видеть каждый день. Стоит ли говорить что при указанном раскладе я заинтересован еще и в скорости работы? Потому что надежность и так обеспечена. Не теми мерами так иными (роялит то в конце концов результат).

> а не скоростными режимами, которые нафик никому не впёрлись.

См. выше. Мне скоростные режимы вполне себе вперлись. Я не нанимался машины ждать. Пусть они меня ждут. Надежность - это хорошо. Еще 1 уровень страховки - тоже. Но если это приведет к 6мб/сек на шпиндель, мне такое решение и даром ни к чему. Т.к. меня не устраивают его параметры.

> Важна прежде всего надёжность, а скорость работы тюнится под конкретную задачу.

А кто сказал что у меня с надежностью проблемы? За последние несколько лет я вообще никаких данных не терял по вине ФС. В принципе. Я не спорю что чексуммы - хорошо. Мало ли, вдруг там фирмвара сдуреет или помеха на кабеле? Там конечно свои слои ECC/чексумм, но есть маленькая но ненулевая вероятность что и они облажаются. По поводу чего еще слой поверх - это в принципе хорошо. Равно как и недеструктивная запись aka возможность передумать и вернуть в вид как было. Ну вот в btrfs все это есть. При этом оно не настолько убер-тормоз как ZFS. Чем и лучше, собственно.