Názory k článku
Bcachefs nebude už v jádře 6.17?

Takže na to ve výsledku opět doplatí uživatelé.

To asi nebude tak jednoznačná odpověď. Na problémy filesystému také doplatí(doplatili) uživatelé.

Dle meho nazoru by bylo chybou, pokud by se tak opravdu stalo. Bcachefs by jednou mohl byt pro linux ten pravej "next gen" filesystem...

A rozdil mezi btrfs a bcachefs je jakej prosim?

(jediny co me chybi na btrfs je explicitnejsi pooling - at jde nastvit na metadata aby byli na SSD a napr pro soubory mensi nez X taky)

A integrované šifrování, ale na tom se taky dělá https://lore.kernel.org/linux-btrfs/20240124195831.GA1212739@perftesting/T/

Bcachefs je tak na experimentování, v produkčním prostředí ho nikdo, kdo je při smyslech nepoužívá (snad). I sám Linus lituje jeho zařazení do jádra. Tak si myslím, že v 6.17 na beton nebude. IMHO, je to dobré rozhodnutí, vzhledem k problémům se samotným souborovým systémem a i kvůli problémům Kenta, který se odmítá podřídit pravidlům vývoje.

To je jak telenovela už :)

Nevím, asi bych to trochu zrelaxoval přesně z toho důvodu, že je to pořád označené coby "experimentální" filesystém.
Čímž neříkám, že se nemají i klidně detailně rozebírat, kontrolovat a rozporovat jednotlivé patche (tzn ne slepě pullovat všechno). Ale asi bych se v tomhle stavu věci tak úplně nefixoval na okna vydávání. Což zas dává velký smysl, jestli se to někdy dostane do produkční fáze.

Ale to je samozřejmě jen moje kecání v diskuzi, neznám další detaily, ani co si případně psali mimo to odkazované vlákno. A mám svým způsobem pochopení i pro Linuse, jestliže se mu pořád vrací problémy s Bcachefs, co pak musí rozhodovat a teď třeba přemýšlí, jestli to nezařadil moc brzy a neměl to nechat ještě nějakou dobu bokem.
Obecně to bude možná někdy fantastický fs, ale je zároveň komplexní a v tuhle chvíli má prostě obrovský bus factor, deset let na něm nedělá nikdo jiný než Kent.

To cca dvouměsíční release okno je pro experimentální FS, který by produkčně nikdo používat neměl, takový problém? Ten, kdo chce přispět k vývoji, stejně potřebuje řešit vlastní jádro a tedy kernel release ho netrápí. A ti ostatní se můžou podívat a vyzkoušet, ale na to není potřeba tlačit někam změny za každou cenu.

Tohle není poprvé, co se Kent snaží ignorovat release cyklus, takže se tu nedá říct "je to nějaká důležitá výjimka". Když nebude Linus vynucovat štábní kulturu, začnou mu takovéhle nečekané velké změny na poslední chvíli posílat i další a riziko poroste.

Ano v tomhle máte asi pravdu se štábní kulturou. Netuším kolik podobných velkých změn u experimentálních modulů musí/musel Linus řešit, ani jestli si tohle opravdu vyžaduje výjimku (rozhodně to nevypadá jako bugfix) z těchhle pravidel.

Bral jsem to čistě ze svého hlediska, kdy prostě když je něco označené jako experimentální a relativně rapidně se to vyvíjí, tak k tomu přistupuji trochu tolerantněji, a vlastně mě až tak moc nezajímají nějaké další cykly, pokud ta konkrétní úprava dává smysl.
I když jasně, jestliže tohle chce někdo aktivně testovat a chce to co nejrychleji, může si také nejspíš sestavit z jiné pracovní větve.

Ono nejde jen o samotný Bcachefs. Ta změna teoreticky může rozbít něco jiného. Ano, nemělo by. Ale i kvůli tomu se dělá několik kol RC verzí. Dávat změnu do pozdější RC znamená, že se lidé s dostatečnou váhou slova zaručí za to, že to nic nerozbije. Opravdu je tohle změna, která v tuhle chvíli má vyžadovat pozornost takových lidí?

Pro specificke veci se vzdy da pouzivat out-of-tree model, hlavne kdyz je to one-man-show. Zarazeni do jadra by pak bylo jen v pripade, ze se to opravdu pouziva vsemi nebo alespon vetsinou uzivatelu.

Myslim, ze kdyby se vice produkcniho kodu drzelo mimo jadro - tak by taky doslo ke zklidneni vyvoje samotneho jadra a nerozbijelo se porad nejake API :) takto, kdyz je mimo jadro pouze "ctvrta cenova" tak jsou sily velice asymetricky rozlozeny.

Je cas vyhrabat ten mikrokernel od "konkurence" :D

Model "vsemi nebo alespon vetsinou uzivatelu" neni aplikovatelny ani na ty filesystemy. Natoz treba na ovladace zarizeni, zeano :-) Pokud by lpelo i jen na te vetsine uzivatelu, nezaclenite nikdy nic...

30. 6. 2025, 13:52 editováno autorem komentáře

To je slovo do pranice :) Chápu, ale asi na to nemám takhle jednoznačný názor. S těmi out-of-tree moduly může být prakticky pěkný opruz (mám to od ZFS, přes NV ovladače, až po komerční, proprietární moduly od filesystémů nebo nějaké forky jádra pro SoC). Otázkou je, pokud by jich bylo řádově víc, jestli by to skutečně v rámci vývoje jádra něco zklidnilo.. a potom i kompatibilita mezi distribucemi by mohlo být vcelku peklo.

Z hlediska procesu a vývojového modelu nikdy nic jako experimentální status neexistovalo, je to spíš pro uživatele. Pravidla pro to, co je v -rc přijatelné, se neměnila léta (https://yarchive.net/comp/linux/merge_window.html), občas něco uteče, a kdokoli může dostat pojeb "tohle patří do příštío cyklu". Časem se to ustálí, každý maintainer ví, co a jak a funguje to dlouhodobě dobře. Linus přímo pulluje od cca 70 lidí, pro názornost https://lwn.net/Articles/981742/ , krát počet -rc. Nemuset se moc zabývat každým jednotlivě je nutnost.

Dík za vysvětlení a odkazy.