25.06.2017 01:06, Sergey Matveev пишет: > *** artiom <artio...@yandex.ru> [2017-06-25 00:54]: >> Вы хотите сказать, что она жрёт 20% места под метаданные?! >> Или что она просто начинает сильно фрагментироваться, при заполнении? > > Из-за её copy-on-write природы она начинает сильно фрагментироваться, > верно. Любое изменение данных это создание полной копии и блока данных и > сопутствующей метаинформации. Само собой перед записью они агрегируются, > но всё-равно при записи большого файла на диск он никогда не будет > размещён последовательно: каждые 1-5 секунд ZFS делает checkpoint-ы -- > то есть на диске идут сколько-то блоков данных файла, потом всякая > метаинформация, снова блоки, потом метаинформация. Причём каждый набор > метаинформации создаваемый в последующих 1-5 секунд делает неактуальным > предыдущую. То есть она потенциально становится свободным местом. > Например *X*FS реально абсолютно последовательно может разместить файл > на диске Потому и фрагментация низкая: я с 11-го года комп не дефрагментировал, посмотрел e4defrag-ом, меньше двух процентов.
> а ZFS нет -- поэтому и нужно много памяти под кэш чтобы > сгладить всё это, не создавая огромный IO на диск. > Так всё-таки RAM или дисковое пространство свободное больше требуется? > Но вот зато при неправильной конфигурации 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-а на диски, при котором на них будет > дефрагментированный образ создан. Условно: mv всего на другой раздел? > Можно сделать полный zfs send и > восстановление ФС zfs recv-ом, но это потребует остановки ФС, что не > всегда допустимо и возможно. Есть хаки в виде просто копирования файла: > cp file file.tmp && mv file.tmp file, чтобы сделать его > дефрагментированным, если, например, он был медленно записан (то бишь, > из-за частых checkpoint-ов, сильно разряжён). Где-то на форумах они > говорят что создание online дефрагментации это жутко нетривиальная вещь, > требующая чуть ли не переписывания всего кода, ибо везде всё одна > крипта, деревья Меркле, checkoint, итд, итд -- сложно это сделать так, > чтобы гарантировать "железную" надёжность и поэтому не будут делать. > А нет a-la e4defrag?
