ZFS: повторно сжать существующие файлы после изменения алгоритма сжатия


14

У меня есть пул, который был создан в 2011 году с использованием lzjb compression, и только через пару лет обновление позволило мне установить сжатие lz4. По моим оценкам, по крайней мере 20% содержимого (по пространству) в массиве было создано до 2013 года, что означает, что он все еще сжат с использованием lzjb.

Я могу придумать пару вариантов, чтобы исправить это и восстановить (некоторое) пространство:

  1. Резервное копирование и восстановление в новый пул. Не очень практично, так как у меня недостаточно избыточного хранилища для хранения временной копии. Восстановление также потребует, чтобы пул был отключен в течение нескольких часов.

  2. Напишите сценарий для повторного копирования любого файла с отметкой времени старше 2013 года. Потенциально рискованно, особенно если он задыхается от пробелов или других специальных символов и в результате искажает оригинальное имя.

Есть ли какой-нибудь способ заставить ZFS повторно сжимать любые устаревшие блоки, используя текущий алгоритм сжатия? Вроде как скраб, но лечит компрессию.

Смежный вопрос: есть ли способ увидеть использование каждого типа алгоритма сжатия? zdb просто показывает общую статистику сжатия, а не разбивает ее на отдельные алгоритмы.


2
Я почти уверен, что вы назвали только два варианта. См. Также обсуждение в выпуске 3013 о том, почему эта функция не существует, и вы можете вообще не захотеть этого делать.
Майкл Хэмптон

2
Предполагается, что lz4 лучше всего сжимает на 10%, чем lzjb. Если 20% ваших данных будут сжаты на 10% лучше, вы получите максимум на 2% больше свободного места. Стоит ли оно того?
труба

1
Если вы пишете сценарий оболочки для выполнения копирования, добавьте export LC_ALL=Cв начало сценария, и все не-ASCII специальные символы в именах файлов останутся без изменений. Сохранение пробелов и тире нетронутыми сложнее, использовать двойные кавычки и --, например cp -- "$SOURCE" "$TARGET".
Очки

4
@pipe Space - одно (очень) небольшое преимущество, но меня больше интересует скорость декомпрессии. Из справочной страницы FreeBSD zpool-features: «Как правило, сжатие lz4 примерно на 50% быстрее для сжимаемых данных и на 200% быстрее для несжимаемых данных, чем lzjb. Кроме того, примерно на 80% быстрее для декомпрессии, при этом коэффициент сжатия примерно на 10% выше. "
rowan194

@pts Я бы не назвал соблюдение фундаментальных правил программирования оболочки (двойные кавычки вокруг переменных или использование --) "хитрее". Это так же важно, как избегать внедрения SQL, например.
glglgl

Ответы:


14

Вы должны заново скопировать данные (полностью или частично), или zfs отправит / получит данные в новый пул или файловую систему ZFS.

Других вариантов нет.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.