Meta zegt 'miljarden dollars' te besparen door gebruik van bestandssysteem Btrfs

Je zou kunnen denken dat de discussie over bestandssystemen er eentje is die in de marge wordt gevoerd. Maar niet bij Meta. Het bedrijf zegt namelijk 'miljarden dollars' te besparen door een bepaald bestandssysteem te gebruiken, Btrfs.

Dat zegt Josef Bacik, een ontwikkelaar voor Meta die ook een maintainer is van Btrfs, in een mail aan maintainers van een alternatief bestandssysteem, bcachefs. "De volledige Meta-infrastructuur is volledig op Btrfs gebouwd", zegt Bacik. "We hebben miljarden dollars bespaard in infrastructuurkosten dankzij de features en mate van robuustheid van Btrfs."

Hoewel Bacik niet specifiek uitlegt op welke manier Meta geld bespaart, is het al langer bekend dat het bedrijf Btrfs inzet. Daar hebben mensen als Bacik ook al langer presentaties over gegeven. Meta heeft meerdere programmeurs in dienst die ook werken als maintainer van het bestandssysteem.

Bacik reageert in zijn mail op recente ophef over een alternatief bestandssysteem, bcachefs. Dat zou een nieuw filesystem worden dat in de Linux-kernel zou moeten worden geïmplementeerd, maar Linus Torvalds trok daar eerder de stekker uit bij de ontwikkeling van kernelversie 6.17.

Update, 13.12 uur - We noemden Linus Torvalds in het artikel aanvankelijk Linux Torvalds. Deze logische fout is hersteld.

Reacties (146)

146

143

102

Wijzig sortering

HollowGamer 11 augustus 2025 12:59

Even voor de duidelijkheid, bcachefs is niet gekilled door Linus (de ontwikkelaar van Linux-kernel). Linus was er klaar mee dat de PRs door de ontwikkelaar(s) voor issues zorgen buiten de bcachefs tree. De ontwikkeling van bcachefs gaat gewoon door, maar dus buiten de Linux-kernel om.

Dit hadden ze in mijn optiek ook gewoon moeten doen vanaf het begin. Het is zeker goed dat Linus hem toch een kans heeft gegeven, maar wat ik zo heb meegekregen is de ontwikkelaar van bcachefs iemand die nogal graag met een hele grote PR komt, en daarbij onvoldoende test. Het doet mij denken aan de recente Xorg-ontwikkelaar die patches stuurde en onvoldoende op werden gecheckt. Beide zijn geen slechte mensen, maar vaak is het beter om dan te zeggen: 'doe je ding in je eigen tree, en stuur ons een (kleine) PR met aanpassingen die ook voor ons handig zijn'.

Btrfs werkt hier super, ook voor snapshots (ik vind het vaag dat Valve dat nog niet gebruikt voor de SteamDeck), daarnaast is de compressie erg top. Het blijft wel veel langzamer als je het vergelijkt met ext4, en encryptie zit er nog steeds niet in - je hebt nog altijd luks nodig voor dat. Maar daar krijg je ook genoeg goede dingen voor terug. :)

[Reactie gewijzigd door HollowGamer op 11 augustus 2025 13:01]

Xander2 @HollowGamer • 11 augustus 2025 13:19

Btrfs werkt hier super, ook voor snapshots (ik vind het vaag dat Valve dat nog niet gebruikt voor de SteamDeck), daarnaast is de compressie erg top. Het blijft wel veel langzamer als je het vergelijkt met ext4, en encryptie zit er nog steeds niet in - je hebt nog altijd luks nodig voor dat. Maar daar krijg je ook genoeg goede dingen voor terug.

Veel langzamer ben ik het niet mee eens. Je zit ondanks journalling bij ext4 met corruptie op termijn en dat moet je ook meenemen in het geheel. Net als backups (snapshots wat niet kan met ext4).

Als je inodes op zijn in een directory heb je met ext4 echt een probleem. Stabiliteit van een FS (waarom je voor ext4 of XFS koos) is het belangrijkste, al zou ik voor flash op een SD kaart of medium dat zeer gevoelig is voor writes geen btrfs kiezen.

RobertMe @Xander2 • 11 augustus 2025 13:50

Net als backups (snapshots wat niet kan met ext4).

Voor de goede orde, snapshots zijn natuurlijk geen backups. Snapshots zijn alleen dat, een punt in het verleden. Maar nog steeds opgeslagen op dezelfde systeem. Gaat de HDD (of raid set) stuk zijn je snapshots ook weg. En als het filesystem serieus corrupt raakt (en dat is v.z.i.w. bij Btrfs toch nog steeds een risico, al dan niet in bepaalde setups (raid-5/6)) zijn de snapshots ook weg. Of...

Een backup is pas een backup als die ook op zijn minst op een zelfstandig systeem / HDD / ... staat. Waarbij Btrfs neem ik aan, net zoals ZFS, ern "send/receive" mechanisme heeft waarmee je snapshots kunt sturen (/synchroniseren) naar een ander volume (? geen idee of dit de term is, bij ZFS is het een pool, oftewel: de combinatie van schijven die een geheel oplevert waar je data op opslaat). En al stuur je de snapshots naar een (tijdelijk) aangesloten externe HDD, pas dan is het een backup. Omdat je dan daadwerkelijk nog aan de bestanden kunt terwijl het originele volume/pool niet meer te gebruiken is.
(En eigenlijk heb je natuurlijk pas een backup nadat je een restore hebt gedaan/getest

. Anders heb je alleen het vermoeden dat je een backup hebt).

Maar, uiteraard geldt dus wel dat snapshots, en de mogelijkheid tot het "kopiëren" van snapshots naar een ander systeem / volume/pool, het maken van backups veel eenvoudiger maakt.
* RobertMe synchroniseert met Syncthing bestanden vanaf PCs/laptops naar een "server" waar het "veilig" door ZFS wordt opgeslagen. Vervolgens worden daar ook snapshots gemaakt zodat bv dus ook verloren documenten nog teruggezocht kunnen worden. En met ZFS' send & receive gaan de snapshots ook nog eens naar een simpele Orange Pi bij familie waardoor er ook een offsite backup is. Waarbij de bestanden (niet het OS zelf, want minder relevant) ook nog eens zijn opgeslagen in een dataset (subvolume?) met ZFS native encryptie, en de send & receive "raw" is waardoor de gegevens versleuteld over de lijn gaan en de andere kant ze ook onmogelijk kan lezen zonder de encryptiesleutel te kennen. Iets dat Btrfs dan niet kan, want geen native encryptie ondersteuning.

kabelmannetje @RobertMe • 11 augustus 2025 14:11

Een btrfs- snapshot kan een prima backup zijn. Het is immers een diff. Deze wordt bij mij naast de primaire, ook naar een 2e ssd geschreven. Deze snapshot-locatie kan alles zijn, het is immers slechts een serie files.

Er zijn meerdere regimes van snapshots mogelijk.

Van de primaire ssd plus wat recente snapshots, maak ik wekelijks een backup naar externe HD. En een maandelijkse op een andere, die ik bij ouders aflever.

[Reactie gewijzigd door kabelmannetje op 11 augustus 2025 14:13]

joker1977 @kabelmannetje • 11 augustus 2025 20:58

Een btrfs- snapshot kan een prima backup zijn. Het is immers een diff. Deze wordt bij mij naast de primaire, ook naar een 2e ssd geschreven. Deze snapshot-locatie kan alles zijn, het is immers slechts een serie files.

Een snapshot is zeer zeker geen backup. Op het moment dat je FS onderuit gaat, of het onderliggende medium dan heb je geen backup.

RAID is geen backup .Een snapshot is ook geen backup.

kabelmannetje @joker1977 • 12 augustus 2025 08:00

Een snapshot is een prima backup, het is immers een diff zoals ik stelde. De wekelijkse full backup die ik maak, kan gewoon geheel gerestored worden. De snapshots die op beide SSDs staan, zorgen voor mogelijkheid tot een restore van maximaal een uur oud. En dat is prima.

RAID is geen backup .Een snapshot is ook geen backup.

Een magentron is geel. Een kanarie is ook geel.

Een snapshot ook wegschrijven naar een 2e ssd zoals gesteld, is een prima optie om een computer te kunnen restoren tot zeer recent na een crash. En als mijn computer plus ssds in de fik vliegt als wost case scenario, dan is dataverlies dus maximaal een week. Brandt mijn huis agf, dan is het maximaal een maand.

ioor @kabelmannetje • 12 augustus 2025 08:12

Als als als....snapshot is geen backup..anders had t een backup geheten....

Backups bewaar je niet op t zelfde systeem...sterker nog...die houdt je t liefst niet eens op dezelfde locatie....

[Reactie gewijzigd door ioor op 12 augustus 2025 08:17]

kabelmannetje @ioor • 12 augustus 2025 08:16

Dan is een diff op tape ook geen backup.... Dat is het wel, dus een snapshot is het ook, in combinatie met de aanwezige full backup.

ioor @kabelmannetje • 12 augustus 2025 08:19

Op dezelfde locatie?

Btw..is een dif niet een onderdeel van een totale backup?

O...en als 2 verschillende vogels een ei leggen, zijn ze nog steeds niet hetzelfde...

[Reactie gewijzigd door ioor op 12 augustus 2025 08:21]

kabelmannetje @ioor • 12 augustus 2025 08:20

Op dezelfde locatie?

Nee dus.

- faalt 1 SSD, max dataverlies 1 uur

- vliegt mijn computer in de fik, max dataverlies 1 week.

- vliegt mijn huis in de fik, samen met mijn externe HD, max dataverlies 1 maand.

Btw..is een dif niet een onderdeel van een totale backup?

Ja. Net zoals snapshots in gesteld voorbeeld.

O...en als 2 verschillende vogels een ei leggen, zijn ze nog steeds niet hetzelfde...

Dus, je geeft een valse analogie. Raid is geen snapshot. Een snapshot is geen raid.

[Reactie gewijzigd door kabelmannetje op 12 augustus 2025 08:31]

joker1977 @kabelmannetje • 12 augustus 2025 09:27

Ik vind het prima dat jij een snapshot een backup maakt. Dat het dan mogelijk is dat die backup niet werkt omdat het medium onderuit gaat vind jij acceptabel. Maar dat maakt het DUS geen backup.

Een snapshot beschermt je tegen dataverlies omdat je als user een fout maakt. Maar het beschermt je niet tegen bv. een defect medium.

De definitie van backup is in essentie dat het je beschermt tegen alle potentiële problemen. Een backup "moet" dan ook eigenlijk air-gapped zijn van je systeem, op een andere locatie. Liefst op 2 locaties

Verdiep je maar eens in de best strategies van backups en de mantra's van backups. Dan begrijp je waarom ik zeg dat een snapshot geen backup is en RAID ook niet.

kabelmannetje @joker1977 • 12 augustus 2025 14:10

Ik vind het prima dat jij een snapshot een backup maakt. Dat het dan mogelijk is dat die backup niet werkt omdat het medium onderuit gaat vind jij acceptabel. Maar dat maakt het DUS geen backup.

Nee, dat vind ik niet acceptabel, hoe verzin je het. Daarom dus snapshots op 2 devices en 2x full backup op externe HD.

Dat maakt het gewoon een backup.

Verdiep je maar eens in de best strategies van backups en de mantra's van backups.

Waarom? Ik heb uitgebreid in datacenters aan backup-strategien gewerkt.

Dan begrijp je waarom ik zeg dat een snapshot geen backup is en RAID ook niet.

Een koe is geen vogel. Dus een kat is ook geen vogel. Wat een raid nu weer met mijn systeem te maken heeft, is mij een raadsel.

Snapshot ook naar een andere SSD schrijven, gaat prima. Er is immers een weekly full backup aanwezig om volledig te restoren bij genoemd OS falen. Fikt mijn PC helemaal af, dan heb ik persoonlijk niet tot niet boeiend dataverlies en binnen no time weer een werkend systeem. Elk ander scenario kan ik volledig restoren tot maximaal een uur oud.

[Reactie gewijzigd door kabelmannetje op 12 augustus 2025 14:17]

ioor @kabelmannetje • 12 augustus 2025 08:23

De vogels bedoel je...maar ik begrijp je niet helemaal denk ik.

Voor wat ik weet...een backup is een copy van al je data en wat niet op tzelfde systeem bewaart wordt. Incremental en snapshots dragen daaraan bij maar zijn dus geen backup opzich.

En je voorbeeld is toch compleet anders dan wat wij als systeem beheerders veilig vinden/vonden.

Sterker nog..volgens mij was t wettelijk geregeld dat je je backup niet op locatie mocht bewaren

[Reactie gewijzigd door ioor op 12 augustus 2025 08:35]

Xander2 @RobertMe • 11 augustus 2025 14:22

Snapshots zijn backups, een oude versie van het systeem.

Elders parkeren is een backup protocol dat verstandig is.

Snapshots zijn hier niet alleen handig voor het maken van backups maar leveren veel betrouwbaarder backups, performance en systeemintegriteit wat je er ook verder mee doet.

Als ik het FS moet 'locken' om een backup te maken wordt het risico op verloren data (op het moment van backup in geheugen) evenredig aan de hoeveelheid cache die ik alloceer. Tevens heb ik niet de garantie aan het begin van de backup dat een atomaire write op een verder gelegen stuk intussen wordt uitgevoerd tenzij ik de journalling aanzet en grote risico's op dataverlies loop bij stroomverlies of andere crashes.

Er zijn prima tools voor BtrFS (b.v. btrbk) om deze remote (ssh/usb) te transporteren, lijkt me niet in een FS te horen.

syl765 @Xander2 • 11 augustus 2025 22:47

Toch als je de definitie opzoekt van backup dan word er in negen van de tien gevallen verwezen naar een externe locatie.

Een snapshot zie ik ook meer als een lokale backup. Dus even voor die wijziging het bestand vastzetten in zijn huidige vorm.

Als je gegevensdrager met alle snapshots onleesbaar is heb je niets meer aan al je snapshots. Dan ga je restoren vanaf je backup. Dus van de gegevensdrager elders.

kabelmannetje @syl765 • 12 augustus 2025 08:19

Een snapshot zie ik ook meer als een lokale backup. Dus even voor die wijziging het bestand vastzetten in zijn huidige vorm.

Mijn snapshots worden via 2 configs elk uur gemaakt. Config A. gaat naar SSD 1 met OS. B. gaat naar SSD 2 waar home en meuk is. Wekelijks volgt een full backup naar een externe HD en zo kan ik - tenzij m'n computer in de fik gaat, tot een uur terug restoren. En anders een week.

hachee @Xander2 • 14 augustus 2025 09:18

Als je een snapshot kan parkeren op een andere locatie, hetzij andere SSD/remote location, en je kunt deze ook op een nieuwe FS restoren (na een dive fail/FS corruption) kan ik het defineren als een backup, anders is het niet meer dan een snapshot.

HollowGamer @Xander2 • 11 augustus 2025 13:27

Er zijn recente benchmarks van Phoronix die helaas dat nog altijd laten zien. Dacht dat XFS het snelste was, gevolgd door ext4. Als je op Btrfs compressie aanzet (zstd) wordt het iets sneller, maar gaat het wel ten koste van je CPU performance.

Toegegeven Btrfs is niet meer zo langzaam als vroeger, de komende Linux 6.16/6.17 hebben flinke performance boost patches, dus ben ook zeer benieuwd of het (nog) korter kan kruipen naar ext4.

Met het laatste bedoel je geen NVMe/SSD toch? :)
Tegenwoordig maak ik mij minder druk om writes daarop, aangezien ik die vaak upgrade na 2-3 jaar voor de hogere capaciteit o.a.

Xander2 @HollowGamer • 11 augustus 2025 13:43

Die CPU performance heb je gewoon liggen over het algemeen en zstd is razendsnel, dat levert al performance- en ruimte winst als ik swap in geheugen comprimeer met zstd of LC4 op een quadcore 1 Ghz ARM raspberry oid.

Alleen bij grote bestanden als video en audio heeft het geen zin omdat daar geen compressiewinst ligt.

Het is niet zwart/wit. Op m'n ARM NAS heb ik de boot/scratch disk op ext4 en de data op mechanische schijven met btrfs zonder compressie. Dat is sneller in gebruik omdat ext4/XFS simpeler is en die keer dat ik reboot is voldoende voor een diepe check op de ext4 schijf zonder uren in de wacht te staan of ernstig dataverlies, wat wel een probleem zou zijn voor de mechanische schijven wat ik voorkom met btrfs.

Ik denk niet dat het performance-technisch qua writes XFS/ext4/FAT gaat benaderen maar dat is niet erg.

HollowGamer @Xander2 • 11 augustus 2025 14:21

Alleen bij grote bestanden als video en audio heeft het geen zin omdat daar geen compressiewinst ligt.

Ik merk dat dus wel grappig genoeg. Met compression-force scheelt het ~80GB(!) t.o.v. zonder op mijn Synology NAS op video-bestanden (zstd:9 - backup). Het nadeel is wel dat het langzamer is/kan zijn, maar ik dacht dat metadata ook iets mee wordt gedaan, en dat al veel kan schelen.

Xander2 @HollowGamer • 11 augustus 2025 14:33

Misschien geldt dat voor containers en andere data, maar video is lossy gecomprimeerd en zal zelden verbetering opleveren omdat het in principe ook gebruik maakt van LZ.

Dan kun je beter de video met VP9 of moderne codec opslaan dan bij wijze van spreken een RAR in een ZIP opslaan.

HollowGamer @Xander2 • 11 augustus 2025 14:37

Het plan is ooit alles om te zetten naar X265, maar helaas nog niet aan toe gekomen.

Xander2 @HollowGamer • 11 augustus 2025 14:45

Schijfruimte kost geen drol

Energie en tijd wel. Opnieuw schrijven verkort de levensduur.

Recoding is zelden interessant tenzij je een provider bent..

kabelmannetje @HollowGamer • 11 augustus 2025 14:07

Hangt heel veel van het type workload af. Databases, AI, sequentieel/parralel, etc.

Met desktop-gebruik zal je het niet merken. Zonder snapshots, vallen alle andere fs bij mij meteen af. En blijft BTRFs over.

joker1977 @kabelmannetje • 11 augustus 2025 20:56

ZFS

kabelmannetje @joker1977 • 12 augustus 2025 07:28

Er is wat mij bekend, slechts 1 gangbare distributie dat ZFS support. Op productie out-of-tree en unsupported filesystems gebruiken, doe ik niet.

nicenemo @kabelmannetje • 12 augustus 2025 07:53

1 gangbare?? Debian Fedora, OpenSuSE, Redhat , Arch worden allemaal ondersteund.

TrueNAS Scale en Proxmox leunen op ZFS.

https://openzfs.github.io/openzfs-docs/Getting%20Started/index.html

[Reactie gewijzigd door nicenemo op 12 augustus 2025 07:53]

kabelmannetje @nicenemo • 12 augustus 2025 08:05

Fedora

Nee. https://fedoraproject.org/wiki/ZFS

Debian

Nee. https://wiki.debian.org/ZFS

Redhat

nee.

TrueNAS Scale en Proxmox leunen op ZFS.

Wie gebruikt dit op de desktop?

joker1977 @kabelmannetje • 12 augustus 2025 09:39

Dat is je eigen keus. Wat er unsupported aan is, hangt af van je eigen definitie van support. Volgens mij ondersteunt Ubuntu ZFS zondermeer.

Out-of-tree is het zeker, licentie-technisch probleem.

ZFS is, voor zover ik weet, nog steeds stabieler en sneller dan BTRFS. Maar eerlijk is eerlijk, de systeemeisen liggen nogal wat hoger en mijn ervaring met BTRFS zijn niet recent.

Heeft BTRFS nu al goede support voor RAID5/RAID6? Zijn er al reparatie-tools ?

kabelmannetje @joker1977 • 12 augustus 2025 14:05

Dat is je eigen keus. Wat er unsupported aan is, hangt af van je eigen definitie van support. Volgens mij ondersteunt Ubuntu ZFS zondermeer.

Zoals ik al zei, er is maar 1 gangbare. Ubuntu. En nee, de rest heeft geen support. Je kan flauw een symantische draai eraan geven, de links zijn volkomen duidelijk.

ZFS is, voor zover ik weet, nog steeds stabieler en sneller dan BTRFS. Maar eerlijk is eerlijk, de systeemeisen liggen nogal wat hoger en mijn ervaring met BTRFS zijn niet recent.

Niet echt. https://nicholaslyz.com/blog/2025/06/07/btrfs-vs-zfs-performance/

BTRFs is al jaren stable. Bedrijven als Meta kiezen niet ZFS omdat "het sneller" (twijfelachtig dus) is. Maar wel BTRFs omdat het volledig gesupport wordt, direct in de kernel zit - korte lijntjes met devs, GPL, etc.

kabelmannetje @HollowGamer • 11 augustus 2025 13:09

Dit is maar het halve verhaal. Keer op keer heeft Kent het voor elkaar gekregen de top devs van de Linux kernel te schofferen, steeds weer opnieuw de code of conduct te overtreden, dan wel zinloos aan te twijfelen, weer patches aan te leveren die features bevatten ipv bug fixes. Helemaal hilarisch is dat Kent bcachefs "stable" verklaren wilde in 6.18. Met alle ellende die Kent als dev met autistische trekken, met zich meebrengt. Herhaaldelijk is hij op zijn gedrag aangesproken. Meermaals door Linus zelf. Hij bleek niet in staat tot enige zelfreflectie en bleef ook daarna de Linux kernel frusteren.

Stekker eruit was dus de enige logische oplossing, Kent brengt niks meer dan totaal zinloze ruis, ruzie en frustraties voor iedereen. Als je in teamverband wil werken, dan pas je je aan. Helaas voor deze man, onmogelijk.

[Reactie gewijzigd door kabelmannetje op 11 augustus 2025 13:18]

HollowGamer @kabelmannetje • 11 augustus 2025 13:20

Ik heb met dit soort comments wat moeite. De filmpjes over hem op YouTube vind ik ook gek. We hebben het hier over een persoon (mens), die zoals iedereen, bepaalde trekken heeft die niet (goed) passen bij het huidige team.

Zelf heb ik ook autisme, dus herken ik ook best veel wat je zegt en bedoelt. Alleen dat hij zo wordt afgemaakt, vind ik vaak zo gek en ook heel raar tegenwoordig. Brodie (bekende YouTuber) maakte ook recent een filmpje waarbij iemand met issues (dacht diegene die de Macbook patches maakte?), helemaal de grond in boort en wegzet als een heel vervelend persoon.

Hier hebben we onze mond vol van een VVD'er die iemand onterecht op Twitter afmaakt, maar kennelijk is het heel normaal geworden in de software-wereld dat opeens wel goed te vinden?

Het is gewoon simpel: sluit iemand niet goed aan, blokkeer het toegang of zet het lager op de prio lijst. Het hele toxic gedoe, o.a. naar de Rust-developers, vind ik vaak enorm stom om te zien.

kabelmannetje @HollowGamer • 11 augustus 2025 13:25

Het is gewoon simpel: sluit iemand niet goed aan, blokkeer het toegang

Dat is dus gebeurd. Deze persoon kan niet in een team samenwerken. Hij heeft meerdere kansen gehad en niet in staat tot verbetering of enige zelfreflectie.

Ik zie niet een reden dat BcacheFS ooit nog in de Linux kernel komt in huidige vorm. Met Kent's instelling is samenwerken onmogelijk, levert het schade aan het project op en niemand zal zich commiteren aan zulke cristische software, gescreven door iemand met deze eigenschappen.

En dat is jammer, technisch zat het goed inelkaar. De enige optie is dat iemand Kent's communicatie en patches controleert. En hem afschermt van de rest van het project. Lijkt mij uitgesloten .

HollowGamer @kabelmannetje • 11 augustus 2025 13:31

Je schrijft het alsof je hem persoonlijk kent, maar gok dat dit niet zo is?

Over alles wat je schrijft zal zeker een kern van waarheid zitten, maar laten we niet doen alsof Linus zo goed is in communicatie of zelfreflectie - en daar is niets mis mee.

Vaak heb ik meer met de tegendraadse ontwikkelaars, omdat ze ook pushen voor veranderingen. Helaas is dat wat je beschrijft dan wel vaak een gevolg. Dat is ook iets wat hij kan leren, dus wellicht zou de Linux Foundation ook iets kunnen doen aan ondersteuning/training van ontwikkelaars?

Deze Kent cancellen vind ik gewoon niet mooi. Laat hem inderdaad zijn eigen ding doen erbuiten, en verder is het wel genoeg geweest.

kabelmannetje @HollowGamer • 11 augustus 2025 13:39

Je schrijft het alsof je hem persoonlijk kent, maar gok dat dit niet zo is?

Natuurlijk ken ik hem niet persoonlijk. Maar de Linux kernel devs wel...

Over alles wat je schrijft zal zeker een kern van waarheid zitten, maar laten we niet doen alsof Linus zo goed is in communicatie of zelfreflectie - en daar is niets mis mee.

Nogmaals, de diverse kernel devs spreken de waarheid. Linus is prima in staat dit gigantische project succesvol te leiden. Itt Kent. Vandaar dat hij (waarschijnlijk) een ruim gedragen en terechte ban for life krijgt.

Vaak heb ik meer met de tegendraadse ontwikkelaars, omdat ze ook pushen voor veranderingen. Helaas is dat wat je beschrijft dan wel vaak een gevolg. Dat is ook iets wat hij kan leren, dus wellicht zou de Linux Foundation ook iets kunnen doen aan ondersteuning/training van ontwikkelaars?

Nee, dat kan hij dus niet leren. Herhaaldelijk is hij op gedrag aangesproken en hij blijkt niet in staat, zijn gedrag aan te passen.

Deze Kent cancellen vind ik gewoon niet mooi. Laat hem inderdaad zijn eigen ding doen erbuiten, en verder is het wel genoeg geweest.

Kent laat zichzelf cancellen met zijn gedag. De Linux kernel is echt te belangrijk om te laten frusteren door iemand die niet in staat is tot samenwerking.

[Reactie gewijzigd door kabelmannetje op 11 augustus 2025 13:41]

MrMonkE @kabelmannetje • 11 augustus 2025 16:50

Welk gedrag is dat?

kabelmannetje @MrMonkE • 11 augustus 2025 17:01

Continue de confrontatie met kernel developers zoeken. Niet aan de development regels houden. Ondanks herhaaldelijk erop aangesproken worden, gewoon doorgaan, geen zelfreflectie of lerend vermogen.

dasiro @kabelmannetje • 11 augustus 2025 20:02

Als zelfgediagnosticeerd autist kan ik je zeggen dat dit normaal gedrag is, maar dat de wereld ook een probleem heeft om daar mee om te gaan. Je kan 100x NEE roepen tegen een Chinees, hij zal niet begrijpen wat je bedoelt en extra gefrustreerd raken tot je het op een manier en in een taal uitlegt dat hij verstaat. Het grootste probleem ontstaat nog als je beide autisme hebt, iets wat in deze industrie nog veel vaker voor komt, gezien het heel deterministische karakter van het werk, waar we éxtra in uitblinken.

kabelmannetje @dasiro • 12 augustus 2025 07:39

Dus, dan zal ook die Chinees die niet kan communiceren, die steeds de confrontatie zoekt, niet luistert naar anderen en een project frustreert, uit het project gezet worden. Hier is natuurlijke geen sprake van meerdere autisten zoals je lijkt te suggeren. Dat is er maar 1: Kent.

De kernel devs kunnen prima met Kent omgaan. Hij heeft herhaaldelijk een kans gehad zijn gedrag te verbeteren, er is gesuggeerd om therapie te doen, er is keer op keer aangegeven wat verwacht wordt, maar het houdt eens op als je alles negeert. Linux is niet een hobby-projectje. Mensen die niet aantoonbaar niet kunnen samenwerken, horen daar dus niet thuis.

dasiro @kabelmannetje • 12 augustus 2025 07:54

Hier is natuurlijke geen sprake van meerdere autisten zoals je lijkt te suggeren. Dat is er maar 1: Kent.

Of er slechts 1 is kan ik niet uitsluiten, ik ken er niemand van, maar herken wel bepaalde patronen die eraan gelinkt zijn.

De kernel devs kunnen prima met Kent omgaan. Hij heeft herhaaldelijk een kans gehad zijn gedrag te verbeteren, er is gesuggeerd om therapie te doen, er is keer op keer aangegeven wat verwacht wordt, maar het houdt eens op als je alles negeert

Ook dit is een klassiek patroon van iemand die niet met autisme om kan gaan. Je kan niet verwachten dat hij het communicatie en samenwerkingsprobleem helemaal zelf oplost. net zoals een blinde niet kan zien, ga je hem actief moeten helpen en dat doe je niet door te zeggen: simpel toch, kijk gewoon ff links en rechts voor je oversteekt.

kabelmannetje @dasiro • 12 augustus 2025 08:10

Of er slechts 1 is kan ik niet uitsluiten, ik ken er niemand van, maar herken wel bepaalde patronen die eraan gelinkt zijn.

Dat jij dat niet kan uitsluiten, is bijzonder. De rest van de kernel devs kan dat immers prima. Het is Kent en Kent alleen, die niet wil luisteren, niet kan/wil samenwerken, geen advies aanneemt, en zich niet aan de regels houdt.

Ook dit is een klassiek patroon van iemand die niet met autisme om kan gaan. Je kan niet verwachten dat hij het communicatie en samenwerkingsprobleem helemaal zelf oplost. net zoals een blinde niet kan zien, ga je hem actief moeten helpen en dat doe je niet door te zeggen: simpel toch, kijk gewoon ff links en rechts voor je oversteekt.

Bijzonder. Linux kernel development is immers niet een therapeutische sessie van psychologen waar iemand geleerd (in dit geval dus tevergeefs) wordt om met z'n autisme om te gaan. Terwijl tegelijkertijd het project zelf schade oploopt. Als je niet wil of kan samenwerken, dan hoor je daar niet thuis. Dan ga je maar wat anders doen. Of, Kent neemt eens een keer advies aan van anderen en je gaat in therapie bij een psycholoog. Gezien zijn gebrek aan zelfreflectie en neiging de oorzaak bij anderen neerleggen, weinig aannemelijk.

[Reactie gewijzigd door kabelmannetje op 12 augustus 2025 08:12]

kabelmannetje @dasiro • 12 augustus 2025 13:55

Wow. Je schrijft zelf autisme te hebben, maar dat is geen argument om je zo dan zo agressief te gedragen naar anderen. Net als Kent deed. Het gebrek aan zelfreflectie en te leren, was reden Kent te wieberen. De Linux kernel is echt geen therapeutische omgeving om daar te leren met autisme om te gaan.

Succes ermee.

dasiro @kabelmannetje • 12 augustus 2025 17:43

Jij ageert, ik reageer, met dat verschil dat ik me blijkbaar beter dan jou in iemand anders z'n plaats kan stellen. Je zal het wel ontkennen, maar ik zou bijna denken dat je ook een spectrumstoornis hebt.

Communiceren met anderen is geen therapie, maar de dagdagelijkse realiteit waar beide partijen aan moeten werken. Mensen die daar geen rekening mee willen houden treft zo mogelijk méér schuld, dan de persoon die dat niet kan.

kabelmannetje @dasiro • 12 augustus 2025 18:44

Jij ageert, ik reageer, met dat verschil dat ik me blijkbaar beter dan jou in iemand anders z'n plaats kan stellen.

Dat is een drogreden vanuit authoriteit. Jammer, die heb jij natuurlijk niet. Wel de kernel devs.

Je zal het wel ontkennen, maar ik zou bijna denken dat je ook een spectrumstoornis hebt.

Wederom een drogreden, een ad hominem. Dat jij een psycholoog bent, lijkt mij ook uitgesloten. Jammer van deze flauwe en ruzie zoekende opmerking van je.

Communiceren met anderen is geen therapie, maar de dagdagelijkse realiteit waar beide partijen aan moeten werken.

En dat is een foute conclusie. Kernel devs hoeven hun project helemaal niet te laten frustreren door Kent en hoeven ook niet de rol van psycholoog op te nemen om therapie te geven. In therapie ga je bij een psycholoog. Niet bij kernel devs.

Mensen die daar geen rekening mee willen houden treft zo mogelijk méér schuld, dan de persoon die dat niet kan.

En dat is weer een foute voorstelling van de feiten. Kernel devs hebben meermaals Kent de kans gegeven te verbeteren. Hij weigerde zich aan te passen. Dus, dan is het exit.

[Reactie gewijzigd door kabelmannetje op 12 augustus 2025 18:47]

HollowGamer @kabelmannetje • 11 augustus 2025 13:49

Kent laat zichzelf cancellen met zijn gedag. De Linux kernel is echt te belangrijk om te laten frusteren door iemand die niet in staat is tot samenwerking.

Mogelijk zijn er wel genoeg mensen die met hem kunnen aanwerken? Vroeger waren er mensen die zo eigenwijs waren (zal andere woorden niet benoemen), waar we nu uiteindelijk nog altijd dankbaar voor zijn wat ze hebben uitgevonden.

Nu ga ik hem niet op datzelfde level plaatsen, maar ik zie het gewoon terug als je de Linux-kanalen volgt. Ik heb niets met snap, maar de ontwikkelaars ervan, zou ik persoonlijk nooit aanspreken. Zij geloven in wat ze doen, en er zijn genoeg mensen die het wel fijn vinden om mee te werken. Ik vind het systeem niet fijn, maar ik kan niet zoiets maken, en ze doen dit veelal onbetaald(!) ook.

Verder zijn veel ontwikkelaars op sociaal gebied in de minderheid, vooral als ze dieper in het systeem zitten. Vandaar dat ik aangaf dat het beter was dat zijn project niet geaccepteerd werd in de Linux-kernel, aangezien je het al zag aankomen. Het was niet nieuw en ook geen nieuw gedrag van hem, hij deed dit al ervoor, en hij ging echt niet veranderen door het op te nemen in de kernel.

Dat Linus hem zo afmaakte vond ik ook wel jammer en zielig. Terecht dat er ook mensen zijn (zoals ik o.a.) die ook vinden dat Linus beter moet handelen of anders ermee om moet gaan (zoals Russische ontwikkelaars buitensluiten - of hij nu een punt heeft of niet - het gaat op de manier waarop).

kabelmannetje @HollowGamer • 11 augustus 2025 14:03

Mogelijk zijn er wel genoeg mensen die met hem kunnen aanwerken?

Niet zo relevant, hij kan niet in de Linux kernel samenwerken. Punt.

? Vroeger waren er mensen die zo eigenwijs waren (zal andere woorden niet benoemen), waar we nu uiteindelijk nog altijd dankbaar voor zijn wat ze hebben uitgevonden.

Niet heel relevante valse analogie, als argument om de Linux kernel te frustreren.

Het was niet nieuw en ook geen nieuw gedrag van hem, hij deed dit al ervoor, en hij ging echt niet veranderen door het op te nemen in de kernel.

Eerder zeg je dat hij een kans moet hebben. Nu zeg je dat het terecht is dat hij niet in de kernel zit. Die kans heeft hij herhaaldelijk gehad en hij is niet in staat tot samenwerking. Feit, dus exit.

Dat Linus hem zo afmaakte vond ik ook wel jammer en zielig. T

Volkomen verzonnen. Ik heb de wisseling gevolgd en Linus heeft het professioneel en correct opgelost. Met volledige instemming van top-devs. Wat jij daar verder van vindt, is niet zo relevant. Autisme hebben is geen argument een zo'n kritisch stuk software, te frustreren.

[Reactie gewijzigd door kabelmannetje op 11 augustus 2025 14:04]

HollowGamer @kabelmannetje • 11 augustus 2025 14:16

Eerder zeg je dat hij een kans moet hebben. Nu zeg je dat het terecht is dat hij niet in de kernel zit. Die kans heeft hij herhaaldelijk gehad en hij is niet in staat tot samenwerking. Feit, dus exit.

Dat heb ik nooit gezegd, ik zei dat het Linus sierde het een kans te geven. Maar gaf daarbij ook aan, dat het niet in de kernel had moeten zitten, gezien de vele changes die de ontwikkelaar doet en inderdaad daarbij de (kernel)richtlijnen niet volgt.

Het was voor mij echt een verrassing dat Linus het toeliet, maar misschien kwam het ook omdat hij Rust toe heeft gelaten, en dacht dan dit ook maar? Opzicht is het ook niet fout, je kan altijd later toch weggaan van de kernel.

Volkomen verzonnen. Ik heb de wisseling gevolgd en Linus heeft het professioneel en correct opgelost. Met volledige instemming van top-devs. Wat jij daar verder van vindt, is niet zo relevant. Autisme hebben is geen argument een zo'n kritisch stuk software, te frustreren.

Deels mee eens, maar om verder alles niet relevant te maken, is geen goede manier om te zeggen 'dan maar niet'. Mensen zijn geen robots, dus deal with it dat er mensen tussenzitten die lastig zijn. En ja, die hoef je niet in je team te willen. Linus had dat in mijn ogen wel beter kunnen doen, of hem al niet in zijn team eens kans moeten geven.

Zoop @HollowGamer • 11 augustus 2025 13:53

Hij wordt toch niet per se gecancelled? Er worden enkele redenen genoemd dat te maken heeft met zijn gedrag, welke zo ver ik weet niet gelogen zijn. Dus wat is het punt dan?

Wellicht zijn het autistische trekjes waar hij niet veel aan kan doen, maar bot gezegd heeft de rest van het project niets mee te maken, ongeacht de reden, er valt niet samen te werken met deze man. Het is zijn verantwoordelijkheid daar verbetering in te maken (zeker nadat er meerdere kansen zijn gepasseerd), desnoods door onder iemand te gaan zitten die zijn werk controleert. Als niemand meer met hem wil werken door dit soort berichtgeving, dan is dat toch echt zijn eigen probleem om wat te doen aan zijn reputatie.

In any case, ik zie geen probleem met het presenteren van feiten over wat er gebeurd is. Het is geen lastercampagne tegen mr Kent ofzo.

HollowGamer @Zoop • 11 augustus 2025 14:00

In any case, ik zie geen probleem met het presenteren van feiten over wat er gebeurd is. Het is geen lastercampagne tegen mr Kent ofzo.

Het feit dat iedereen zijn naam kent en gebruikt, vind ik dat er dus wel dat meespeelt. Iedereen kent bijvoorbeeld ook de naam van de Pulseaudio/systemd ontwikkelaar, en vaak is dat niet in een positieve context, maar ook als iemand die iets niet goed doet voor de Linux-wereld (niet mijn woorden, maar zoek eens op artikelen en zijn naam).

Ik snap wat je zegt, alleen vind het nogal moeilijk omdat het om kwetsbare ontwikkelaars gaat, en ik vind dat die onvoldoende worden beschermd of ondersteund.

tedades @Zoop • 11 augustus 2025 16:55

Voor de volledigheid: wat zijn die autistische trekjes? Zoals ik het lees is er overlap tussen systeemdenkers en mensen met autisme. Maar uit de context in deze lopende discussie lijkt het gebruikt te worden als negatief gedrag. Maar blijkbaar ben ik daar onbekend mee, want het zegt mij niets. Wat ik online kan vinden zou het kunnen zijn: focus op details (lijkt me juist een positief iets bij kernel werk), ongelukkige communicatie (niet perse autistisch), snappen en volgen van ongeschreven regels, geïsoleerd en introvert leven.

ronaldvr @HollowGamer • 11 augustus 2025 13:35

Ik begrijp dat jij daar moeite mee hebt, maar anderen hebben weer moeite met de manier waarop die persoon zich gedraagt. En het is nu eenmaal niet mogelijk om het altijd iedereen helemaal naar de zin te maken, dus dan moeten er keuzes worden gemaakt.

En als een andere partij zich daar den niet goedschiks naar voegt dan loopt het uit de hand. En daar kan je dan diegenen die een streep trekken niet voor aankijken dat die iets 'verkeerd' doen: Als het lang genoeg geduurd heeft de ander volop kansen heeft gekregen dan zullen er uiteindelijk consequenties volgen. Dat is dan onvermijdelijk.

HollowGamer @ronaldvr • 11 augustus 2025 14:04

Het probleem is dat Linus alleen niet zo goed hier mee omgaat. Aan de ene kant prijs ik Linus enorm voor zijn directe aanpak, aan de andere kant vind ik het ook soms schuren.

Deze persoon had je ook anders uit je team kunnen zetten. Het is alsof je bij het amateurvoetbal te horen te krijgt, dat je niet meer mag meedoen omdat je alles fout doet (zelf meegemaakt). Soms moet je harde woorden gebruiken, maar Linus heeft in mijn ogen meteen de bijl gekozen en hem nogal afgemaakt op zijn PRs/mailinglists.

Dat vind ik jammer, want je maakt hierdoor het wel wat toxic. Snap Linus ook, maar soms denk ik wel 'het kan een tandje minder of met meer gevoel'. Het zijn vaak vrijwilligers, en ik snap dat sommige mensen denken 'ik doe liever niet een PR sturen, want Linus kan mij ook keihard afmaken'. De rechterhand van Linus, doet dit bijvoorbeeld stukken beter.

[Reactie gewijzigd door HollowGamer op 11 augustus 2025 14:06]

bkor @HollowGamer • 11 augustus 2025 14:21

Soms moet je harde woorden gebruiken, maar Linus heeft in mijn ogen meteen de bijl gekozen en hem nogal afgemaakt op zijn PRs/mailinglists.

Dat zeg je echt veel te makkelijk. Linus heeft echt gigantisch veel discussie gevoerd. En enorm vaak aangegeven over de verschillende problemen rondom de samenwerken. Het gedrag veranderde niet, de persoon dacht elke keer toch "gelijk" te hebben.

Zeggen dat Linus gelijk een "bijl heeft gekozen" vind ik de geschiedenis vervalsen.

HollowGamer @bkor • 11 augustus 2025 14:41

Daar heb je zeker een punt, en ook gelijk in.

Linus heeft het ook geprobeerd, en dat is ook wat ik benoem. Voor mij was het al een verrassing dat het project in de kernel ooit is gekomen (gezien hoe Linus omgaat met een standaard manier van werken).

Het einde had voor mij anders gekund. Je kunt ook uit elkaar gaan met een iets zachtere toon, al snap ik zeker de frustraties van Linus zelf. Je moet helaas tegenwoordig zeggen: 'we gaan uit elkaar, dat is geen excuses om het heel groot te maken of hem persoonlijk aan te vallen' (zoals dus in elk artikel + YT fimpje).

DefaultError @ronaldvr • 11 augustus 2025 14:49

In de regel past een spreuk niet op een tegel.

“Er is nog nooit een kok gevonden die koken kon naar alle monden”.

DefaultError @kabelmannetje • 11 augustus 2025 14:46

Klinkt als Rock&Roll, negatieve aandacht=aandacht. Mogelijkerwijs levert het een prima deal op die wij als lezer en gebruiker tot op de dag van vandaag ‘nog’ niet weten hoe dit allemaal tot stand is gekomen.

Hardfreak @HollowGamer • 11 augustus 2025 13:08

Belangrijk detail in het verhaal is dat de maintainer van bcachefs na het aanmaken van de release candidate geregeld afkwam met PR's waarin nog nieuwe features zaten. Na de RC fase is het de bedoeling om alleen nog maar bugfixes te submitten omdat nieuwe features betekenen dat je heel de RC opnieuw moet gaan testen. De bcachefs maintainer trok zich daar heel weinig van aan en maakte PR's aan met zowel bugfixes als nieuwe features in (met dus het potentieel dat er voor die nieuwe features opnieuw bugfixes nodig zijn alvorens ze de RC finaal konden maken).

Ondanks meerdere waarschuwingen van Linus bleef de maintainer dat dus en dus wat dat betreft is het een heel goede beslissing om bcachefs uit de kernel te halen. Jammer voor de mensen die het gebruiken, maar de stabiliteit van de linux kernel is net iets belangrijker dan het ego van één persoon.

HollowGamer @Hardfreak • 11 augustus 2025 13:14

Klopt, hij volgde niet de richtlijnen van de Linux-kernel, en kwam dan vaak achteraf met een fix voor corruptie issues(!) die mensen hadden.

Ik zou persoonlijk het dan ook niet aanraden, en gewoon bij btrfs of zfs blijven (ext4 voor simpele stuff). Bcachefs ziet er leuk uit op papier, maar in de praktijk is het echt een ramp. Hopelijk komen er wel features van dit naar btrfs (zoals o.a. memory caching), en bepaalde ideeën zitten al deels in de kernel zelf - zodat het werkt met vrijwel ieder FS (dacht o.a. dedup).

dmantione

Linux

@HollowGamer • 11 augustus 2025 13:18

Ik zie dit toch wel als het eind van BcacheFS. Zeker kan het buiten de kernel doorontwikkeld worden. Dat is ook met ReiserFS gebeurd, maar zonder dat het in de kernel zit, zal niemand het gebruiken. Net als bij ReiserFS denk ik dat er ook bij BcacheFS een wonder zal moeten gebeuren om het terug in de kernel te krijgen, de verhoudingen zijn namelijk goed verziekt.

BcacheFS wil mijn inziens ook een probleem oplossen dat niet bestaat. De hele website van BcacheFS leest als een soortminachting jegens BTRFS. Als men wat BTRFS niet voor elkaar krijgt wel even zou regelen.

De waarheid is dat ik al minstens 5 jaar meerdere computers op BTRFS draai en zoals Meta hier stelt, er draait een hoop kritische infrastructuur op BTRFS. BTRFS zit in de kernel, wordt verder verbeterd omdat BTRFS business is, terwijl BcacheFS buiten de kernel amper externe programmeurs en feedback zal krijgen om het verder te verbeteren.

HollowGamer @dmantione • 11 augustus 2025 13:37

Persoonlijk en gevoelsmatig (ben geen kernel developer - volg het van een afstand) denk ik dat een filesystem steeds meer gaat leunen op de kernel. Waarbij 'vroeger' zaken echt in het FS zaten, zie je nu best veel door de kernel heengaan. Dat is veel sneller en robuster, en je krijgt een API dat een FS kan aanspreken.

Volgens mij is dat heel lang zo, maar toch zie ik in mijn glazen bol dat de kernel meer van dit soort dingen gaat doen. We hebben snelheid nodig en de overhead willen 'we' wegnemen. Ik dacht dat Btrfs bijvoorbeeld veel door de kernel laat doen tegenwoordig, en andere daar ook weer van profiteren.

Maar als iemand hier meer over weet, dan lijkt me dat wel interessant om te weten. :)

Halfscherp @HollowGamer • 11 augustus 2025 23:42

Het is meer dat Kent het liefst bugfixes zo snel mogelijk in de handen van gebruikers krijgt, wat fundamenteel incompatible is met hoe development aan de Linux kernel gedaan wordt. Vooral omdat voor sommige bugfixes er nieuwe features nodig waren, en die horen volgens Linus dan in een ander kernel development proces.

Uiteindelijk zal bcachefs wel terugkomen in de tree denk ik. De manier waarop het werkt is wel echt de toekomst.

maali @HollowGamer • 11 augustus 2025 13:36

de enige filesystem killer blijft dus Reiser! ;)

RobertMe @maali • 11 augustus 2025 13:55

Ook die heeft zijn filesystem niet vermoord. Maar dat is wel een gevolg van...
Hans Reiser voor degenen die "hem" niet "kennen".

HollowGamer @RobertMe • 11 augustus 2025 14:23

Vandaar ook die knipoog op het einde van zijn comment, maar goed dat je het erbij zegt.

Ben je vaker ReiserFS tegengekomen? Ben het één keer tegengekomen op een externe schijf van een onbekende vendor. Verder nooit echt gezien.

BeerenburgCola @HollowGamer • 11 augustus 2025 17:36

(Open)SuSE installeerde het jaren als default fs. Werkte merkzaam efficiënter en sneller dan ext4.
Nu werkt (Open)SuSE default met btrfs. Was wel effe wennen aan die subvolumes, maar werkt ook prima.

dcm360

@HollowGamer • 11 augustus 2025 17:40

Toen ik begon met Linux was ReiserFS de standaard in (Open)Suse. Met de arrestatie van Hans zijn die na een tijdje overgestapt op Ext, en tegenwoordig is BTRFS al jarenlang de standaard.

Umbrah 11 augustus 2025 13:19

Het ding is inderdaad dat ik me ondertussen goed kan voorstellen dat je bij bepaalde niveaus je filesystem en de CPU-usage van je storage oplossing zó zwaar kan belasten, dat elk stukje marge veel kan schelen.

Ik ben momenteel voor Tweakers Testpanel een Samsung 9100Pro aan het testen, op een systeem met een 9800X3D, en ik kan je een ding zeggen: de drive is zeker niet een bottleneck. Mijn 9800X3D is dat. Alleen bij single-stream transfers of licht multi-stream gebruik haal ik de cap, maar multi-stream zelfs bij een PGSQL stresstest is de CPU de bottleneck... nog steeds met een indrukwekkend aantal IOPS... Ik zit natuurlijk voor nu vast aan Windows, maar ik denk dat ReFS al flink wat zal schelen, maar zelfs dan, en dat zal ook onderdeel zijn van mijn conclusie:

- Deze drive zal wat CPU's overleven qua performance
- Ik snap waarom dedicated storage machines nóg vaker een ding zijn puur vanwege de IO-load wat moderne NVME opslag kan bieden...

Ik bedoel, die 9100Pro trekt zo'n 3mln IOPS en zo'n 14GB/sec (grote B!) -- het geheugen van mijn bak heeft "ongeveer" 96GBps als bandbreedte -- denk niet dat de snelheid van storage (op random na) ooit zo dicht bij de snelheid van geheugen heeft gelegen.

De complexiteit van een filesystem kan dan al vrij snel inderdaad de bottleneck zijn, zeker met dingen als journalling, versioning, encryptie, en geavanceerd rechtenbeheer.

Zet me wel aan het denken om de SSD ook eens met ReFS proberen te testen :D

HollowGamer @Umbrah • 11 augustus 2025 14:27

Zit het niet in de lanes die kunnen worden aangesproken? Die dingen die je noemt, gaan vrijwel allemaal door de kernel en merk je vrij weinig van. Heb je voor encryptie het volgende gedaan: https://wiki.archlinux.org/title/Dm-crypt/Specialties#Disable_workqueue_for_increased_solid_state_drive_(SSD)_performance

Verder zou ik ook zeker de temperatures checken. Je ziet dat zo'n controle heel warm wordt, en ik merk al vanaf 70C een vertraging op mijn simpel systeem. Die dingen worden nog steeds ongelofelijk warm!

Umbrah @HollowGamer • 11 augustus 2025 14:59

Geloof me, de controller is het probleem niet, de hele SSD zit onder eerder overcapaciteit dan ondercapaciteit qua koeling (watergekoeld systeem met grote 3-NVME-drive sized heatsink op de 9100pro tussen zes noctua fans in windtunnel configuratie).

Met de lanes bedoel ik op de hoeveelheid queues van de SSD controller. Als je met zeg maar 32 queues op 16 threads aan de gang gaat, en een redelijke echte load doet (dus niet zeg maar een crystaldisk dingetje niveautje 1GiB), merk je dat de CPU er meer moeite mee heeft dan wat de NVME controller, óf het NAND óf het DRAM van de NVME drive doet.

Je arch link heb ik weinig aan, omdat ik, zoals ik aangaf, voor sommige workloads vast zit aan Windows (zelfde reden dat ik aan nVidia vast zit).

Op Windows kan de encryptie via TCG-Opal gaan, wat feitelijk een hardware accellerated bitlocker is (een van de redenen dat Win11 een TPM requirement heeft). Dat werkt erg goed, en tegenwoordig moet je je best doen wil dat niet aan staan.

Ik kan je vertellen dat het verschil tussen aan/uit op Win11 ongeveer 45% performance verschil is, waar hardware bitlocker via TCG-Opal bijna (1 á 2% verschil) net zo snel is als unencrypted, met de zelfde size/cache eigenschappen en dezelfde effecten van een TRIM.

HollowGamer @Umbrah • 11 augustus 2025 15:25

Waarom reageer je dan op Linux bericht?

Je kunt tegenwoordig ook met luks over OPAL gaan, zelfs deels (een gedeelte hw, rest sw). De OPAL standaard zit vol met bugs, je kunt die in hetzelfde rijtje zetten als HW-RAID.

Umbrah @HollowGamer • 11 augustus 2025 15:42

Ik reageerde op een filesystem bericht, filesystems en OS-en zijn los/vast van elkaar, maar niet expliciet Linux of Windows. Bovendien schrijf ik ook:

Het ding is inderdaad dat ik me ondertussen goed kan voorstellen dat je bij bepaalde niveaus je filesystem en de CPU-usage van je storage oplossing zó zwaar kan belasten, dat elk stukje marge veel kan schelen.

En ik gebruik een analogie waar ik hetzelfde mee maak met een high-end drive op een consumenten platform, waar ik ook al merk dat elk stukje uitmaakt. Met de schaal waarop Meta opereert (als je artikelen als dit leest: Meta wil 5GW-datacenter maken en honderden miljarden dollars investeren - update - Tweakers) gaat het niet zozeer om OS-en, maar om het paradigma van de overhead.

BTRFS heeft een lagere overhead -- iets wat je op een Gen3 of Gen4 drive op een consumenten platform mogelijk niet eens merkt (waar EXT4 ook nog niet een grens is, of NTFS zelfs), maar voor deze schaal wel. Net zoals ik met mijn Gen5 'pro' drive (met pro tussen haakjes, want het is geen enterprise drive) ook al de grens bereik, en dus baat kan hebben bij een alternatief FS (Voor Windows is ReFS vrij logisch, maar ook Windows kan out-of-the-box om met EXT4 en BTRFS).

Moraal van het verhaal: gek dat je dit als Linux artikel ziet. Voor Meta is welliswaar BTRFS de oplossing, maar ik las het artikel toch echt in de zin van: "met hoge eisen zijn zelfs de ogenschijnlijk kleinste optimalisaties een enorme kostenbesparing".

Overigens kan ik me voorstellen dat Meta uiteraard voor alles wat transactioneel is (conveinience API's, en stateless container/racks) welliswaar BTFS gebruikt, maar voor long-term persistent storage zal het verhaal ongetwijfeld genuanceerder liggen; bedrijven als Meta opereren multi-tiered waar long-term persistent storage ongetwijfeld op filesystems als ZFS, Ceph, of zelfs Gluster gebaseerd is

jdh009 11 augustus 2025 13:02

Voor de minder technisch onderlegden op dit gebied, waar ik zelf ook toe behoor, mis ik denk ik nog wat informatie: Wat maakt Btrfs zo anders dan bestandssystemen als FAT32, NTFS en ext4? Ik lees dat Btrfs functies heeft als snapshots, compressie, deduplicatie, ingebouwde RAID en controle op datacorruptie. Klopt het dat de gangbare bestandssystemen in Windows en Linux deze functies niet of slechts deels hebben, en in de basis alleen verantwoordelijk zijn voor het opslaan en terugvinden van bestanden via hun eigen metadatastructuren, zoals FAT in FAT32, MFT in NTFS en inodes in ext4, terwijl extra functies via aparte software of hardware moeten worden geregeld? Of lees ik het helemaal verkeerd en is het verschil minder groot? Met andere woorden: is Btrfs het Zwitsers zakmes onder de bestandssystemen, terwijl de andere systemen meer één enkel gereedschap zijn?

edit:
Openingszin is niet bedoeld als commentaar op het nieuwsbericht, maar omdat mijn kennis op dit gebied beperkt is en vooral van het type ‘klok-en-klepel’.

[Reactie gewijzigd door jdh009 op 11 augustus 2025 13:16]

RobertMe @jdh009 • 11 augustus 2025 13:17

Btrfs is inderdaad een Zwitsers zakmes. Niet perse het Zwitsers zakmes, want er is ook "concurrentie". Waarbij ZFS de bekendste is en al decennia ontstaat. Ooit nog door Sun initieel ontwikkeld voor Solaris. Maar wel onder een open source licentie maar tegelijkertijd mogelijk wat conflicten met de GPL licentie. Daardoor dat ZFS intussen wel onafhankelijk wordt ontwikkeld, onder de OpenZFS paraplu, maar geen gemeengoed is onder Linux. Btrfs is meen ik zelfs gestart als een "ZFS voor Linux zonder licentie problemen".

En zoals je dus aanhaalt. Btrfs, en ZFS, kunnen dus bv "native" RAID doen en striping / mirroring / parity etc "doen". Terwijl bv met een ext onder Linux zou je eerst LVM moeten gebruiken om X schijven samen te voegen tot een virtuele schijf en vervolgens daar bovenop ext te gebruiken.
De voordelen van deze combinatie van filesysyem + volume manager zijn er ook legio. Met het grootste dat de combinatie veel beter bestand is tegen fouten. Immers heeft een Btrfs / ZFS beter inzicht in welke data op welke schijf staan en wat ee gevolgen van bv een lees-fout zijn. Terwijl in ieder geval een hardware RAID veel eerder een complete schikf er uit gooit omdat een actie mislukt. Terwijl het dus ook een lees-actie van een minder belangrijk document kan zijn waarbij puur een lees error voldoende is en Btrfs / ZFS ook een error kunnen geven puur daarop en vervolgens de error ergens in een logboek vastleggen / beheerder per mail informeren / ....
En ook zaken als deduplicatie en compressie op filesystem niveau geeft voordelen ten opzichte van bv handmatig alles gaan zippen (alleen al doordat je het niet handmatig hoeft te doen).

En uiteraard checksumming niet vergeten. Overal worden checksums van opgeslagen en bij het lezen wordt deze ook altijd gecontroleerd. Bij een bitflip op de HDD/SSD zal dit door de (afwijkende) checksum netjes worden gerapporteerd. Terwijl als je een ext gebruikt je echt niet van alle bestanden handmatig een md5 / sha / ... hash gaat opslaan en bij elke actie controleren en evt periodiek controleren. (Terwijl je Btrfs / ZFS periodiek een "scrub" kunt laten doen om alle data te controleren op basis van de opgeslagen checksums).

Zoop @RobertMe • 11 augustus 2025 13:28

Dus als ik jou zo lees "miljarden besparen" van Meta zal hem dan met name zitten in RAID oplossingen, checksumming, archiving, zaken waar je normaal extra software/hardware voor nodig hebt (en dus infrastructuur = manuren) en daar dus op kunnen besparen? Vind ik miljarden nog steeds erg veel ...

Want verder lijkt mij het nou niet revolutionair meer voordeel in algemeen gebruik (zoals snelheid of andere productie optimalisatie) te hebben, als ik jou zo hoor.

jdh009 @Zoop • 11 augustus 2025 13:40

Klinkt inderdaad logisch. En daarnaast: als je bijvoorbeeld x % compressie haalt op je bestanden, heb je in theorie ook x % minder opslag nodig of kun je x % meer data kwijt op dezelfde hardware. Dat betekent minder fysieke opslagapparatuur, minder stroomverbruik en minder koeling, wat op grote schaal flink kan schelen in de kosten. Compressie en decompressie kost wel rekenkracht, maar vermoedelijk wegen de besparingen op tegen de extra CPU-belasting (ik neem aan dat dit nog gewoon afgehandeld wordt via de CPU).

Zoop @jdh009 • 11 augustus 2025 13:45

Ja maar dat is dus ook mogelijk zonder Btrfs, het is alleen wel praktisch dat Btrfs dat zelf biedt. Dus dat soort voordelen zijn zonder ook wel te halen, maar daar komt dan wellicht meer software en infrastructuur bij kijken, dat lijken mij echter geen miljarden kostenposten.

Besparen van schijfruimte (en dus ook ruimte/stroomgebruik/koeling in een datacenter) is inderdaad logisch een grote kostenbestaarder te kunnen zijn, maar again, dat is niet per se inherent aan Btrfs (al vermoed ik wel dat Meta hier op doelt).

jdh009 @Zoop • 11 augustus 2025 13:53

Eens. Lijkt mij dat de grote besparing vooral uit de oplossing zelf komt. Compressie, deduplicatie, snapshots, checksums, RAID en de overige functies die hier onder het nieuwsbericht genoemd worden, verkleinen de opslagvoet en drukken energie- en koelingskosten. Btrfs lijkt vooral praktisch omdat dit in één systeem zit, zodat je minder losse software, minder integraties en minder gespecialiseerd beheer nodig hebt. Ik vermoed dat de totale besparing op hyperschaal dan groot kan zijn, maar dat het relatieve verschil tussen Btrfs en een goed samengestelde alternatieve stack vooral zit in lagere overhead en complexiteit, niet in een wonder aan extra efficiëntie, maar dat is puur een inschatting van mijn kant.

RobertMe @Zoop • 11 augustus 2025 14:00

Ja maar dat is dus ook mogelijk zonder Btrfs, het is alleen wel praktisch dat Btrfs dat zelf biedt. Dus dat soort voordelen zijn zonder ook wel te halen, maar daar komt dan wellicht meer software en infrastructuur bij kijken, dat lijken mij echter geen miljarden kostenposten.

Besparen van schijfruimte (en dus ook ruimte/stroomgebruik/koeling in een datacenter) is inderdaad logisch een grote kostenbestaarder te kunnen zijn, maar again, dat is niet per se inherent aan Btrfs (al vermoed ik wel dat Meta hier op doelt).

ZFS deed al die dingen dus al letterlijk voordat Btrfs bestond

En op Facebook schaal. ZFS ondersteund dus ook nog eens het opslaan van een Zettabyte aan data op een pool. Ik weet niet of Btrfs zoveel data kan opslaan?

RobertMe @Zoop • 11 augustus 2025 13:35

Mogelijk. Maar gezien ze het niet toelichten kunnen we niet meer dan speculeren. Anderzijds konden ze ook ZFS nemen. Licentie issues (als die er al zijn) spelen alleen bij distributie in binaire (/gecompileerde) vorm. Dus voor Facebook intern gewoon prima te gebruiken als ze het zelf compileren. En dan hoefden ze ook niet meerdere Btrfs developers in dienst te hebben. Waarbij ZFS ook al decennia aan serieuze gebruikers heeft. Wordt o.a. onderhouden door bedrijven / universiteiten die serieus veel data opslaan / verwerken. (Wellicht geen FB schaal, maar FB staat zo ongeveer op zijn eigen trede zeg maar. Alleen de Googles, Amazons, Microsofts en zo zullen net zo groot of groter zijn lijkt mij).

En ja, al die features gaan uiteraard wel gepaard met een (iets) lagere performance.

DefaultError @RobertMe • 11 augustus 2025 14:37

Ik vraag me af of het huidige developing van Bcachefs te maken heeft met de ontwikkeling van hagelnieuwe SSD’s.

Een oude artikel uit Tweakers: Subsidie NLnet

Dit was anders een nog mooiere ‘catch’ geworden.

DefaultError @RobertMe • 11 augustus 2025 14:08

Waarom wordt bespaard? Meta gebruikt Btrfs, het door Oracle in 2007 ontwikkelde bestandensysteem. Dat ze besparen slaat mogelijk op hebben bespaart vanwege de prima mogelijkheden en gunstige licentie kosten. Dat wordt niet duidelijk vernoemd maar bij het kunnen gebruiken van NTFS, ZFS, HPFS, exFAT, FAT en FAT32, etcetera, moet er licentie kosten afgedragen worden. Standaard is exFAT niet op Linux geïnstalleerd en zal bij gebruik geïnstalleerd moeten worden.

Verschillende OS’en gebruiken door de jaren heen op hun eigen wijze een steeds betere en veilige manier om bestanden op te slaan.

Nu wordt een ‘oude’ Bcachefs, aangekondigd in 2015, in gebruik genomen en de licentie afspraken komen op tafel. Best groot Meta en allen dat gegeven is gunstig voor de ontwikkelaars van Bcachefs.

Als Bcachefs gebruikt gaat worden door Meta wat door Linus Torvalds team is ontwikkeld en momenteel geparkeerd staat, dan zal dat ongetwijfeld met een ‘besparende’ licentie deal te maken hebben.

Edit: Btrfs i.p.v. Brtfs

[Reactie gewijzigd door DefaultError op 11 augustus 2025 14:21]

HollowGamer @jdh009 • 11 augustus 2025 13:10

Eigenlijk alles wat je opnoemt, zit niet in ext4, FAT32 en NTFS. Dus je geeft je eigen antwoord al.

Windows heeft het overigens wel, maar vooral in hun nieuw FS - wat nog steeds experimenteel is. Ik ken niemand die dit draait?

GertMenkel

Besturingssystemen

@HollowGamer • 11 augustus 2025 13:43

NTFS heeft compressie, CoW, snapshots, en een aantal dingen die ZFS niet per se heeft. Het probleem met al die features is helaas dat die features alleen worden aangeboden in dure enterprise-edities van Windows waardoor uptake minimaal is en de features snel in maintenance mode verdwijnen.

NTFS doet geen RAID in zichzelf (al heeft Windows daar wel Storage Spaces voor die een block device aanbieden waar je NTFS op kunt zetten, à la LVM, inclusief de mogelijkheid voor LVM/ZFS-achtige SSD read/write caches), maar het komt behoorlijk ver qua features als je het vergelijkt met andere moderne bestandssystemen. Het is jammer dat Microsoft ontwikkelaars niet zo hard helpt om meer uit het bestandssysteem te halen.

HollowGamer @GertMenkel • 11 augustus 2025 14:11

Zitten die ZFS features niet in de opvolger van NTFS? Die is inderdaad enkel op de Enterprise-edities, en dacht ik met heel weinig 3rd-party ondersteuning beschikbaar.

NTFS kan al ontzettend veel inderdaad, het is alleen allemaal wel achterhaald en ouderwets. Compressie is bijvoorbeeld niet te kiezen, het is aan/uit. Op btrfs kan je kiezen voor welke en op welk niveau. Voor mijn data heb ik bijvoorbeeld het heel hoog staan, maar op het OS zelf weer op zstd:1.

GertMenkel

Besturingssystemen

@HollowGamer • 11 augustus 2025 14:45

Het is zeker ook aan ReFS toegevoegd, maar NTFS blijkt die functies ook gewoon te hebben. Helaas zijn die functies echter niet zomaar aan applicaties beschikbaar. VSS werkt bijvoorbeeld grotendeels met CoW, maar de CoW-API die applicaties kunnen gebruiken werkt dan weer alleen met ReFS. Je kunt dus een perfect valide bestandssysteem hebben dat met CoW geoptimaliseerd is, alleen je kunt dat niet maken met de standaard Windows-drivers. Hier heb je bijvoorbeeld een Linux-tooltje dat je NTFS-volume slimmer kan gebruiken.

Compressie is te kiezen met bijvoorbeeld compact.exe; dan heb je keuze uit xpress4k, xpress8k, xpress16k, en ook lzx. Die hebben allemaal verschillende performance/compressie-verhoudingen (zo kan het ene algoritme multicore werken waar de andere maar op 1-2 cores werkt bijvoorbeeld). De oude C-API biedt alleen compressie aan/uit, maar NTFS kan meer bieden als je de nieuwe API pakt die DeviceIoControl gebruikt).

LZX comprimeert veel beter, maar moet volledig worden gedecomprimeerd als je het bestand aanpast, dus is vooral geschikt voor data-archieven en applicatiedata, en totaal niet voor databases of log files. XPRESS zit er een beetje tussenin en lijkt me beter voor de meeste use cases. Ik weet niet hoe LZX/XPRESS zich tegenover zstd verhoudem, maar ik denk dat het maar net ligt aan je use case. Zo heb ik zstd op mijn btrfs-schijf op de desktop heel anders ingesteld staan dan op de SD-kaart in mijn Steam Deck (waar ik compressie gebruik om de transfer speeds van het SD-kaartje op te krikken).

Dit is dan ook wat ik bedoel met dat het zo jammer is dat Microsoft ontwikkelaars niet helpt, de API's zijn lastig te vinden (als ze al voor niet-drivers beschikbaar zijn) zelfs als je weet dat die functies in het bestandssysteem bestaan, en sommige daarvan werken ook nog eens alleen op sommige versies van het OS...

[Reactie gewijzigd door GertMenkel op 11 augustus 2025 14:50]

Xander2 @jdh009 • 11 augustus 2025 13:28

Hardware RAID is achterhaald, je performance krijgt een gigantische tik als de hardware besluit de data weg te schrijven, dus het is "blind" vullen totdat je een probleem krijgt.

FAT32 heeft geen journalling, ofwel je indexering/data kan corrupt raken en je kunt caching eigenlijk niet betrouwbaar gebruiken. NTFS is eigenlijk geen 1 systeem maar diverse revisies, soft links en multiple access waren/zijn grote problemen, terwijl dingen als snapshots al wel vroeg geregeld waren.

Het gaat om extra features, metadata per file, data 1x opslaan, efficiënt opslaan en caching, automatische error-correctie e.d. Allemaal features die vooral in de serverruimte van belang waren maar nu ook naar de desktop komen omdat ze gewoon handig zijn en tegenwoordig genoeg geheugen/performance aanwezig is.

Het is al performance-technisch al voordelig om delen van het geheugen te comprimeren dus dat is winst op alle vlakken bij trager lange termijn opslag.

dmantione

Linux

@Xander2 • 11 augustus 2025 13:45

Mijn inziens draai je zowel BTRFS als ZFS nog altijd het beste op een hardware-RAID. De RAID-functionaliteit van BTRFS is onvolledig en ZFS wordt retetraag als je de hoeveelheid schijven in een array vergroot.

BTRFS/ZFS op een HW-raid draait daarentegen als een zonnetje. Snel, makkelijk en toch alle geavanceerde functies van beide systemen.

svane @dmantione • 11 augustus 2025 16:46

Mijn inziens draai je zowel BTRFS als ZFS nog altijd het beste op een hardware-RAID.

Daar zijn de developers van ZFS het in elk geval mee oneens.

Hardware RAID controllers should not be used with ZFS. While ZFS will likely be more reliable than other filesystems on Hardware RAID, it will not be as reliable as it would be on its own.

IO response times will be increased (i.e. reduced performance) whenever the OS blocks on IO operations because the system CPU blocks on a much weaker embedded CPU used in the RAID controller. This lowers IOPS relative to what ZFS could have achieved.

Ook op Wikipedia wordt dit omschreven

While ZFS can work with hardware RAID devices, it will usually work more efficiently and with greater data protection if it has raw access to all storage devices.

Disks connected to the system using a hardware, firmware, other "soft" RAID, or any other controller that modifies the ZFS-to-disk I/O path will affect ZFS performance and data integrity.

Mogelijk dat hardware RAID veel sneller is dan ZFS, niet veel over gehoord, maar zou kunnen.

Maar ZFS in combinatie met hardware RAID zou ik dus niet doen

dmantione

Linux

@svane • 11 augustus 2025 21:01

Ik ben ermee bekend, maar de resultaten zijn er simpelweg niet naar: Je haalt serieus meer prestaties uit je schijven met een HW-raidcontroller. Ik heb het vaak gebenchmarkt (want de vraag komt iedere keer weer terug bij klanten), een keer op keer de conclusie: Die RAID-controller is de investering echt waard.

ZFS in combinatie met HW-RAID is zinnig omdat ZFS nog steeds het vermogen heeft het bestandssysteem over meerdere RAID-arrays te verdelen (geen LVM nodig), compressie mogelijk is en natuurlijk de snapshots en serialisatie voor backups. Voldoende dus reden om het (in veel situaties) boven xfs te verkiezen.

svane @dmantione • 12 augustus 2025 08:12

Interessant, bedankt voor de context. Merk je de performance problemen vooral bij schrijven? en/of bij lezen?

Ik heb zelf een relatief kleine setup van 4 schijven met ZFS in Proxmox. 't gaat hier echter om HDD's die ik dan ook echt alleen voor 'langzame' zaken gebruik, dus qua performance nooit zo naar omgekeken, de rest van de data staat op NVME's zonder raid.

Mocht ik ook iets groters/nieuws bouwen dan is dit wel interessant om dieper in te duiken!

dmantione

Linux

@svane • 12 augustus 2025 11:26

Zowel schrijven al lezen, maar schrijven in sterkere mate dan lezen. Het gaat hier vooral om applicaties die grote bestanden sequentieel lezen en schrijven (als het random I/O is gebruik je tegenwoordig SSD's). Een goede benchmark daarvoor is de IOzone mixed workload test (-i 8 ) in multithreaded mode (bijvorbeeld -t 64 voor 64 threads).

Verder is er nog de kwestie van de cache: RAID-controllers hebben een cachegeheugen dat beveiligd is met een batterij of supercondensator. Dat heeft gevolgen voor situaties waarin data atomair word weggeschreven. Dat doen bestandssystemen voor de metadata om de integriteit te kunnen garanderen en databases doen het ook. Een controller kan als er een fsync wordt uitgevoerd de data in de cache opslaan en onmiddellijk terugmelden dat de data is weggeschreven, om vervolgens op zijn gemak de data naar schijven weg te schrijven. Als de stroom uitvalt, kan de schrijfbewerking gewoon voltooid worden als de stroom weer terug is.

Een software-oplossing moet de data onmiddellijk weg gaan schrijven en het programma kan pas weer verder nadat dat gebeurd is. In situaties waar dit een rol speelt, versnelt een RAID-controller de boel zelfs als je helemaal geen RAID gebruikt.

[Reactie gewijzigd door dmantione op 12 augustus 2025 11:26]

svane @dmantione • 12 augustus 2025 12:14

Wederom interessant, wederom bedankt. Om eerlijk te zijn verwacht ik niet binnenkort een rebuild te doen, (blijft een hobby-project), maar mooi om in 't achterhoofd te houden!

Ik heb net even voor de lol gekeken met bonnie++ wat onze server doet met sequentieel lezen en schrijven (64GB):

lezen: 1.1 GB/s

schrijven: 403 MB/s

Dit is met vier exos x20 schijven in RAIDZ1 die max 272MB/s lezen/schrijven.

Enig idee of en hoeveel hier nog extra uitgehaald zou kunnen worden? Of zijn dit soort dingen echt alleen interessant bij grotere setups?

offtopic:
Voel je niet verplicht te antwoorden of hier tijd aan te besteden, ben gewoon nieuwsgierig

dmantione

Linux

@svane • 12 augustus 2025 12:40

Om te beginnen bij RAIDZ1, vergelijk baar baar RAID5, verwacht je maximaal 3 keer de bandbreedte van je harde schijf. Je schijf kan maximaal 272MB/s, en dat haal je alleen als je aan het begin van de schijf leest/schrijft, dus als je 1,1MB/s weet te lezen, dan is er iets bijzonders aan de hand. Het kan zijn dat er caching optreedt; een server met meer dan 64GB geheugen is vrij normaal, of er is iets anders aan de hand. Het is nuttig om je af te vragen waar die snelheid vandaan komt en of die voor de praktijk ook relevant is.

Schrijven met 403 MB/s is ongeveer 134MB/s. Dat is niet heel beroerd, maar met moderne schijven, zoals je zegt 272MB/s, het is mogelijk om er meer uit te halen, zeker in een dergelijk eenvoudige opstelling, dus ik denk zeker dat dat beter kan. Vraag is in hoeverre ZFS hier al beperkend is, je zou eens MDRAID+ZFS kunnen vergelijken met ZFS en zien wat het verschil is in jouw opstelling.

Probeer verder eens de Deadline-scheduler te activeren, dat helpt vaak ook al wat.

svane @dmantione • 12 augustus 2025 14:03

een server met meer dan 64GB geheugen is vrij normaal,

We hebben 128GB

, dus er zal vast iets met caching gebeuren inderdaad! Heb in de praktijk ook geen klachten over de lees snelheid.

Schrijfsnelheid is dan inderdaad niet optimaal, kan niet zo snel vinden waarom. de HDD's staan al op 'mq-deadline', en de NVME's op 'none', maar thanks voor de tips.

Zitten toch op een 1Gbit verbinding nu, dus in de praktijk ligt de bottleneck daar bij ons vooral.

Leuk om je ervaringen te horen. Ik ga d'r snel weer vandoor voordat de mods doorhebben dat we hier wel heel off-topic zijn inmiddels!

Xander2 @dmantione • 11 augustus 2025 14:05

Hardware RAID heeft alleen nog een functie in zeer specifieke situaties (mission-critical e.d.), waar je veel geld neertelt en spares achter de hand hebt.

Voor de meeste consumer- en veel professionele doeleinden functioneert mdraid (software) uitstekend en zelfs beter met als voordeel dat je de schijf elders kan hangen zonder over de hardware te hoeven beschikken.

Een goedkope RAID card is weggegooid geld, een oude Areca is weggegooid geld. Die hardware is een bottleneck met snelle drives, ECC, moderne CPU's en veel geheugen. De I/O en bandbreedte van een simpele x64 setup kun je veel hoger belasten dan een gemiddelde hardware RAID aankan wat betekent dat je schrijven/lezen beter kan overlaten aan het OS.

dmantione

Linux

@Xander2 • 11 augustus 2025 15:00

Probeer maar eens een RAID6-array van 16+2 schijven te maken: De prestaties in software-RAID van BTRFS/ZFS donderen in elkaar, terwijl een RAID-kaart er meerdere gigabytes/s weet uit te persen.

Dat een software-RAID in sommige situaties adequaat is daarover geen discussie en hardware-RAID is ook uitdagend bij grote hoeveelheden NVMe SSD's (maar het is niet dat SW RAID dan opeens wel presteert).

Xander2 @dmantione • 11 augustus 2025 18:38

Ik gebruik al tijden mdraid los van FS omdat het uitstekend performt en in geval van uitval/corruptie me veel meer recovery mogelijkheden biedt en Linux of BSD i.c.m. ECC vele malen stabieler is dan een hardware oplossing.

De paar keer dat ik hardware RAID nodig heb gehad (mission critical) is RAID6 of enige redundantie niet interessant en ook niet aanwezig op de (peperdure) RAID hardware.

Reed-Solomon of XOR gaan waanzinnig veel sneller op een multi-core CPU. De cache op een RAID kaart is een keer gevuld en te onvoorspelbaar. Als dat ding synchroniseert loopt de boel vast qua geheugen maar weigert het systeem niet aanvragen.

Voor consumenten weggegooid geld.

SubSpace

@dmantione • 11 augustus 2025 20:22

16+2 RAID6 is sowieso geen goed idee, imo

Ik ben geen ZFS expert, maar meerdere vdevs lijkt me dan een goed idee.

[Reactie gewijzigd door SubSpace op 11 augustus 2025 20:23]

dmantione

Linux

@SubSpace • 11 augustus 2025 20:55

Goed onderbouwd antwoord....

16+2 is een goed idee voor hoge prestaties, omdat je SAS-expander en SAS-kabels een eindige capaciteit hebben. Bij 16+2 is 1/9 van je capaciteit nodig om de pariteit naar de RAID-controller te sturen. Bij 10+2 ben je al 1/6 van je capaciteit kwijt. Bij 6+2, waar ZFS ingebouwde RAID van houdt, ben je een kwart kwijt.

Justberry @jdh009 • 11 augustus 2025 13:12

Ik heb meer geleerd van jou bericht dan het nieuwsbericht. Hoop dat ze hem gaan uitbreiden met wat Btrfs nou is en waarom het dus beter is.

Dat is juist de kracht van tweakers, dit soort nieuws bericht aanpakken om ook de lezers meer kennis te geven

kabelmannetje @jdh009 • 11 augustus 2025 13:12

- Copy on write. Bijna onmogelijk om een fs te corrumperen.

- Snapshots. Je kan elk moment teruggaan naar moment van een snapshot. BtrFS icm snapper/grub-snapper en integratie in package management, bestaat niet in Windows.

- real time compression

- zeer flexibel gebruik van subvolumes

- integrity checking/ data scrubbing

Wikipedia: Btrfs

[Reactie gewijzigd door kabelmannetje op 11 augustus 2025 13:15]

dmantione

Linux

@jdh009 • 11 augustus 2025 13:35

Een toepassing waar bestanddsystemen als BTRFS en ZFS retegoed in zijn, zijn backups. Bij een conventioneel bestandssysteem moet een backprogramma het hele bestandssysteem scannen om te weten welke bestanden gewijzigd zijn. Als het om een groot archief van een paar petabyte gaat, dan is dat een enorm tijdrovende en zware operatie.

Omdat het systeem tijdens de backup vaak gebruikt wordt, is het ook lastig te garanderen dat de backup een echte momentopname is en bij sommige software zoals databases kan dat zelfs betekenen dat corrupte data gebackupt wordt.

BTRFS kunnen met een druk op de knop snapshots genereren en ook weer met een druk op de knop de verschillen tussen twee snapshots uitspugen. Dit zijn lichte en efficiënte bewerkingen. Een snapshot is atomair: Het bevat de exacte toestand van het bestandssysteem op dat moment.

Daarmee wordt iets opgelost dat veel beheerders van computersystemen voorheen slapeloze nachten bezorgde.

Het is belangrijk in grote dure computersystemen, maar ik gebruik het ook gewoon op mijn eigen laptop: Eéń keer per dag een snapshot van mijn homedir maken, en het verschil tussen twee dagen naar een andere SSD exporteren. Eén in de zoveel tijd wordt er een kopie naar mijn desktop gekopieerd.

bluppfisk @dmantione • 12 augustus 2025 15:38

Ik stel me daar nu plots vragen bij. Als je database meerdere files gebruikt voor zijn opslag, en je neemt een snapshot wanneer nog niet alle files geschreven zijn, is die snapshot toch ook in een inconsistente staat? Hoe kan je de atomiciteit garanderen in zo'n geval?

dmantione

Linux

@bluppfisk • 12 augustus 2025 15:45

Een goede database is transactiegeoriënteerd. Ofwel een transactie wordt volledig uitgevoerd, ofwel de tijdelijke wijzigingen worden teruggedraaid. Als een snapshot in het midden van het uitvoeren van een transactie plaatsvindt, dan zal een database die vanaf de tijdopname van de bestanden verder moet werken, een onvoltooide transactie zien en die eerst ongedaan maken voordat hij verder gaat.

Omega @jdh009 • 11 augustus 2025 13:42

Voor de gemiddelde thuisgebruiker die enkel een grote root-partitie wil hebben om daar al z'n zooi op te mikken is Btrfs vooral interessant voor z'n resistentie tegen corruptie en de datacompressie. Het copy-on-write gedrag van het bestandssysteem voorkomt dataverlies tijdens schijfacties bij stroomverlies of een systeemfout. De datacompressie zorgt er voor dat je data efficiënter wordt opgeslagen en vermindert wear op je SSD. Dit gaat wel ten koste van (schrijf-) prestaties, maar daar merk jij als gebruiker niks van tenzij je gaat benchmarken of zeer zware langdurige workloads draait.

Voor de systeembeheerder zijn de vele features van Btrfs interessant. Met een snapshot kan je een onmiddellijke kopie maken van je systeem zodat je makkelijk terug kan rollen. Je kan gebruik maken van subvolumen, dit is een soort partitie binnen een partitie die zich richting de gebruiker gedraagt als een map, echter kan je deze volumen regels opleggen (eg. compressie, limitaties op grootte, read-only etc..) en mounten net als een normale partitie. En dan is er nog veel meer.

Zo heb ik een systeem ontwikkeld dat gebruik maakt van Btrfs om systeemupdates atomisch uit te voeren. De update worden gepackaged in geëxporteerde subvolumen, deze wordt gedownload en vervolgens geïmporteerd op een specifieke locatie in het bestandssysteem. Dan wordt er door middel van een bootloader entry dit subvolume opstartbaar gemaakt. Het oude systeem blijft gewoon draaien, deze is niet aangeraakt, en zodra ik reboot zit in in mijn geupdate systeem.

Btrfs is vergelijkbaar met ReFS op Windows in basisfunctionaliteit.

[Reactie gewijzigd door Omega op 11 augustus 2025 13:54]

foobar79 @jdh009 • 11 augustus 2025 13:23

Het grootste verschil, naar mijn mening, is dat het een copy on write bestandssysteem is:
Als je een wijziging maakt in een bestand wordt niet het bestand (/datablock) overschreven maar een geheel nieuwe versie van het bestand aangemaakt met de nieuwe inhoud.
Hierdoor worden een aantal zaken "gratis" zoals b.v. snapshots om terug te gaan naar vorige versies.

Voor de rest zijn er inderdaad een boel functies geintegreerd die je traditioneel anders in je volume manager zou doen omdat btrfs tevens tegelijkertijd een volume manager is.

The Zep Man

Besturingssystemen
Linux

11 augustus 2025 12:54

Als vuistregel gebruik ik Btrfs voor bijna alles. Alleen de snapshotting functionaliteit maakt het de keuze al waard.

Voor een enkele Linux server met veel redundante diskruimte gebruik ik ZFS. Dat is een stuk flexibeler wanneer het over meerdere onderliggende opslagapparaten gaat.

[Reactie gewijzigd door The Zep Man op 11 augustus 2025 13:10]

HollowGamer @The Zep Man • 11 augustus 2025 13:06

Alleen zit ZFS niet in de Linux-kernel, tenzij je kiest voor een distro die het verpakt.

Ik vertrouw dat minder, aangezien het gecompiled wordt voor de kernel, die vaak niet in sync is met upstream. M.a.w. de kernel loopt voor, op wat ZFS kan verwachten.

Xander2 @HollowGamer • 11 augustus 2025 13:30

Yup en ZFS gebruikt meer geheugen.

HollowGamer @Xander2 • 11 augustus 2025 14:31

Dit kun je tweaken, maar gaat ten koste van performance.

Xander2 @HollowGamer • 11 augustus 2025 14:40

Zeker, alleen BtrFS kun je ook tweaken en is simpelweg meer lichtgewicht.

Maakt verder niet uit wat je kiest en preferentie is maar voor mij geldt dat ik bij Linux altijd kies voor een "first-class" citizen. Ik wil dat iets essentieels als een FS getest is vóór release en onmiddelijk gepatched wordt in mainstream bij problemen. Daar kan ik niet van op aan bij ZFS in het geval van Linux.

Linus en maintainers hebben in dat aspect wat je ook ervan vindt een extreem hoog kwaliteitsniveau en waanzinnig trackrecord.

The Zep Man

Besturingssystemen
Linux

@HollowGamer • 11 augustus 2025 13:12

Ik vertrouw dat minder, aangezien het gecompiled wordt voor de kernel, die vaak niet in sync is met upstream. M.a.w. de kernel loopt voor, op wat ZFS kan verwachten.

Het is beschikbaar voor een kernel die langdurig ondersteund wordt. Daarmee blijven zaken prima in sync met upstream, want er worden binnen een bestaande branch geen zaken geïntroduceerd in de kernel die compatibiliteit breken.

Op mijn server draai ik niet de nieuwste kernel branch, maar wel (ondersteunde) LTS die tijdig vervangen wordt met de nieuwe LTS naast de tussentijdse updates. Qua beveiliging is er dus ook geen probleem. Als er toch iets mis zou gaan dan zou ik altijd nog een versie terug kunnen gaan, maar dat is in al die jaren dat ik dit draai niet voorgekomen.

[Reactie gewijzigd door The Zep Man op 11 augustus 2025 13:16]

HollowGamer @The Zep Man • 11 augustus 2025 14:30

Ik heb dat helaas meegemaakt, en ik draai vaak een rolling distro of meer richting bleeding edge (Fedora bijvoorbeeld).

Dat is natuurlijk mijn eigen probleem, maar daardoor is ZFS bijvoorbeeld al veel minder interessant, en kan je beter in zo'n geval voor iets als Btrfs gaan.

The Zep Man

Besturingssystemen
Linux

@HollowGamer • 11 augustus 2025 17:37

Ik draai Arch Linux met de LTS kernel. Die is rolling, en de ZFS modules rollen vrolijk mee. Een downgrade van enkel de kernel + ZFS modules is ook geen probleem al zou dat ooit nodig zijn.

Sando @The Zep Man • 11 augustus 2025 14:06

Als vuistregel gebruik ik Btrfs voor bijna alles. Alleen de snapshotting functionaliteit maakt het de keuze al waard.

Voor een enkele Linux server met veel redundante diskruimte gebruik ik ZFS. Dat is een stuk flexibeler wanneer het over meerdere onderliggende opslagapparaten gaat.

Het voordeel van Btrfs is toch dat het flexibeler is? Ik dacht dat je makkelijker schijven van verschillende groottes kon mengen. Bij ZFS (dat ik ook veel gebruik) wordt een pool vaak beperkt tot de kleinste schijf. Pas als je die vervangt kan je de pool vergroten.

Misschien loop ik achter, vroeger was ZFS als geavanceerder, ook met snapshots, compressie, en vooral self-healing. Btrfs was flexiberer en gebruikte (veel) minder geheugen.

The Zep Man

Besturingssystemen
Linux

@Sando • 11 augustus 2025 17:39

Het voordeel van Btrfs is toch dat het flexibeler is?

Flexibeler ten opzichte van wat? Ten opzichte van ext4 zeker. Ten opzichte van ZFS is laatstgenoemde flexibeler.

Sando @The Zep Man • 12 augustus 2025 00:47

Dat staat haaks op wat ik net zei. Btrfs is flexibel met het mengen van verschillende schijven en kan goed werken op systemen met (veel of) weinig geheugen. Bij ZFS moet je goed opletten welke schijven je mengt, en moet je veel geheugen hebben anders neemt de performance snel af.

Volgens jou is ZFS flexibeler, maar kan je dan eens wat concrete voorbeelden geven? Ik gebruik ZFS naar tevredenheid, maar één ding is het niet: Flexibel. Althans, vergeleken met Btrfs, waar je on the fly je RAID1 kunt aanpassen. Ik denk dat dit de flexibiliteit is die Meta geld bespaard, iets wat ZFS niet heeft.

The Zep Man

Besturingssystemen
Linux

@Sando • 12 augustus 2025 09:37

Volgens jou is ZFS flexibeler, maar kan je dan eens wat concrete voorbeelden geven?

In-place upgrade van disken naar grotere disken in een RAID10-set zonder downtime is een voorbeeld. Stabiele RAID5/6 ondersteuning is een ander.

Meer geheugengebruik is overdreven, tenzij je aan de slag gaat met zaken als deduplicatie. Ook betreft dit een server. Geheugen zat.

Verder ben ik geen Meta.

[Reactie gewijzigd door The Zep Man op 12 augustus 2025 10:17]

dmantione

Linux

@The Zep Man • 12 augustus 2025 11:44

Waar ik in praktijk problemen mee gezien heb is de ZFS-geheugencache. ZFS integreert niet met de Linux-VM, maar heeft zijn eigen cache en dat betekent dat het minder goed interageert met het geheugenbeheer. Ik heb situaties meegemaakt waar de Linux OOM-killer in actie schoot. Niet omdat het geheugen vol zat, maar omdat ZFS een flink deel van het geheugen voor cache gebruikte en het resterende deel gefragmenteerd was geraakt. Het handmatig beperken van de ZFS-cache was toen de oplossing.

Niet gezegd dat BTRFS beter is dan ZFS, beiden zijn goede stukjes technologie met hun sterktes en zwaktes, maar BTRFS integreert wel volledig met de Linux-VM en dergelijke problemen zullen niet optreden op een systeem met BTRFS.

Marctraider 11 augustus 2025 13:20

Is het toeval dat er altijd drama speelt met filesystems? Toen met ReiserFS was er ook moord (letterlijk)

Zijn het bepaalde slimme figuren waar een steekje los zit, dat blijkbaar goed combineert met het maken van een FS? Dit vraagt om onderzoek :P

kabelmannetje @Marctraider • 11 augustus 2025 13:36

Is het toeval dat er altijd drama speelt met filesystems?

Nee. Drama is altijd onderdeel van projecten. Wayland, X11, LibreX, PipeWire, SystemD, Gnome/KDE/QT, Emacs/VI, compilers, enz enz.

Reiser is veroordeeld moordenaar, Kent heeft autisme waardoor hij niet kan samenwerken/zelfreflectie. Er zijn veel zeer succesvolle en redelijk drama-vrije FS onder Linux. XFS, EXT4, BTRFS, JFS, FSF, ProcFS, SysFS, enzenz.

SPee @kabelmannetje • 12 augustus 2025 11:19

Die FS zijn zo oud, dat die drama die er toen was alweer vergeten is.

Soldaatje @Marctraider • 11 augustus 2025 13:31

Ik kwam laatst nog wat oude schijven tegen die ik destijds geformateerd had als ReiserFS, dat zit niet meer in de huidige kernel dus toen moest ik een VM starten met een oude kernel om het te kunnen lezen, (helaas) stond er niks interessants op.

HollowGamer @Marctraider • 11 augustus 2025 14:32

Zijn het bepaalde slimme figuren waar een steekje los zit, dat blijkbaar goed combineert met het maken van een FS? Dit vraagt om onderzoek

Persoonlijk denk ik dat die mensen vaak op het autisme spectrum zitten of iets hebben gemaakt. Vaak zijn ze sociaal niet zo handig of goed als 'normale mensen', maar daardoor worden ze vaak ook niet goed begrepen of onterecht weggezet.

locke960 11 augustus 2025 22:24

Meta zegt 'miljarden dollars' te besparen door gebruik van bestandssysteem Btrfs

Dat vind ik een nogal sterke uitspraak, zo zonder verdere verklaring en uitleg over hoe Btrfs daar dan de oorzaak van is. Ik heb daar moeite mee omdat die uitspraak is gedaan in de context van een kernel-drama over bcachefs en, vooral, de ontwikkelaar daarvan.

Het kan best kloppen, maar ik zou daar toch iet meer onderbouwing van willen zien.

kuurtjes @locke960 • 11 augustus 2025 22:54

De uitspraak komt ook van de developer zelf. Iets met "wij van wc-eend".

RobertMe 11 augustus 2025 12:57

Volgens mij heeft Btrfs juist helemaal niet de reputatie om robuust te zijn? In basis configuraties werkt het intussen goed (genoeg), maar las ik toevallig laatst hier op het forum nog iets van een corrupt filesystem (na een unclean shutdown). En in RAID opstellingen (Btrfs is immers een filesystem als volume manager) schijnen er sowieso nog steeds wat "problemen" te zijn en daardoor niet eens aangeraden te worden?
Deze claim van de maintainer (geen onafhankelijke bron) dat ook nog eens gebeurt bij het proberen in diskrediet te brengen van een concurrerend filesystem, en zonder enige uitleg, kan ik eerlijk gezegd dus helemaal niks mee.

IMO blijft daarmee dan ook de enige serieuze optie als je specifiek de fearures van Btrfs nodig hebt (snapshots, geïntegreerde volume manager / RAID ondersteuning, ...) dan ook ZFS. En zonder die features gebruik ik "gewoon" nog steeds Ext4.

HollowGamer @RobertMe • 11 augustus 2025 13:07

Dit was jaren geleden het geval, en voor RAID-5 is het nog altijd een probleem. Synology gebruikt voor die reden nog altijd LVM.

Nu heb ik zelf een RAID-0 opstelling, en jaren RAID-1 gehad. Het beste blijft niet vertrouwen op RAID als backup, maar een copy te maken naar een ander systeem (zoals een NAS). Ik heb ook door kapot memory een ext4/xfs corruptie gehad. Het zegt allemaal niet zoveel.

[Reactie gewijzigd door HollowGamer op 11 augustus 2025 13:08]

Hardfreak @HollowGamer • 11 augustus 2025 13:19

Het grote voordeel van RAID-1 met zfs of btrfs is dat je een checksum hebt die gebruikt kan worden om bitrot te herstellen. Een gewone RAID controller (of zelfs software RAID zoals in Windows of md in Linux) heeft het probleem dat bij bitrot op één schijf er helemaal geen manier is om te bepalen welke schijf nu de juiste kopie bevat.

Uiteraard maakt corrupt geheugen het verhaal een beetje complexer, maar je kan altijd achteraf een scrub doen met wel correct werkend geheugen en meer kans hebben op herstel. Neemt niet weg dat RAID idd geen backup is, maar het kan wel deel uitmaken van een goede backup strategie.

HollowGamer @Hardfreak • 11 augustus 2025 14:34

Mee eens, het biedt geen garanties, maar het maakt het wel hopelijk beter bij corruptie issues.

Waarom is ECC geheugen eigenlijk nooit een standaard geworden (buiten enterprise) - heeft die geen voordelen in dit soort gevallen?

skimine @HollowGamer • 11 augustus 2025 17:11

Waarschijnlijk vanwege kosten (zoals altijd). En voor de meeste toepassingen is non-ecc dan "stabiel genoeg".

Blokker_1999

Besturingssystemen
Linux

@HollowGamer • 11 augustus 2025 13:20

RAID is dan ook geen backup, nooit geweest, zal het ook nooit zijn. RAID biedt redundantie. Heb je een defecte schijf, blijft je storage doorwerken. En met RAID0 heb je zelfs dat niet meer, vandaar ook de 0. 0 zou je dan ook nooit op zichzelf mogen gebruiken, maar altijd in combinatie met andere RAID vormen.

Qoffee @Blokker_1999 • 11 augustus 2025 13:34

Raid 0 is dan ook geen redundantie oplossing maar een performance optie. Dit is prima alleen te gebruiken zo lang het maar aansluit bij je use case.

HollowGamer @Qoffee • 11 augustus 2025 14:35

Precies! Ik gebruik RAID-0, maar spiegel deze naar een backup. Het is wel een laag minder robust, maar voor mijn usecase is het voldoende.

teek2

@HollowGamer • 11 augustus 2025 13:24

Ja dit inderdaad. Vergeet niet dat Btrfs helemaal in het open is ontwikkeld, en dus zagen we alle kinderziektes. ZFS werd net na zijn pubertijd door Sun openbaar gemaakt, dus die instabiele tijd hebben we helemaal niet gezien.

Dat gezegd, ik denk dat ik voor ZFS zou kiezen omdat de reputatie echt top is en de featureset heel er goed. Maar, misschien is het onterecht. Dat Btrfs in-tree is, is een heel groot voordeel idd. Veel Btrfs issues waren ook van voor de tijd dat Meta er veel tijd en geld in stak.

[Reactie gewijzigd door teek2 op 11 augustus 2025 13:25]

Soldaatje @RobertMe • 11 augustus 2025 13:16

Ja, er zijn blijkbaar nog problemen met raid: https://wiki.archlinux.org/title/Btrfs Daarom gebruik ik ook nog mdadm,