Bees — a btrfs deduplicator daemon

Там хардлинками не обойдешься, не войдет.

То есть ты хочешь сказать, что там есть файлы, которые совпадают частично? Учитывая, что пакеты в репозиториях в подавляющем большинстве случаев сжатые, что-то не сходится.

Повторный проход блочного дедупликатора.

А ты точно понял, о какой ситуации я говорил в первом комментарии треда?

Онлайн дедупликация слишком много памяти хочет. Имхо оффлайн подход (да ещё и инкрементальный) как в сабже - это самый правильный подход.

сжатие и на F2FS есть

В код мне вникать лень, но судя информации в интернете и моим экспериментам, сжатие файлов в F2FS не освобождает место. При записи гигабайта нулей на ФС с включенным сжатием свободного места станет на гигабайт меньше, как и при записи на ФС без сжатия. Реально на накопитель запишется намного меньше, ведь нули хорошо сжимаются. Только вот пользователю от этого видимой пользы нет.

Проще считать, что в F2FS сжатия нет.

То есть ты хочешь сказать, что там есть файлы, которые совпадают частично? Учитывая, что пакеты в репозиториях в подавляющем большинстве случаев сжатые, что-то не сходится.

Я сам удивлён, но точно говорю, что между rpm-ками даже разных мажорных версий RHELа есть что подедуплицировать, большими многомегабайтными кусками.

А ты точно понял, о какой ситуации я говорил в первом комментарии треда?

Да вроде да, неэкономное рванье экстента при записи в середину. Неприятно, но жить можно, если дедуплицируешь и сам, а не только снапшотами балуешься. И тут как раз въезжает сабж на белом коне.

Да вроде да, неэкономное рванье экстента при записи в середину. Неприятно, но жить можно, если дедуплицируешь и сам

Ну ок, понял правильно. А дедупликация-то тут при чём? Дедуплицировать нечего, ситуация возникает, даже когда есть ровно один файл, просто его «плотность» меньше единицы.

И тут как раз въезжает сабж на белом коне.

Тут нужен «анти-дедупликатор», который ищет не полностью зареференсенные экстенты, копирует их по кускам в новые экстенты и через FIDEDUPERANGE атомарно заменяет одно на другое.

Не, неправильно понял все-таки.

Если у тебя CoW незадействован и больше нигде первый экстент не использовался, то теперь, получается, ты хочешь autodefrag? Или опять я не догоняю?

1. write(foo, 0, "AAAAAA", 6)

extent1: AAAAAA
foo:     AAAAAA (foo=extent1[0:6])

2. write(foo, 2, "BB", 2)

extent1: AAAAAA
extent2:   BB  
foo:     AABBAA (foo=extent1[0:2] + extent2[0:2] + extent1[4:6])

3. magic_extent_split(foo)

extent1: AA
extent2:   BB
extent3:     AA
foo:     AABBAA (foo=extent1[0:2] + extent2[0:2] + extent3[0:2])

Сейчас в btrfs происходит (1) и (2). Было бы неплохо после (2) делать (3).

bees is a block-oriented userspace deduplication agent designed for large btrfs filesystems

Их (утилит-дедупликаторов) уже штук пять написали, поэтому не особо это и новость. Есть дефрагментатор, который умеет и btrfs, и xfs.

Снапшоты в btrfs и так дедуплицированы по определению.

При создании снапшота, модифицируются только метаданные. Данные остаются на своих местах на диске. Автоматическая дедупликация данных при создании снапшота – это был бы идиотизм, и такой снапшот создавался бы часами, а то и днями.

Наоборот, при необходимости имеет смысл вручную запускать дедупликацию данных перед созданием снапшота.

Их не нужно дедуплицировать отдельным демоном.

Не «не нужно», а невозможно. По крайней мере так было несколько лет назад. Снапшот в RO, двигать его экстенты нельзя.

А почему она не имеет смысла в случае с кучей похожих виртуалок/контейнеров, например?

Конечно она имеет смысл, и люди активно используют эту возможность. Ну, например, у Red Hat даже специальный out-of-tree драйвер VDO для этого есть (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/storage_administration_guide/vdo-integration)

1.write(foo, 0, «AAAAAA», 6) 2.write(foo, 2, «BB», 2)

Чо? Реально думаешь, что btrfs создает новый экстент при перезаписи существующего?

Было бы неплохо после (2) делать (3).

И как это сделать на CoW? Extent1 может использоваться другим файлом, в том числе и в каком-то снимке. Теоретически можно хранить в экстенте список всех мест, где он используется, чтобы потом можно было везде обновлять. Но тогда запись в файл превратится в неимоверную жесть с лавиной обновления метаданных.

btrfs создает новый экстент при перезаписи существующего?

Да. И проверить легко. Создай ФС на гигабайт, запиши 100 мегабайт данных. У меня на весь файл получился один экстент. Потом записывай куски по 50 мегабайт в этот же файл, со смещением в 25, 24, 23 и так далее. После каждой записи делай sync. Через некоторое время место на ФС кончится, хотя там всего один файл на сто мегабайт.

Делаешь btrfs fi defrag /path/to/file, и свободное место снова доступно.

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

Эээ… ну ты ведь в курсе, что extent backreferences уже есть?

Без них было бы очень сложно, например, делать balance или ресайз вниз.

При создании снапшота, модифицируются только метаданные. Данные остаются на своих местах на диске. Автоматическая дедупликация данных при создании снапшота – это был бы идиотизм, и такой снапшот создавался бы часами, а то и днями.

И зачем ты мне это рассказываешь? Думаешь, я не знаю?

Не «не нужно», а невозможно. По крайней мере так было несколько лет назад. Снапшот в RO, двигать его экстенты нельзя.

Вылезай из танка. Какие-то ограниченные манипуляции (собственно, BTRFS_IOC_FILE_EXTENT_SAME) над файлами в снапшоте вполне возможны, даже если он RO.

Делаешь btrfs fi defrag /path/to/file, и свободное место снова доступно.

мдаа, в проде на несколько Тб не дело fi defrag запускать. тем более, часто

Создай ФС на гигабайт, запиши 100 мегабайт данных.

У меня nodatacow маунт опция стоит, она это поведение отменяет. На голой btrfs и вправду такое происходит, но размер используемых данных не растет, и место не заканчивается.

#!/bin/bash
rm file.img
truncate -s 1G file.img
losetup /dev/loop0 file.img || exit 0
mkfs.btrfs /dev/loop0 || exit 0
mkdir mnt || exit 0
mount /dev/loop0 mnt
dd if=/dev/urandom of=mnt/test.file bs=1M count=100 oflag=direct
sync
filefrag -e mnt/test.file
ls -s file.img

for seek in {0..50}; do
	dd if=/dev/urandom of=mnt/test.file bs=1M count=50 seek=$seek \
		oflag=direct conv=nocreat,notrunc
	sync
	filefrag -e mnt/test.file
	ls -s file.img
	df -h mnt
done

dd if=/dev/urandom of=mnt/file2.img bs=1M count=800
sync

umount mnt
losetup -d /dev/loop0
rmdir mnt

О как. Ау. Это ж как должно быть плохо образцам VM без nodatacow.

rebalance + дедупликация должны помочь, но привнести свои минусы.

О как. Ау. Это ж как должно быть плохо образцам VM без nodatacow.

Всё так.

# compsize /mnt/vm/libvirt/images/windows.img
Processed 1 file, 945431 regular extents (1098755 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced
TOTAL      100%      864G         864G         791G
none       100%      864G         864G         791G

Видишь? Ссылок больше, чем экстентов. Это именно та ситуация, которую я описал выше под пунктом (2).

rebalance + дедупликация должны помочь

Да чего ты заладил со своей дедупликацией. Она эту проблему абсолютно никак не затрагивает, т. к. дедуплицировать нечего, все данные уникальны. Ребаланс тоже не в тему, т. к. ребаланс просто тасует по диску существующие экстенты, при этом никак их не изменяя (по определению).

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

Ну или запилить истинный extent splitting прямо в драйвере, но это якобы настолько сложная проблема, что к ней никто даже не собирается притрагиваться.

Про дедупликацию я заладил потому что всегда ожидаю худшего, а оно включает переиспользование экстентов в общем случае, её тоже надо подчинить.

А rebalance… Блин, а если не rebalance, как тогда звалась операция, которая имитировала практически что запись каждого файла заново? Она ещё все раздедуплицировала вхламину.

Наверное, ты имеешь в виду дефраг. Это почти то что нужно, только обычный дефраг совершает много лишней работы и не гарантирует совершения правильной работы (если все интересующие нас куски экстента будут больше target extent size, то дефраг пробежит мимо них, а если выкрутить target extent size в 9000, то такой дефраг у тебя займёт 100 лет и очень много лишнего I/O).

Да, эта, спасибо.

ну ты ведь в курсе

Нет, не был в курсе. Или забыл. В любом случае, проблема с большим числом обновлений метаданных остаётся в силе. Если у файла десять ссылок, то при записи в один из них обновлять метаданные придётся у всех десяти.

Яннп. Когда ты пишешь в файл, ты пишешь в один конкретный файл. Если ты пишешь поверх шаренного экстента, то он аншарится от твоего файла и создаётся новый экстент, т. о. количество обновлений ссылок всегда O(1). Операций, прямо модифицирующих шаренные экстенты, в общем-то и нет, потому что они нарушают семантику copy-on-write.

он аншарится от твоего файла и создаётся новый экстент

Он целиком копируется в новое место или одни и те же байты могут принадлежать сразу нескольким разным экстентам?

Экстент — это непрерывная последовательность байт на диске, т. е. самая низкоуровневая конструкция. В btrfs, насколько я понимаю, все экстенты immutable (nodatacow в расчёт не берём). Части одного экстента могут принадлежать разным файлам, и даже нескольким сразу (это и есть дедупликация, рефлинки и т. п.).

Под «он аншарится» я имел в виду, что новые байты пишутся в новый экстент (не пошаренный ни с какими другими файлами) и на них создаётся ровно одна ссылка из того файла, в который записали. А старая ссылка либо уничтожается, либо заменяется на некоторое количество (1 или 2) частичных ссылок.

новые байты пишутся в новый экстент (не пошаренный ни с какими другими файлами) и на них создаётся ровно одна ссылка из того файла, в который записали. А старая ссылка либо уничтожается, либо заменяется на некоторое количество (1 или 2) частичных ссылок.

Но ведь это ровно то поведение, которое сейчас уже есть. Я думал, что ты пытаешься описать желаемое поведение.

Существующее и желаемое поведение я описал здесь. А сейчас я просто отвечал на твой вопрос.

А, я понял, что ты пытаешься сказать. Предположим, что у нас есть один большой экстент, на который ссылается N файлов. Потом мы по очереди вышибаем из каждого файла серединку. Дальше есть два варианта поведения:

• либо мы втупую делаем extent splitting для каждого файла по отдельности (при этом оставляя оригинальный экстент нетронутым, т. к. на него всё ещё есть ссылки). Тогда мы теряем дедупликацию;
• либо при первых N-1 операциях мы замечаем, что на серединку экстента всё ещё ссылаются какие-то файлы и от extent splitting нет пользы, а при N-й операции замечаем, что на серединку экстента больше никто не ссылается, в этот момент делаем extent splitting и тут нам нужно сразу обновить N файлов, чтобы они ссылались на новые экстенты.

Ну да. Всё так.

я привык к ext4.

Спасибо за разъяснение. Получается, это сжатие только для экономии ресурса?

Была у меня мысль через пол-года (как сжатие на F2FS будет в lts ядре) перейти на F2FS. Теперь, по крайней мере, не будет одной иллюзии.

И думается, как только перешедших на F2FS будет больше, неизбежны возгласы — «нас обманули».

Получается, это сжатие только для экономии ресурса?

Выходит, что так.