Btrfs такая хитрая штука, что место есть, а операции записи легко могут вернуть ошибку. Жаль нет исходных данных для тестирования...
Я недавно диск 2 тб с данными 1 тб сконвертировал в btrfs и он уменьшался только до 1.5 тб, пока я не вырубил дублирование метаданных. Balance и прочая запись писали нет места, а в usage было свободно минимум 170 гб.
Очень странные результаты для btrfs, скорее всего не хватило свободного места на диске и дедупликация отвалилась. Некоторые соображения:
Дедупликация в bees всегда происходит одновременно со сжатием и по умолчанию это тормознутый zlib, поэтому и проц жрёт, compress=lzo опция монтирования в помощь
Чтение маленькими блоками, я бы блоками меньше 4к не читал никогда, ибо размер страницы памяти. А еще с маленькими блоками больше перевыделений памяти при сложении.
Btrfs такая хитрая штука, что место есть, а операции записи легко могут вернуть ошибку. Жаль нет исходных данных для тестирования...
Я недавно диск 2 тб с данными 1 тб сконвертировал в btrfs и он уменьшался только до 1.5 тб, пока я не вырубил дублирование метаданных. Balance и прочая запись писали нет места, а в usage было свободно минимум 170 гб.
Очень странные результаты для btrfs, скорее всего не хватило свободного места на диске и дедупликация отвалилась. Некоторые соображения:
Дедупликация в bees всегда происходит одновременно со сжатием и по умолчанию это тормознутый zlib, поэтому и проц жрёт, compress=lzo опция монтирования в помощь
В комплекте с bees уже есть systemd unit
Можно также попробовать duperemove + xfs