*** artiom <artio...@yandex.ru> [2017-06-25 00:54]: >Вы хотите сказать, что она жрёт 20% места под метаданные?! >Или что она просто начинает сильно фрагментироваться, при заполнении?
Из-за её copy-on-write природы она начинает сильно фрагментироваться, верно. Любое изменение данных это создание полной копии и блока данных и сопутствующей метаинформации. Само собой перед записью они агрегируются, но всё-равно при записи большого файла на диск он никогда не будет размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы -- то есть на диске идут сколько-то блоков данных файла, потом всякая метаинформация, снова блоки, потом метаинформация. Причём каждый набор метаинформации создаваемый в последующих 1-5 секунд делает неактуальным предыдущую. То есть она потенциально становится свободным местом. Например *X*FS реально абсолютно последовательно может разместить файл на диске, а ZFS нет -- поэтому и нужно много памяти под кэш чтобы сгладить всё это, не создавая огромный IO на диск. Но вот зато при неправильной конфигурации RAIDZ, в которой выбрать определённое количество дисков и определённый размер блока (recordsize), то можно, фактически, просто так потерять 50% места буквально в пустую. Вот тут есть тема про это: https://www.delphix.com/blog/delphix-engineering/zfs-raidz-stripe-width-or-how-i-learned-stop-worrying-and-love-raidz RAIDZ сделан так, что добавляет чётность, но кол-во получившихся блоков для данных+parity должны быть кратны чему-то там и поэтому там будет создан блок чисто для padding-а, для выравнивания некоего, не несущего полезных данных. Статья эта подчёркивает что в RAIDZ на parity всё же будет больше затрачено места чем в аналогичных уровнях RAID, как правило. >Во втором случае, ведь должна быть онлайн дефрагментация... Вот это можно сказать и недостаток. Её нет. Есть хаки в виде resilvering-а, то бишь rebuild-а на диски, при котором на них будет дефрагментированный образ создан. Можно сделать полный zfs send и восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не всегда допустимо и возможно. Есть хаки в виде просто копирования файла: cp file file.tmp && mv file.tmp file, чтобы сделать его дефрагментированным, если, например, он был медленно записан (то бишь, из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они говорят что создание online дефрагментации это жутко нетривиальная вещь, требующая чуть ли не переписывания всего кода, ибо везде всё одна крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так, чтобы гарантировать "железную" надёжность и поэтому не будут делать. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF
