Pull to refresh

Comments 47

Проблема нехватки места в btrfs действительно есть. Но ее можно решить ступенчатой ребалансировкой дерева, включая метаданные. Бежать за новым диском не нужно.

Однако файловая система не должна заставлять пользователя делать это руками.

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

Грубейшая ошибка. Путаете "балансировку" блок-групп (операция btrfs balance) и балансировку B-дерева. Второе — низкоуровневая операция, которая обязана происходить детерминистично, автоматически, независимо от пользователя.

Возможно я что-то не понял.

Я сталкивался с тем, что на диске много свободного места, но btrfs не может записать файлы.

И решал проблему именно через btrfs balance, запуская его несколько раз постепенно меняя параметры фильтров.

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

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

Да. Это всё не о том. В прошлом у btrfs было много проблем с исчерпанием неаллоцированного места (в каком-то смысле частный случай внутренней фрагментации). В определённый момент всё место на диске оказывалось зарезервировано под данные, а для метаданных ничего не оставалось. Своего рода "исчерпание inode-ов", только на новый лад.


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


"Перебалансировать" B-дерево вручную нельзя, это гораздо более низкоуровневая операция.

А на практики может получится интересно.
Synology DSM (там отпаченный линукс), две штатных ФС — ext4 и btrfs.
Docker.
Кучу subvolumes жрущих место терабайтами (при том что размер контейнеров в сумме где то 200 Gb)


И вроде как это не только с Synology происходит — см например https://github.com/moby/moby/issues/27653


"Решения":


  • экспорт/удалить докер со всеми хвостами/импорт/повторить через несколько месяцев
  • грязный хак с образом диска (отформатированного в ext4) для каталога докера — https://gist.github.com/hopeseekr/cd2058e71d01deca5bae9f4e5a555440

И кто виноват? проблема или в btrfs или в docker, с учетом того что на ext4 проблемы нет....

Хотя казалось бы, слоёные образы докера идеально вписывается в концепцию subvolume и снапшотов.

А место реально кончается или только du об этом говорит?

Дело в том, что снапшот это по сути subvolume, а subvolume для vfs это просто директория.

vfs не имеет понятия о том, что в снапшоте большая часть данных шарится. Он будет считать снапшот полноценной директорией.

Грубо говоря если вы сделаете снапшот скажем на гигабайт данных, то btrfs посчитает это как 1 гигабайт снапшот + все что изменилось после (будем считать что ничего не изменилось, тогда 0).

А vfs будет считать что это все вместе 2 полноценных гигабайта занимает.

В конкретно моем случае с Synology — я не могу подтвердить что место реально кончается до состояния "запись на диск не возможна". встроенные механизмы Synology считают что свободное место утекает (и алертят). df -h тоже показывает что места становится меньше. если проблема с показом свободного места — ну так разве не файловая система решает сколько показывать свободного места?
ладно, допустим что тут Synology криво отпатчили ядро (и docker) — но по ссылке на у на github на issue в moby почитать — тоже проблема и люди все какие можно данные приводят там и там вовсе не Synology а голые дистрибутивы.

tl;dr;


Линукс — гнилые компромиссы и коррумпированное окружение, btrfs г-но, xfs и ext4 развивать смысла не имеет, наш запрос на включение в апстрим проигнорировали, ну и не надо нам других ОС хватит.


Окаай. Хватит, так хватит. Но файловая система в режиме out-of-tree не прошла пристального взгляда мейнтейнеров, а во что это превращается мы знаем на примере попыток притащить кривыми ручками кривой порт wireguard'а в freebsd. Удачи в Out-of-tree унынии.


Юзаю btrfs уже 10 лет. Свободное место — да, особенность системы.

Свободное место — да, особенность системы.

То-есть, я правильно понимаю, «мыши плакали, кололись, но продолжали есть кактус»? Интересно, вот в OS/2 HPFS / HPFS386, образца 1988 / 1992 годов было то же самое B-Tree, в своей основе, но никаких таких феерических эффектов, со свободным местом, ни разу не возникало...

Чтобы "плакать" нужно "колоться". По практическому наблюдению (в том числе в условиях случайно недостаточно большого root volume, постоянно страдающего от нехватки места из-за забитого apt-кеша), место может заканчиваться. Но это ни разу не привело к коррапту (а интервью обещает именно его), плюс место, вообще говоря, заканчивается на любом томе, который 30Гб в размере, а надо 40+.


Вот вам живой снапшот с моей системы:


$ df -h  / /git /home/steam
Filesystem                  Size  Used Avail Use% Mounted on
/dev/mapper/retro--vg-root   76G   71G  1.8G  98% /
/dev/mapper/open-git         64G  6.0G   58G  10% /git
/dev/sda                    895G  780G  113G  88% /home/steam

$ sudo du -x --max-depth=0 -h  / /git /home/steam 
51G         /
6.0G    /git
775G    /home/steam

git: 6==6
steam: 780 — 775 = 5Gb
root: 51 != 71.


Присмотримся к ним подробнее:


$ sudo btrfs subvolume list / |wc -l
33
$ sudo btrfs filesystem  df / 
Data, single: total=70.02GiB, used=69.28GiB
$ sudo btrfs filesystem df /home/steam/
Data, single: total=888.23GiB, used=775.40GiB

(home у меня очень старый, ~2009, тогда никаких btrfs в продакшене даже близко не было).


Итого: драматичная нехватка места на самом деле — снапшоты и subvolumes, а остальное — ну да, файловая система сожрала под себя 12Гб из терабайта. Почему? Вопрос интересный. Тот же df что-то говорит про Metadata, DUP: total=3.00GiB, used=1.57GiB и ещё несколько таких же. Возможно, переиграл со снапшотами (которые были).


Т.е. вот она живая система с временем установки 2016 год (вроде бы, не уверен), пережившая три компьютера и 4 дисковых носителя (привет, pvmove), с кучей неприятных историй из-за poweroff, зависаний (особенно, когда второй компьютер умирал), 3 мажорных версий ядра с бесчисленными минорами — и no issues found.


За всё время работы с btrfs я в ней видел один баг с резким снижением производительности, и было это в старинном 3.14 в весьма специфичных условиях виртуализации.


Но герои с новой файловой системой, которую в апстрим не приняли, конечно, лучше знают, какая файловая система лучше.

Можно сказать повезло.Я тоже данные на btrfs не терял,но блин ни разу её поченить после сбоя не удалось,кроме мелкой ошибки.А один эпик файл мне так не кто обьяснить не смог,бэкап долго лежал(дублированный на других носителях) ,ошибка чек суммы.Фиг чиниться.Ну ладно,с других дисков снял данные- а суммы файлов совподают,данные целые.Не память,не процессор не глючили,я только вспомнил что возможно конвертировал этот диск с ext4.Так нечего не сбоило,данные дописывались,пока я на 64 бит дистрибутив не перешел.....

У меня достаточно серверов (в т.ч. с btrfs), чтобы видеть, что это не "повезло", а вполне нормальная система. Более того, у меня есть как минимум две истории, как взрывались xfs и ext4. xfs вообще поступила великолепно, и когда из LVM ушёл в оффлайн большой кусок, что-то в метаданных поменяла так, что все файлы остались на месте, с правильными именами, датами и размерами, но внутри были только нули. Я потом вычищал архив банальным поиском файлов "только из нулей".

xfs вообще поступила великолепно

Известная бага которую вроде 4 года назад починили, только версию фс не знаю, но только то что 5 и выше это точно.
А один эпик файл мне так не кто обьяснить не смог, бэкап долго лежал(дублированный на других носителях), ошибка чек суммы.Фиг чиниться.

А в чём, собственно, проблема? Working as intended. Побились данные на диске, бтрфс это поймал.


Чтобы bit rot случился, памяти и процессору глючить необязательно.

Побились данные на диске
Не читаем что я написал?
а суммы файлов совподают, данные целые
Это у меня был архивы с данными для сверки и востановления.Все файлы проверил -md5 и sha256 совпали с длинной файлов.Диск целый, бад блоков нет.Пролежали данные около 3-4 лет, я к тому времени на 64 бит lts перешел, а тут засада… Точно такой архив только с ext4, скопировал, проверил, сравнил… много думал что эта за хрень и почему на ровном месте не ремонтируеться. Даже очистка контрольной суммы не помогла, на середине тестофь утилита btrfs падала в корку 0:-(

Так не приняли же по политическим причинам. Т.к. Райзер жену убил.

Насколько я помню первые попытки продвижения были еще при Гансе.
К слову да, дело было еще в 2004-2005 годах (https://lwn.net/Articles/151206/), а об исчезновении его жены заявили в 2006-м.
Продвинуть в ядро — это длительная басня. Как основные замечания исправили, так Ганса и посадили.

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


Присылать патч с настроением "Все беды прежде всего от некомпетентности и необразованности тех, кто принимает решения" (т.е. мейнтенейров) — это такой заряд токсичности, что проигнорировать предложение принять его в апстрим, наверное, самый простой способ избежать токсичности. ИМХО, конечно.


Но я бы от человека с таким настроем тоже бы код не принял.

По-моему вы путаете причину со следствием. Токсичность именно из-за того, что по политическим причинам не приняли прорывную ФС, несмотря на 10 летний труд.

При этом более худшая ФС (райзерфс 3.6) прекрасно была принята и есть во всех дистрибутивах.
Подождите, ReiserFS была первая журналируемая ФС в ядре Linux (надстройка над ext2 была пару версий ядра спустя), с чего она более худшая? Не говоря уже про туже «упаковку хвостов».
Насколько я помню, речь шла про ext4 (из предыдущего интервью).

А что касается токсичности, в рассылках ядра я ничего такого не видел (https://lwn.net/Articles/151206/), Namesys исправляли все замечания ментейнеров (пусть и в ущерб самой R4) и в какой-то момент они исправили. Ментейнеры ядра по каким-то своим личным взглядам не давали зеленый свет. Где-то еще была критика про плагиновую систему, мол Namesys хочет наклепать проприетарных плагинов и продавать им.
Судя по всему в очередной раз кто-то на кого-то обиделся и все.
P.S. Не берусь утверждать со 100% что все что я сказал выше правда. Это все было давно. Где-то прочитал, где-то услышал и т.п. и не смогу сейчас подвердить абсолютно все свои слова какими-то ссылками.

Да и вообще, Эдуард прав насчет «жизни вне ядра». Тот-же Кон Коливас со своим BFS / MuQSS, живет и живет. Reiser4 тоже вполне себе живет.
Более худшая в сравнении с ReiserFS 4 имелось ввиду.

Но это ни разу не привело к коррапту (а интервью обещает именно его)

Несогласен, интервью общает локальный DoS от непривелигерованного пользователя:

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

Даже интересно стало воспроизвести такое.

Там было и про коррапт тоже. В целом — пускай показывают скрипт, будем репортить/думать.

Вот я тоже очень хочу увидеть этот скрипт. Надо бы попробовать написать такой по описанию.

BTRFS я не использую в проде, но для ZFS я знаю несколько способов как её ушатать.

Фичи BTRFS и ZFS зачастую перевешивают их недостатки, поэтому они будут использоваться. Но если Эдуард Шишкин не излагает только теоретические вещи, и BTRFS можно так легко убить, то лучше знать об этих corner case.

для ZFS я знаю несколько способов как её ушатать.

можно детали?

Даже интересно стало воспроизвести такое.

Элементарно Ват… ой.Читаем багтрек 10 летней давности про sqlite2 и порчу данных на btrfs, нечего не поменялось, кое-что в 3 версии поправили специально для btrfs… Не выставляем бит nodatocow на созданную базу, создаем и индексируем базу, профит.Хрен чиниться.Я такое словил на приложение MyRuLib когда поставил индексировать архив с книгами.У меня перекомпилированная версия этой программы переведенная одним умельцем на wxWidgets.

Добавлю -сейчас данные могут не побиться,но COW журнал "помрет".Балансировка у меня помирала не поработав и 2 минут...

> Свободное место — да, особенность системы.

как и дичайший write amplification.

А вы статью-то читали? " due to a push to provide more features such as snapshots and stronger data integrity"


Теперь возьмите условную "хорошую" файловую систему, положите её в добротный стек, который в себя включает снапшоты и чексуммы, и посмотрите какой там будет write amplification. Если вы никогда не пробовали LVM'ные снапшоты, то поверьте мне, каждые 4кб превратятся в 4МБ, что соответствует 1000x amplification (а ещё битмэп).
А потом ещё чексуммы пересчитать и записать.


Фичи стоят IO. Особенно, если перезаписывать рандомными 4Кб с fsync после каждого IO в 100Мб файле.

Какое отношение имеет write amplification к моему (не-)прочтению статьи, вы логику-то включали?

Может мне теперь надо прочитать и forums.gentoo.org/viewtopic-t-834065-start-0.html или forums.unraid.net/bug-reports/stable-releases/680-massive-write-amplification-on-raid-1-btrfs-ssd-cache-pool-with-sparse-files-r811 дабы эта дичайшесть как-то изменилось? )

Почитал. Одно — статья в которой в проблеме виноват торрент-клиент, второе — тред 2010 года (при всём уважении, btrfs тогда не была production ready). И я не вижу сколь-либо ощутимого write amplification, не смотря на то, что у меня на brfs и images виртуалок, и git'ы. 2.6Tb за 4 месяца, в которых и dmcrypt, и бенчмарк нового устройства, и pvmove старой системы.

Я пользуюсь Btrfs давно, write amp. заметил не сразу, но она там действительно настолько жуткая, что подумываю уменьшить отведенное ей место, юзать только там, где прям необходимо.

Кстати, еще один pitfall — systemd's journal. И 2 раза вставать на journal'е:
# WARNING: Enabling the NOCOW attribute improves journal performance
#     substantially, but also disables the btrfs checksum logic. In
#     btrfs RAID filesystems the checksums are needed for rebuilding
#     corrupted files. Without checksums such rebuilds are not
#     possible.
Вот еще человек пишет, про Firefox (sqlite) на Btrfs:
firefox/xxxx.default-release/storage/.../xxxx.sqlite: 1825 extents found
Повторю: давно ей пользуюсь. Ценю, но это не значит, что у нее нет недостатков. Write amp — один из таковых.
> Если вы никогда не пробовали LVM'ные снапшоты

нужно совсем быть укуренным, чтобы сравнить dm snapshots (так это называется), с реализацией снэп-ов у Btrfs. Не надо мне тут вещать про LVM, поджав губу, мой коммент никаких религиозных чувств у вменяемого человека задеть не мог бы. )
К сожалению, мне уже давно не 30 лет
Да уж, выгорел Шишкин…
Спасибо за интервью! Было интересно читать.
1) все та же пугающая картинка в теме этих ФС. бррррррр
2) ну если не btrfs и не zfs, то что есть со сжатием данных? вот реально надо для почтовика, а ничо нет другого!!! тот же reiser4 какбэ не для прода…
Осилил всё, но интервью производит гнетущее впечатление: академический снобизм + плохо скрываемая обида на мейнтейнеров Linux.

Краткое содержание (помимо постоянного поминания некоего «некомпететного», «бескультурного» и «губонадувательного» лидера — очевидно, человек не выдержал общения с Торвальдсом):

Btrfs - говно
Как я для себя позиционирую Btrfs? Как нечто, что именоваться файловой системой категорически не может, не говоря уже об использовании.

Bcachefs - говно
Так что, «будущее файловых систем в Линукс» — это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого «будущего» займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен).

HAMMER - говно
По HAMMERу: читал статью от создателя. Не заинтересовало. Опять же, B-деревья. Эта структура данных безнадёжно устарела. Мы отказались от неё ещё в прошлом веке.

ext4 и XFS - говно
Разрабатывать ext4 и XFS нет смысла. Как параллельно, так и любую из них на выбор.

Энтерпрайз (кроме RHEL) - говно
Я знаю только один энтерпрайз, основанный на GNU/Linux — это RHEL. Всё остальное, с моей точки зрения, лишь выдаётся за энтерпрайз, но таковым не является.

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

Это напоминает финансовую пирамиду: на вершине располагаются заварившие эту кашу авантюристы, и те немногие, кому «повезло»: они «сняли дивиденды», т.е. получили деньги на разработку, устроились менеджерами на высокооплачиваемую работу, «засветились» на конференциях, и т.п. Далее идут те, кому «не повезло»: они будут подсчитывать убытки, расхлебывать последствия развертывания в продакшн непригодного программного продукта ", и т.д. Их гораздо больше. Ну, и в основании пирамиды — огромная масса разработчиков, «пилящих» никчёмный код. Они — в самом большом проигрыше, ибо впустую потраченное время не вернёшь. Такие пирамиды чрезвычайно выгодны Торвальдсу и его приближенным.
/spoiler>
Ну человек познал жизь, чо… )
Появились контрольные суммы метаданных и недавно я дополнил их "экономичными" зеркалами" (пока нестабильный материал). В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием "скраб" и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют "костылями".

Умышленно или не умышленно, но «гражданин соврамши».

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

Интервью довольно старое (4-5 лет наверное).

Зашёл сюда почитать про файловые системы а свелось все к обсуждению политической ситуации в комюнити, и резюмированию что все равно. Господа, а что по файловым системам, что где выбирать? Ext4, btrfs xfs где какие кейсы?

Обычное состояние для русскоязычного около-ИТ сообщества. Для технических подробностей нужны другие места и английский язык.
Обсуждать преимущества ФС стоит после выбора ОС.
Я тут noname, но выскажусь. Эдуард, может быть, неправ по форме (всё — гавно, один я в белом), но прав по существу. Дело в том, что всё, что связано с надежным хранением состояния (будь-то файлы, базы данных или просто NVRAM), не может разрабатываться так, как разрабатывается код, который эти данные в полете обрабатывает. Специалисты по хранению данных обязаны быть параноиками надежности «на долгие времена» и устойчивости «в худшем случае», так как хранение данных — это mission critical. Можете считать это всё профессиональными деформациями. И если такие люди выдавливаются из сообщества по причине их «эмоциональной токсичности» (ну неудобны они в общении, да), то у меня для такого сообщества плохие новости. Да, с такими людьми трудно, да, они друг друга любыт еще меньше, чем окружающие — их. Но те, кто решаться делать их работу и станут параноиками надежности — получат те же профессиональные деформации.

Эдуарду — успехов с его проектом и пожелания перерасти уже формат файловых систем. Он своё уже отжил.
Only those users with full accounts are able to leave comments. Log in, please.