>Какая сборка мусора, ты о чем? Слияние снапшотов и подобные по смыслу операции для расчистки тома, которые придется делать чтобы освободить место на нем. Собственно CoW логика кроме плюсов имеет и минусы - если что-то пишется в сторонку, это во первых вызывает усиление фрагментации а во вторых добавляет новые данные. И если ничего по этому поводу не делать - место то не резиновое, бесконечно дописывать в сторонку - не выйдет. Если честно - я не очень сильно изучал как ZFS разруливает подобные ситуации (в манах это как-то мало упоминается) и вы в своем вправе вправить мне мозг. Единственное что я понял из манов - что в ZFS по сути не делается каких-то специальных потуг дефрага при подобных операциях.
>> И фрагментация взлетит до небес, при том сильнее чем на классической ФС по идее.
>Все носятся с этой фрагментацией как с писаной торбой.
Дык я не виноват что фрагментированый доступ убивает скорость доступа на механических дисках в уйму раз, как и стопицот лет назад.
>Безусловно, последовательное чтение объекта, состоящего из блоков маленького размера, >которые расположены случайным образом, будет страдать, если нет никаких других
>механизмов с этим бороться. Но далеко не все задачи в современном IT мире
>сводятся к последовательному чтению.
Знаете как про это говорят? :) "С пола упасть нельзя!" :).Действительно, если ФС уже и так в полной ж... - хуже ей уже не будет, как ни извращайся :)
>более того, он может оказаться выигрышнее, нежели их строго последовательное
>расположение.
Скорее, я сделаю ставку на "монопенисуально". Рандом доступ на то и рандом. Если это не так - значит это уже не рандом.
>Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово
>- кэширование. Знакомо?
Знакомо. Но при современных объемах дисков более-менее полно их закешировать нереально. А так то ессно да, можно быстро выдавить в кеш а там пусть себе ФС хоть час педалит. Только палка о двух концах. Куча данных в оперативке имеет свойство теряться при сбоях + это не заслуга файловой системы, а заслуга кеша, как ни крути.
>Дефрагментация имеет смысл на не-CoW системах.
Да и на CoW имеет смысл. Тем более что логично накладывается на процедуру слияния-удалния снапшотов и т.п. - почему бы при слиянии заодно и блоки попоследовательнее не выстроить до кучи? Вполне логичное решение ведь.
>Для систем, построенных на CoW, смысла гораздо меньше
ИМХО это сильно зависит от того как используется ФС. В упомянутом случае (торент) это имеет стопроцентный смысл. Потому что торент сам по себе то срач блоками разводит, CoW ему еще подыграет а из-за засранного на 90% тома без больших свободных линейных кусков вообще получится полный крантец. А вот если этот мяумикс отдефрагить - так как бы скачанные файлы никто и не модифицирует особо, например...
>- потому как CoW будет тут же эффект от дефрагментации нивелировать.
Только в случае интенсивной дозаписи. И как бы далеко не любой файл в ФС подвергается постоянной интенсивной записи. Посему оно будет нивелировано только для постоянно записываемых файлов которые и на обычной то ФС засираются. К слову на обычной ФС они засираются несколько меньше, т.к. ФС может переписат блок прямо в файле, оставив доступ последовательным, а в CoW логике так уже не катит.
>Тем не менее, смысл есть - имеет смысл дефрагментировать
>свободное пространство и неизменяемые данные (снимки).
Кроме того - а некоторые файлы вообще мало или редко меняются. Упомянутое вами валидно если файл меняется часто и много. Только при этом CoW неплохой срач разведет. Да, запись будет быстрой, но это будет иметь свои минусы. Не бывает халявы нахаляву :)
>Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы
>с эффектами от фрагментации.
Угу, конечно. Если все хранить в RAMдиске, доступ к ним будет моментальным. Только это не достоинство ФС ни разу, и без гигантских дисковых буфферов все это будет крайне уныло тормозить. Уж не потому ли ZFS и требует вагон памяти для нормальной работы? :)
