LINUX.ORG.RU
решено ФорумAdmin

zfs - Странная Математика.

 


0

2

Приветствую, о глубокоуважаемый олл!

Использую zfs и заметил что раздел с более высокой компрессией вмещает меньше данных.

Итак: Есть Диск с 2.66t разделом, zfs на этом разделе с упаковкой lz4.
Есть диск для бэкапа (rsync) с таким же разделом и упаковкой gzip-9
Давно начал синкать на него и всегда на нем после синка оставалось больше свободного пространства чем на lz4.
Однако после очередного синка место кончилось.

#zfs get all LZ4
LZ4 used 2,60T -
LZ4 available 13,3G -
LZ4 referenced 2,38T -
LZ4 compressratio 1.09x -

#zfs get all GZIP-9
GZIP-9 used 2,61T -
GZIP-9 available 0 -
GZIP-9 referenced 2,39T -
GZIP-9 compressratio 1.12x -

В итоге получается что компрессия у gzip-9 выше (да и процессора жрет гораздо больше) но эффективность ниже чем у lz4.

Вот такая математика. Придется удалять раздел и синкать заново с упаковкой lz4. Молясь при этом чтобы не сдох основной...

★★★

Последнее исправление: n0mad (всего исправлений: 1)

Ответ на: комментарий от smilessss

других бэкапов нет?
тогда ссзб

Ну где же еще набраться 3T винтов...
Пока пустил #zpool scrub
Посмотрю поменяется ли что то...

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)
Ответ на: комментарий от n0mad

Ну где же еще набраться 3T винтов...

Лей в облака, лей на сервера, которые специально припасены для этого случая, к которым есть отдельный канал на 1/10 gb

smilessss ★★★★★
()
Ответ на: комментарий от smilessss

Лей в облака, лей на сервера, которые специально припасены для этого случая, к которым есть отдельный канал на 1/10 gb

У меня дома ничего не припасено на 1/10gb. Лишь 2*3T/USB3

n0mad ★★★
() автор топика

Ну, наверное, дело в метаданных, которые хранятся на диске параллельно с полезной информацией — как известно, «плотность файла меньше единицы»... Ведь на раздел конечного размера влезает конечное количество пустых файлов, даром что у каждого размер ноль ;)

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Ну, наверное, дело в метаданных, которые хранятся на диске параллельно с полезной информацией — как известно, «плотность файла меньше единицы»...

Я тоже пришел к этому мнению. Почему и запостил сюда.
Такая вот математика. Большая компрессия меньше вмещает.

n0mad ★★★
() автор топика

Вот такая математика.

очевидно, данные несжимаемые.

Можно строго доказать, что чем лучше сжимает архиватор(обычные файлы, например тексты), тем _хуже_ он «сжимает» несжимаемое, например /dev/random.

Отключи вообще компрессию (впрочем, кто тебя знает, может у тебя завтра появятся сжимаемые данные, т.ч. надёжнее lz4).

emulek
()
Ответ на: комментарий от emulek

Как бы все нормальные ФС перед тем, как записывать на диск прозрачно сжатые данные, проверяют, уменьшился ли после сжатия их размер. То, что ты сказал, вряд ли релевантно.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

проверяют, уменьшился ли после сжатия их размер

Знаешь, какой самый быстрый способ проверки? Сжать блок, и сравнить размер с исходным. Но если ты его УЖЕ сжал, то какой смысл писать исходный, если сжатый почти не отличается? Быстрее будет жать всё потоком, без всяких проверок. Так и сжатие будет лучше, если оно есть. Если его нет, то разница будет меньше 0.5%, что не имеет значения.

Не, можно конечно проверить только первый блок, а потом гнать потоком, но где гарантия, что первый блок не жмётся, а дальше жмётся? Лучше поиметь много терабайт, чем потерять 0.5%.

Ну и да, всё ещё и от данных зависит, можно придумать множество видов данных, в которых архиватор X работает хуже Y, хотя общепринято считать наоборот. И да, разница в этом худшем случае тоже 0.5%, потому на неё все внимания не обращают.

Да, кстати, а что за данные-то?

emulek
()
Ответ на: комментарий от emulek

Знаешь, какой самый быстрый способ проверки? Сжать блок, и сравнить размер с исходным.

Так и происходит.

Но если ты его УЖЕ сжал, то какой смысл писать исходный, если сжатый почти не отличается?

Чтобы быстрее считывать.

Быстрее будет жать всё потоком, без всяких проверок.

ФС принципиально не может сжимать данные потоком, т. к. в этом случае она не сможет позволять random access к данным внутри файла. Поэтому данные перед сжатием всегда разбиваются на весьма маленькие куски (~64 KiB).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Another particular thing to note is that LZ4's performance on incompressible data is very high. It achieves this by incorporating an "early abort" mechanism which will trigger if LZ4 can't meet the expected minimum compression ratio (12.5% on ZFS). This feature is particularly useful to storage administrators who would like to use compression as an "enable and forget about it" feature. Enabling LZ4 across the board only uses compression where appropriate, while making sure that the algorithm won't work hard on incompressible data (e.g. multimedia) and reads don't incur a latency penalty due to transparent decompression.

Я так понимаю, что благодаря это фишке он избегает сжатия несжимаемых данных и связанных с этим накладных расходов в виде метаданных и т.п. Это только мои мысли, могу ошибаться.

blind_oracle ★★★★★
()
Ответ на: комментарий от intelfx

видимо какая-то особенность zfs, тут я не компетентен.

но почему ты так озабочен потерями в 0.5% ? Возможно разрабы пошли на это потому, что в противном случае потери были-бы намного серьёзнее?

emulek
()
Ответ на: комментарий от emulek

Я не озабочен. Я вообще мимопроходил. У меня reiser4 и её реализацией прозрачного сжатия я в целом доволен (хотя там внутри — адъ).

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

ну я тоже мимокрокодил, я лишь заметил, что меньшее сжатие более «лучшего» архиватора на некоторых(весьма частых) наборах данных — давно известный и объяснимый факт. И это фундаментальная проблема, всякие оптимизации вроде «тут сжимаем, тут не сжимаем» ничего не меняют качественно, а только количественно (причём всегда в худшую сторону).

ЗЫЖ кстати я вообще считаю, что сжатие в ФС — не нужно.

emulek
()

LZ4 создан для юзер-спейс приложений, которые сжимают большие объемы данных. Для файловых систем, которые сжимают независимо маленькие логические кусочки файла он не подходит - lzo и gzip тут работают лучше.

anonymous
()

Дело было не в бобине...

Всё замечательно и gzip-9 жмет лучше lz4

NAS3T-pub 2,4T 2,4T 74G 97% /opt/pub
NAS3T-pub/Sound 303G 229G 74G 76% /opt/pub/Sound
BAR3T-pub 2,4T 2,3T 119G 96% /opt/pub.BKP
BAR3T-pub/Sound 347G 229G 119G 66% /opt/pub.BKP/Sound

119G свободных вместо 74G (+45G), просто отвалился /Sound на бэкап разделе и исходный начал писаться в основной раздел - вот место и закончилось.

n0mad ★★★
() автор топика
Последнее исправление: n0mad (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.