>>Я задавал этот вопрос на Sun Tech Days 2008 архитектору ZFS. Он
>>ответил буквально следующее:
>>-- Ввиду специфики работы Copy-on-Write аллокатор будет тормозить _всегда_ при малом
>>остатке выделяемого пространства --
>
>В чем-то он тут прав - для CoW механики это и правда
>неудобная ситуация, придется часто дергаться на сборку мусора чтобы вообще хоть
>что-то смочь записать.Какая сборка мусора, ты о чем?
> И фрагментация взлетит до небес, при том сильнее чем на классической ФС по идее.
Все носятся с этой фрагментацией как с писаной торбой. Безусловно, последовательное чтение объекта, состоящего из блоков маленького размера, которые расположены случайным образом, будет страдать, если нет никаких других механизмов с этим бороться. Но далеко не все задачи в современном IT мире сводятся к последовательному чтению. Если же чтение случайное - то случайный разброс блоков вообще пофиг, более того, он может оказаться выигрышнее, нежели их строго последовательное расположение.
Плюс с эффектами оной можно бороться не только дефрагментацией. Есть такое слово - кэширование. Знакомо?
> Вот только ... делая сборку мусора логично сделать до кучи некую дефрагментацию, оно прямо напрашивается, блин.
Дефрагментация имеет смысл на не-CoW системах. Для систем, построенных на CoW, смысла гораздо меньше - потому как CoW будет тут же эффект от дефрагментации нивелировать. Тем не менее, смысл есть - имеет смысл дефрагментировать свободное пространство и неизменяемые данные (снимки).
Специально для тебя повторяю еще раз: дефрагментация - не единственный способ борьбы с эффектами от фрагментации.
