LINUX.ORG.RU

Дедупликация в Btrfs

 ,

Дедупликация в Btrfs

3

4

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. На очень слабых машинах это может быть критичным.

Самая идиотская затея — запустить дедупликацию на поврежденной файловой системе, особенно если повреждения вызваны битой памятью. Это почти гарантированно приведёт к безвозвратной потере данных!

Ссылки

★★

Проверено: hobbit ()
Последнее исправление: rtxtxtrx (всего исправлений: 19)

Никто не следит за развитием данной фс?

Сам Btrfs не имеет встроенных утилит для дедупликации

Что то планируют реализовывать в штатных утилитах? Или может онлайн дедупликацию?

Со стороны кажется что развитие стагнировало. Изменения в последних ядрах кажутся мелкими.

Может кто то следит за развитием и может описать подробнее?

Behem0th ★★★★★
()
Ответ на: комментарий от xaTa

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

rtxtxtrx ★★
() автор топика
Ответ на: комментарий от guyvernk

зачем вообще нужна эта бтрфс кроме боль дырка ж*па

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

rtxtxtrx ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

бездумной копипасты команд в терминал с сайтов, где инструцкии пишут люди, поклоняющиеся кришне

А если автор инструкций поклонялся богу-императору, истлевающему на золотом троне, то у btrfs шансов не порваться будет больше? :D

Manhunt ★★★★★
()
Ответ на: комментарий от xaTa

тогда странные вопросы. если для тебя нормально, что у тебя ~30% из занятого места одни и те же блоки, то не используй дедупликацию. я чисто такой примитивный пример привел как этот мусор появляется. у меня без дедупликации занято было 160-180 гигов, с ней 130

rtxtxtrx ★★
() автор топика
Ответ на: комментарий от xaTa

В Btrfs есть блоки с данными EXTENT_DATA и ссылки на них EXTENT_DATA_REF. Типы данных? Как их назвать? У блоков есть хеш. Вот по этому хешу стронние утилиты ищут одинаковые блоки и «заменяют» их ссылками на оригинал. Это я так себе представляю, потому как мне глубоко плевать как оно там работает, но ожидать, что все сломается из-за криворукости автора я тоже не жду, эта утилита повсеместно используется на серверах и тп

rtxtxtrx ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

Ааа. Догнал наконец. Спасибо что разжевал.

xaTa ★★★
()

Мне кажется сама необходиость этой статьи говорит о ненужности btrfs. В своё время я уже огребал с ней проблем, но тогда она не завлялась как стабильная. Но кроме этого дедупликация хроном сильно доставала да и не особо работала на ноуте, включеном только когда нужно что то делать.

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

kirill_rrr ★★★★★
()
Последнее исправление: kirill_rrr (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

и агитируют против, так как в каком-то бородатом 2015-2017 она себе файлы похерела исключительно из-за своего рукожопства

Слушал доклад про новую и прогрессивную бронетракторную ФС то ли в 2007, то ли в 2008 году. Тогда она действительно давала классный прирост на HDD во многих операциях, но сейчас её пытаются переобуть на лету под другое железо и под другие задачи. Ещё детские болячки не починены, а оно уже страшный и сложный монстр. Обделённый вниманием разработчиков и не нужный бизнесу.

kirill_rrr ★★★★★
()
Ответ на: комментарий от realbarmaley

Без неё этим и пользоваться то нельзя. Всё классно первые 2 месяца, а потом место куда то пропало, и производительность как будто ntfs-3G со сжатием...

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

Не хочется даже думать о том что произойдёт, если во время дедупликации рубануть питание.

Произойдет ужасная вещь — дубликат не будет «удален» (в кавычках, конечно же, так как по факту ничего не удаляется)

rtxtxtrx ★★
() автор топика
Последнее исправление: rtxtxtrx (всего исправлений: 1)

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

4.2 прямо с порога. Ее, еще теплую, мокрую и липкую, втащили в ядро для опытов над пользователями еще в 2009, и за 10 лет устойчивого развития, сопровождаемого тщательным контролем качества, она достигла таких высот, что ее даже выкинули нахер из рхела, ибо себе дороже связываться.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 2)
Ответ на: комментарий от thesis

Btrfs — это лучшая файловая система в галактике! ZFS, конечно, в дедуплокацию умеет из коробки, но не могет тип RAID поменять… Советую Btrfs использовать вместе с Flatpak и программировать в Vim. А если серьезно, то она у меня на сервере около 5 лет. Полет нормальный, брат жив, прекращай

rtxtxtrx ★★
() автор топика
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Ответ на: комментарий от rtxtxtrx

ZFS, конечно, в дедуплокацию умеет из коробки…

Тормозная она там, ограниченная область применения из-за этого.

altwazar ★★★★
()
Ответ на: комментарий от rtxtxtrx

угу, но для zfs я не нашел какой-нибудь более-менее проверенный дедупликатор, который можно было бы использовать за пределами выделенной под хранение данных машины.

altwazar ★★★★
()
Ответ на: комментарий от rtxtxtrx

она у меня на сервере около 5 лет. Полет нормальный, брат жив

Для плохо понимающих речь, еще раз, немного другими словами: утверждение «показала высокую надежность и стабильность, и именно поэтому включена в ядро» является 4.2, потому что она была включена в ядро ЗА МНОГО ЛЕТ до того, как что-то там показала (если показала вообще).

thesis ★★★★★
()

Пару месяцев назад тоже загорелся btrfs, но потом начал читать маны и понял, что у меня для этой технологии слишком большой половой член. И остался на ext4.

somemong
()
Ответ на: комментарий от thesis

До сих пор её баги фиксят в ядре. Ради интереса посмотрел changelog 6.11.7. 4 или 5 багов btrfs. ext4 вообще не упоминается.
Я пришёл к выводу, что лучше в нестандартные отношения с btrfs не входить. Снапшоты - да, а сжатие, рейды, дедупликация и тому подобное - нет.

rupert ★★★★★
()
Ответ на: комментарий от rupert

Я про нынешнее качество батерэфэса ничего не знаю (хотя и подозреваю, бгг) и говорить не буду. Я только о ретроспективе.

Интересно, доедет ли до онтопика полный набор фич NTFS, да чтобы в стабильной реализации. А то на заборе вон написано, что она и в дедупликации рвет всех как тузик клизму.

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 1)
Ответ на: комментарий от rupert

ext4 самая штабильная файловая система, которую не может убить один коммит, ведь верно?

сжатие, рейды, дедупликация и тому подобное - нет.

сжатие даже в ntfs есть в отличии от лучшей ext4… которая и целостность блоков с данными не гарантирует…

rtxtxtrx ★★
() автор топика
Ответ на: комментарий от rtxtxtrx

ext4… которая и целостность блоков с данными не гарантирует…

Мне интересно как вообще люди живут на файловых системах без проверки целостности. И не страдают от того факта, что в любой момент данные на диске могут тихо повредиться и ты об этом не узнаешь. По причине банального сбоя диска, да и bit rot даже в лежащих на полке дисках никто не отменял.

А потом эти битые файлы еще и в бэкапы попадут. И проблема проявится только когда будет уже поздно, а все «правильные» копии файла давно перезаписаны битым.

Лично для меня только это уже сильный повод использовать Btrfs/ZFS/Bcachefs. Можно конечно и вручную пересчитывать хешсуммы файлов каждый раз когда ими пользуешься, но намного проще и удобнее использовать фс с проверкой целостности блоков.

greedyskoof
()
Последнее исправление: greedyskoof (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Когда в Debian заметил баг-репорт, огорчился, но, заглянув внутрь, немного полегчало: случай всё же специфичный.

… direct IO writes are ending in wrong locations effectively corrupting data. …

Когда нужны гарантии целостности, то после определённого кол-ва обычного эффективного буферизированного write вызывают fsync.

Прямую запись для винчестера использую очень редко, разве что, для починки софт-бэдов (если они не превратятся в бэды), а для SSD она вообще бесполезна, т.к. всё равно данные не пишутся точно по указанному LBA.

gag ★★★★★
()
Ответ на: комментарий от greedyskoof

… в любой момент данные на диске могут тихо повредиться … bit rot …

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

Ну, разве что есть одно но, но оно тоже не гниение, а связано с тем, что при записи новых данных, то ли от вибрации, вышедшей за пределы дозволенной, то ли от толчка, что-то запишется поверх соседнего старого. Ошибка записи нового можно будет легко обнаружить, а вот то, что пострадало что-то рядом останется незаметным, пока его потом не объявят «сгнило», что не так.

Ну, и есть ещё кое-что. После определённого кол-ва перезаписей одной и той же дорожки, винчестер втихаря освежает/перезаписывает соседние дорожки. Осуществляется ли затем проверка соответствия перезаписанных данных - это загадка.

gag ★★★★★
()
Последнее исправление: gag (всего исправлений: 1)
Ответ на: комментарий от rtxtxtrx

Ты сравнил один залётный баг в ext4 с долгой серией багов в btrfs. Приемущество ext4 в том, что она простая как валенок, и поэтому надёжная. Если что, данные всегда можно вытащить. Из btrfs со сжатием (или ntfs со сжатием) фиг что достанешь, если файловая система скуксится. Ну и другие «продвинутые» фичи btrfs её надёжность совсем не увеличивают.

Не, я сам использую btrfs, потому что снапшоты. А всё другое остальное - побоку.

rupert ★★★★★
()
Ответ на: комментарий от greedyskoof

Проверка целостности блоков может выглядеть и так:

[914319.376789] Workqueue: btrfs-worker btrfs_work_helper [btrfs]
[914319.384849] Call trace: 
[914319.384885]  unwind_backtrace from show_stack+0x18/0x1c
[914319.393105]  show_stack from dump_stack_lvl+0x50/0x58
[914319.398475]  dump_stack_lvl from warn_alloc+0xd8/0x168
[914319.403928]  warn_alloc from __alloc_pages+0xb14/0xd34
[914319.409352]  __alloc_pages from __kmalloc_large_node+0x6c/0x150
[914319.415592]  __kmalloc_large_node from __kmalloc+0x2c0/0x378
[914319.421568]  __kmalloc from dwc2_map_urb_for_dma+0x8c/0x134
[914319.427460]  dwc2_map_urb_for_dma from usb_hcd_submit_urb+0xc4/0x97c
[914319.434142]  usb_hcd_submit_urb from rx_submit+0x158/0x2d4 [usbnet]
[914319.440790]  rx_submit [usbnet] from rx_complete+0x320/0x370 [usbnet]
[914319.447606]  rx_complete [usbnet] from __usb_hcd_giveback_urb+0xa8/0x138
[914319.457439]  __usb_hcd_giveback_urb from usb_giveback_urb_bh+0xa8/0x120
[914319.467272]  usb_giveback_urb_bh from process_one_work+0x168/0x398
[914319.476616]  process_one_work from bh_worker+0x168/0x1f4
[914319.485034]  bh_worker from tasklet_action+0x14/0x28
[914319.493049]  tasklet_action from handle_softirqs+0xc4/0x2b8
[914319.501667]  handle_softirqs from call_with_stack+0x18/0x20
[914319.510299]  call_with_stack from __irq_svc+0x90/0xac
...
[914319.563351]  __irq_svc from crc32_body+0x64/0x144
[914319.570948]  crc32_body from chksum_update+0x18/0x24 [crc32c_generic]
[914319.580405]  chksum_update [crc32c_generic] from csum_tree_block+0x80/0x194 [btrfs]
[914319.593053]  csum_tree_block [btrfs] from btree_csum_one_bio+0x14c/0x448 [btrfs]
[914319.607395]  btree_csum_one_bio [btrfs] from run_one_async_start+0x38/0x3c [btrfs]
[914319.621991]  run_one_async_start [btrfs] from btrfs_work_helper+0xd4/0x248 [btrfs]
[914319.636598]  btrfs_work_helper [btrfs] from process_one_work+0x168/0x398
[914319.648421]  process_one_work from worker_thread+0x1e4/0x3fc
[914319.657101]  worker_thread from kthread+0xcc/0xf0
[914319.664937]  kthread from ret_from_fork+0x14/0x28
...
[914427.323126] BTRFS warning (device mmcblk0p3): csum failed root 256 ino 903826 off 10223616 csum 0x6c9fe308 expected csum 0xb246cfe9 mirror 1
[914427.341775] BTRFS error (device mmcblk0p3): bdev /dev/mmcblk0p3 errs: wr 0, rd 0, flush 0, corrupt 14, gen 0
[914427.357855] BTRFS warning (device mmcblk0p3): csum failed root 256 ino 903826 off 10227712 csum 0xc2560627 expected csum 0xbe8af6cc mirror 1
[914427.376776] BTRFS error (device mmcblk0p3): bdev /dev/mmcblk0p3 errs: wr 0, rd 0, flush 0, corrupt 15, gen 0
[914427.393420] BTRFS warning (device mmcblk0p3): csum failed root 256 ino 903826 off 10231808 csum 0x59fa987f expected csum 0xf9ee9c0d mirror 1
[914427.413152] BTRFS error (device mmcblk0p3): bdev /dev/mmcblk0p3 errs: wr 0, rd 0, flush 0, corrupt 16, gen 0
undef ★★
()
Ответ на: комментарий от gag

В какой любой?

В абсолютно любой. На consumer-grade железе вообще нет никаких гарантий. Глючные прошивки и контроллеры всюду. И банально внезапные потери питания с повреждением данных.

У меня лично есть SSD, который в целом работает отлично и SMART в полном порядке, но при этом нет-нет да изредка портит данные. То ли при сильной нагрузке, то при перегреве, да черт его знает. До перехода на Btrfs это вообще не обнаруживалось, просто какие-то случайные глюки или внезапно отказывалась стартовать система. Именно правильная фс позволила вычислить диск как источник проблемы.

А с HDD например нестабильные сектора частое явление. Перед тем как перейти в состояние полностью «битого» нечитаемого сектора, они сперва могут начать читать оттуда мусор.

greedyskoof
()
Последнее исправление: greedyskoof (всего исправлений: 1)
Ответ на: комментарий от rupert

Если что, данные всегда можно вытащить.

Главный вопрос - зачем? Если произошел крах фс или сбой диска, данным оттуда уже нельзя верить. Btrfs нарочно не дает прочитать потенциально битые данные.

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

greedyskoof
()
Последнее исправление: greedyskoof (всего исправлений: 1)
Ответ на: комментарий от rupert

или ntfs со сжатием

Был у меня случай, когда перезаписался кусок MFT. Восстанавливал с помощью R-STUDIO. Программа даже сжатые файлы распаковала. Дело было на HDD, а перезапись произошла из-за перекрытия границ разделов. Огрех восстановления потерянного раздела.

Radjah ★★★★★
()
Ответ на: комментарий от rupert

выведи мне список багов btrfs, убивающих систему. я помню что когда-то метадата могла все место отожрать и не вернуть, что была деградация производительности из-за коммита в ядро, сломавшего все… по этой причине как раз включение в ядро — это огромнейший плюс, никто в приницпе не обязан в ядре что-то чинить, если из-за каких-то изменений так zfs сломают. там небольшой список фс систем стабильных: ext2/3/4, btrfs, xfs, jfs, reiserfs (будет удалена в 2025), vfat, сквашфс, nfs, exfat, udf и какая-то iso для дисков, добавили только cachesfs, но и то скорее всего заместо рейзера, так как стало ясно, что последний никогда не признается, где прикопал жену, а значит и не выйдет никогда опять же… кажись я что-то еще забыл, но число файловых систем огромное просто, а тех, которые в ядре считанное количество, и то что среди них btrfs уже говорит о том, что она к проду готова

rtxtxtrx ★★
() автор топика
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.