Usunięcie kodu Bcachefs z jądra: co to oznacza dla przyszłości systemu plików

Bcachefs został usunięty z jądra Linuksa 6.18, zabierając ze sobą 117 000 linii kodu. Decyzja Linusa Torvaldsa jest ukoronowaniem dziesięciu lat sporów między poprawkami, testami i sporami. Dla administratorów pytanie jest proste: kontynuować ścieżkę zewnętrznych modułów, czy wrócić do klasycznych systemów Ext4, XFS i ZFS? Moment jest nie do końca oczywisty. Pakiety DKMS właśnie trafiły do ​​repozytoriów Debiana, Fedory i Ubuntu, oszczędzając tym samym produktywnym użytkownikom Czarnego Poniedziałku. Pozostaje pytanie, co to usunięcie mówi o zarządzaniu jądrem, a co ważniejsze, o przyszłości systemów plików. Nagłe usunięcie Bcachefs z jądra Linuksa 6.18: Prawdziwe powody Wszystko wynika z konfliktu dotyczącego stylu kodowania i komunikacji między Kentem Overstreetem a zespołem głównym. Linus Torvalds tolerował integrację w wersji 6.7 „na wszelki wypadek”, a następnie zamroził wkład od wersji 6.17. Kolejne okno scalania potwierdziło werdykt: czyste i proste usunięcie.Oficjalny argument: „zmniejszenie zamieszania”, ponieważ moduł DKMS jest gotowy. Nieoficjalnie przypomina, że ​​żaden projekt nie może zignorować procesu współpracy, jakkolwiek obiecującego by on nie był. Dodatkowo, jądro oszczędza 350 KB na obrazie ISO, co jest ukłonem w stronę tych, którzy wciąż preferują minimalistyczny rozruch. Natychmiastowy wpływ na Red Hat, Canonical i pochodne Red Hat nigdy nie włączał domyślnie Bcachefs, preferując ostrożność odziedziczoną po RHEL. Canonical

omawiał to w swoim instalatorze „Ubuntu Pro”, ale już liczył na ZFS do natywnego szyfrowania. Po stronie Fedory, nocne testy uwzględniały Bcachefs od marca; Fedora 40 przejdzie zatem na moduł DKMS, podobnie jak współczesny Debian Sid. Ryzyko? Aktualizacja jądra, która pomija rekompilację modułu na serwerze produkcyjnym. Konserwatorzy zalecają zablokowanie wersji lub użycie Ansible do weryfikacji obecności pliku .ko po każdym restarcie. Proces, którego niektórzy nie doświadczyli od czasów sterowników Nvidia 96xx.Sprawdzone alternatywy: Ext4, XFS i ZFS trzymają poprzeczkę Według badania StackShare, w 2025 roku Ext4 pozostanie domyślnym wyborem dla 80% instalacji serwerowych. Jego solidność i niskie obciążenie procesora sprawiają, że jest on bezkonkurencyjny w przypadku obciążeń konteneryzowanych.XFS

wygrywa we wdrożeniach z bardzo dużymi plikami dzięki imponującej, ciągłej alokacji.

ZFS

zachowuje przewagę migawek i deduplikacji online, nawet jeśli licencja CDDL nadal ogranicza jego integrację z główną linią. Najnowsze testy porównawcze na Ryzen 9000 pokazują różnicę zaledwie 3% w odczytach sekwencyjnych w porównaniu z Bcachefs, co jest nieznaczną różnicą w porównaniu z komfortem oficjalnego wsparcia.

Czy warto migrować, czy pozostać przy Bcachefs jako module DKMS?

Klastry, które już korzystają z Bcachefs, nie są skazane na porażkę. Moduł DKMS kompiluje się w 40 sekund na wirtualnym procesorze (vCPU), a kompatybilność sięga jądra 5.15 LTS. Jednak każda większa aktualizacja będzie wymagała ręcznego punktu kontrolnego: testu przywracania, przebudowy RAID, walidacji sum kontrolnych. Pokusa powrotu do Ext4 jest silna dla małych zespołów. Jednak rezygnacja z CoW i sum kontrolnych zwielokrotnia liczbę zapisów i zużycie dysków SSD. Prawdopodobny kompromis: konwersja woluminów krytycznych do ZFS przy jednoczesnym zachowaniu Bcachefs na efemeryczne pamięci podręczne obiektów, gdzie kompresja LZ4 nadal się sprawdza. Ta saga ujawnia kulturę jądra Linuksa. Przez 30 lat jądro ewoluowało w tempie zestawu poprawek co dziewięć sekund. Linus Torvalds przypomniał nam: drzwi są otwarte dla każdego kodu, ale debata pozostaje publiczna i czasami gorąca. Bcachefs nie jest ani pierwszym, ani ostatnim, który doświadczył tej naturalnej selekcji; przypomnijmy sobie Reiser4 czy Tux3. Społeczność postrzega to usunięcie jako wyraźny sygnał: liczba i jakość testów są ważniejsze niż genialność projektu. Opiekunowie podsystemów z zadowoleniem przyjmują to, ponieważ zaległości w błędach dotyczących pamięci masowej już się zmniejszają. Jak na ironię, szum wokół usunięcia zapewnia Bcachefs widoczność, której nie miał jego pierwotny commit.Czy kiedykolwiek powróci?

Kent Overstreet nie powiedział jeszcze ostatniego słowa. Pracuje nad wersją „bcachefs-next”, zgodną ze stylem jądra i konwencjami testowania. Jeśli uda mu się zmobilizować grupę zadaniową recenzentów, drzwi do wersji 6.20 mogą się otworzyć.

W międzyczasie administratorzy muszą wybrać: śledzić wydania DKMS czy wzmocnić swoje zasoby, korzystając z trzech historycznych filarów. W świecie, w którym liczy się każda milisekunda operacji wejścia/wyjścia, decyzja nie jest podejmowana pochopnie, ale odyseja wolnego miejsca na dysku trwa, łatka po łatce.

Źródło: linuxnews.de