Я экспериментирую с использованием ZFS для дедупликации большой библиотеки файлов FLAC. Цель этого двоякая:
- Уменьшить использование хранилища
- Уменьшите пропускную способность, необходимую для синхронизации библиотеки с облачным хранилищем
Многие из этих файлов имеют одинаковые музыкальные треки, но с разных физических носителей. Это означает, что по большей части они одинаковы и обычно близки к одинаковому размеру, что заставляет меня думать, что они должны извлечь выгоду из дедупликации на уровне блоков.
Однако в моем тестировании я не вижу хороших результатов. Когда я создаю пул и добавляю три из этих треков (идентичные песни с разных носителей), zpool list сообщает о 1,00 дедупликации. Если я копирую все файлы (делаю точные дубликаты из трех), дедуплицирует подъемы, так что я знаю, что он включен и работает, но он не обнаруживает дублирования в исходной коллекции файлов.
Моей первой мыслью было, что, возможно, некоторые из переменных данных заголовка (теги метаданных и т.д.) Могут неправильно выравнивать объем данных в этих файлах (звуковые кадры), но даже делают данные заголовка согласованными для всех трех файлов, не ' Кажется, это никак не повлияет на дедупликацию.
Я рассматриваю возможность использования альтернативных маршрутов (тестирование других дедуплицируемых файловых систем, а также некоторый пользовательский код), но, поскольку мы уже используем ZFS и мне нравятся опции репликации ZFS, я бы предпочел использовать ZFS dedupe для этого проекта; но, возможно, он просто не способен хорошо работать с такими данными.
Будем благодарны за любые отзывы о настройке, которые могут улучшить производительность дедупликации для такого рода набора данных, или подтверждение того, что дедупликация ZFS не является подходящим инструментом для этой работы.