Комментарии 48
Проблема нехватки места в 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/steamgit: 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 ушёл в оффлайн большой кусок, что-то в метаданных поменяла так, что все файлы остались на месте, с правильными именами, датами и размерами, но внутри были только нули. Я потом вычищал архив банальным поиском файлов "только из нулей".
А один эпик файл мне так не кто обьяснить не смог, бэкап долго лежал(дублированный на других носителях), ошибка чек суммы.Фиг чиниться.
А в чём, собственно, проблема? Working as intended. Побились данные на диске, бтрфс это поймал.
Чтобы bit rot случился, памяти и процессору глючить необязательно.
Побились данные на дискеНе читаем что я написал?
а суммы файлов совподают, данные целыеЭто у меня был архивы с данными для сверки и востановления.Все файлы проверил -md5 и sha256 совпали с длинной файлов.Диск целый, бад блоков нет.Пролежали данные около 3-4 лет, я к тому времени на 64 бит lts перешел, а тут засада… Точно такой архив только с ext4, скопировал, проверил, сравнил… много думал что эта за хрень и почему на ровном месте не ремонтируеться. Даже очистка контрольной суммы не помогла, на середине тестофь утилита btrfs падала в корку 0:-(
Так не приняли же по политическим причинам. Т.к. Райзер жену убил.
А вот это вот, мягко говоря, интерпретация. Судя по первым комментариям про комьюнити, возможно, дело не в имени Райзера, а в несколько враждебном и снисходительном отношении к комьюнити.
Присылать патч с настроением "Все беды прежде всего от некомпетентности и необразованности тех, кто принимает решения" (т.е. мейнтенейров) — это такой заряд токсичности, что проигнорировать предложение принять его в апстрим, наверное, самый простой способ избежать токсичности. ИМХО, конечно.
Но я бы от человека с таким настроем тоже бы код не принял.
При этом более худшая ФС (райзерфс 3.6) прекрасно была принята и есть во всех дистрибутивах.
Насколько я помню, речь шла про ext4 (из предыдущего интервью).
А что касается токсичности, в рассылках ядра я ничего такого не видел (https://lwn.net/Articles/151206/), Namesys исправляли все замечания ментейнеров (пусть и в ущерб самой R4) и в какой-то момент они исправили. Ментейнеры ядра по каким-то своим личным взглядам не давали зеленый свет. Где-то еще была критика про плагиновую систему, мол Namesys хочет наклепать проприетарных плагинов и продавать им.
Судя по всему в очередной раз кто-то на кого-то обиделся и все.
P.S. Не берусь утверждать со 100% что все что я сказал выше правда. Это все было давно. Где-то прочитал, где-то услышал и т.п. и не смогу сейчас подвердить абсолютно все свои слова какими-то ссылками.
Да и вообще, Эдуард прав насчет «жизни вне ядра». Тот-же Кон Коливас со своим BFS / MuQSS, живет и живет. Reiser4 тоже вполне себе живет.
Но это ни разу не привело к коррапту (а интервью обещает именно его)
Несогласен, интервью общает локальный DoS от непривелигерованного пользователя:
> Хуже всего то, что непривилегированный пользователь почти всегда может за достаточно короткое время в обход любых дисковых квот лишить всех свободного места.
Даже интересно стало воспроизвести такое.
Там было и про коррапт тоже. В целом — пускай показывают скрипт, будем репортить/думать.
Вот я тоже очень хочу увидеть этот скрипт. Надо бы попробовать написать такой по описанию.
BTRFS я не использую в проде, но для ZFS я знаю несколько способов как её ушатать.
Фичи BTRFS и ZFS зачастую перевешивают их недостатки, поэтому они будут использоваться. Но если Эдуард Шишкин не излагает только теоретические вещи, и BTRFS можно так легко убить, то лучше знать об этих corner case.
Даже интересно стало воспроизвести такое.
Элементарно Ват… ой.Читаем багтрек 10 летней давности про sqlite2 и порчу данных на btrfs, нечего не поменялось, кое-что в 3 версии поправили специально для btrfs… Не выставляем бит nodatocow на созданную базу, создаем и индексируем базу, профит.Хрен чиниться.Я такое словил на приложение MyRuLib когда поставил индексировать архив с книгами.У меня перекомпилированная версия этой программы переведенная одним умельцем на wxWidgets.
А вы статью-то читали? " 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Мб файле.
Может мне теперь надо прочитать и 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 старой системы.
Кстати, еще один pitfall — systemd's journal. И 2 раза вставать на journal'е:
Вот еще человек пишет, про Firefox (sqlite) на Btrfs:# 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/xxxx.default-release/storage/.../xxxx.sqlite: 1825 extents foundнужно совсем быть укуренным, чтобы сравнить dm snapshots (так это называется), с реализацией снэп-ов у Btrfs. Не надо мне тут вещать про LVM, поджав губу, мой коммент никаких религиозных чувств у вменяемого человека задеть не мог бы. )
К сожалению, мне уже давно не 30 летДа уж, выгорел Шишкин…
2) ну если не btrfs и не zfs, то что есть со сжатием данных? вот реально надо для почтовика, а ничо нет другого!!! тот же reiser4 какбэ не для прода…
Краткое содержание (помимо постоянного поминания некоего «некомпететного», «бескультурного» и «губонадувательного» лидера — очевидно, человек не выдержал общения с Торвальдсом):
Как я для себя позиционирую Btrfs? Как нечто, что именоваться файловой системой категорически не может, не говоря уже об использовании.
Так что, «будущее файловых систем в Линукс» — это очередной сильно распиаренный, но мало пригодный к использованию софт. После Btrfs с большой вероятностью место такого «будущего» займёт Bcachefs, представляющая собой ещё одну попытку скрестить Linux block layer с файловой системой (дурной пример заразителен).
По HAMMERу: читал статью от создателя. Не заинтересовало. Опять же, B-деревья. Эта структура данных безнадёжно устарела. Мы отказались от неё ещё в прошлом веке.
Разрабатывать ext4 и XFS нет смысла. Как параллельно, так и любую из них на выбор.
Я знаю только один энтерпрайз, основанный на GNU/Linux — это RHEL. Всё остальное, с моей точки зрения, лишь выдаётся за энтерпрайз, но таковым не является.
Вокруг некомпетентных лидеров-одиночек всегда складывается коррумпированное окружение./spoiler>
…
Это напоминает финансовую пирамиду: на вершине располагаются заварившие эту кашу авантюристы, и те немногие, кому «повезло»: они «сняли дивиденды», т.е. получили деньги на разработку, устроились менеджерами на высокооплачиваемую работу, «засветились» на конференциях, и т.п. Далее идут те, кому «не повезло»: они будут подсчитывать убытки, расхлебывать последствия развертывания в продакшн непригодного программного продукта ", и т.д. Их гораздо больше. Ну, и в основании пирамиды — огромная масса разработчиков, «пилящих» никчёмный код. Они — в самом большом проигрыше, ибо впустую потраченное время не вернёшь. Такие пирамиды чрезвычайно выгодны Торвальдсу и его приближенным.
Появились контрольные суммы метаданных и недавно я дополнил их "экономичными" зеркалами" (пока нестабильный материал). В случае провала проверки контрольной суммы какого-либо блока Reiser4 немедленно считывает соответствующий блок с девайса-реплики. Заметьте, что ZFS и Btrfs так не могут: не позволяет дизайн. Там вы должны запустить специальный фоновый сканирующий процесс под названием "скраб" и ждать, когда он доберётся до проблемного блока. Такие мероприятия программисты образно называют "костылями".
Умышленно или не умышленно, но «гражданин соврамши».
Зашёл сюда почитать про файловые системы а свелось все к обсуждению политической ситуации в комюнити, и резюмированию что все равно. Господа, а что по файловым системам, что где выбирать? Ext4, btrfs xfs где какие кейсы?
Эдуарду — успехов с его проектом и пожелания перерасти уже формат файловых систем. Он своё уже отжил.
Второе интервью с разработчиком Reiser4 Эдуардом Шишкиным