Bestandssysteem bcachefs blijft in Linux-kernel, maar wordt enkel extern beheerd

Bestandssysteem bcachefs wordt voortaan alleen nog door externe partijen beheerd. Linux-hoofdontwikkelaar Linus Torvalds heeft de status van de ontwikkeling voor maintainers aangepast naar 'extern beheerd'. Dat betekent dat het filesystem nog wel in de Linux-kernel zit, maar dat Linux-makers geen pullrequests meer behandelen.

Linus Torvalds schrijft dat in een bericht aan Linux-kernelmaintainers. "Markeer bcachefs als extern beheerd", schrijft hij. Hij verwijst daarbij naar 'lange discussies, publiek en privé'.

In de praktijk betekent dat vooralsnog weinig voor gebruikers van het bestandssysteem in Linux. Bcachefs blijft weliswaar in de oudere kernels zitten, maar het is nog niet duidelijk of dat in de toekomst nog wel gebeurt. Eerder dit jaar liet Torvalds al weten dat hij bcachefs niet in Linux-kernel 6.17 wilde hebben, al is de status daarvan momenteel niet duidelijk. In ieder geval gaan Torvalds en andere kernelontwikkelaars zelf niet meer verder met het doorontwikkelen van bcachefs.

Bcachefs is een opensource copy-on-writebestandssysteem dat eind 2023 werd toegevoegd aan de Linux-kernel. Sindsdien liggen Linux-ontwikkelaars, waaronder Torvalds, in de clinch met ontwikkelaars van bcachefs. Het gaat onder andere om verschillen van mening over de stabiliteit en releaseschema's van het bestandssysteem. Torvalds liet eerder al weten daarom niet meer mee te werken aan het beheren ervan.

Reacties (58)

[johnbetonschaar]

Het gaat onder andere om verschillen van mening over de stabiliteit en releaseschema's van het bestandssysteem.

Volgens mij is dit niet het hoofdprobleem met bcachefs hoewel hier wel al heel wat verhitte discussies over geweest zijn op de Linux kernel mailing lists. Maar dat is bij wel meer subsystemen en drivers zo.

Het grote probleem met bcachefs is eigenlijk helemaal niet met bcachefs als technologie, maar dat de persoon die het ontwikkelt continu met iedereen overhoop ligt vanwege zijn gedrag en uitspraken over onder meer andere filesystems als BTRFS en over het ontwikkel proces van de kernel zelf. En dit blijft zich continu herhalen ondanks verschillende pogingen om tot een betere manier van samenwerken te komen, maar dus tevergeefs. Inmiddels zijn er al verschillende bepalende kernel devs geweest die zeggen niet meer met de ontwikkelaar van bcachefs te willen samenwerken, en dat de code daarom maar beter uit de kernel verwijderd kan worden omdat het op deze manier niet fatsoenlijk gereviewed en gemaintained kan worden.

[Halfscherp]

Ben je zelf ook maintainer? Want dit is echt een extreem biased perspectief.

Kent wordt op de LKML letterlijk getrolled. Iemand van Facebook vraagt hem iets over BTRFS, hij antwoordt, en vervolgens gaat een andere maintainer onmiddelijk reageren met "zie! hij begint gelijk weer over BTRFS".

Kent is weldegelijk een moeilijk persoon, maar bepaalde maintainers (Ted Tso) staan zelf ook bekend als enorme klootzakken. Ted is zo ongelooflijk vervelend als maintainer dat hij tot twee keer toe een lead Rust dev zover het spits op heeft gedreven dat diegene opgaf en stopte / ontslag nam als hoofd contributor.

[Reactie gewijzigd door Halfscherp op 30 augustus 2025 19:12]

[NaioN]

Zie onderste deel van de wiki:
Wiki BcacheFS

BcacheFS wordt verwijderd, omdat de betreffende developer zich niet aan de richtlijnen houdt. Met name het feit dat hij verwacht dat Linus ALLE patches integraal integreert en hij ook meerdere malen features heeft toegevoegd in de patches voor RC releases, waarin alleen bug fixes zijn toegestaan.

Hij is wel gewaarschuwd op zijn wijze van communicatie, maar dat heeft destijds niet geleid tot het niet accepteren van patches of nu niet tot het "external maintained" verklaren van BcacheFS.

[Halfscherp]

hij ook meerdere malen features heeft toegevoegd in de patches voor RC releases, waarin alleen bug fixes zijn toegestaan.

Als je je wat beter had ingelezen had je gezien dat er enorm gebakkelei is over wat een bugfix vs een feature release is.

Om een voorbeeld te noemen, er was een bepaalde bug die het filesystem ontoegankelijk maakte. Die bug is gefixed, maar om mensen te helpen voor wier het filesystem al ontoegankelijk was is er een bcachefs tools toegevoegd.

Linus vindt dat de bugfix een bugfix is maar dat de tools commit thuishoort in een feature release. Kent wil zijn gebruikers met problemen helpen en vindt dat zowel de bugfix als een herstel van de bug thuishoren in een bugfix release.

Nou geldt hier uiteindelijk wel: Linus is de eindbaas en eigenaar. Je hebt je naar hem te schikken, zelfs als je het totaal niet met hem eens bent en zelfs als hij al dan niet bij het foute eind zit. En daar gaat het bij Kent fout. Want als hij iets meer flex had en er mee kon leven dat de vorige users langer moesten wachten op een bugfix, dan hadden nu alle gebruikers van bcachefs het voordeel van in-tree zijn.

[Makkerman]

Linus heeft toch helemaal gelijk hier of ben ik nou gek? Een tooltje hoort niet thuis in een bugfix, maar is gewoon een feature release.

Leuk dat mensen daarbij zijn geholpen, maar dat is niet de afspraak die gemaakt is voor de ontwikkeling van de kernel. Kent moet zich gewoon aan gemaakte afspraken houden. Punt.

[Halfscherp]

Dat is dus het discussiepunt. Duidelijk is dat een fix voor een bug in een bugfix release hoort. Maar hoort het repareren van de schade van die bug ook bij bugfixen? Kent vindt van wel, Linus niet.

Linus argument is overigens ook dat bcachefs het "experimental" label heeft en dat daarom de gebruikers bugs verwachten, en het daarom minder kritiek is om de reparatie in de handen van gebruikers te krijgen. Kan ik me ook wel in vinden.

[Thijzer]

Alle respect voor Kent zijn tijd, toewijding schap en kunnen, een merkwaardige ontwikkelaar, maar je hoort je wel aan de regels te houden. De kernel is en giga project met duidelijke afspraken, waar iedereen zich moet aan houden.

[Hyronymus]

Ja, waarom houden wij ons nog aan de wet eigenlijk!

[MrFax]

Je snapt mijn punt helemaal niet dus.

[Hyronymus]

Ik had niet door dat je een punt maakte en daarmee miste ik hem.

[johnbetonschaar]

Nee ik volg het alleen op afstand en je hebt inderdaad een punt dat er wel meer aparte karakters zijn, maar de manier waarop Kent er elke keer ingaat en hoe hij voor geen enkele feedback of bijsturing vatbaar is, is gewoon niet te ontkennen. Ik baseer me alleen maar op wat ik op LKML threads langs zie komen en dat is geen goede reclame voor Kent.

[kalikari]

Klopt helemaal dat het soms erg lastig samenwerken is met kernel maintainers. Kent zijn gedrevenheid helpt niet. Als voorbeeld van een ander voorval: ongeveer twee decenia geleden liep Con Kolivas tegen problemen aan met zijn patches voor CPU scheduling. Wikipedia: Con Kolivas

Wat ik ook denk wat inmiddels mee speelt zijn persoonlijke gevoelens. Ook al verbeterd Kent zich, bij sommige maintainers zal dat nooit genoeg zijn. Mijn hoop is dat Kent in 'alle rust' kan doorwerken en dat na verloop van tijd er toch weer een weg terug kan komen. Maar daar waar Kent lastig kan zijn, zijn er ook maintainers die net zo als Kent in elkaar zitten... We gaan het zien. bcachefs heeft de belofte te zijn wat BTRFS had moeten zijn.

[MornixRS]

Behalve dat het hier niet over anderen gaat maar over Kent. Ik denk dat zijn communicatie met Linus Torvalds meer dan genoeg zegt. Hij is het probleem in dit geval. Dat er ook andere moeilijke personen zijn doet niet ter zake. Verder gaat het ook niet om discussie op allerlei platforms maar om de communicatie, eisen en handelen rondom het onderhouden van de code. Ook daar houdt Kent zich niet aan de regels en eist hij zaken met soms ridicule argumenten.

[Superstoned]

Yup. Het hele verhaal laat ook weer zien dat je een beetje social skills nodig hebt om efficiënt samen te kunnen werken - niet alleen in een bedrijf maar ook een open source community.

[D13DS3L]

Communities managen is een vak apart, vooral wanneer het gaat over abstracte onderwerpen als privacy en security waar er niet altijd objectieve waarheden zijn... In de /e/os & grapheneos communities (en vooral de communicatie tussen beide) merk ik dat zelf het ergst, waardoor ik zelf niet meer door de bomen het bos kan zien als ontwerper onder de programmeurs!

[Superstoned]

Ja, dat is zeker ook zo, het is niet zo makkelijk. Nu is de kernel aan de ene kant een enorm grote community, aan de andere kant is het aantal mensen waar je mee moet werken niet zo enorm daar het flink is opgesplitst. Het probleem met Kent lijkt wel redelijk extreem te zijn. Hij is denk ik misschien best geschikt als contributor maar niet als maintainer. Als ie slim was zocht ie iemand die zijn visie deelt maar meer social skills heeft, laat die persoon maintainer zijn, en werkt nauw samen.

Maar daarvoor moet je een gezond ego hebben (in de zin dat je je niet direct aangevallen voelt als iemand anders eens in het spotlight staat). En natuurlijk ook zo iemand vinden, en met dat persoon samen kunnen werken.

[ultimate-tester]

Wat betekent dit precies, vraag ik als Linux leek? Geen PRs betekent geen updates neem ik aan op de versie die in de kernel zit, dus verdere updates moeten via packages komen?

[laurxp]

Om te beginnen: bcachefs is altijd "experimental" gebleven. Er is een hoop ontwikkeling gaande, en er zal dan ook nog een hoop bugs in zitten. Het is expliciet niet de bedoeling om bcachefs te gebruiken voor belangrijke data, je moet er als gebruiker vanuit gaan dat je bestandssysteem op ieder moment zou kunnen exploderen. Dit beperkt direct al de real-world impact hiervan: er is simpelweg niemand die bcachefs in een kritische productie-omgeving draait en daarom updates moet hebben.

In de praktijk zijn er in de toekomst twee opties:

Nummer één is om Kent's fork van de kernel te gebruiken. Het voordeel is dat je de nieuwste bcachefs patches krijgt, het nadeel is dat je het zelf moet compileren en dat je waarschijnlijk flink gaat achterlopen met alle andere patches. Prima optie voor de bestandssysteem nerds, compleet onacceptabel voor een productieomgeving.

Nummer twee is om er een out-of-tree DKMS driver van te maken. In feite blijf je hierbij de reguliere kernel van je distro gebruiken, maar laat je die kernel een los gecompileerde drivermodule laden. Voordeel is dat je vrij gemakkelijk zowel een goed ondersteunde kernel én een recente driver kan gebruiken, nadeel is dat de driver geen grotere aanpassingen aan de kernel kan doen, en dat er altijd het risico is dat een update van één van de twee ervoor zorgt dat de combinatie niet meer werkt. Dit is de aanpak die bijvoorbeeld ook ZFS gebruikt (wat om licentietechnische redenen niet in de reguliere kernel mag), en de instructies voor gebruik zijn in essentie installeer een package.

De vraag is of dit goed genoeg is. Beide opties zijn prima voor experimentele drivers, of drivers die echt een significante toegevoegde waarde hebben, maar feit is dat het op lange termijn gewoon geen aantrekkelijke opties zijn. Het blijft altijd een hoop extra ontwikkelwerk, en het blijft altijd een risico voor de gebruiker. Dat is wellicht de moeite waard voor bijvoorbeeld iets cruciaals als Nvidia-drivers, maar is de community bereid om door deze hoepels te springen puur en alleen omdat de ontwikkelaar van bcachefs te sociaal incapabel is om de regels van de kernel community te volgen? Is bcachefs daadwerkelijk zoveel beter dan bijvoorbeeld btrfs?

[Reactie gewijzigd door laurxp op 30 augustus 2025 14:05]

[markg85]

Effectief hetzelfde als ZFS. Een kernel module die extern wordt ontwikkeld en niet in de kernel zelf zit. En zo was bcachefs voor het in de kernel kwam en de ego's met elkaar in botsing kwamen.

Op den duur zal bcachefs wel uit de kernel worden geknikkerd. Of de ontwikkelaar ervan legt het bij met Linus maar die kans lijkt vrij klein.

[downtime]

Op den duur zal bcachefs wel uit de kernel worden geknikkerd. Of de ontwikkelaar ervan legt het bij met Linus maar die kans lijkt vrij klein.

Dat laatste lijkt me ondenkbaar. Die ontwikkelaar zal de leiding van het project moeten overlaten aan iemand die het vertrouwen van Linus nog niet verloren heeft. Maar dat zal zijn ego wel niet toelaten en dus zal bcachefs hierna een stille dood sterven.

[afterburn]

In praktijk wss hetzelfde als deprecated. Niet omdat het oud of niet onderhouden wordt maar omdat de kernel niet bijgewerkt wordt en er zo ruimte wordt gemaakt voor gebruikers om te anticiperen op het verwijderen van de code uit de kernel zonder gelijk de stekker er uit te trekken en onnodig problemen te genereren voor eventuele gebruikers van bcachefs

[HollowGamer]

Dit gebeurt vaker. Het betekent dat het nu nog in de kernel zit, maar na verloop van tijd kan worden verwijderd van de (main) tree.

[K0L3N]

Het lijkt er op dat het niet meer onderhouden word, maar er nog wel in zit zodat systemen niet omvallen na een patch. Je kunt nog wel zelf deze toevoegen aan de kernel, dus ik verwacht niet dat het omvalt, alleen zal het iets meer niche worden.

[Jeoh]

Volgens mij wou de ontwikkelaar van bcachefs al verder gaan als DKMS module: https://www.patreon.com/posts/on-pending-132658586

[HollowGamer]

Kan je vanaf DKMS booten (bcachefs als rootfs)?

Ik dacht namelijk dat dit mogelijk was. Voor een FS-module is DKMS ook niet erg fijn, het kan werken - en het sloopt niet upgrades, maar je weet pas later of het goed werkt.

[beerse]

Als je met een linux kernel bij het booten een module nodig hebt, zal je er voor moeten zorgen dat de module in het boot en het root filesysteem zit en dat de kernel ze kan vinden bij het opstarten.
De meeste linux distributies beginnen met een read-only boot filesysteem dat in het geheel in het geheugen geladen wordt. Denk ter vergelijk aan een cdrom-iso image dat in het geheugen geladen wordt. Je module moet dan in dat image staan, iets anders kan ze niet lezen.

[NaioN]

Ja, daarvoor gebruiken de meeste distributies initramfs, dat is een klein bestandssysteem waarin benodigde drivers en modules geplaatst worden om vervolgens het root filesystem te kunenn benaderen. De initramfs wordt na kernel/DKMS/andere aanpassingen opnieuw opgebouwd met de benodigde modules. Zo is het ook mogelijk om ZFS als root filesystem te gebruiken.

[HollowGamer]

Maar ook als DKMS? Ik dacht juist dat deze compiled na initramfs - ook reactie op @beerse.

Heb het waarschijnlijk mis, maar ik dacht dat DKMS dus compiled veel later.

[beerse]

Alles wat bij booten van de kernel niet in de kernel zit ingebakken zal ergens vandaan gehaald moeten worden. Met initramfs is dat precies de plaats waar het vandaan kan komen, andere filesystemen zijn nog niet gemount.

Als er iets pas compileert na initramfs, dan zal de bron daarvoor ergens vandaan moeten komen. Ofwel het staat op initramfs, of wel het staat ergens waarvoor de toegangszaken in de kernel zitten of wat uit initramfs komt. Of dat weer inidirect of zelfs indirect-indirect. Het is maar net hoe het geconfigureerd is.

[NaioN]

De driver wordt bij install gecompileerd en vervolgens, indien nodig, toegevoegd aan de initramfs.

[PdeBie]

Als leek zijnde was ik ook benieuwd naar wat er dan wel ondersteund wordt en wat de verschillen zijn.

[Superstoned]

Btrfs heeft grotendeels dezelfde functionaliteit en is een stuk volwassener en maakt deel uit van de kernel. Dus dat is de betere keuze als je copy-on-write zoekt. Dat geeft je features zoals super efficiënte snapshots en rollback, en btrfs-send kan ook heel efficiënt backups naar externe systemen streamen. Als dat soort dingen niet belangrijk is voor je dan zijn ext4 en XFS ook best…

Zelf gebruik ik btrfs voor mijn root en xfs voor mijn home maar als ik een herinstallatie doe ga ik voor alles op btrfs.

[Halfscherp]

Bcachefs heeft al die features ook, en zit eigenlijk al beter in elkaar. Er is een hele sloot aan tests (syzbot) waar bcachefs minder fails heeft dan BTRFS, XFS en EXT4.

[The Zep Man]

Bcachefs heeft al die features ook, en zit eigenlijk al beter in elkaar.

Als het niet meegeleverd wordt met de kernel dan zal het professioneel niet gebruikt worden. Technisch kan het nog zo mooi zijn, je hebt er niets aan als niemand het gebruikt.

Zelf ben ik een fanatieke gebruiker van ZFS onder Linux (ontwikkeling buiten de kernel om i.v.m. licentiegeneuzel) met één systeem. Combinatie van LTS kernel en de package manager de rest op laten lossen. Werkt prima en ultrastabiel, maar dit gebruik ik enkel als hobbyist en zie je nooit in een organisatie.

[Reactie gewijzigd door The Zep Man op 30 augustus 2025 13:41]

[Guru Evi]

Organisaties gebruiken gewoon wat een grote groep, Ubuntu of Proxmox of TrueNAS, aangeeft te ondersteunen waar ZFS boot inbegrepen is in de distributie.

Zowel BTRFS alsook bcachefs heeft genoeg “kinderproblemen” die al sinds het begin bestaan dat er weinig distro zijn die het officieel gaan aanbevelen.

[Reactie gewijzigd door Guru Evi op 30 augustus 2025 19:10]

[Oliekoets]

De nieuwere Fedora-Core releases vanaf versie 33 (workstation/desktop editions) en later alle editions, heeft al BTRFS als default filesysteem.

RHEL10 heeft nog steeds XFS als standaard, maar ik denk zomaar dat RHEL-11 ook btrfs gaat worden.

[Reactie gewijzigd door Oliekoets op 31 augustus 2025 23:49]

[Guru Evi]

Er zit veel in FC die er later weer uitgesloopt wordt. Het is ook niet langer een upstream distro, maar gewoon een community distro en sinds RH afstand genomen heeft zijn er nog meer dingen die meer gedaan worden door evangelisten van een of ander subsysteem dan een oog op een degelijke langdurig ondersteuning. Ik weet niet of BTRFS stabiel genoeg is om een oudere major/minor versie (vb 6.5) vandaag voor 10 jaar te ondersteunen met backports zonder major/minor (feature) upgrade, wat het doel is van RHEL dat je systeem niet van functionaliteit (meer of minder) verandert.

[Reactie gewijzigd door Guru Evi op 1 september 2025 00:30]

[Oliekoets]

Nou gewoon een community-distro is niet helemaal waar.

• De meerderheid van de fedora council zijn redhat board members
• De meerderheid van actieve fedora ontwikkelaars staan bij redhat op de payroll

https://docs.fedoraproject.org/en-US/legal/trademarks/

Tja. Nee ik kan dat niet als community distro zien.

Ik zie ook dat BTRFS officieel deprecated is sinds RHEL8 en niet meer supported.

[anvil]

Er zijn genoeg organisaties die het wel gebruiken hoor...

Ik beheer enkele HPC systemen en een ervan heeft ZFS draaien op een 4-tal BeeGFS servers die tesamen een 2PB filesystem vormen, Er is gekozen voor ZFS vanwege performance en stabiliteit, spul draait inmiddels dik een jaar storingsvrij met af en toe behoorlijke I/O loads.

[Superstoned]

en zit eigenlijk al beter in elkaar. Er is een hele sloot aan tests (syzbot) waar bcachefs minder fails heeft dan BTRFS, XFS en EXT4.

Kijk, dat kun je mooi zeggen. En het is qua design zeker wel interessant - al lijkt het ook een beetje een trade-off te zijn qua prestaties voor verschillende scenario's. En Kent lijkt zeker een goede development hygene te hebben.

Maarrrr tests zijn maar tests, en de realiteit is toch vaak anders. En serieus enterprise gebruik vereist toch vaak meer en andere dingen dan gebruik op kleinere schaal. En je ziet vaak problemen pas op grotere schaal duidelijker worden. Dat meer mensen misschien klagen over btrfs heeft te maken met het grotere gebruik.

Er klagen ook meer mensen over de S25 of de iPhone 17 dan over een Nokia telefoon - betekend niet dat de Nokia beter is, het heet meer te maken met het aantal gebruikers.

Ik wil niet zeggen dat je fout zit, maar een mooi design en goede test uitkomsten is nog geen bewijs. Hoogstens een hint. En het niet met de kernel community kunnen werken is in any case, zelfs als het product verder technisch geweldig is, game over wat mij betreft. Ik vertrouw meer in de collectieve inteligentie van de kernel community dan in 1 of 1 klein groepje ontwikkelaars, hoe briljant ze ook zijn. Als je niet mee wil/kan doen met dat collectief - ja, jammer.

[ro8in]

Het grootste probleem van Linux is momenteel de ontwikkeling van de kernel zelf. Iedereen is daar meer bezig met zijn plasje over PRs te doen dan daadwerkelijk progressie te begeleiden en het is meer ego's die op elkaar botsen de laatste jaren en heb het gevoel dat (heb de stats niet gecheckt) dat inmiddels meer wordt geweigerd telkens dan nog included.

Als je toevoegingen gaat excluden die technisch gezien gewoon goed zijn om gestag over regeltjes en vooral persoonlijke gevoelens dan gaat er iets mis. Dan laat je het eindproduct bewust dus slechter zijn dan het had kunnen zijn omdat je er op mensen niveau niet goed uitkomt.

[vanviegen]

Stel, jij geeft leiding aan de development afdeling die de core systemen van een bank ontwikkelt. Eén ontwikkelaar, een slimme vent met op zich goede ideeën (maar niet slimmer dan tal van anderen binnen de organisatie), heeft continu ruzie met allerlei collega's. Hij denkt enkel aan de belangen van zijn eigen kleine onderdeeltje in het enorme project, en eist dat alles en iedereen daarvoor moet wijken. Je hebt al tal van keren geprobeerd om hem op rustige en vriendelijke (en soms ook iets minder vriendelijke) manier uit te leggen dat het op deze manier echt niet kan, en dat hij zijn collega's heel veel stress bezorgt. Maar telkens zonder succes.

Zou jij deze man contractverlenging aanbieden omdat zijn werk op zich goed is? Is de bank daar, in breder perspectief, bij gebaat?

[RoyD]

Hij is blijkbaar wel slimmer dan tal van anderen. Maar als een tool verbeterd wordt om eerdere bugs te herstellen in een testversie, is dat in mijn ogen geen uitbreiding van de functionaliteit maar hoort het als fix bij de testversie. Maar misschien was het beter geweest om deze apart beschikbaar te stellen voor bepaalde gebruikers zodat het geen conflicten gaf. Jammer dat een goed bestandssysteem zo in een doodlopende weg komt. Krijg een beetje het ReiserFS gevoel. Alleen dat had dan weer een andere oorzaak.

[ro8in]

Ik snap het hoor het is een lastige situatie, maar als zijn werk echt een grote impact heeft en gewoon een enorme verbetering is dan moet je misschien kijken of het hele ontwikkel proces misschien aangepast kan worden om toch op een manier het werk van dit soort moeilijke personen included kan blijven worden. Dit hoeft dan niet perse alleen voor het werk van deze specifieke persoon te zijn, maar ook voor alle toekomstige moelijke personen die misschien wel echt goede toevoegingen hebben. Linux is een open systeem gemaakt door iedereen. Je krijgt nu dus wel een situatie waarin iemand zijn persoonlijkheid aan bepaalde voorwaarden moet voldoen ofzo.

[Reactie gewijzigd door ro8in op 1 september 2025 11:45]

[AnguishedOne]

Effectief zal dit heel erg aan je distributie liggen.

en of zij de git tree van kents patches naar binnen halen terwijl ze de kernel bouwen. Dit zal dus per Linux distributie maker verschillen maar ik gok dat de meeste er niks mee gaan doen waar je effectief als er in de toekomst geen nieuwe patches upstream gaan naar de kernel op een oude versie blijft. Je kunt uiteraard altijd zelf een repository toevoegen of de kernel bouwen met de changes.


We weten nu eigelijk te weinig op hier echt iets over te zeggen aangezien er niet aangegeven wordt of toekomstige versies in de kernel blijven en of worden geupdate.

[Reactie gewijzigd door AnguishedOne op 30 augustus 2025 11:31]

[afterburn]

Dit is als klagen over een boete bij een snelheidsovertreding omdat je wegenbelasting betaald. Snijd geen hout.

Dit speelt al jaren en waar het in 1 zin op neer komt is dat Overstreet systematisch weigert zich te houden aan de regels omtrent het publiceren van patches aan de kernel, wat er op welk moment in die patches zit, en hoe ze gedocumenteerd zijn bij de publicatie.

Regels die noodzakelijk zijn voor een project met de grootte en complexiteit als de Linux kernel om grip te houden op de stabiliteit en onderhoudbaarheid van het geheel VS de wensen van een individu die werkt aan een heel klein stukje zonder overzicht op het grotere geheel.

Regels die 20-25 jaar geleden zijn ingevoerd juist omdat gedrag zoals Overstreet dat nu laat zien zorgde voor grote problemen binnen de kernel.

Linux is de cowboy fase al lang ontgroeid, maar de ontwikkeling van bcachefs zit er middenin en dat werkt niet.

[kabelmannetje]

Kernel devs gebruiken "steeds meer AI"? Bron?

Thorvals is "sociaal gestoord"? Kan je duidelijk aangeven waar in de communicatie tussen hem en Kent, dit blijkt?

[L0g0ff]

Waarom zouden ze het niet als een module (akmod) aanleveren en als het een groot succes blijkt te zijn kun je het altijd nog native in je kernel bakken toch?

Ik snap uiteraard wel het voordeel van native integratie maar als zo'n maintainer er een bende en je zit met allenaal rotzooi in je kernel zou ik het er als product owner in de eerst volgende release er weer uithalen.

Al bedenk ik me net dat voor iedereen met dit filesystem dan een breaking change aan zit te komen

[kabelmannetje]

Waarom zouden ze het niet als een module (akmod) aanleveren en als het een groot succes blijkt te zijn kun je het altijd nog native in je kernel bakken toch?

Het ligt niet aan de techniek. Maar wel aan de onmogelijkheid om met Overstreet samen te werken. Of aan regels te houden, of aan het verstand te peuteren dat het aan deze developer z'n gebrek aan basis-comminicatieve vaardigheden ligt. Echt geen distributie gaat voor een zo'n belangrijk deel van de kernel, committeren aan deze persoon met persoonlijkheidsstoornissen.

[HollowGamer]

Het voordeel van in de 'tree' zitten, is dat jouw patches worden meegenomen in zijn geheel. Voor een FS, heb je soms een patch nodig op kernel niveau. Ben geen kenner, maar ik dacht namelijk dat deze ontwikkelaar ook daar patches voor nodig had.

Btrfs heeft bijvoorbeeld voordeel van kernel-patches (of nieuwe features), terwijl bcachefs rekening moet houden met versies, en compiled tegen de tree aan. Dat maakt het minder flexible en gevoelig voor breaking.

[beerse]

Waarom zouden ze het niet als een module (akmod) aanleveren en als het een groot succes blijkt te zijn kun je het altijd nog native in je kernel bakken toch?

Het nadeel van een module voor een filesysteem is dat je dan dus de module moet kunnen lezen voordat je het filesytseem kan benaderen. Een kip en ei probleem. Daarvoor heeft linux overigens al jaren een read-only boot filesysteem.

Een ander nadeel van een module is dat het net wat meer overhead vraagt en dus net wat minder topsnelheid draait. Al is dit puur theoretisch en voor normaal gebruik niet echt merkbaar.

[likewise]

Welke overhead doel je op? Zit er een functie-call-indirectie extra in?

[beerse]

Technische details van de runtime omgeving heb ik niet meer op mijn netvlies staan. Maar ja een extra redirect (of mogelijk zelfs meer) is mogelijk. Andersom kan de code in de kernel zelf zodanig compileert dat er minder redirects nodig zijn, dat is met externe modules niet mogelijk. Tel daarbij dat code uit een module anders geoptimaliseerd is dan wat rechstreeks in de kernel zit. En de puur theoretische mogelijkheid dat de module geladen moet worden.

Zoals gesteld, allemaal theoretisch en op de grens van meetbaar. Maar toch.

[likewise]

Uit interesse heb ik het even opgezocht; er is geen run-time overhead voor functie calls, d.w.z. geen extra call latency. Wel kan het zijn dat er wat optimalisaties missen omdat cross-functie inlining niet langer compile-time mogelijk zijn. Dus de impact is extreem laag (maar wat dat precies betekent weet ik niet).

[GeEkIe]

Ziet er wel indrukwekkend uit (Wiki):

He intended it to be an advanced file system with modern features like those of ZFS or Btrfs, with the speed and performance of file systems such as ext4 and XFS.

[downtime]

In een wiki ziet alles er indrukwekkend uit. Nu nog waarmaken.