A Linux kernel levelezőlistán ismét feszültségek alakultak ki, miután a Bcachefs fájlrendszer fejlesztői késői új funkciókat próbáltak becsempészni a 6.16-os kernelciklus „javítások” címszó alatt beküldött kódjaiba. A kernelfejlesztés megszokott rendje szerint új funkciók csak az úgynevezett „merge window” alatt kerülhetnek be, amely a 6.16-os ciklusra vonatkozóan már közel két hete lezárult. A Bcachefs fejlesztői azonban kivételt szeretnének, mivel szerintük ezek az újdonságok adatbiztonsági szempontból szükségesek.
Tartalomjegyzék
Torvalds elutasítja a merge ablakon túli funkciók beolvasztását
A hétvégi 6.16-rc3 verzióba szánt legfrissebb Bcachefs csomag tegnap került beküldésre. Néhány kisebb ellenőrzési és javítási módosítást, valamint regressziós hibák javítását tartalmazza, de egy új funkció is szerepel benne: a „journal_rewind”. Ez lehetővé teszi, hogy a fájlrendszer egy korábbi állapotba legyen visszaállítható, így egyfajta „katasztrófa” utáni helyreállítási eszközként szolgálna. Bár még nem teljesen kész, és ismert korlátai is vannak, a cél, hogy előrelépést jelentsen a Bcachefs megbízhatóságában.
A pull requestre válaszul Linus Torvalds így reagált:
„Úgy tűnik, megint elfelejtetted, mi értelme van a merge ablaknak. Nem kezdünk el új funkciókat hozzáadni csak azért, mert találtál más hibákat. Továbbra is meg vagyok győződve róla, hogy aki a bcachefs-t használja, az számít rá, hogy kísérleti. Legalábbis jobb, ha így van. Az rc javítások maradjanak tisztán hibajavítások.”
Erre válaszul a Bcachefs vezető fejlesztője, Kent Overstreet az alábbi választ közölte:
„A cél az, hogy a felhasználók működő kódot kapjanak, nem igaz? Őszintén szólva, a legtöbb felhasználó, akit én látok, egyszerűen csak egy olyan fájlrendszert akar, ami működik. Nagyon sokan megégették már magukat a btrfs-sel. Sőt, mostanában egyre több beszélgetésben látom, hogy az emberek az XFS esetében (!) is helyrehozhatatlan fájlrendszerekről beszélnek. Ez engem is meglepett, és nem is gondolom, hogy a kód minőségével lenne baj, de intő jelnek kellene lennie arra, hogy mennyi minden esik ki a réseken és milyen rosszul állunk.
Sokan még mindig nem akarnak elmozdulni az ext4-től – és ezt meg is tudom érteni.
Ha rákeresel, nem fogsz ilyen történeteket találni a bcachefs-ről – kivéve ha én mondom el, hogy mire kell odafigyelni. És ez egy csomó kemény munka eredménye, mert eltökélt szándékom, hogy nem ismétlem meg a múlt hibáit. Aktívan vadászom a hibajelentéseket, és gyakran mondom az embereknek: ’Nem érdekel, hogy szerinted hardverhiba vagy user error, a fájlrendszer dolga, hogy ne veszítsen adatot; add meg nekem az infót, amire szükségem van, és én megoldom.’ Ez a cél: olyasmit szállítani, amiben a felhasználók megbízhatnak.”
Egy másik megjegyzésre, amely szerint a merge ablak időszakai előre jól ismertek, Overstreet így válaszolt:
„Ez egy könnyű szabály a kernel többi részénél, ahol a hibáid egy újraindítással eltűnnek. A fájlrendszereknek nincs ilyen luxusuk. A múltban többször is kénytelen voltam új lemezen tárolt formátum-funkciókat rohamtempóban bevezetni, hogy megelőzzem a kialakuló problémákat – a btree bitmap a taginformációs szekcióban például különösen emlékezetes volt, de teljes mértékben bizonyította a hasznát.
Szerencsére most már messze vagyunk ettől. Most egy kb. 70 soros patchről beszélünk, amely csak annyit csinál, hogy a naplóból nem a frissítéseket, hanem a felülírásokat választja ki, és visszafelé rendezi őket.
És most jöhet a következő kérdés: miért nem hagyjuk ezt egy külön ágban, azoknak, akiknek szüksége van rá, a következő merge ablakig?
Sok felhasználónak már az is túl nagy kérés, hogy lefordítson egy kernelt valami véletlenszerű git tárolóból. Rengeteg időm megy el arra, hogy kvázi támogatást nyújtsak – ez ma már így megy. De az rc kiadásokat a legtöbb disztribúció becsomagolja, és egyszerűen nem akarunk még három hónapot várni, hogy ez bekerüljön a következő stabil verzióba – különösen, ha ez lehet a különbség egy elveszett és egy megmentett fájlrendszer között.
Van még pár patch tracepointokhoz és introspekciós fejlesztésekhez is; nem tudom, Linus ezekre is utalt-e. De ezek is fontosak.
Legalább annyira gondolok arra, hogy ’hogyan tehetem a kódbázist könnyen debuggolhatóvá, karbantarthatóvá, valós környezetben is tesztelhetővé’, mint magára a hibakeresésre. Ugyanolyan fontos. Ez részben arról szól, hogy gyors visszacsatolási ciklust alakítsak ki köztem és a hibákat jelentő felhasználók között – ez bizalmat épít, közösséget teremt, és lehetőséget ad arra, hogy megtanítsam őket jobb tesztelésre és hibabejelentésre.
És sosem szűnök meg csodálkozni azon, hogy amikor hozzáadok egy naplózást vagy fejlesztek egy tracepointot, egy héttel később pont arra van szükségem máshol.
Más szóval – nem csak az számít, hogy kijavítjuk a hibákat, hanem az is, hogy hogyan tesszük ezt.
Eszközök a javításhoz, eszközök a hibakereséshez – az egész csak eszközökről szól, egészen a legmélyéig…”
Végül ezt is hozzátette:
„Megvan az ideje és helye a szabályoknak, és megvan az ideje és helye annak is, hogy az ember használja az eszét és józan ítélőképességét. Én vagyok az, aki felelős azért, hogy a bcachefs felhasználóknak működő fájlrendszerük legyen. Ez azt jelenti, hogy elolvasom és válaszolok minden hibajelentésre, és nyomon követem, hogy mi működik és mi nem az fs/bcachefs/ könyvtárban. Nem te, és nem Linus.
Nincs szükség erre a mikromenedzselésre, amivé ez az egész vált. Csak konfliktust és drámát szül.”
Funkcionalitás vagy fegyelem?
Ez a helyzet jól példázza a nyílt forráskódú fejlesztés egyik klasszikus feszültségforrását: a stabilitás és a rugalmasság közötti ellentétet.
Linus Torvalds álláspontja teljesen érthető: a kernel fejlesztésének szabályai nem öncélúak, hanem a minőségbiztosítást és az előrejelezhetőséget szolgálják. A „merge window” rendszere azért van, hogy az új funkciók jól tesztelhetők legyenek, és a későbbi RC szakasz már tényleg csak hibajavításokról szóljon. Ha ezt a szabályt valaki rendszeresen áthágja, az precedenst teremt, ami gyengítheti az egész modell stabilitását.
Kent Overstreet reakciója ugyanakkor szintén jogos szempontokat vet fel. A fájlrendszerek világa érzékeny: ha egy kernelmodul hibásan működik, egy újraindítás megoldás lehet; de ha egy fájlrendszer hibás, adatvesztés történik. Ebben az értelemben a Bcachefs fejlesztője egy gyakorlatias megközelítést képvisel, amely szerint az elérhető RC kernelekbe való bekerülés már most sok felhasználónak nyújtana biztonságot — és szerinte a beküldött változtatás éppen ezt szolgálja.
A gond az, hogy ez nem egy technikai vita, hanem egy bizalomvita is: Linus úgy érzi, valaki megint megpróbálja kiskapukon átvinni az akaratát. Kent Overstreet szerint pedig a szabályt betartani „elvi” kérdés, de az adatvesztés megelőzése valós tét.
Személyes véleményem az, hogy Kent Overstreet érvei a fájlrendszerek különleges státuszáról jogosak, és valóban lehetne keresni egy rugalmasabb, de dokumentált kivételkezelést például fájlrendszer-helyreállítást célzó, kis méretű és tesztelt patchek esetére. Ugyanakkor az, ahogy Overstreet az egyensúlyt felborítja a „mindent a felhasználókért” zászló alatt, végső soron a közösség működését is veszélyeztetheti, ha ezzel felold minden strukturált határt.
Az optimális megoldás valószínűleg az lenne, ha Overstreet proaktívan előre jelezné, milyen funkciók érkeznek, és azok bekerülésére kialakulna egy külön elbírálási mechanizmus — például egy „fájlrendszer-specifikus kivételi eljárás” a merge ablakon kívüli adatbiztonsági fejlesztésekhez. Így elkerülhető lenne a nyilvános súrlódás, és közben a fájlrendszer fejlesztése is gördülékenyebb lehetne.
A cikk írásának idején Linus Torvalds még nem vonta be a journal_rewind funkciót tartalmazó Bcachefs pull requestet a Linux 6.16 kódjába.
