> Это сделано обычно, как навесной механизм.Надо же, до вас стало доползать. Вот именно поэтому и логично если эта механика будет в ФС. Там она может работать лучше. "Дома и стены помогают".
> Единственная более-менее известная среда, умеющая
> действительно CoW FS - это Parallels Virtuozzo.
В виртуализаторах оно обычно делается на блочном уровне - уровне виртуального диска. Так универсальнее в том плане что виртуализатор вообще не знает какая там ФС у гуеста - ему наплевать. По поводу чего снапшоты в почти всех форматах виртуальных дисков - CoW.
> на обычных файлах. В качестве бэкбона используется GIT. Как только допилят
> BTRFS - начну использовать BTRFS, ибо зачем городить огород.
В принципе звучит разумно, но кто там лучше будет работать - это еще вопрос. Git исходно оптимизился под версионирование кучи текстовой мелочи в основном. А файловая система общего назначения должна приемлимо работать и так и сяк, поэтому критерии оптимизации более другие чем у git (мало психов будут хранить 50Гб файлы в git, а в файловой системе - запросто).
>> Во первых, если записи мало + есть дефрагер, это проблемой не будет.
> У ZFS есть дефрагер? (shocked!)
У btrfs есть. У zfs - нету. По поводу чего iZEN и будет теперь так и будет топырить пальцы с своими 6Мб/сек пока пул не разберет и пересоберет, ха-ха :)
>> Во вторых, это tradeoff.
> О чём и речь. И этот трейдоф на большинстве требовательных к диску
> ворклоадов приведет к граблям.
А вы что, статистику собирали по тому у кого какие ворклоады и кто и как на них себя ведет? Или как получено "большинство"? А то в целом - btrfs весьма прилично себя ведет на большинстве бенчей. Нет, у него есть слабые места, например скулайт: видимо двойная работа у тамошнего журнала совместно с CoW получается. Но на большинстве ворклоадов он не сильно проигрывает ext4 при не в пример более крутой фичности, полном журналировании, снапшотах и прочая.
> Исключение - места, где действительно светит (shines)
> дедупликация. Или ворклоады, нетребовательные к диску.
Как бы на уровне дизайна btrfs совершенно не обязан тормозить. В отличие от упырей из сана эти по крайней мере осилили экстентное распределение. По поводу чего оно обставляет ZFS примерно как ext4 обставляет ext3, по тем же самым причинам.
>> При интенсивной записи - с лихвой окупится
> Геммороем при чтении.
Зависит от того как и что читается и что и как писалось, ssd или hdd, etc. По поводу чего столь безаппеляционные заявки выглядят странно. У btrfs также есть дефрагер. В ZFS - ну да, дефрагера нету. Приветы изену :)
> А плюсы будут разве что если регулярно писать и удалять тысячи файлов объёмом
> в кластер (чтобы хоть как-то заметить разницу в скорости записи от метаданных).
С чего бы ради? По идее удобным случаем является длинная непрерывная запись, например. Если честно журналить все - на этой операции все просядет немеряно. А если честно не журналить - так при крахе данные в отличие от метаданных могут оказаться в промежуточном состоянии. Вот редактировал я допустим PNG, а на середине записи все фигакнулось. По поводу чего в обычной ФС если не журналить данные, можно получить полфайла новых и полфайла старых. И оно потом на середине обломается прочесть остальное.
