LINUX.ORG.RU
ФорумAdmin

Ох BTRFS, ну сколько можно

 , , , ,


0

6

Сколько лет прошло, думал BTRFS довели до ума, решил использовать её в продакешене, но прошло два дня и …

2 недели тестировал все возможные способы репликации виртуальных машин с одного места в другое, без простоя. Протестировал кучу разных способов и остановился на BTRFS, как на единстрвенной COW которая не ест SSD. Кстати, фанатам ZFS ничего не скажу, живите спокойно в блаженном неведении :)

Что я проверил:

  1. ZFS, мучал около недели, как быстродействием так и оверхедом на диск не доволен, ещё RAM жрёт, а без RAM совсем печально всё. Мне не подходит, так как вся RAM отдаётся виртуалкам, хосту с ZFS ничего не останется, почти.
  2. LVM, да, у неё есть возможность как у ZFS сделать онлайн инкрементальную реприкацию, почти как в zfs send/recieve, но об этом мало известно. Отказался из-за чудовищно низкой скорости при наличи снапшотов, которые необходимы для репликации, в остальном терпимо.
  3. LVM thin, очень похожа на ZFS, те-же недостатки, мало тестировал
  4. BTRFS - почти не ест SSD, огромные проблемы с фрагмантацией, но я нашел способ их решить, поэтому остановился на ней

Дано:

  1. сервер с qemu/libvirt, Debian bookworm
  2. одна виртуалка, с ext4 mysql innodb блекджеком и шл ну в общем сайт PHP, данных всего 100Гб, довольно активная - 20ГБ записей на диск в сутки, диск, 70% из них блоками <=4k, 20% 8k, и так далее. Как видите много random write. RAW диск виртуалки на разделе BTRFS.

Перенёс всё со старого хоста ext4 на новую виртуалочку с RAW на btrfs разделе. Всё работало полтора дня и началось:

  1. начали биться индексы у таблиц
  2. данные в таблицах начали исчезать Долго не терпел, сразу всё откатил назад, у юзеров стресс, пьют валериану.

Не ожидал такого. Запустил btrfs scrub - ошибок не обнаружено. Да как так то? BTRFS raid1, значит ошибка внутри BTRFS или в интерфейсе между KVM и BTRFS.

Вот такой вот опыт.

А я уже и дефрагментатор для неё новый написал, офигенный, который не жрёт ни диск ни SSD, но видимо не судьба.

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

Что теперь делать даже не знаю, рисковать с BTRFS больше не хочу, а других подходящих COW c онлайн репликацией снапшотами не существует …



Последнее исправление: Nohack (всего исправлений: 5)

Ответ на: комментарий от anonymous

У LVM-thin проблема не в скорости (не помню уже как там со скоростью), а в размере блока, он у него 64к, это значит что на каждый чих (4к) будет писаться 64к (x16), меня это не устраивает.

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

Без виртуалки не вижу смысла тестировать, надо бы запустить внутри виртуалки стресс тест диска чтобы повторить проблему, а дальше уже можно будет тюнить, но это если будет время. Ядро не старое, а стабильное Debian Stable, как старое вино :)

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

Стресс-тест диска не воспроизведёт детали поведения подсистемы, в которых может быть проблема: несколько очередей, запросы разного размера, барьеры.

Разве что если записать полный трейс и гонять его по кругу, пытаясь поймать разные результаты.

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

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

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

blksnap посмотри

Посмотрел, не нашёл ни одной софтины которая бы делала что-либо практическое, его добавила в ядро коммерческая организация которая делает бекапы за деньги, используя это API в ядре. По описанию полный аналог dm-mapper, то есть LVM снапшотов, но без dmsetup

Nohack
() автор топика

А я уже и дефрагментатор для неё новый написал, офигенный, который не жрёт ни диск ни SSD, но видимо не судьба.

Ну ты исходники всё-таки выложи. Вдруг ЕЁ всё же починят :)))

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

Это ты не понимаешь что читаешь.

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

При дефолтном размере экстента в 4МБ, это приводит к чтению и потом записи 4МБ (итого 8МБ), поэтому под снапшотами резко кончается полоса.

Выставляешь размер 128К и внезапно всё начинает работать нормально.

Но можешь упорствовать дальше и рассуждать о том, чего не понимаешь.

no-dashi-v2 ★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от t184256

Дефрагментация BTRFS, кто не знает, осуществляется ядром, можно только указать ему какие куски соединить. Поэтому если и есть ошибка в дефрагментаторе, то она в ядре.

Nohack
() автор топика

ZFS, мучал около недели, как быстродействием так и оверхедом на диск не доволен, ещё RAM жрёт, а без RAM совсем печально всё. Мне не подходит, так как вся RAM отдаётся виртуалкам, хосту с ZFS ничего не останется, почти.

Какой тип нагрузки? ZFS имеет очень развитую систему кеширования. Это позволяет подобрать кеш, оптимальный для твоих задач.

hateWin ★☆
()
Ответ на: комментарий от no-dashi-v2

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

Никак не влияет, я проверял, а ты просто фантазёр. Проблема с LVM в другом, она там из-за того, что каждая операция записи при наличии снапшота, приводит к 3м операциям: одному чтению, одной записи в само устройство и одной записи в снапшот, и ещё метадату наверняка пишет куда-то, эти нюансы я не знаю. В итоге скорость падает в 5 раз.

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

Никак не влияет, я проверял

Не знаю что ты «проверял», но у нас таких серваков с LVM больше 50 штук, на каждом за ночь делается несколько десятков снапшотов, все работает нормально.

no-dashi-v2 ★★★
()
Последнее исправление: no-dashi-v2 (всего исправлений: 1)
Ответ на: комментарий от no-dashi-v2

Это не значит, что твои фантазии совпадают с реальностью, просто ты не курсе насколько сильно оно тормозит, хотя NVME сейчас такие быстрые, что это может быть незаметно. Потестируй, это же просто и сам всё увидишь: vgcreate -s 4k потом fio randwrite 4k sync=100 vgcreate -s 64k потом fio randwrite 4k sync=100 vgcreate -s 512k потом fio randwrite 4k sync=100

результаты одинаковые, снапшоты не забудь :)

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

Да нет желания, вы же всё обосрёте, всё сомнению подвергнете, тут не так, там не так, как дети, а мне нужно будет вам все сопли подтирать, объяснять почему это правильно, не, спасибо, не надо.

Nohack
() автор топика
6 августа 2024 г.
Ответ на: комментарий от anonymous

Небольшое обновление, прошло 2.5 месяца с момента сбоя на BTRFS, с тех пор я переустановил всё на ext4 и никаких проблем с тех пор на этом железе не было. Это для тех кто надеется, что дело было в железе, а не в BTRFS.

Nohack
() автор топика

Сколько лет прошло, думал BTRFS довели до ума

Это не вопрос времени. Там с самого начала было очевидно, что это тупик.

Что теперь делать даже не знаю, рисковать с BTRFS больше не хочу, а других подходящих COW c онлайн репликацией снапшотами не существует …

Есть ZFS. Есть bcachefs, который пока очень молодой, но уже позиционируется как стабильный и выглядит примерно как «btrfs, но сделанный сразу правильно».

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

Сначала надежда была на сбой железа, теперь на сбой дефрагментатора, ну что тут можно сказать, риск дело благородное!

Повторюсь - дефрагментация в BTRFS работает через ядро и осуществляется кодом BTRFS в ядре, ему можно только сказать «соедини такие-то фрагменты данных», всё остальное ядро делает само. Если дефрагментация осуществляется ядром правильно, то извне невозможно ничего сломать просто передавая запросы о соединении каких-то фрагментов.

Мой дефрагментатор работал также, поэтому если сбой был из-за дефрагментации, то проблема всё-равно в самой BTRFS, которая сломала сама себя дефрагментируя саму себя.

Возможно сбой связан с дефрагментацией (но не с моим дефрагментатором), тогда советую не дефрагментировать ничего на BTRFS.

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

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

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

Да нет желания, вы же всё обосрёте, всё сомнению подвергнете, тут не так, там не так, как дети, а мне нужно будет вам все сопли подтирать, объяснять почему это правильно, не, спасибо, не надо.

Ну объясни точно так же логику, зачем создал топик? Хотел всех предупредить используя свой (анонимный) авторитет?)

goingUp ★★★★★
()