Btrfs — это замечательная файловая система, главными фишками которой являются легковесные снапшоты, реализуемые через Copy-On-Write (COW), и сжатие. Она показала высокую надежность и стабильность, и именно поэтому она включена в ядро Linux. Однако, даже наличие COW не позволяет избежать избыточности данных на уровне блоков.
Как возникает дублирование данных?
Дубликаты данных могут существовать, даже если не используются снапшоты
Типичная ситуация:
Когда вы обновляете пакет и создаете снимок файловой системы, фиксируется текущее состояние данных. Затем, если вы снова скачиваете обновление, оно может содержать почти те же самые данные, как предыдущее, с небольшими изменениями. Механизм Copy-On-Write отслеживает изменение файлов, помогая избежать дублирования блоков данных. Но простое переименование файла или его перемещение в другое место при обновлении (установка по другому пути) ломают этот механизм: и уже появляются одинаковые блоки с данными. С каждым новым обновлением и снимком количество таких одинаковых данных увеличивается. Эти дубликаты занимают место на диске, пока вы не удалите старые снимки, либо не выполните дедупликацию.
Дедупликация
Дедупликация — это процесс нахождения дубликатов данных и их удаления.
Существует два основных типа дедупликации:
- In-band (онлайн) — когда данные перед записью проверяются на существование дубликатов. Такой метод требует значительных вычислительных ресурсов и памяти.
- Out-of-band (офлайн) — дедупликация происходит после записи и является менее затратной по ресурсам.
Btrfs, в отличие от ZFS, реализует только офлайн-дедупликацию.
Сам Btrfs (обычно пакет btrfs-progs) не имеет встроенных утилит для дедупликации, но предоставляет все необходимые средства для ее реализации сторонними утилитами.
Дедупликация бывает на уровне файлов и на уровне блоков. Чтобы найти и удалить одинаковые файлы, вы, конечно, можете использовать duperemove. Но у него применение довольно специфическое, что делает его практически бесполезным для наших целей, тем более cp в Btrfs не приводит к реальному копированию данных (копии файлов ничего не весят). Строго говоря, Btrfs работает не с файлами, а с блоками данных (экстентами), поэтому и дедупликацию в ней нужно проводить на этом уровне. Для этих целей и существует bees.
Bees — блочный дедупликатор
BEES — это не пчелы, а аббревиатура от Best-Effort Extent-Same. Эту идиому можно перевести как науличший достижимый одинаковый диапазон. Звучит бредово, если не знать, что экстенты-диапазоны — это просто блоки данных. Данная утилита проверяет чексумы этих блоков, которые иногда называют хешами, если она находит совпадение, то копия блока заменяется на ссылку на него.
Установка:
yay -S bees
Для начала нужно узнать UUID корневой файловой системы:
$ sudo btrfs fi show /
Label: none uuid: 83ba9a0a-7858-48f0-b679-618954059b1a
Total devices 2 FS bytes used 153.13GiB
devid 2 size 449.98GiB used 223.03GiB path /dev/mapper/root1
devid 3 size 449.98GiB used 223.03GiB path /dev/mapper/root2
Затем создайте конфигурационный файл для bees, например, /etc/bees/root.conf.
Укажите в нем UUID:
UUID=83ba9a0a-7858-48f0-b679-618954059b1a
Задайте размер базы экстентов:
DB_SIZE=$((256*1024*1024)) # 256MiB в байтах
Рекомендованный размер базы экстентов («хеш-таблицы») приведен в документации:
unique data size | hash table size |average dedupe extent size
1TB | 4GB | 4K
1TB | 1GB | 16K
1TB | 256MB | 64K
1TB | 128MB | 128K <- рекомендуется
1TB | 16MB | 1024K
64TB | 1GB | 1024K
Эта таблица показывает рекомендованные размеры для различных объемов уникальных данных. База хешей экстентов полностью грузится в оперативную память и периодически сбрасывается на диск, так что можно сказать, что вы тут указываете сколько вам не жалко выделить оперативной памяти для дедупликации. 128K — это стандартный размер экстента, но учтите, что это не постоянная величина. Чтобы не ошибиться, можно просто задать размер хеш-таблицы в 1 GB, если, конечно, количество RAM позволяет.
Для вывода только предупреждений и ошибок при работе beesd добавьте в конфиг:
OPTIONS="-P -v 6"
Проверьте перед этим файловую систему на ошибки и обязательно исправьте их перед запуском
Запуск дедупликации вручную:
sudo beesd 83ba9a0a-7858-48f0-b679-618954059b1a
Не ждите окончания процесса дедупликации. Он будет продолжаться бесконечно и в начале будет очень сильно грузить процессор.
В Arch вместе с пакетом идет systemd-юнит. Если хотите чтобы сервис запускался автоматически при старте системы выполните:
sudo systemctl enable --now beesd@83ba9a0a-7858-48f0-b679-618954059b1a
Проверка статуса дедупликации:
cat /run/bees/83ba9a0a-7858-48f0-b679-618954059b1a.status
Плюсы и минусы блочной дедупликации
Дедупликация позволяет значительно экономить место. Запуск beesd гарантированно увеличит свободное место на разделе и уменьшит занятое на 25-30%. Но она требует памяти и CPU. На очень слабых машинах это может быть критичным.
Самая идиотская затея — запустить дедупликацию на поврежденной файловой системе, особенно если повреждения вызваны битой памятью. Это почти гарантированно приведёт к безвозвратной потере данных!
Ссылки
- Страница проекта (поставьте репе звезду хоть, я поставил)
- Btrfs/Deduplication/Bees
