> Любой CoW при 50/50 r/w без немеряного кеша - слоупок, за счёт гиперфрагментации.

Хочу послушать научное обоснование столь громкого заявления. Ну насчет слоупока для любого дизайна CoW. Вообще, имхо наихучший режим будет если много мелких дозаписей. И кстати это плохо и для CoW и для обычных ФС - обе сгородят дикое количество фрагментов. Я так XFS положил до состояния когда файл в несколько Гб стирался на механическом диске секунд 30. Просто потому что дурно дозаписывался: сильно фрагментировался + метаданных вымахало много. Но это постараться надо еще, реально на такое наткнуться можно разве что качая огромный торрент без преаллокации.

> А у ZFS еще одна проблема есть на этой ниве - ARC
> никак не взаимодействует с системным кешем,

Некоторые моменты дизайна этого пепелаца от саней - за гранью моего понимания. В том плане "а нафига они это делали вот так?". Временами возникает ощущение что ответ - "я его слепила из того что было". Btrfs в этом плане более любопытен: автор дизайна смотрел на другие ФС и их сильные и слабые места + довольно удачно вылез перец предложивший модификацию b-деревьев.

> в итоге имеем двойное кеширование,

Учтя что оно и так в силу блочного аллокатора слоупок - ну да, весело.

> ФС по возможности читают и отдают приложению данные вообще в zero-copy
> режиме, тупым маппингом страниц. И пишут в кеш в ряде случаев так же.

Справедливости ради, обычно файловая система в диск упирается все-таки. Копирование страниц - ничто по сравнению с двиганием голов накопителя. Хотя на скоростных SSD это уже станет актуальнее. Зато там иной mindf..k в плане тормознутой записи и невозможностью настоящего рандомного доступа мелкими блоками на запись, очень желательности делать trim и прочая.

>> Сильно зависит от - там запись однократная: пишется только то что изменено.
> Ничего не зависит. Взяли файл размером в гиг. Переписали метр в середину
> (БД, к примеру). На традиционных FS блок встанет ровно туда, куда надо.

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

> А на CoW - вылететь может и в другую половину
> диска, и при последовательном чтении файла потом всегда будет весело.

Вот только странный какой-то ворклоад получается, когда запись мелкими кусочками а чтение огромным блоком. Ну то-есть, теоретически - ничему не противоречит. Практически - можно какую угодно ФС сильно просадить, если специально озаботиться. Но зачем?

>> Тогда как журналирующая ФС сделает 2 записи - сначала в журнал,
>> а потом коммит того что в журнале на диск.
> Данные в традиционных FS обычно не журналируются - незачем.

Ага, а если на середине записи вдруг случится факап, у нас получится наполовину старый и наполовину новый файл. Проблема только в том что хотя сама ФС на уровне метаданных логически корректна - метаданные описывают какой-то файл, внутренняя структура этого файла окажется повреждена и будет содержать некорректные данные. Просто потому что не было данных ни чтобы довести запись до конца, ни чтобы откатить в вид как было. Поэтому - будет то что получилось. Не обязательно юзабельное вообще. СУБД такое лечат делая свою отдельную журнальную подсистему, раз уж ФС убогая и так не может, там данные для доведения транзакции до финиша или отката прихраниваются в журнал БД. Что опять же тормозит нещадно из-за двукратной записи. Хотя БД-версионники тоже бывают. Как раз чтобы два раза не писать. По сути, СУБД дореализовывает за недоношенными ФС кучу того что по уму должно было бы быть их обязанностью. Все-равно 90% этой механики в ФС уже есть, мля.

> Если вдруг, и журнал начинает напрягать - его выносят на отдельный мелкий носитель (SSD).

...и меняют их штабелями. При интенсивной записи мелкими блоками с синхронизацией, столь характерной для журнала БД - особенно, т.к. SSD вообще не умеет на запись мелкими блоками работать (типичный erase block NAND нынче 512Кбайт). Особенно если TRIM нет, так что контроллер wear leveling'а постепенно сваливается в режим "т.к. неизвестно занят ли блок, будем решать проблемы по мере их возникновения" (в терминах CoW ФС это как если бы GC ждал момента когда том забьется до отказа и только потом начинал бы чистить, успокаиваясь как только немного разгребли).

>> Не скажите. Один из основных козырей - технология имеет потенциал делать запись
>> на диск со скоростью нежурналинуемой ФС
> И потом иметь грабли при чтении размазанного ровным слоем по диску файла.

А вот это зависит от того как именно запись делалась. При ряде ворклоадов будет лучше, при ряде - хуже. Разным дизайнам - разные свойства. Это нормально. Кстати если уж на то пошло, честное журналирование данных+метаданных (эквивалентное тому что делает CoW) в классике вообще тормозное как трындец. По поводу чего им никто и не пользуется почти. А если не журналить честно - так вон в btrfs тоже CoW можно выключить, например. Смысл этого деяния оставим на совести того кто его производит. Но можно же! Как раз примерно то же самое по смыслу и получим. Как раз фрагментация от CoW и отпадет. Ну, как тормоза от журналирования в классике. Улавливаете некую симметрию? Нежурналирующую ФС надо сравнивать с нежурналирующей. Или уж журналирующую с журналирующей. Чудес не бывает ;)

> А если исключить перезапись - т.е. писать файлы, и не менять
> - имеем как раз read-mostly паттерн.

А если исключить полный журналинг данных - имеем ФС не способную честно откатить транзакцию или докатить ее до финиша, по поводу чего она хоть и будет логически корректна (не надо запускать fsck, который будет неделю жевать большой том) но файл на котором оборвалась запись вполне может быть порушен. Т.е. собственно честного журналинга по приинципу "все или ничего" и не обеспечивается как раз. Есть компромисс. В CoW - никаких компромиссов, все можно вернуть в вид как было до факапа в любой момент. Фрагмент или успевает дописаться и мы получаем новое состояние, или не успевает и остается старое. А так чтобы полфайла старое а полфайла новое - не будет. На классике это возможно только при полном журналинге данных. Тормознутом чтопипец из-за двойной записи данных в журнал и на диск. Неизбежном, т.к. иначе нельзя гарантровать транзакционность вида "все или ничего".

> Вся эта идея CoW FS не нова. Я подобные алгоритмы видел еще в веарлевелерах
> на самсунговских флешах, допустим, в SGH-X100, лет шесть-семь тому назад.

Верно подмечено: wear leveling по сути чем-то таким и является.

> Их чуть-чуть проапгрейдить, и получится CoW FS. Для флеша -
> да, круто, там как раз то самое размазывание и интересно.

Ну да. Правда без trim этой логике постепенно становится душно. По поводу чего trim в современных флешах и придумали, как я понимаю. И кстати на такой накопитель CoW ФС опять же лучше наложится чем полный журналинг: потенциально в 2 раза меньше записи на накопитель при полном журналировании, так что внутренней логике придется в 2 раза меньше записей разгребать.

> Для механических дисков - грабельки.

Так честный журнал в классике тоже грабельки, знаете ли. А нечестный как-то с CoW и сравнивать не больно честно. Ну вон отрубите в btrfs cow - получите нечто наподобие. Если уж сравнивать нежурналы и недожурналы - так пусть и у бтрфс будет не полный журналинг, чтоли. А то как-то нечестно когда некто полностью журналит, а его ставят в один ряд с нежурналирующими или недожурналирующими.