Folytatódik a háború a Bcachefs körül - de van még visszaút?

Kernel

tl:dr;

  • Igen, BcacheFS (erősen valószínű, hogy) ki lesz rakva a kernelből (6.17-től).
  • És nem, nem technikai okokból, hanem személyi és közösségi konfliktus miatt.
  • Ez hosszú távon azt is jelentheti, hogy a fájlrendszer elhal – hacsak valaki más át nem veszi.

Hosszabban:

BcacheFS kontra Linus Torvalds – A Linux kernelből való kizárás története

Kérdés: Ez azt jelenti, hogy Linus kirúgta a BcacheFS-t a kernelfából?

Válasz: Röviden: igen, úgy tűnik, hogy Linus Torvalds de facto kirúgta a BcacheFS-t a Linux kernelből – legalábbis a 6.17-es verziótól kezdve, ha nem történik valami nagyon komoly fordulat.

Mi történt?

  • Linus Torvalds kijelentette: „we’ll be parting ways in 6.17”, és „we’re done”. Ez egyértelmű utalás arra, hogy a fájlrendszer ki fog kerülni a fő kernelből.
  • Kent Overstreet (a BcacheFS fő fejlesztője) visszavágott: „I positively enjoy working with you - when you’re not being a dick.” Ez tovább fokozta a konfliktust.
  • Ez nem új – 2023 végén a Linux Code of Conduct egy hónapra már el is tiltotta Kentet.

Technikai háttér

A BcacheFS egy ambiciózus, CoW-alapú fájlrendszer, amely olyan funkciókat integrál, mint:

  • Beépített cache és journaling
  • Snapshot támogatás
  • Inline tömörítés
  • Checksumming és multi-thread I/O

A kritika nem az architektúrát érte, hanem a kód minősége és a kommunikációs stílus volt problémás.

Mi következhet?

  • A BcacheFS várhatóan kikerül a Linux kernel 6.17-es verziójától.
  • Ha nem lesz új maintainer, vagy Kent nem változtat hozzáállásán, a fájlrendszer halálra van ítélve.
  • Alternatíva lehet: külön patchként fenntartani, vagy egy disztribúcióban külön támogatni.

Frissítés – 2025. július

Kérdés: Meggondolta magát Linus? Lesz még esély BcacheFS-nek?

Válasz: Nem. A legfrissebb források szerint Linus nem hátrált meg, a 6.17-es kernelből való kizárás továbbra is érvényben van.

Források (2025. július)

Összegzés

Kérdés Állapot
Linus visszavonta a döntést? Nem
BcacheFS a 6.17-es kernelben? Nem
Van esély a visszatérésre? Jelenleg minimális

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( ulysses v | 2025. 07. 04., p – 09:14 )

Elkezdtem olvasgatni a levelezést, egészen szép baráti bazmegelős csevegés lehetne belőle egy sör mellett, de alapvetően jogosnak tűnik Linus baja. Kent, a bcachefs karbantartója ugyanis egy recovery toolt akar betolni a 6.16-ba, de az RC1 után Linus már csak javításokat fogad be, nem új fícsőröket. Ezt az első válaszoló meg is mondja neki, hogy nem technikai problémák vannak elsősorban, hanem magasról tesz a kernelfejlesztés megszokott workflowjára.

( kikadff v | 2025. 07. 04., p – 09:17 )

A bcachefs kódminőségével kapcsolatban az alábbi problémák merültek fel:

 * Instabilitás és kísérleti jelleg: Több forrás is instabilnak és kísérletinek tartja, nem javasolják éles rendszerekben való használatát. Gyakori, hogy a felhasználóknak a legújabb kernelre kell frissíteniük a kritikus hibajavításokért. Linus Torvalds maga is megbánta a bcachefs beolvasztását a fő kernelbe.

 * Gyakori és kiterjedt javítások: A fejlesztés során túl gyakran és kiterjedten nyújtanak be javításokat, amelyek inkább új funkciók fejlesztésének tűnnek, semmint hibajavításoknak, és ez ütközik a kernel kiadási szabályaival.

 * Adatvesztés és adatkorrupció: Aggodalmak merültek fel az adatvesztéssel és az adatkorrupcióval kapcsolatban. Konkrétan említik az "inode_not_unlinked" hibákat, lassú felülírásokat snapshotok esetén, írásvédetté váló fájlrendszert hash tábla hibák miatt, adatkorrupciót "Journal stuck" üzenetekkel, és "misaligned write" írási hibákat. Deadlockok is előfordultak fsck futtatása közben.

 * Zárolási kód problémák: Linus Torvalds különösen aggodalmát fejezte ki a zárolási kóddal kapcsolatban, és kifogásolta a nagy, monolitikus "pull request"-eket (egyesített kódbeadványokat).

 * Éretlen felhasználói eszközök: A fájlrendszerhez tartozó felhasználói térbeli (userspace) eszközök éretlennek, kiforratlannak minősülnek.

 * Kommunikációs stílus: Bár közvetlenül nem kódminőségi probléma, a fejlesztői kommunikáció stílusa is hozzájárult a projekt megítéléséhez, feszültségeket és konfliktusokat okozva, ami közvetve befolyásolhatja a kódminőségről alkotott képet.

- by Gemini.

A zárolási kód (angolul locking code) a számítógép-programozásban használt kódgyűjteményre utal, amely biztosítja, hogy több, egyidejűleg futó folyamat vagy szál ne férjen hozzá egyszerre ugyanazokhoz az adatokhoz vagy erőforrásokhoz, és ne okozzon így inkonzisztenciát vagy adatkorrupciót.

Működése és fontossága

Képzeld el, hogy több ember próbál egyszerre írni ugyanabba a dokumentumba anélkül, hogy tudnának egymásról. Valószínűleg összevisszaság lenne a végeredmény. A zárolási kód pontosan ezt akadályozza meg szoftveres környezetben.

Amikor egy program több szálon fut (például egy webböngésző, amely egyszerre több lapot is betölt, vagy egy operációs rendszer, amely egyszerre több alkalmazást is futtat), ezek a szálak gyakran ugyanazokat a memóriaterületeket vagy fájlokat akarják elérni. Ha két szál egyszerre próbálja megváltoztatni ugyanazt az adatot, az úgynevezett versenyhelyzet (race condition) jöhet létre, ami kiszámíthatatlan és hibás eredményekhez vezethet.

A zárolási kód különféle mechanizmusokat (például mutexeket, szemaforokat, spinlockokat) használ annak biztosítására, hogy egy adott kritikus szekcióba (ahol az adatok módosítása történik) csak egy szál léphessen be egyszerre. Amikor egy szál belép egy ilyen kritikus szekcióba, "zárolja" az erőforrást, és csak akkor oldja fel a zárat, ha végzett vele, így a többi szál addig várni kénytelen.

Problémák a zárolási kóddal

A zárolási kód helyes implementálása rendkívül komplex feladat. A hibásan megírt zárolási kód súlyos problémákat okozhat:

 * Deadlock (holtpont): Két vagy több szál kölcsönösen vár egymásra, és egyik sem tud továbbhaladni. Például az A szál vár a B szál által tartott zárat, miközben a B szál vár az A szál által tartott zárat.

 * Livelock (élő holtpont): A szálak folyamatosan változtatják az állapotukat, de nem haladnak előre a feladatukban, mert állandóan próbálják elkerülni egymást, vagy ütköznek a zárolási szabályokkal.

 * Starvation (éheztetés): Egy vagy több szál soha nem jut hozzá egy erőforráshoz, mert a többi szál folyamatosan elfoglalja azt.

 * Performancia romlás: A túlzott vagy rosszul optimalizált zárolás jelentősen lelassíthatja a program végrehajtását, mivel a szálaknak sokat kell várniuk egymásra.

Linus Torvalds, a Linux kernel fő fejlesztője, gyakran rendkívül szigorúan ellenőrzi a kernelbe bekerülő zárolási kódot, mert annak hibái súlyos rendszerösszeomlásokat, adatvesztést és performancia problémákat okozhatnak. A bcachefs esetében valószínűleg ezek a problémák merültek fel, és aggodalmakat váltottak ki a kód stabilitásával kapcsolatban.

-by Gemini.

Nice: 

Pillanatnyilag nincs külön beállítási felület, ahol előre megadhatnád a preferenciáidat. A beállításokat és azt, hogy hogyan válaszoljak, a veled való kommunikáció alapján tudom alakítani.

Egyszerűen csak mondd el nekem, mit szeretnél:

 * Emlékeztesselek valamire? Például, "Kérlek, emlékezz arra, hogy a cégem neve 'XYZ Innovációk'."

 * Változtassak a válaszaim stílusán? Például, "Kérlek, próbálj meg tömörebben fogalmazni." vagy "Légy egy kicsit barátságosabb a hangnemben."

 * Töröljek egy korábbi információt? Például, "Kérlek, felejtsd el azt a címet, amit korábban megadtam."

Ezeket a kéréseket igyekszem figyelembe venni a jövőbeni válaszaim során.

------

A zárolási kód (angolul locking code) a programozásban arra szolgál, hogy szinkronizálja a párhuzamosan futó folyamatokat vagy szálakat, megakadályozva, hogy egyszerre módosítsák ugyanazt az adatot vagy erőforrást. Ez létfontosságú az adatkonzisztencia és a rendszerstabilitás fenntartásához.

Problémák a zárolási kóddal:

A zárolási kód hibás implementálása súlyos következményekkel járhat, mint például:

 * Holtpont (deadlock): Szálak kölcsönösen várnak egymásra.

 * Élő holtpont (livelock): Szálak folyamatosan változtatják az állapotukat, de nem haladnak előre.

 * Éheztetés (starvation): Egy szál sosem jut hozzá egy erőforráshoz.

 * Teljesítményromlás: Felesleges várakozások miatt lelassul a program.

Linus Torvalds aggodalmai a bcachefs zárolási kódjával kapcsolatban valószínűleg a fenti kockázatokra vonatkoztak, kiemelve a kernel stabilitásának fontosságát.

Ezért használok ChatGPT Plus-t:

Beállítások → ChatGPT testreszabása

A Beállítások → ChatGPT testreszabása menüpontban két fő dolgot állíthatsz be:

  1. Személyiség hangolása – Megadhatod, hogy a ChatGPT milyen stílusban kommunikáljon (pl. tömör, barátságos, professzionális, szókimondó stb.).

  2. Téged érintő infók megosztása – Beírhatsz olyan adatokat (pl. neved, munkaköröd, preferenciáid), amelyeket az asszisztens figyelembe vesz, hogy személyre szabottabb választ adjon.

És:

Mentett memória:

A Mentett memória funkció arra szolgál, hogy tartósan megjegyezzek rólad bizonyos információkat – például a neved, szereped, preferenciáid vagy visszatérő témáid –, hogy hosszabb távon is személyre szabottabb válaszokat adhassak.

Fő funkciói:

  • Automatikus tanulás: Ha észreveszem, hogy gyakran említesz valamit (pl. a munkaköröd vagy írási stílusod), felajánlom, hogy elmentsem.

  • Kézi szerkesztés: A Beállítások → Mentett memória menüpont alatt bármikor megnézheted, módosíthatod vagy törölheted ezeket az adatokat.

  • Teljes kikapcsolás: Ha nem akarod, hogy bármit is megjegyezzek hosszú távon, a memóriafunkció teljesen kikapcsolható.

Fontos: az aktuális beszélgetésen belül nem a memória, hanem az adott kontextus alapján válaszolok. A memória inkább a több beszélgetésen átívelő „emlékezésre” való.

trey @ gépház

Pl:

Milyen képességei legyenek a ChatGPT-nek?

Nálam a beállítása: Vitázó, érvelő. Egyenes, szókimondó. Tömör, sallangmentes.

Ja, a mentési funkció triggerelhető, pl.:

Összefoglaló:HTML

A beszélgetés témájáról egy Drupal Teljes szöveg -> Forrás kompatibilis összefoglalót kérek letisztult HTML-bem és az alján egy Discaimer szöveggel: 

<i><p>(A cikk nyomokban <a href="https://hup.hu/faq/20240804/hasznal-e_a_hup_a_hivatalos_tartalmai_eloal…">Mesterséges Intelligencia által szolgáltatott adatokat</a> tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)<p></i>

Mentsd el.

Válasz:

Memória frissítve!

De ez már lvl 0.2 szint.

trey @ gépház

Mit kérek, ha Összefoglaló:HTML-t írok?

A ChatGPT ezt mondta:

Ha azt írod: „Összefoglaló:HTML”, akkor a következőre kérsz:

Egy tömör, informatív összefoglalót a megadott témáról vagy cikkről, HTML formátumban, amely:

  1. Letisztult, forrás-kompatibilis HTML legyen (pl. Drupal vagy más CMS szerkesztőbe másolható formában),

  2. A tartalom végén szerepeljen egy diszkréten megjelenő disclaimer az MI-forrásról, így:

<i><p>(A cikk nyomokban <a href="https://hup.hu/faq/20240804/hasznal-e_a_hup_a_hivatalos_tartalmai_eloallitasahoz_mesterseges_intelligenciat">Mesterséges Intelligencia által szolgáltatott adatokat</a> tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)</p></i>

Stílusjegyek:

  • Strukturált, könnyen másolható.

  • HTML-ben címek: <h2>, bekezdések: <p>, listák: <ul><li>.

  • Nincs inline CSS vagy felesleges osztály, csak alap HTML-elemek.

  • Nincs sallang, nincs szócséplés – informatív, lényegre törő.

Ha van konkrét szöveg vagy cikk, amit szeretnél összefoglalni ilyen formában, küldd, és átalakítom.

Ezt mondtad:

Melyik oldalra?

A ChatGPT ezt mondta:

A disclaimer, amit a „Összefoglaló:HTML” végére kéred, a HUP-ra (Hungarian Unix Portal) mutat. Pontosabban erre az oldalra:

https://hup.hu/faq/20240804/hasznal-e_a_hup_a_hivatalos_tartalmai_eloallitasahoz_mesterseges_intelligenciat

Ez a link a HUP hivatalos állásfoglalását tartalmazza arról, hogy használnak-e mesterséges intelligenciát tartalmak előállításához.

A disclaimer célja tehát az, hogy a saját cikked végén jelezd: az adott tartalom tartalmazhat MI által generált vagy feldolgozott részeket, ezért érdemes kritikus szemmel olvasni. Ez a HUP közösségi normáival is összhangban van.

trey @ gépház

( Raynes v | 2025. 07. 04., p – 20:34 )

Szerkesztve: 2025. 07. 04., p – 23:56

Meg vagy dicsérve, végre kitetted hírnek. Kicsit AI-s a struktúrája, de alapos hír. Eleve nem lett volna szabad felvenni a kernelbe ezt a Bcachefs-t, túl új, túl kiforratlan, túl instabil. Dolgozza át a fejlesztő a kernelen kívül, hogy alap szinten használható legyen, akkor vegyék vissza a kernelbe, ha már kiforrott, csak apróbb simítások, karbantartás van vele hátra.

Azzal nem értek egyet, hogy a Bcachefs elhal, mert nem lesz a kernelben. Ha a fejlesztő nem hagyja, nem hal az el. A ZFS sincs a kernelben, igaz annál a licencprobléma szól közbe, de attól él és virul.

Persze ezt Kentet sajnálom, kezdtem már megkedvelni. Milyen lazán le-dick-ezte Linus-t, azóta ezen röhögök.

Egy valamit viszont nem értek. A kifogásolt patch most mégis befogadásra került, megjelenik a 6.16-os kernellel, de minek, ha a 6.17-ben már nem lesz benne? Mert az tuti, hogy Linus kidobja ezt az ürgét, már nem először fenyegetőzik vele, most is megígérte, már csak azért is tartani fogja, hogy ne tartsák gyengekezűnek, hanem számítsanak rá, hogy amit ő megmond, hogy úgy lesz, az úgy lesz.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( arpi_esp v | 2025. 07. 05., szo – 09:10 )

valaki leirna (megkerdezne valamelyik draga ai-t) hogy miert is lenne jobb ez a bcachefs a btfrs-nel?

https://g.co/gemini/share/11cfc89711bf

De óvatosan fogadd el a válaszát, mert már az első félmondat is nettó hazugság. ("A megadott cikk jelenleg nem elérhető") :)

szerk: https://chatgpt.com/share/6868e14c-4254-8006-a8b1-0e861445bf90

Lényegében nem jobb, a Btrfs-nek javítaná néhány hiányosságát, amit itt felettem soroltak, de ez mind csak álmodozás, meg terv. Szerintem teljesen felesleges is, inkább a Btrfs fejlesztésébe szált volna be ez az Overstreet.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( influencer | 2025. 07. 05., szo – 23:10 )

Kellene egy új generációs Linux kernel, ahol nem kell mindenféle támogatást a kernelbe beletenni, hogy elérhető legyen. Tudom, nyilván van oka, hogy így van, de ezeket az okokat más szemszögből megközelíteni és új koncepciót kitalálni.

Nem értem, hogy ezt hogyan érted. A Linux kernel monolitikus, benne kell lennie minden drivernek, ha más nem, külön forgatott, és utólag felcsatolt modul formájában. Ha nem teszed a kernelbe, akkor honnan lesz elérhető? 

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Ideális lenne más, mikrokernel, vagy eddig még nem implementált működés. Például hogy egy module manager berántja a szükséges drivereket, de önmagában a kernelben nincs benne a driver támogatása. Ha így működne, akkor bármilyen régi driverrel ami ilyen másik kernel kompatibilis, a legújabb kernel is be tudná tölteni.  A kernel pedig nem lenne nagy méretű azért, mert benne van mindenféle támogatás. Így a régi gépeken is lehetne úgy a legújabb kernel, hogy nem kell manuálisan fordítani hozzá a régi hardver támogatást, amit már kivettek az újabb kernelből. Vagy éppen nem kell régi kernelt használni, ami már évek óta nincs frissítve, mert abban még ott az adott gép hardver támogatása. Ebből a nézetből írtam.

Ebben az a probléma hogy az API-t akkor nagyon stabilan kellene tartani, a Linux esetében viszont úgy döntöttek hogy fontosabb hogy gyorsan lehessen haladni mintsem hogy évtizedekig kompatibilisek legyenek olyan eszközökkel, amit már valójában csak pár ember használ. Ilyen szempontból pl. a Huawei és társai sokkal jobb helyzetben vannak, ők mikrokernel-t használnak, viszont teljesen kontrollálják mind a HW-t, mind a támogatás hosszát. 

De Fenyő bával annak idején már lemeccselte ezt Linus. Ettől függetlenül egyrészt ott van a FUSE, másrészt el lehetne menni egy hibrid irányba, hogyaszondja, el kellene kezdeni bizonyos eszközosztályokhoz valami stabil inerfészt heggeszteni, hogy akik futottak még, de jó lenne valami Linux támogatás jó sebességgel, azok legyenek szívesek azt használni.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Az nem Fenyő bá, hanem Karácsonyfa bá.

Ez a Kent Overstreet azt írta, hogy a FUSE nem alkalmas neki FS fejlesztésre, sok tesztje meg debugja nem megy vele.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Részben. A Weihnachtsbaum is karácsonyfa, de a Tannenbaum is. A fenyő az a Tanne.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”