Linux-bestandssysteem bcachefs is veelbelovend, maar levert nu vooral drama op

Tekst

Een bestandssysteem dat in 2023 is toegevoegd aan de Linux-kernel, wordt nu door de kernelontwikkelaars op afstand gezet. Oprichter en eindverantwoordelijke Linus Torvalds heeft bepaald: bcachefs blijft voorlopig wel in de kernel, maar wordt voortaan extern beheerd. Achter de schermen spelen soaptaferelen, met eigengereide persoonlijkheden, strikte regels voor softwareontwikkeling, felle discussies en botte aanvaringen.

Voor degenen die wat meer zijn ingevoerd in de opensourcewereld, komt de breuk tussen Linux en bcachefs niet als een verrassing. Het bestandssysteem blijft weliswaar in de Linux-kernel, maar wordt voortaan alleen extern beheerd. De kernelontwikkelaars, met Linux-schepper Linus Torvalds aan het hoofd, trekken hun handen ervan af. Kenners hebben dit zien aankomen.

Wat is er aan de hand?

Eind juni kwam al een barst in de relatie tussen het opensourcebesturingssysteem en het opensourcebestandssysteem. Wat er toen aan de hand was? Simpel gezegd: een pullverzoek voor ingediende code van bcachefs. Het klinkt als niets bijzonders; pullverzoeken zijn immers een geaccepteerde manier van gezamenlijke codeontwikkeling. Daarbij vraagt een ontwikkelaar van een element in de softwarecode om wijzigingen 'binnen te halen' in de hoofdtak van het totale softwareproject, in dit geval bcachefs en Linux.

De GitHub-pagina van Linus Torvalds

Terwijl pullverzoeken een normale manier van samenwerken zijn, komt daar wel wat bij kijken. Wijzigingen in het ene kunnen namelijk gevolgen hebben voor het ander. Zo moeten veranderingen worden geïntegreerd, moet het nieuwe geheel vervolgens worden getest en kan dan pas een vinkje worden gezet voor succesvolle opname van de gewijzigde code. Naast codekwaliteit speelt timing hierbij een belangrijke rol. Het pullverzoek voor bcachefs had een probleem op dat laatstgenoemde gebied. Een kwestie van ongelukkige timing of botweg eigenwijze momentkeuze?

Het pullverzoek was bedoeld voor het toevoegen van functies aan bcachefs, dat sinds oktober 2023 is opgenomen in de Linux-kernel. De kernel van een besturingssysteem is als het ware het hart en vervult essentiële functies op een laag niveau, direct op de hardware. Andere elementen van een besturingssysteem draaien op een hoger niveau en vervullen andere functies. Daarbovenop draaien de applicaties.

Zorgvuldig mee omgaan

De kernel is dus een belangrijk stuk software en de ontwikkeling daarvan moet zorgvuldig worden aangepakt. Daar zijn dan ook strikte regels voor. Het pullverzoek van eind juni was een schending van die regels. De kernel bevond zich toen in een kritieke fase van de ontwikkeling: de fase waarin zogeheten releasekandidaten worden gemaakt en waarin alleen nog fixes mogen worden toegevoegd.

Nieuwe code voor functionaliteit mag alleen worden toegevoegd in de vooraf bepaalde periode voor het samenvoegen van zulke, meer algemene code. Het zogeheten mergetijdsvenster was voor de toen in ontwikkeling zijnde kernelversie al twee weken gesloten. Concreet ging het om versie 6.16 van de Linux-kernel, die eind juli uitkwam. Linus Torvalds, de oorspronkelijke maker van Linux, was niet bepaald blij met deze schending van de regels.

Linus Torvalds, maker en eindverantwoordelijke van Linux

De ontwikkelaar van bcachefs, Kent Overstreet, wilde een uitzondering op de regels. Zijn argument daarvoor was dat de gewijzigde code fouten zou verhelpen en verbeteringen zou brengen voor de veiligheid van opgeslagen data. Torvalds kapte die redenatie af: "Je lijkt weer te zijn vergeten wat het doel van de mergeperiode was. We gaan geen nieuwe functies toevoegen omdat je andere bugs hebt gevonden", schreef hij in de mailinglijst voor kernelontwikkelaars.

Het punt van dataveiligheid werd toen afgewezen op grond van de experimentele status van bcachefs. "Ik blijf er standvastig van overtuigd dat iedereen die bcachefs gebruikt, verwacht dat het experimenteel is", oordeelde Torvalds, waarna hij Overstreet opdroeg ervoor te zorgen dat de fixes ook echt puur fixes zijn en geen verkapte features.

Hulp zoeken

Bestandssysteem en moord

Het 'buiten zetten' van bcachefs voor de Linux-kernel kan een voorbode zijn van volledige verbanning. Dat klinkt vergaand, maar is eerder al eens gebeurd bij ReiserFS. Dat bestandssysteem werd na afkeuring in 2022 uiteindelijk in 2025 verwijderd uit Linux. Dit volgde op verwaarlozing van de ontwikkeling doordat de oorspronkelijke maker, Hans Reiser, in 2008 is veroordeeld voor de moord op zijn vrouw.

Reiser heeft eind 2023 vanuit de gevangenis een brief geschreven waarin hij spijt betuigt en excuses aanbiedt. Dat doet hij ook voor zijn verkeerde aanpak bij het indienen van code. De ontwikkelaar van het ooit veelbelovende ReiserFS erkent dat hij met zijn gedrag leden van de Linux-gemeenschap van zich heeft vervreemd. Deze inzichten zijn te danken aan lessen in conflictoplossing die Reiser heeft gevolgd. De vergelijking valt te trekken met de hulp die Torvalds eind 2018 is gaan zoeken​ voor zijn gedrag, wat weer valt te vergelijken met hoe Overstreet zich nu heeft opgesteld.

Een duidelijk signaal, zij het misschien wat bot geformuleerd. Torvalds is hiermee echter milder dan hij vroeger was. Jaren terug was de maker van Linux berucht om zijn uithalen en gebrekkige sociale vaardigheden. Torvalds valt te beschouwen als een van de 'welwillende dictators' die voor het leven zijn aangesteld. Daarbij vervult zo'n belangrijke leider op het gebied van opensourcesoftware een bepalende rol, maar wel op een gedienstige wijze. Torvalds heeft in zijn lange carrière de ontwikkeling van Linux met overtuiging beschermd, wat nogal eens met botte bewoordingen en harde oordelen is gebeurd.

Eind 2018 is Torvalds tot het inzicht gekomen dat zijn gedrag niet door de beugel kan. Hij heeft toen tijdelijk een stap teruggedaan van de Linux-ontwikkeling, om hulp te zoeken zodat hij voortaan beter met zijn emoties om kan gaan. “Ik moet wat van mijn gedrag aanpassen en ik wil mijn excuses aanbieden aan de mensen die door mijn persoonlijke gedrag zijn gekwetst en mogelijk zijn weggejaagd van kernelontwikkelwerk”, schreef Torvalds toen.

Het is en blijft niet makkelijk om een leider te zijn, zeker niet als je gepassioneerd bent over wat je doet. Hetzelfde valt te zeggen over de ontwikkelaar van bcachefs. Overstreet lijkt de afwijzing van zijn pullverzoek eind juni dit jaar te hebben opgevat als uitdaging. Hij reageerde op Torvalds' mededeling over het doel van het mergevenster dat het doel toch is om mensen code te geven die werkt, met nadruk op die laatste twee woorden.

Overstreet wees in zijn reactie op problemen met andere bestandssystemen waarbij gebruikers zijn geraakt door onherstelbaar dataverlies. "Er zijn nog altijd mensen die niet willen afstappen van ext4 en ik kan ze dat niet kwalijk nemen", schrijft de bcachefs-maker over een ander, ouder bestandssysteem. Het doel is volgens hem ervoor te zorgen dat gebruikers software krijgen die ze kunnen vertrouwen en waar ze op kunnen bouwen. "Ik zie niet dat jij dat begrijpt", sluit hij dat bericht aan Torvalds af.

De toon was gezet. Sindsdien is er achter de schermen veel gebeurd, en zeker niet voor het eerst. Een niet onbelangrijk detail in de woordenwisseling van eind juni is het woord 'weer' dat Torvalds gebruikte in zijn boodschap aan Overstreet. Die ontwikkelaar heeft zich eerder al niet gehouden aan de regels voor wanneer welke codewijzigingen mogen worden ingediend. Vanuit passie, vanuit eigengereidheid of wellicht vanuit eigenwijsheid?

Briljant, gepassioneerd, koppig, blind

Op onlinefora wordt Overstreet omschreven als een briljante ontwikkelaar met veel passie voor zijn software. De kwaliteit van zijn code gaat hem echt aan het hart. Tegelijkertijd wordt Overstreet ook koppig en blind genoemd, waarbij hij regels van anderen niet als valide lijkt te zien. Duidelijk is dat het fixen van bugs en het voorkomen van dataverlies kritieke kwesties voor hem zijn. Voor Torvalds en de andere kernelontwikkelaars zijn de regels voor codewijzigingen echter ook kritieke kwesties.

De diverse aanvaringen hebben nu geleid tot de uitzetting van bcachefs. Dat bestandssysteem voor Linux wordt voortaan extern beheerd, beveelt Torvalds, die eindverantwoordelijk is. "Volgens lange discussies, publiek en privé", stelt hij nog kort. Daarmee is bcachefs niet langer officieel ondersteund in de Linux-kernel. Het is de vraag wat dit gaat betekenen voor releases van het opensourcebesturingssysteem na versie 6.17, dat nu in de fase van release candidates zit.

Keuzes, keuzes

Mogelijk verdwijnt bcachefs geheel uit de kernel. Zo'n verwijdering klinkt vergaand, maar is dat niet per se. Ten eerste is bcachefs nog experimenteel, in ieder geval wat Torvalds betreft. Ten tweede is dat bestandssysteem slechts een van de vele opties in Linux. Het opensourcebesturingssysteem heeft − in tegenstelling tot Windows en macOS − niet één officieel bestandssysteem.

De keuze voor een bestandssysteem kan verschillen per aanbieder van Linux-distributie, zoals Ubuntu, Mint, Red Hat, SUSE enzovoorts. Daarnaast kunnen gebruikers kiezen welk bestandssysteem ze gebruiken in hun Linux-installatie. Ten derde is er een precedent: het veelbelovende bestandssysteem ReiserFS is recent verwijderd uit Linux.

Het drama rond bcachefs nu kan een gemis opleveren voor Linux-aanbieders en -gebruikers. Een geavanceerd nieuw fundament voor bestandsopslag dreigt door botsende persoonlijkheden en bestaande regels voor softwareontwikkeling op een zijspoor te raken. Aan de andere kant is de handhaving van regels juist van belang voor Linux-aanbieders en -gebruikers. Betrouwbare ontwikkeling en release van het besturingssysteem vormen het fundament voor vertrouwen om het te verpakken in een distributie, aan te bieden en te gebruiken.

_{Redactie: Jasper Bakker • Eindredactie: Monique van den Boomen}

Reacties (154)

[Ultraman]

Ik houd bcachefs al enige jaren periodiek in de gaten. Technisch lijkt het mij een interessant bestandsysteem en het zou best eens superieur kunnen worden in vergelijking met het huidige aanbod. Maar ik kijk er vanaf het begin al met een schuin oog naar. Puur vanwege het feit dat meneer Overstreet zijn bestandsysteem aanprijst door af te geven op een zeker ander bestandsysteem. Als je je waarde wilt aantonen door af te geven op een ander vind ik je onsympathiek en verlies je bij mij een hoop punten.

Het is jammer dat Overstreet zich niet wenst te houden aan de manier van werken binnen de kernelontwikkelgroep. Nu het buiten de kernel lijkt te blijven ga ik het zeker nooit gebruiken als root filesysteem.

[Superstoned]

Ach, dat je jezelf vergelijkt met een ander, vergelijkbaar product - Overstreet overdrijft nogal eens, maar op zich lig ik er niet zo wakker van.

Het niet met anderen kunnen werken, daar heb ik meer moeite mee. Uiteindelijk kun je alleen maar zoveel. Je MOET samen iets doen met andere mensen. En als je moeilijk bent om mee te werken krijg je simpelweg minder input. Op bedrijvsniveau zeggen ze wel eens: hoeveel engineers je ook hebt, de meeste engineers werken niet voor jouw. Dus open source & samenwerken brengt gewoon meer ideen binnen. Dat gaat natuurlijk ook op voor 1 individu. Je kunt nog zo slim zijn, de gecombineerde kennis en creativiteit van de hele kernel community kun je nooit evenaren.

Een bijkomend ding is dat je vaak ziet dat ontwikkelaars een probleem zien, en de bestaande oplossingen niet goed genoeg vinden en denken dat ze het beter kunnen. In veel gevallen is dat omdat ze het probleem wat de bestaande oplossing aanpakt, niet helemaal zien. Vooral als ze roepen dat het te ingewikkeld is ("bloat"). Daarom duurt het bouwen van een initiele oplossing vaak niet zo lang, maar blijkt daarna dat er enorm veel kleine corner cases zijn die je toch echt ook moet tackelen voordat het product echt viable/enterprise ready is. En dat duurt zo 100x langer dan die eerste versie die het initiele probleem wat je had oplost.

En dat probleem is helemaal enorm als je dus alles beter denkt te weten. De concurrent waar mr Overstreet zo over zeurt is al in enorm veel plaatsen in gebruik - en of hij het echt beter kan, ik ben skeptisch. Wil hij het alleen doen - dan weet ik zeker dat dat het niet wordt.

[Llopigat]

Liever gewoon OpenZFS. Stabiel, veilig en geen drama, behalve wat gezeur vanuit de Linux hoek over licentiebepalingen. Ik draai het al vele jaren op root en het heeft me al meerdere keren uit de brand geholpen. Met name snapshots, maar ook door het herkennen van datarot.

Ik vind dit ook wel erg tekenend voor Overstreet:

"Er zijn nog altijd mensen die niet willen afstappen van ext4 en ik kan ze dat niet kwalijk nemen", schrijft de bcachefs-maker over een ander, ouder bestandssysteem.

"Er zijn nog altijd"?? Zijn eigen FS is nog niet uit experimentele status maar hij loopt nu al te klagen dat mensen het stabiele ext4 gebruiken. Hij heeft nogal oogkleppen op, het enige dat telt is zijn hobbyprojectje.

Niet dat bcachefs geen waarde heeft hoor, maar het moet zich nog bewijzen. Met filesystems is stabiliteit gewoon megabelangrijk.

[Reactie gewijzigd door Llopigat op 4 september 2025 11:07]

[Halfscherp]

Bcachefs heeft zich al bewezen? Kent (die een vrij hoge standaard heeft qua code) vindt het op het moment stabiel genoeg om het experimental label eraf te halen. De bug tracker bevat ook geen serieuze bugs meer, en als je syzbot checkt (die de syzkaller kernel fuzzer gebruikt) heeft bcachefs minder failed tests dan ext4, BTRFS of XFS.

Ik zie verder downthread ook dat dit een "hobbyprojectje" wordt genoemd, maar in feite is bcachefs de volgende generatie van filesystems. BTRFS, ZFS en APFS zijn van de vorige generatie, en ext4 is nog ouder.

Kent is sinds de vorige merge window zelf ook al op zoek naar iemand die als een soort tussenpersoon tussen hem en Linus / de kernel maintainers kan fungeren. Die zijn ook niet blind voor hoe bcachefs een flinke stap vooruit is qua techniek, dus ik vermoedt dat het vanaf dat moment vrij snel weer terug in de kernel komt. Ook omdat de ontwikkeling nu in rustiger vaarwater komt.

[Llopigat]

Het is meer een hobbyproject omdat het van een enkele ontwikkelaar is.

ZFS is door een heel team gemaakt met de backing van een groot bedrijf (Sun). Bovendien heeft hte zich al 24 jaar bewezen in produktie. Btrfs ook, de ontwikkeling wordt gesponsord door RedHat, Meta, Oracle enz. Dat geeft vertrouwen in de lange-termijn support.

Ik denk dat bcachefs er ook wel komt, al kan het ook zijn dat de principes erachter worden geimplementeerd door een groter project dat populairder wordt. Tiered storage is op zich een handig punt, maar het wordt pas echt wat zodra de industrie erachter gaat staan voor serieuze workloads.

Ik vergelijk het een beetje met ReiserFS wat dat betreft. De hoofdontwikkelaar valt weg (wat voor reden dan ook) en het project is dood. Dat is als gebruiker natuurlijk niet echt handig. Dat de naam van een moordenaar direct aan het produkt is gekoppeld natuurlijk ook niet, en dat probleem speelt hier niet. Maar het enkele-ontwikkelaar punt is wel een grote achilleshiel.

[Reactie gewijzigd door Llopigat op 4 september 2025 15:28]

[Halfscherp]

Ah ja, de beruchte bus factor haha. Dat ben ik wel met je eens.

Als bcachefs uiteindelijk doodbloed vermoed ik dat eerst Apple uiteindelijk met een APFS+ / APFS2 gaat komen op basis van de principes van bcachefs, en daarna komt er aan de kant van Linux of hernieuwde interesse in bcachefs, of een nieuw project. Beetje hetzelfde principe als systemd, dat is ook zwaar gestoeld op Apple's manier van init doen.

[goarilla]

Mmm interessant dus systemd is gestoeld op launchd ? Ik weet niet wat er zo geavanceerd is aan APFS ... maar de laatste keer dat ik Apple gebruikte was het nog HFS+ denk ik: een journaling filesystem zoals ext4 met wat van apple's weirdness (resource forks).

Welke features vind jij de moeite in bcachefs om ook ergens anders te krijgen.
Want ik dacht dat alles nu richting Object Storage ging met POSIX fs layers voor wanneer
het nodig was. Niet dat ik dat enigszins goed begrijp.

[Reactie gewijzigd door goarilla op 4 september 2025 18:12]

[Halfscherp]

Ja, systemd is geinspireerd door launchd. Maar bijvoorbeeld immutable filesystems zijn op Linux veel populairder geworden sinds Apple System Integrity Protection heeft geintroduceerd op de desktop. SteamOS doet dit op het moment bijvoorbeeld ook, al doen zij het nog vrij knullig omdat Arch geen immutable filesystem kent. Fedora wel via Silverblue, en Bazzite werkt wel op die manier.

Het belangrijkste verschil met bcachefs is dat het een "filesystem as a database is", en dat daarnaast enorm veel trees (inode tree, extent tree, directory tree, etc.) gebruikt. Bij bijna alle filesystems tot nu toe werd alles onder de inode gehangen, wat zowel qua performance als betrouwbaarheid impact heeft. Bij bcachefs heb je bijvoorbeeld zelfs met problemen in de inode geloof ik nog gerede kans op data recovery. Bij een traditioneel filesystem is het dan voor de leek voorbij.

[goarilla]

SteamOS doet dit op het moment bijvoorbeeld ook, al doen zij het nog vrij knullig omdat Arch geen immutable filesystem kent. Fedora wel via Silverblue, en Bazzite werkt wel op die manier.

Zijn er dan dedicated immutable fileystems ?
Of hebben we het over mount flags:
mount -o ro / # niet zeker of dit kan (als /var bepaalde updates
krijgt (moet de dirents van / dit ook kunnen weerspiegelen niet ?)
mount -o ro /etc
mount -o ro /usr
mount -o rw /var
mount -o rw /tmp
mount -o rw /home
Hebben we het dan over union/squashfs filesystems ?

Het belangrijkste verschil met bcachefs is dat het een "filesystem as a database is", en dat daarnaast enorm veel trees (inode tree, extent tree, directory tree, etc.) gebruikt. Bij bijna alle filesystems tot nu toe werd alles onder de inode gehangen, wat zowel qua performance als betrouwbaarheid impact heeft. Bij bcachefs heb je bijvoorbeeld zelfs met problemen in de inode geloof ik nog gerede kans op data recovery. Bij een traditioneel filesystem is het dan voor de leek voorbij.

Ik begrijp dat je in tree structuren (hashed/balanced bv.) sneller kan zoeken maar je moet toch ergens de POSIX metadata hangen, hoe helpt een boom structuur de betrouwbaarheid hier, als de inode leaf kapot is ... ?

[Jerie]

Sun bestaat niet meer, overgenomen door Oracle. Solaris is een overblijfsel van Sun maar alle kundige engineers zijn allang weg bij Oracle. OpenZFS gebruikt ook geen nieuwe code meer van Oracle. Eigenlijk is OpenZFS geavanceerder dan ZFS maar er zit geen officieel groot bedrijf achter. Is het daarmee een hobbyproject? Was Btrfs geen hobbyproject omdat Chris Mason bij Facebook werkte? Is bcacge geen hobbyproject omdat Kent Overstreet bij Google werkte, terwijl hij bij Google wegging om full-time aan bcachefs te werken?

Sommige bestandssystemen kunnen door meerdere OSen benaderd worden. Dat vind ik persoonlijk prettig. Bij ZFS werkt dat, al heeft een ZFS ook een interne versie. Als je eeen modern filesystem wilt dat ook benaderbaar is op andere OSen kom je m.i. dan ook bij ZFS uit (specifiek: OpenZFS).

[goarilla]

Ik denk dat het nu niet meer zo is en dat iedereen is gemigreerd naar OpenZFS maar er was wel een tijd dat Illumos/Nexenta/OpenSolaris, FreeBSD and ZoL toch anders genoeg waren om dit niet te doen. Maar inderdaad het is heel leuk om FreeBSD als alternatief te kunnen hebben.

[Jerie]

Sinds FreeBSD 13 is OpenZFS de standaard ZFS (FreeBSD is de basis van allerlei andere OSen). We zitten inmiddels op FreeBSD 14. Maar ZFS werkt ook op Windows en macOS prima. Van alle moderne filesystems (met bijvoorbeeld CoW) het meest portable filesystem.

[ScharlakenRood]

Solaris is een overblijfsel van Sun maar alle kundige engineers zijn allang weg bij Oracle.

Oracle Cloud draait volledig op Solaris/ZFS voor zijn storage component. Hoop dus wel dat er nog veel expertise zit.

[theseboetz]

Kan je aan mij uitleggen hoe bcachefs een stap vooruit is? Ik weet vrij weinig van bestandssystemen, dus als je doet alsof ik 10 ben, dan moet het denk ik goedkomen. Ik ben heel erg benieuwd wat voor vernieuwingen dit soort systemen kunnen brengen.

[Stetsed]

Ik denk dat de waarde die bcachefs zou brengen niet zozeer zou zijn dat het heel veel nieuwe features had, dat had hij well maar OpenZFS heeft veel van dezelfde. Het grotere ding is dat het een native kernel module zou zijn wat de bar heel wat verlaagt. Inderdaad OpenZFS kan je op elke distro als DKMS module toevoegen, echter is dit voor veel mensen all te veel moeite en doen weinig distro's dit zelf waardoor zo ver ik weet Ubuntu de enige is die het automatisch heeft.

Ik gebruik ZFS bijvoorbeeld op mijn proxmox servers maar ook op me desktop en laptop met gebruik van Arch Linux. Dit is omdat ik het fijn vindt dat ik sommige van de features die je noemt zoals snapshots kan gebruiken. Echter is dit vaak well extra moeite.

Dit is jammer want zoals jij all zegt het heeft heel veel goede punten, maar Linus heeft ook all gezegt dat tenzij hij een brief krijgt van Oracle's(De houders van de copyright van ZFS nu) waarin staat dat ze OpenZFS mogen gebruiken en meer belangrijk licensen onder de GPLv2 die de kernel gebruik, gaat hij er niet in komen. BCacheFS had dit kunnen invullen omdat het niet gebaseerd is op ZFS maar well veel van dezelfde technieken.

Maar ik moet well zeggen dat ik eerder had verwacht dat hij uit de kernel zou worden getrokken, want Kent die doet elke keer weer hetzelfde en elke keer zegt hij nooit "Excuses mijn fout" maar altijd "Ja maar zijn doen dit en zij doen dat!"

[Hans1990]

Zelfde hier! Ik draai kleine 10 jaar ZFS op mijn NAS met een 4TB schijven array. Daar heb ik 8-9 jaar terug ooit data opgezet en organiseerd die grotendeel statisch is. Deze data wordt ook buitenshuis gebackupped. Maar toch al 2x in de afgelopen jaren wat correcties gezien tijdens scrubs, ik vermoed dus door bitrot op statische sectors die na zoveel jaren teveel in verval zijn geraakt. Nu is met deze levensduur van schijven dat het eerst volgende risico natuurlijk.

Ik vind het fijn om de cutting edge software te gebruiken, en ik draai daardoor op mijn desktop Arch met soms wat quirks vanwege updates. Maar er zit nog altijd een verschil tussen userland quirks zoals een bugje in een GUI ofzo, dan alles wat onder de motorkap gebeurd. Aan de stabiliteit van zaken als de kernel, systemd, e.d. wil ik zoveel mogelijk 'sane defaults' gebruiken en niet teveel rommelen.

Al zou ik nu een experimental FS zoals bcachefs inzetten, dan zou dat voor een tweede schijf zijn waar ik bijvoorbeeld een Steam game library op een HDD (array) zet met SSD als backing. Maar zeker nog niet voor iets waar mijn eigen data op staat.
Eem ext4 vervanger is alles wat het labeltje 'experimental' heeft absoluut niet.

[Llopigat]

Ja precies, mijn grote NAS draait nog op ext4, met destijds het idee dat als er wat mis ging, er meer tools waren om data terug te kunnen halen.

Maar ik heb pas een geval gehad waar een heleboel files opeens 0 bytes waren. En in het filesysteem opeens als socket waren aangemerkt. Deze waren door rsync gewoon als zodanig meegebackupt en op de target ook gewist. Gelukkig draaide de target wel ZFS met auto snapshots (sanoid) dus heb ik het daar nog terug kunnen halen. Maar ik ga binnenkort ook maar mijn hele NAS overzetten. Een scrub kunnen doen is toch wel een heel groot goed.

[Ventieldopje]

En zie ook hier, een sync is geen backup!

[Llopigat]

Het is een sync die ik periodiek doe als backup Meestal 1x in de maand.

Maar als die gewoon meebackupt wat er gebeurt voor je het gemerkt hebt dan heb je daar ook niet zo veel aan. Dat is met elke vorm van backup wel een ding.

[goarilla]

En is resilvering, zolang de schijf niet te vol is, ookal is die bug verholpen nu denk ik, zoveel better
dan block per block parity recalculations and alles schrijven. Het knijp-je-aars-toe venster is zoveel
kleiner geworden nu.

[GertMenkel]

Het is zo'n zonde dat Oracle en diens ontwikkelaars het licentieprobleem niet willen oplossen. Solaris is praktisch gezien dood, ze verdienen er geen cent aan om zich aan CDDL vast te klampen. Er zitten nog wel wat andere nadelen aan ZFS (het RAM-gebruik en het risico op datacorruptie als je geen ECC gebruikt) maar het lost een hele hoop problemen op. Ik gebruik zelf meestal BTRFS, maar vooral om het gedoe met kernelmodules te voorkomen.

"Er zijn nog altijd"?? Zijn eigen FS is nog niet uit experimentele status maar hij loopt nu al te klagen dat mensen het stabiele ext4 gebruiken. Hij heeft nogal oogkleppen op, het enige dat telt is zijn hobbyprojectje.

Ik denk niet dat hij hier bedoelt dat mensen zouden moeten overstappen naar bcachefs, maar eerder naar andere, nieuwere stabiele bestandssystemen. Linux kent al tijden modernere, stabiele bestandssystemen als F2FS, (Open)ZFS, BTRFS, en nog zo veel meer, maar ext4 of zelfs XFS blijft de norm voor veel mensen.

Natuurlijk wil je stabiliteit in je bestandssysteem, maar ext4 is onderhand 17 jaar oud en begint toch echt achter te lopen. Dingen als gebrek aan compressie op bestandssysteemniveau (dat toch makkelijk gigabytes kan schelen als het om logbestanden gaat). Gebruik je dat soort dingen niet, dan kun je je systeem lekker vloeiend maken door over te stappen op F2FS omdat de meeste mensen toch SSD's gebruiken. F2FS draait al tien jaar stabiel op honderden miljoenen smartphones, maar toch wordt ext4 geprefereerd voor "stabiliteit".

Iedereen moet zelf kiezen hoe ze hun computer inrichten, maar de terughoudendheid van Linux-gebruikers als het op moderne bestandssystemen aankomt doet met toch denken aan de mensen die Windows XP op FAT32 draaiden omdat ze NTFS niet vertrouwden.

[Reactie gewijzigd door GertMenkel op 4 september 2025 11:42]

[goarilla]

Geen ECC is een risico maar het is een risico dat ik gerust wil nemen. Ik ben destijds gebeten door stille XFS bit rot en xfs_repair of xfs_fsk dat OOM ging omdat het gigantisch veel geheugen moest hebben.
Stond in de manual maar ik heb en had geen 2 GB/TB aan geheugen.

[LANnerd]

Een gebrek aan ECC geheugen is voor ZFS niet een groter probleem dan elk ander file system. Elk filesystem heeft baat bij ECC of heeft dezelfde of zelfs grotere risico's bij het gebrek daar aan.

Het moet nu echt een keer klaar zijn met deze myth, maar zie het elke keer als het over ZFS gaat weer voorbij komen.

[Llopigat]

Goed punt. Ik denk dat het is doordat ZFS immuun is (of het op zijn minst opmerkt) voor veel andere datacorruptie mogelijkheden, dat er zo gehamerd wordt op ECC geheugen.

[LANnerd]

Sterker nog, ik denk dat juist zonder ECC ZFS je beste optie is.
Het heeft mijn data iig al meer dan eens gered toen bleek dat een van mn geheugen reepjes niet mee werkte en errors gaf. ZFS merkte het netjes op bij een scrub en heeft alle corrupte data weten te corrigeren en mij bewust gemaakt van het issue waarna het probleem snel verholpen kon worden. de meeste andere file systems hadden het niet eens opgemerkt en me rustig over tijd mn data laten vernielen.

[Llopigat]

Ja lijkt me ook. Alleen het probleem is dat bij geheugen errors ook de checksum 'goed' kan zijn. Omdat hij dan gewoon de verkeerde data wegschrijft. Het hangt er maar net vanaf welk bitje omvalt.

Maargoed als er een error is dan volgen er wel meer en uiteindelijk merk je het wel zoals je zegt. Ik doe ook dagelijks een scrub op mijn werkstation en ik heb een cron actie die me dan een mailtje stuurt als de uitkomst niet "0 errors" is.

[Reactie gewijzigd door Llopigat op 6 september 2025 11:52]

[emansom2]

Yep! TransIP gebruikt het al jaren zonder problemen afaik.

Aanpassing:

Ja natuurlijk is de ontwikkelaar van z'n eigen bestandssysteem, een voorstander ervan. Zelfs ook al zou hij zeggen dat iedereen het moet gebruiken, is dat toch te verwachten?

Is Bugatti opeens aansprakelijk als het zegt, dat iedereen hun nieuwe W16 monster moet kopen?

Torvalds is uiteindelijk de bepaler of het in de standaard lijst komt, die beslissing en verantwoordelijkheid hoort niet opeens heen en weer gegooit te worden door Torvalds zelf.

[Reactie gewijzigd door emansom2 op 4 september 2025 11:08]

[Llopigat]

Het "experimenteel" label kwam echter van overstreet zelf en hij wilde daar pas sinds Juni vanaf https://www.phoronix.com/news/Bcachefs-Linux-6.17

Al denk ik niet dat dat daadwerkelijk gebeurd is door deze problemen. Ik zie er niet zoveel over omdat google nogal overspoeld is door artikelen over de verwijdering.

Edit: Oh het is ZFS wat TransIP gebruikt, nu snap ik het. Dat is ook al 24 jaar oud natuurlijk, en bedoeld voor datacenters.

[Reactie gewijzigd door Llopigat op 4 september 2025 11:02]

[Vizzie]

Jammer dat dit zo gelopen is, maar ik snap de ontwikkelaars van Linux wel in deze: als je aan iets zo groots en complex werkt met een heleboel mensen moet je je gewoon aan afspraken houden om iets voor elkaar te krijgen, anders wordt het één grote chaos.

Natuurlijk wil de ontwikkelaar van dat bestandssysteem een zo goed mogelijke oplossing leveren, maar dat kan ook een volgende release lijkt mij. Ook daar zal hij vast na het sluiten van de merge-termijn nog wel bugs en of mogelijke verbeteringen in zijn software vinden, maar dat blijft altijd hoe geniaal deze ontwikkelaar ook mag zijn.

[THETCR]

Fixes mogen nog prima gemerged worden.
Nieuwe features mogen alleen niet meer toegevoegd worden.

Kent besloot een PR aan te bieden voor fixes, maar daar ook nieuwe features bij te doen.

Sowieso hoor je iets van conventional commits te volgen en je wijzigingen te scheiden.

Dat Torvalds hier over viel is niet onterecht. De manier waarop had echter wel anders gekund.

[teek2]

Ja, mee eens. En Torvalds is zelf ook wel het type "grote waffel" en niet onbekend met controverse. Dus wat meer begrip had wellicht gekund. Maar ja Kent had ook gewoon minder kunnen zeuren. Helaas, we verliezen iets moois. Al denk ik dat inmiddels de reputatie van BTRFS ook niet meer verdiend is en dat het zeker een solide keuze is om daar voor te gaan.

Zelf heb ik vooral ZFS poolsl, maar op root altijd nog maar EXT4. Al leeft alles op root tegenwoordig toch in Git, en op een laptop heeft COW niet zoveel zin (je detecteerd wel data corruptie maar je kunt er alleen weinig mee... tenminste, misschien van een backup, maar het fixt niet automagisch.)

[Reactie gewijzigd door teek2 op 4 september 2025 12:04]

[Guru Evi]

Root op ZFS is mogelijk tegenwoordig Debian heeft dit dus alles downstream daarvan heeft het. BTRFS en bcachefs proberen hetzelfde probleem op te lossen en beide hebben hetzelfde ontwikkelingsprobleem - namelijk dat features belangrijker zijn dan stabiele data.

ZFS is geschreven met het concept dat data heilig is en dus alles wordt gedaan om te zorgen dat data niet corrupt kan worden in normale omstandigheden. Daarom dat de core van ZFS heel erg stabiel is en enkele honderden lijntjes code, daar wordt niet mee gespeeld. Dat brengt wel mee dat o.a. block pointers niet (gemakkelijk) herschreven of data niet veranderd van locatie worden terwijl BTRFS dit een bug vindt maar het equivalente data structuur is daardoor niet gegarandeerd en als er een bug in een nieuwe feature zit gaat de data mee.

[Reactie gewijzigd door Guru Evi op 4 september 2025 13:17]

[ScharlakenRood]

Vooral het gebruik van ZFS op root niveau heeft voordelen zoals Solaris dit gebruikt. ZFS snapshots maken integraal deel uit van het package systeem en zorgen bij upgrades voor nieuwe en of meerdere Boot environments (BE). ZFS is in mijn ogen niet enkel eenvoudig in gebruik en beschikt over sterke features, doch de integratie met de rest van het OS (upgrades) maakt het echt sterk. Ik wacht al lang op zo een integratie in de Linux wereld ... die door de licentie angsten zeker niet snel zal komen.

[Guru Evi]

Je kunt gewoon een dpkg hook schrijven die een snapshot maakt voor je package installatie begint. Het probleem in Linux om zulke dingen te standaardiseren is dat je LVM en ZFS en BTRFS etc kunt combineren en behalve ZFS is het niet altijd zeker of een snapshot zal werken.

[goarilla]

Zelf heb ik vooral ZFS poolsl, maar op root altijd nog maar EXT4. Al leeft alles op root tegenwoordig toch in Git, en op een laptop heeft COW niet zoveel zin (je detecteerd wel data corruptie maar je kunt er alleen weinig mee... tenminste, misschien van een backup, maar het fixt niet automagisch.)

Hoe alles op root leeft in git ... doe jij reproducible builds van je system en scheid je enkel je home in een dataset ofzo ? Een tijdje terug (~2014-2016) was ik eventjes maintainer van de ZoL/OpenZFS slackbuilds op Slackware en draaide ik ook ZFS op een root dataset in raidz2 door de kernel modules (spl-solaris.ko, zfs.ko, etc ...) in de initrd te proppen. Dit was wel wat werk, omdat in Slackware initrd bouwen na iedere update van zowel de ZFS en de kernel manueel moe(s)t, maar ik had het gedocumenteerd en verspreid in het ##slackware channel en op mijn site. En dat werd geapprecieerd. Ik dacht dat archive.org het gearchiveerd had voordat ik mijn dedicated server afzette maar ik was te laat. Enkel mijn boot partition was geen zfs en bevatte de kernel en de initrd op een dm-raid1 ext? partitie.

Ik zie nu dat er mensen zijn die dit hebben opgepakt of onafhankelijk hebben gecreerd met betere kwaliteit (https://openzfs.github.io...ware/Root%20on%20ZFS.html) (ik deed enkel MBR/GPT, geen UEFI). En ook geen dataset clones. Ik wou gewoon de checksumming en
snapshots die ik live kon terugrollen. Maar er waren toen ook mensen met laptops die een SSD en een HDD bevatten en die 1 vdev mirror hadden met read priorities die naar de SSD ging. Dit is wat ik met wat gegoogle nog kan vinden dat tangentieel dit gebruik beschrijft alhoewel het niet de pagina/blogpost was die ik destijds las en me enorm intrigeerde (https://github.com/openzfs/zfs/issues/11234). Dit liet de persoon die het gebruikte toe om zijn SSD te verliezen en tijdelijk verder te gaan op een degraded ZFS vdev en vice versa.

Ondertussen lijkt OpenZFS ook nog andere dingen geintroduceerd te hebben zoals speciality VDEV's and DRAID maar dat is nutteloos voor 99.9% van de gebruikers. En voor mij zolang BTRFS geen deftige RAID5/6 implementatie heeft is het niet klaar !!!

[Reactie gewijzigd door goarilla op 4 september 2025 16:55]

[teek2]

Mijn NixOS config leeft in git, en met NixOS kan je ook in grub terug naar al je vorige builds.

[goarilla]

Wow jij hebt een LISP hoofd ? Chapeau. NixOS is zoiets zoals (B)LFS voor mij. Staat op de bucketlist maar ik neem die lijst waarschijnlijk mee op de tocht over de Styx.

[teek2]

Nou eerlijk gezegd heb ik de iso gepakt en op mn laptop (en servers) gezet. Na het toevoegen van packages die ik nodig had was ik productief. En nu leer ik in kleine stapjes. ZFS voelt wel als een erg goed ondersteuned, heb ik verder weinig Nixigs voor hoeven doen.

[Stetsed]

"Dus wat meer begrip had wellicht gekund."

Ik moet well zeggen dat hoewel Linus soms inderdaad een tikje arrogant kan zijn. Is deze situtatie van kents eigen maken. Hij heeft nu meer kansen gehad dan elke andere developer ooit zou krijgen in dit soort situtatie, en het is niet dat hij een fout maakte maar hij maakt elke keer weer dezelfde fout, uit mijn hoofd heeft hij bijvoorbeeld 3 keer proberen in een RC merge window features in te brengen, en elke keer zegt hij niet "Sorry" maar "Ik ben belangrijker dan jullie allemaal ik weet het beter".

[teek2]

Hij zegt niet dat hij belangrijker is, hij zegt dat het misschien features lijken, maar dat het dingen zijn waar zijn gebruikers erg op zitten te wachten. Misschien had hij gewoon nog 2 jaar moeten wachten met in-tree worden.

[Tim AtSharp]

"De manier waarop had echter wel anders gekund."

Mogelijks, maar een technsiche discussie omvormen naar iets semantisch is - hoewel erg gangbaar deze tijd - geen weg die naar resultaten leidt. Dat Overstreet dan 'offended' is, en velen dat ook zo zien, maakt niet dat Torvalds zou moeten afwijken van de regels - regels die hij bij iedereen en overal toepast notabene. Het (toestaan van) breken van regels voor/door de ene is het niet respecteren van al degenen die de regels wél volgen...

[NEO256]

Sluit me hierbij aan.

Als ontwikkelaar zelf, wat voor mij voor de meeste chaos in mijn hoofd, mijn werkwijze en doorlooptijd van dingen waar ik aan ontwikkel zorgt, is onzekerheid, wat voorkomt aan gebrek aan vertrouwen, en het ergste is doorbreken van processen die bestaan om fouten onder controle te houden.

Als ik niet uit kan gaan ontwikkel cycli, daarna overgaan op tests met validatie van unit en use cases en daarna naar een release kandidate. In leken taal, een versie die naar de buitenwereld gaat, waar je alleen fouten en interface dingen fixt.

Dan krijg ik gewoon niks meer voor elkaar, want ik kan niet alle aspecten van ontwikkeling tegelijkertijd toepassen. Net als schilderen; defineren, schetsen, valideren, corrigeren, basis laag schilderen, silhouet schilderen, details toevoegen, shaden en schaduwen tenslote cleanup. Dan kun je nog steeds "patchen" als in dat hele proces voor een stuk van je schilderij nog eens toepassen, maar je moet blijven compartimentaliseren.

[WargamingPlayer]

Vanuit eindgebruiker gezien wil je juist twee paden. Pad 1 is het fixen van bugs. Pad 2 het toevoegen van features.

Je wil niet dat beide simultaan lopen. Nu kan een ontwikkelaar wel zeggen “dat is niet uitdagend, past niet in mijn werkstijl, vind ik niet fijn”. Maar vanuit het perspectief van de eindgebruiker (gebruiker, beheerder, compliancy, et Cetera) is dit totaal niet relevant.

Het is namelijk vreselijk om tegen mensen te zeggen we hebben een nieuwe versie waarin fouten opgelost zijn. En twee uur later krijgt de helpdesk 500 telefoontjes dat de software niet werkt, omdat er een nieuwe feature is toegevoegd waarin een bug zit. Gebruikers zien software die werkt of niet werkt. Dat er een bug gefixeerd is interesseert ze niet wanneer een nieuwe feature ook een storing geeft.

Vandaar dat je nooit beide simultaan doet. Ook omdat je voor upgrade of implementatie specifiek wil testen en met extra features maakt het testen te complex.

Bij ons is het ook verboden om dit te doen. En externe leveranciers wordt ook gevraagd om dit strikt te scheiden.

[codeneos]

Conventional commits gaat over de commit. Een PR kan meerdere commits bevatten.

Nu weet ik zsowieso niet of de Linux kernel de conventional commit standaard volgt. De Linux kernel bestaat ook al veel langer dan de CC standaard.

[Reactie gewijzigd door codeneos op 4 september 2025 22:36]

[THETCR]

Ja dat weet ik.
Vandaar de "Sowieso hoor je iets van".

Voor de PR geldt hetzelfde.
Je gooit niet allerlei zaken die niks met elkaar te maken hebben in dezelfde PR, dat is gewoon slordig.

zowiezo

Overigens is het sowieso.

[Reactie gewijzigd door THETCR op 4 september 2025 12:24]

[pixeled]

Sluit me hier 100% bij aan

Begrijp oprecht niet dat Overstreet zo moeilijk doet. Hij kent de regels, een merge windows is alleen voor fixes en hij weet dus dat hij met zijn nieuwe features zal moeten wachten tot de volgende kernel release. Wat zijn "ja maar dit is echt zo belangrijk!"-argument betreft; Bcachefs is experimenteel, mensen die het gebruiken weten dat. Zeker nu deze discussie zo publiekelijk zichtbaar is geworden

In complexe samenwerking zoals kernel development zijn de bestaande regels er voor een goede reden en is het belangrijk die na te leven en zeker ook om die te handhaven. Linus doet het wat dat betreft geweldig, hoewel misschien (te) bot. Het lijkt voor mij (en dit is pure speculatie) alsof Overstreet zijn eigen werk zo belangrijk vindt dat hij niet aan de regels hoeft te voldoen. In mijn optiek vreemd, want dit is niet bepaald een noodgeval of acute situatie waar een uitzondering voor nodig is. Misschien heeft hij moeite om het daadwerkelijke belang van zijn "kindje", Bcachefs, in te schatten.

Oh well. Kernel developer drama, blijft leuk Ik hoop dat Linus zijn werk nog lang blijft doen.

[kabelmannetje]

"Dat Torvalds hier over viel is niet onterecht. De manier waarop had echter wel anders gekund. ”

Want? Keer op keer bleek Kent niet in staat te zijn tot volwassen communicatie, zich aan richtlijnen te committeren, ellenlange rants tegenover andere (BTRFs) devs, rants naar andere devs en een duidelijk toxic houding. Elke communicatie naar Kent, is zinloos omdat hij geen idee heeft wat zelfreflectie is.

Wat moet Thorvalds hiermee, anders dan persoon wieberen?

[arjankoole]

Dat Torvalds hier over viel is niet onterecht. De manier waarop had echter wel anders gekund.

Als het vergelijkt met de Linus van eerst, dan is dit streng maar rechtvaardig. Ik zie weinig mis met de afwijzing in kwestie.

[Keypunchie]

Dat Torvalds hier over viel is niet onterecht. De manier waarop had echter wel anders gekund.

Het lijkt erop dat het gedram van de bcachefs-developer bij Torvalds onder de huid is gekropen.

Van mij hoeft hij echt geen heilige te zijn. De man vroeg om een uitzondering, voor een nogal obscuur filesysteem, het antwoord was "nee". Nou, dan komt het wel in de volgende versie. Of mensen die heel grag al de nieuwe versies willen kunnen gewoon zelf vanaf branch compileren...

[Thomg]

Dat is ook mijn takeaway hier. Door dit toch toe te laten krijg je echt een slippery slope en gaat eigenlijk het hele doel van een mergetijdvenster teniet. Torvalds had het misschien wat leuker kunnen verwoorden, maar ik vind dat Kent hier vooral de fout in gaat. Des te meer ik erover lees wel des te meer ik het gevoel heb dat dit de zoveelste aanvaring was en dat Torvalds er gewoon klaar mee was.

[rob12424]

Ik dacht dat Reiserfs om meerdere redenen doodbloeden.

1. Hoofd maintainer zit gevangen
2. Er was een opvolger dacht dat Btrfs de voordelen van zfs ext4 en Reiserfs ging combineren?

[GertMenkel]

ReiserFS stierf de dag dat Reiser zijn vrouw vermoorde. Technisch gezien is het een prima FS, maar niemand wil zich met Hans Reiser associëren. Veel van de verbeteringen die ReiserFS had, zijn sindsdien in de meeste andere moderne bestandssystemen opgenomen (zoals de journaling in ext3).

BTRFS is sindsdien de standaard geworden voor een aantal grote distro's die bereid zijn af te wijken van XFS (zoals Red Hat) en ext4. Ik zou BTRFS niet echt als een opvolger van ReiserFS kwalificeren, meer een alternatief voor ZFS dat vanwege licentieproblemen al lange tijd extra moeite vereist om met Linux samen te werken. ZFS is dan weer het FS dat de voordelen van ReiserFS naar UNIX bracht.

[xorpd]

Ik heb ook begrepen dat ReiserFS één groot lock heeft en daardoor slecht schaalt over meerdere cores.

[Jerie]

Dat was voor Linux 2.6.33, opgelost in 2009: Wikipedia: ReiserFS

[P_Tingen]

Ik weet nu dat het b-cache-fs is, maar in eerdere berichten las ik het altijd als bca-chefs

* P_Tingen volgt de bestandssystemen in Linux niet heel erg op de voet

[Vizzie]

haha zo las ik het zelfs in dit artikel (wel de eerste keer dat ik er ooit iets over gehoord heb), maar b cache fs is wel een stuk logischer dank voor de uitleg

[JT]

Toch wel spijtig hoor. Ik volg de redentatie van Linus volledig en wat mooi om te zien dat het niet meer zo een hork is als voorheen. Al had hij de jij-bak beter achterwege kunnen laten. Daar starten vaak de ad hominem toespelingen mee.

Bcachefs heeft de status experimenteel. Met die gedachte en acceptatie van bijbehorende risico's nemen mensen dat bestandssysteem dan ook in gebruik. Een reguliere Linux release moet stabiel zijn. Daar gaan mensen vanuit. Daar draaien bedrijven ook op. Thuis heb ik er 2 computers op draaien. Ik zit er echt niet op te wachten dat mijn OS een herinstallatie nodig heeft of een upgrade mijn systeem misschien wel stuk maakt om iets experimenteels bij te werken omdat de hoofdontwikkelaar hier niet mee wou wachten. Dan tast je de betrouwbaarheid van het OS als geheel aan, wat in mijn ogen veel meer doet met betrouwbaarheid dan een bug in een experimentele feature.

En omdat Overstreet dat niet wil zien verdwijnt nu misschien een potentieel mooi nieuw "standaard" bestandssysteem uit de kernel. Geen wonder dat ext4 voor veel gebruikers de de facto standaard blijft.

[Jerie]

Volgens mij wordt deze code helemaal niet gebruikt tenzij je bcachefs gebruikt. En daarmee zit Torvalds tussen de gebruikers en Overstreet in, terwijl Overstreet graag zijn gebruikers wil bedienen voor triage indien ze schade ondervinden door bugs. Het is ontzettend jammer maar die moeten dan maar in de volgende release want zo werken release candidates. Voor beide argumenten is wel wat te zeggen, en dit conflict kent eigenlijk alleen maar verliezers.

[JT]

Als alles goed is gegaan dan is dat inderdaad zo Maar ik heb te vaak gekke dingen meegemaakt, waarbij je niet kunt voorstellen dat een puntkomma in een readme.txt (bij wijze van) de build doet breken of een bug introduceert en dat er na onderzoek tóch blijkt dat dat kon op een manier die niemand had voorzien. Ik kan het me wel voorstellen dat hij het zo rechtlijnig handhaaft in dit geval. Alleen dat modder gooien is zo jammer, daardoor zijn er inderdaad alleen maar verliezers.

[gekkie]

Ik mis eigenlijk nog het deel waarin Kent zich vooral nogal veel uitspreekt over de vermeende kwaliteit van andere linux filesystems. In plaats van eerst eens te zorgen dat zijn eigen filesystem en feature compleet en niet meer expirimenteel is.

Kortom vele andere developers (ook niet altijd de makkelijksten of zonder mening) vinden het inmiddels niet de moeite en energie meer waard om nog te proberen met hem samen te werken. En dat is een probleem omdat er ook voor BCacheFS bij tijd en wijlen toch aanpassingen aan gezamelijke code nodig zijn.

Misschien dat er ook nog wel een stukje ReiserFS in het achterhoofd zit.

Spijtig want BCacheFS heeft als filesystem wel potentie.

[_Thanatos_]

Had niet gehoeven. Als je een PR aanmaakt en de maintainer wil het nog niet mergen, dan wacht diegene toch gewoon? Het feit dat je geen PR mag *inschieten* voor een bepaalde tijd, is wel een beetje vreemd.

Zeg gewoon "Dankje voor het PR. Echter we wachten met mergen totdat de RC-periode voorbij is, gegeven de inhoud. Als die periode voorbij is, dan ben je de eerste."

Maar het moest op z'n Torvalds. Sja hij doet dit soort drama grotendeels zichzelf aan. Hij doet briljant werk en is superslim, maar hij is ook een botte boer.

[RoestVrijStaal]

Maar goed ook dat dit uit de kernel wordt gehaald.

Als ik zo de commit list bekijk, neemt die Kent Overstreet 99% van het werk voor z'n rekening. Voor iets essentieels als een bestandssysteem heb ik liever dat het werk beter verdeeld is over meerdere mensen. Want het gaat hier ten slotte over de opslag van je bestanden.

Als Kent Overstreet als een Hans Reiser z'n vrouw vermoord, zitten mensen die bcachefs als daily driver gebruiken bij gebrek aan een goed ingevoerde maintainer met de gebakken peren. Hoeveel mensen zullen dat überhaupt zijn?

Het zou beter zijn als alle support voor bestandssystemen, met uitzondering van die essentieel zijn om te booten (initramfs) of rudimentair mee te debuggen (kerneldumps) uit de kernel gehaald worden. De bestandsystemen die de eindgebruiker echt wil kan prima via DKMS of via FUSE.

[Reactie gewijzigd door RoestVrijStaal op 4 september 2025 22:28]

[Boedie]

Goed geschreven artikel, leest goed weg!
Ik begrijp de houding van Linus wel, zeker als deze software in experimentele fase zit.
Lekker wachten op een volgend merge-window. Discussies verzanden wel een beetje in semantiek. Is het een bugfix of feature? Tjah...