Молясь при этом чтобы не сдох основной...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

Всё замечательно и 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 на бэкап разделе и исходный начал писаться в основной раздел - вот место и закончилось.