>Я понимаю под этим использование одного и того же носителя для записи
>метаданных обеспечения транзакций записи данных. Чем больше метаданных, обеспечивающих транзакционную целостность, записывается на флэш, тем быстрее идёт износ ячеек. А еще дважды два - четыре. А благородного дона не смущает что в принципе - объем данных сильно больше объема метаданных? И ведь (какое свинство) эти данные оказываются на носителе путем записи. Изнашивая флеш, да :). В классическом варианте журнала плохо то что запись производится два раза. В идеале - в журнал идут и данные и метаданные чтобы "или все или ничего" применилось и к данным и к метаданным. Но это ухайдакает скорость работы ФС ниже плинтуса за счет двойного набора операций с носителем. Обычно идут на компромисс, оставляя журналинг только метаданных а данные ... ну... вот так вот, да. Можно получить и полуперезаписанный файл в принципе.
Кстати по вашей логике - версионные файловые системы (всевозможные их виды) - ничем таким не отличаются от традиционного журнала? А что, метаданные логоподобные (или какие там у кого) структуры - на том же носителе как правило. Даже в специализированный флешовых файловых системах :).Зато классическая ФС с журналом на отдельном девайсе - это что, отличное решение для флеша? ИМХО - какая-то сильно левая классификация.
>В этом контексте, как писал Шварц в своём блоге,
Знаете, вот уж что-что а по опыту визитов на блоги саней - там был пиар. Которому лично я не довряю. Шварцу, знаете ли, продажи толкать надо. Поэтому надеяться на беспристрастность и честное изложение фактов в его лице - наивно.
>ZFS разрабатывалась с учётом как дороговизны флэш-памяти,
Если посмотреть правде в глаза, ZFS разрабатывалась тогда когда флеш никто еще всерьез юзать не собирался. А Шварц скорее всего толкнул красивый спич просто. Что маркетинговые фигуры - любят.
>так и с учётом ограниченного ресурса флэш-ячеек.
И в чем это выражается? В том что версионник сам по себе число записей снижает? :) Ну так btrfs тоже таким свойством обладает, как и любая иная версионная ФС.
>Именно поэтому ZFS для флэш весьма оптимальна,
Чтобы быть ВЕСЬМА оптимальным, надо выравнивать структуры ФС на нативные блоки флеша (erase-блоки и страницы). Чего ессно в ZFS нет. Да и в btrfs тоже. Да и вообще проблематично это для дисков, маскирующих флеш под якобы дисковый носитель с якобы 512-байтными секторами которые якобы можно записывать независимо. Оптимально можно работать с флешом если он напрямую доступен в виде как есть (чтобы можно было наложить геометрию структур на геометрию флеша предсказуемо и удачно). Но операционки ж это не понимают и их ФС для этого не создавали, посему дать прямой и-фейс к флешу производителям ссыкотно (кто ж такие купит?).
>в отличие от традиционных журналируемых файловых систем. А UFS2 с включенным
>механизмом Soft Updates — ещё лучше,
Еще лучще - это если структуры ФС и записи в них будут выровнены на блоки флеша. Чтобы минимизировать перезаписи и ускорить их. Но такое осиливают только для отдельных чипов флеша, для "дисков" с контроллером - сами понимаете, физикой флеша занимается контроллер и как там кому было бы удобно записывать - наружу толком не показывается. В итоге единственное что может сделать ФС - избегать протирания одного и того же места, поменьше записывать и оперировать крупными блоками. Ну и юзать команды discard-а блоков (хоть какой-то хинт контроллеру флешатины о том что ФС более не собирается юзать вон те блоки).
>так как метаданные транзакций практически целиком находятся в памяти
КО намекает: данных в ФС намного больше чем метаданных. Но, собссно, в случае версионников - все достаточно неплохо: идея работы версионника не так уж далека от идеи работы контроллера флеша и размазки записей (как вы думаете, с фига ли специализированные ФС для флеша - это нечто типа log structured как правило?).
>и обеспечивают консистентность ФС, переупорядочивая запросы на запись
>таким образом, чтобы соблюсти принцип правильной очерёдности следования
>блоков и подтверждения их записи.
Если честно - с учетом того что на "диске" на которые подойтдет сватаемая ФС обычно есть контроллер который в меру дури переколбасит то что вы ему дали в то что по его мнению правильно - да хрен бы его там знает как в итоге окажется оптимальнее. А ничего что логика контроллера может весьма и весьма меняться у разных производителей?
>Физический кэш диска, конечно, обманывает ожидания операционных систем
>от записи данных практически всегда
А источник статистики какой? Право, любопытно. А то по моим наблюдениям данный грабель вообще-то в реалистичных конфигах заборот.
>— особенно это касается журналирующих ФС (в том числе и по этому
>показателю они малоэффективны),
Они малоэффективны в основном потому что писать два раза данные (сперва в журнал, потом на диск) - смерти подобно: скорость записи упадет в 2 с фигом раза. Все остальное уже мелочи. Поэтому обычно журналят только метаданные а данные ... ну вы в курсе, да? :)
>а вот механизм CoW успешно противостоит неопрадавшимся "ожиданиям".
Механика CoW просто не гробит данные и не пишет по два раза. Поэтому если не удалось - да и хрен с ним, старые данные никто не трогал же. В итоге скорость записи - на уровне ФС без журнала (запись то - одна). В бтрфс кстати сие верно и для данных и для метаданных как я понимаю. А у саней ... гм, ZIL это по сути журнал. А уж не журналы ли вы только что обругали? Т.е. ваша ругань валидна и для ZFS? :)
