16.04.2013 12:55, Alexey Markov:
Hello, Alexander!
On April, 16 2013 at 13:23 you wrote to Alexey Markov:
??>> Собственно, сабж. Конкретнее: вот есть у меня текстовый файл
??>> размером в гигабайт, и 10 раз в секунду к нему дописывается
??>> ещё по 100 байт (открыли файл, дописали, закрыли). Какой объём
??>> будет подвергаться сжатию на ZFS - весь файл; индивидуальные
??>> кусочки по 100 байт; хвост файла, находящийся в последнем блоке?
AY> Cow подразумевает обновление только измененного блока плюс того
AY> блока где инфа о блоках. Это было бы логично :)
Дело в том, что у ZFS динамический размер блока, по-умолчанию - от
512 байт до 128 килобайт. Судя по доке, сжатие происходит только в
том случае, если сжатый кусок файла потом может уместиться в блоке
меньшего размера, чем раньше. И вот тут возникает проблема: если у
нас к файлу добавляются маленькие кусочки (как это обычно бывает с
логами), то очень скоро весь огромный файл будет представлять собой
последовательность сжатых блоков минимального размера. И выигрыш от
сжатия таких блоков тоже будет минимальный.
AFAIK текущий размер блока выбирается один раз при создании файла
согласно установкам текущей файловой системы. Об этом косвенно
свидетельствуют гайды по оптимизации баз данных (MySQL/PostgreSQL) в
которых чётко прописано что раздел с базой нужно пересоздать иначе вне
зависимости от размера транзакции ZFS будет читать и писать на диск
полные блоки.
Сжатие в ZFS поблоковое, те блоки которые уже были записаны на диск
меняться не будут, будет меняться только последний блок файла. В случае
со сжатием LZ4 получаем ~128/2 = ~56кб/сек на файл при максимальной
скорорсти сжатия 330Мб/сек на Core2Duo - где-то в районе тысячной процента.
--
Sphinx of black quartz, judge my vow.
