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

Ранее занятое место освобождается, если на него более никто не ссылается. Место, на которое ссылаются снимки, освобождается тогда, когда удаляются снимки. Не думаю, что где-то принципиально по-другому

> Единственное что я понял из манов - что в
>ZFS по сути не делается каких-то специальных потуг дефрага при подобных
>операциях.

А в BTRFS делаются? Ссылочку можно?

>>Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово
>>- кэширование. Знакомо?
>
>Знакомо. Но при современных объемах дисков более-менее полно их закешировать нереально.

Хорошо что знакомо. Следующий вопрос. Что такое "рабочий набор" представляешь?

Никто в здравом уме не будет кэшировать диски целиком. Нужно закэшировать рабочий набор, который, как правило, бывает на порядок-другой меньше по размеру, чем все данные приложения.

>А так то ессно да, можно быстро выдавить в кеш а там пусть себе ФС хоть час педалит. Только палка о двух концах. Куча данных в оперативке имеет свойство теряться при сбоях + это не заслуга файловой системы, а заслуга кеша, как ни крути.

В случае классической ФС, жестко завязанной на кэш VM - да. Следующий вопрос - что такое ARC, L2ARC и как они связаны и зачем они нужны, понимаешь?

>>Дефрагментация имеет смысл на не-CoW системах.
>
>Да и на CoW имеет смысл.

О чем я и говорил чуть дальше.

> Тем более что логично накладывается на
>процедуру слияния-удалния снапшотов и т.п. - почему бы при слиянии заодно
>и блоки попоследовательнее не выстроить до кучи? Вполне логичное решение ведь.

А поподробнее? Чтобы всем была понятна твоя логика.

>Только в случае интенсивной дозаписи.

А говоря CoW, мы ведь имеем ввиду запись, не так ли?

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

Естественно, для немодифицируемых файлов это тоже имеет смысл, но я бы сказал что в третью очередь, после свободного пространства и неизменяемых данных. И кстати, большинство их этих малоизменяемых файлов наверняка будут целиком в каком-нибудь снимке, так что на них тоже снизойдет благодать в виде живительной дефрагментации

>>Тем не менее, смысл есть - имеет смысл дефрагментировать
>>свободное пространство и неизменяемые данные (снимки).
>
>Кроме того - а некоторые файлы вообще мало или редко меняются. Упомянутое
>вами валидно если файл меняется часто и  много. Только при
>этом CoW неплохой срач разведет. Да, запись будет быстрой, но это
>будет иметь свои минусы. Не бывает халявы нахаляву :)

Чтение можно сделать не менее быстрым, используя L2ARC. Но в классических ФС ничего подобного нету, впрочем, и в BTRFS тоже пока не наблюдается.

>>Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы
>>с эффектами от фрагментации.
>
>Угу, конечно. Если все хранить в RAMдиске, доступ к ним будет моментальным.

Боюсь, мошна не выдержит все хранить в рамдиске, так как много памяти и слотов для нее - удовольствие не из дешевых.

>Только это не достоинство ФС ни разу, и без гигантских дисковых
>буфферов все это будет крайне уныло тормозить. Уж не потому ли
>ZFS и требует вагон памяти для нормальной работы? :)

Ну-ну. Там, где ты со своим рамдиском упрешься в ограничения количества и емкости модулей памяти платформы, ZFS позволит запихнуть парочку емких SSD для L2ARC. Ты будешь и дальше утверждать, что это не достоинство ФС?