Linux: Torvalds виключає файлову систему Bcachefs з ядра

Торвальдс щойно видалив 117 000 рядків коду для Bcachefs з ядра Linux, скоротивши десять років бурхливої ​​розробки. Версія 6.18, яка вийде менш ніж за два місяці, тому за замовчуванням ігноруватиме цю гібридну файлову систему, незважаючи на те, що її хвалять за розширене управління сховищем. Для спільноти Linux цей епізод є нагадуванням про те, що правила ядра не прощають ні затримок, ні самовпевненості. Чому Bcachefs зник з ядра Linux? У понеділок увечері, ледве через 24 години після випуску версії 6.17, Торвальдс підписав патч, який видаляє Bcachefs. Розробник Kent Overstreet вже два місяці бачив свій код з позначкою «підтримується зовнішніми сторонами», що було знаком відстрочки. Напруженість менше пов’язана з технологіями, ніж з методом: масові патчі, надіслані поза вікном злиття, неузгоджені зміни критичних частин та гарячі публічні обміни. У надшвидкому світі розробки ядра Linux ці порушення еквівалентні segfault у виробництві. Результат: код повертається з дерева, туди, де він був до інтеграції наприкінці 2023 року. Рідкісна чистка в історії вільного програмного забезпечення, особливо для такого чутливого компонента, як файлова система. Зіткнення культур, а не бітів. У своїх електронних листах Оверстріт захищав додавання нових функцій на етапі RC, посилаючись на Btrfs або XFS. Торвальдс заперечив, що ці винятки стосуються цільових виправлень, а не повних переписувань. Тертя загострилося, коли інші розробники ядра виявили патчі, що впливають на їхні підсистеми, без попереднього обговорення. Серед ветеранів ядра співпраця переважає швидкість; ігнорування цього балансу наражає вас на масовий git-реверт. Тому заборона служить навчальним попередженням: процес важливий так само, як і код, особливо в найбільш ретельно перевіреній екосистемі відкритого коду у світі.Негайний вплив на адміністраторів та дистрибутивів

На практиці, лише кілька серверів вже використовували Bcachefs у продакшені. Модуль залишався позначеним як «експериментальний», і лише Arch, Debian та Ubuntu пропонували його для тестування.

Тим не менш, деякі лабораторії зробили ставку на його обіцянку: онлайн-стиснення, контрольні суми та атомарні оновлення в стилі ZFS, все в одному форматі. Їхнє перше питання було простим: як вони можуть продовжувати монтувати свої томи після версії 6.18? Відповідь крилася в старому доброму DKMS. Overstreet рефакторував код таким чином, щоб він компілюється з будь-яким ядром ≥ 6.16, рішення, яке вже перевірено для драйверів Nvidia або VirtualBox. DKMS: Парашут чи Пастка?

Перевага: модуль автоматично перекомпілюється з кожним оновленням, уникаючи сценарію «rootfs не знайдено». Недолік: найменший збій API на стороні ядра призводить до аварії компіляції, через що машина не може завантажитися, якщо Bcachefs знаходиться на кореневому каталозі. Тому деякі дистрибутиви зберігають старе ядро ​​як резервний варіант. Інші обговорюють пакет bcachefs-dkms, який підтримується спільнотою, але набір інструментів для збірки відрізняється між Fedora, openSUSE або Gentoo. Розсудливий адміністратор може повернутися до Ext4, XFS або Btrfs, навіть якщо це означає жертвувати кількома IOPS заради душевного спокою. Тому що нестабільна файлова система може коштувати дорожче, ніж ціла стійка SSD.Основний меседж для екосистеми з відкритим кодом

Розробка файлової системи загального призначення вимагає років реального тестування, подібно до марафону, який пережили Ext4 та Btrfs. Google, Meta, Red Hat та SUSE інвестують мільйони для перевірки кожної зміни, оскільки помилка диска швидко перетворюється на серйозний інцидент. У 2025 році фрагментація сховища — NVMe, SMR, розподілені об’єкти — посилює труднощі. Без розширеної команди або постійної перевірки Bcachefs потрібно буде переконати людей, що вона може йти в ногу з основною лінією, залишаючись актуальною.Справа нарешті нагадує нам, що сила безкоштовне програмне забезпеченняполягає у співпраці. Коли технічні дебати переходять у особистий конфлікт, код відступає, і

Спільнота Linux

втрачає серйозного кандидата на майбутнє зберігання. Джерело: www.heise.de