NLnet geeft subsidie voor ontwikkeling van Linux-bestandssysteem Bcachefs

De Nederlandse stichting NLnet heeft een subsidie toegekend aan de ontwikkeling van Bcachefs. Dat is een opensource copy-on-writebestandssysteem voor Linux. Bcachefs werd eind 2023 toegevoegd aan de Linux-kernel.

Ex-Google-ontwikkelaar Kent Overstreet bracht in 2015 de eerste versie van Bcachefs uit. Het bestandssysteem moet moderne features zoals die van ZFS of btrfs bieden zoals copy-on-write, waarbij onnodig dubbel geheugengebruik tijdens het kopiëren van bestanden vermeden wordt. Volgens de projectpagina van NLnet wil de ontwikkelaar ook aandacht besteden aan 'uitbreidbaarheid en herstelbaarheid'.

Bcachefs is een bestandssysteem voor Linux, dat volgens de makers vooral ‘robuust en betrouwbaar’ moet zijn. De makers willen met het project een algemeen bestandssysteem maken dat ook schaalbaar is voor grotere netwerken, maar vooral ook simpel moet zijn. De makers willen het platform in de toekomst modulair maken zodat er nieuwe features bovenop kunnen worden gezet. De makers noemen ook mogelijke gedistribueerde opslag, zoals IPFS waar Tweakers in 2021 over schreef, maar noemt daar geen concrete plannen bij.

Naast Bcachefs steunt NLnet 40 andere projecten met zijn Next Generation Internet Zero-subsidies. Het is niet duidelijk hoe hoog de subsidie is die Bcachefs krijgt. De website van de stichting noemt naast subsidie voor het bestandssysteem ook het ondersteunen van AMD-processors in de Converged Security Suite. Er komen ook verschillende open hardwareprojecten aan bod, waaronder een DDR3-geheugencontroller.

Reacties (90)

[downtime]

Alweer een nieuw file system voor Linux? Zou het verbeteren van bestaande file systems niet meer opleveren dan het toevoegen van weer een nieuwe standaard? Je krijgt nu al keuzestress als je Linux installeert door het aantal file systems wat ze aanbieden.

[The Zep Man]

Je krijgt nu al keuzestress als je Linux installeert door het aantal file systems wat ze aanbieden.

Valt wel mee als we spreken over desktop Linux. Simpel systeem zonder speciale eisen? De vuistregel is: ext4 is good enough. Wil je zaken als subvolumes (snapshots)? Dan kan je aan de slag met btrfs. Voor desktop Linux hoef je op dit moment de rest niet te overwegen.

Ga je voor andere soorten toepassingen, zoals embedded devices of bijvoorbeeld een NAS? Dan krijg je wat meer keuzes gebaseerd op het onderliggende fysieke medium en je wensenpakket. Je krijgt dan variaties van gespecialiseerde filesystems voor soorten flashgeheugen tot exotische dingen als OpenZFS.

Wat ik vrees voor Bcachefs is dat het een theoretisch bruikbaar bestandssysteem wordt dat je in de praktijk niet zal zien, net als een sliert andere bestandssystemen die native ondersteund worden door Linux. Ik begrijp dat ze een "ZFS killer" willen maken, maar kan je dan beter niet een bestaand iets pakken? Iets als btrfs is verre van perfect en mist voor exotische situaties bepaalde (stabiele) functies, maar de basis is waarschijnlijk goed genoeg om op verder te bouwen.

Wie herinnert ReiserFS nog? In theorie (toen het uitkwam) veel beter, in de praktijk nooit gebruikt.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:04]

[ROcho]

Maar bij ReiserFS kwam het ook omdat de lead developer er niet verder aan kon ontwikkelen door "wat persoonlijke problemen".

[The Zep Man]

ReiserFS is onder de GPLv2 licentie uitgegeven. Kennelijk was er ook geen interesse voor een ander om het op te pakken. Dus eigenlijk was het bestandssysteem helemaal niet zo belangrijk als het afhankelijk was van een enkel persoon.

[dmantione]

Rivaliteit is binnen de open-source wereld een belangrijke factor. Hans Reiser was iemand, die voordat hij de gevangenis in ging, vaak ruzie had met Linux kernel-ontwikkelaars. De reden dat Reiserfs desondanks in de kernel zat, wat dat het features had die andere systemen niet konden bieden. Reiserfs had bijvoorbeeld journalling, dat je geen trage fsck hoefde te doen als je computer niet netjes afgesloten was, en je kon het besturingssysteem van grootte veranderen terwijl het systeem in productie was. In combinatie met LVM was dat een hele belangrijke feature voor de enterprise: Je kon een schijf bijplaatsen, LVM vergroten, je reiserfs vergroten en er was meer ruimte, zonder dat de gebruikers er iets van merkten.

Zoals gezegd wilde niemand met Hans Reiser samenwerken. In plaats daarvan werden de features van ReiserFS aan andere bestandssystemen toegevoegd. Er kwam ext3 dat journalling kon doen en later kreeg ext3 of ext4 ook on-line vergroting. Dus ReiserFS was wel degelijk belangrijk, ik denk dat het sterke invloed heeft gehad op features die we vandaag als doodnormaal beschouwen, maar de afkeer van Hans Reiser was groot genoeg voor anderen om niet aan ReiserFS zelf te willen ontwikkelen.

ReiserFS4 had weer een hoop unieke en krachige features (want visionair was Hans Reiser wel), maar omdat de juridische perikelen losbarsten is de discussie over integratie nooit meer aan de orde gekomen. Zijn groep heeft het systeem wel buiten de kernel doorontwikkeld, de laatste versie dateert uit 2020.

[markwiering]

Een keer toen ik MX Linux installeerde op mijn schootcomputer had ik bij de keuze voor bestandssystemen gekozen voor ReiserFS, omdat ik las dat ReiserFS zéér goed presteert met kleine bestanden. Ik als programmeur werk met heel veel kleine bestanden (tekstbestanden met broncode erin), dus ik dacht: "Dat is voor mij!"

Na de installatie kreeg ik visuele problemen, zoals visuele programma's die door elkaar heenliepen en zodoende het beeld op sommige punten enorm liet knipperen. Ik wist niet hoe ik dit moest oplossen en het Internet raadplegen draaide ook op niks uit.

Toen heb ik MX Linux opnieuw geïnstalleerd, dit keer met EXT4 als keuze - en toen werkte alles weer perfect. Geen visuele rarigheden. Alles werkt zoals het moet werken.

[dmantione]

Het lastig dat met ReiserFS te verklaren, ik heb het jarenlang gebruikt en het was eigenlijk vanaf het begin erg stabiel. Als je toen de gemiddelde harde schijf 120GB was een 1TB server gebruikte, dan gebruikte je ReiserFS bovenop LVM, want ext2 gebruiken met traditionele partities op een 1TB server was niet te doen. Wat je ook las over de ruzies die gevoerd werden. ReiserFS werkte zo goed dat je ook ReiserFS op je desktop en laptop gebruikte, het was ten slotte de standaardkeuze in OpenSuSE. Weg met die oude software!

ReiserFS is inderdaad efficiënt met kleine bestanden, en dat is nog altijd een unieke feature. Het heeft evenwel een achilleshiel die uiteindelijk de ondergang werd: Het gebruikt een globale lock die multitasking verhindert. Het was niet geschreven op een wereld waar er meerdere rekenkernen in een processor zitten en werd een vertragende factor, ook bij gebruik van kleine bestanden.

[fevenhuis]

ReiserFS is wel degelijk verder ontwikkeld naar Reiser4

Persoonlijk vind ik het hoog tijd dat er Europese investeringen komen voor software t.b.v. Europese digitale infrastructuur.

We lopen al veel te lang achter de ellende van Silicon Valley aan te sjokken, daarmee doel ik vooral op het plaatje gegevens opslag maar ook controle over opgeslagen gegevens.

Daarnaast zal Europa uiteindelijk ook een keer op eigen benen moeten kunnen staan met het ontwikkelen van "bureaucratie software".

Ook als we eigen kennis in huis willen hebben voor softwareontwikkeling zullen we moeten investeren in nieuwe software.

Om maar niet te spreken over de veiligheid van de permente man-in-the-middle controle die VS nu uitoefend op Europees netwerkverkeer.

We hebben echter ook onze eigen code repositories nodig.

[Maurits van Baerle]

Ik ben een groot voorstander van Europese zelfvoorzienendheid als het op IT aan komt maar ik zou bestandssystemen niet in de top tien zetten.

De beste bestandssystemen zijn open source en worden over hele wereld ontwikkeld, maar veel belangrijker, je draait ze lokaal. Dus als je een file system als OpenZFS download van GitHub dan heb je daarna verder helemaal niets meer met de buitenwereld te maken. Je data is niet in Rusland, de VS of China opgeslagen, je filesystem belt niet naar huis om te vertellen wat er allemaal opgeslagen staat etc.

Dan zie ik dus nog wel zeker tien belangrijker gebieden waar er nog in mijn ogen te veel afhankelijkheid van niet-Europese leveranciers is.

[fevenhuis]

Security begint bij het filesystem, zeker nu we met zoveel remote/cloud storage te maken hebben.

[latka]

Een bestaand iets betekent iets als ext4 wat al een xtensie is van ext3 wat van ext2 komt. M.a.w een shitload aan irrelevante historie waarmee je wel compatible wilt blijven, maar tevens wilt aanpassen naar copy-on-write wat helemaal niet de basis is van ext2/3/4. Eigenlijk geld voor alle bestaande filesystemen dat als je dat als vertrekpunt neemt je altijd met het bestaande ondisk formaat te maken hebt wat je ontzettend beperkt in je mogelijkheden. Bcachefs is overigens een doorzetting van de tiered storage/ssd cache oplossing die hij eerder al productie klaar had gemaakt.

[HollowGamer]

Je vergeet nog XFS, ik dacht dat BcacheFS features deelt van de grote spelers, daar hoort deze ook bij.

ReiserFS is overigens ook voor een andere reden mislukt. Het was erg ingewikkeld, en met de hoofd ontwikkelaar is een geschiedenis mee.

Ik zou het wel toejuichen. Hoewel Btrfs opzicht goed werkt, ook voor de NAS, is het nog altijd niet zo solide. Hetzelfde geld voor OpenZFS, laatst was daar ook een corruptie op mogelijk. Daarnaast zit OpenZFS nog altijd niet in de kernel, mede door hun stomme licentie.

Niet alles is waterdicht, en de filesystems zijn al redelijk solid, maar BcacheFS wordt wel heel erg flexibel, o.a. met het toevoegen van cache drives, iets dat nog altijd ontbreekt of je erg voor oppassen bij andere. Tevens krijgt het ook native encryptie, iets dat ook weer ontbreekt op de rest.

[trapper]

Wie herinnert ReiserFS nog? In theorie (toen het uitkwam) veel beter, in de praktijk nooit gebruikt.

Dat was mijn filesystem-of-choice, tot dat het uit de gratie raakte, en niet meer goed onderhouden werd (waarschijnlijk omdat Hans Reiser de gevangenis in moest vanwege moord op zijn ex-vrouw...).

[lenwar]

Precies dit.
Ik ben zelf een Linux engineer en het verbaast me soms hoe erg al die projecten langs elkaar heen werken. Zoals @The Zep Man al aangeeft, hoeft de keuze overigens niet zo ingewikkeld te zijn. De meeste distro's geven een standaardsuggestie die in de regel gewoon goed is.

De iets serieuzere distro's hebben dit echt wel goed voor 'ons' uitgedokterd. En ga er maar niet van uit dat jij of ik zouden moeten denken dat we toch echt wat anders dan standaard 'nodig' hebben.
Mijn vuistregel is: Als we het 'denken' dan is het niet zo. Als we het 'weten', dan natuurlijk wel. Er zijn gewoon zaken waar het niet-standaard aanbevolen bestandssysteem echt een meerwaarde biedt voor ons, maar als je dat niet al 'weet', dan is dat (zeer waarschijnlijk) niet zo.

Semi-offtopic:
Persoonlijk verbaast het me dat we onder Linux nog steeds geen gratis bestandssysteem hebben dat waar we gemount partities/volumes kunnen verkleinen. Vrij letterlijk ieder modern besturingssysteem (Windows sinds XP, MacOS sinds OSX, AIX sinds versie 4 dacht ik, z/OS volgens mij altijd al, enz. enz.) sinds jaar en dag heeft een bestandssysteem beschikbaar dat dat kan, behalve Linux. (uiteraard kunnen we Veritas gebruiken onder Linux, maar dat is geen gratis bestandssysteem )
En dan uiteraard even los van hoe vaak we het in de praktijk nodig hebben natuurlijk. Het gaat er om, dat als je het is een keer nodig hebt, dat het niet kan zonder de boel te unmounten.

Edit:
@dmantione wees me erop dat btrfs wel degelijk online verkleind kan worden!

[Reactie gewijzigd door lenwar op 22 juli 2024 18:04]

[HollowGamer]

Waarom zou je online willen verkleinen?

Tegenwoordig werk je met containers, en online verkleinen kan al dynamische daarmee.

[lenwar]

Zoals ik al schreef. Je hebt het niet vaak nodig. En, zoals ik al schreef, daar gaat het niet om.

Ik heb over de jaren heen bijvoorbeeld (SAN-)partities verkleind omdat delen van applicatieve data naar andere systemen was overgedragen (gedeeltelijke functieoverdracht van systeem 1 naar systeem 2). Dus dat er ineens terabytes aan opslag niet meer gebruikt werd en elders ingezet moest kunnen worden.

Ik moest dus daadwerkelijk de applicatie stoppen (onbeschikbaarheid voor (interne) klanten), datapartities unmounten en toen pas kon ik verkleinen. Uiteraard allemaal in te plannen, maar het is zonde dan het nodig is voor iets wat op een willekeurig ander besturingssysteem dat we op dat moment hadden (AIX, Solaris, Windows) gewoon online had gekund.

[HollowGamer]

Dan heb je de indeling misschien niet zo super handig gemaakt.

Tegenwoordig is het veel met containers, en voor opslag zijn ook genoeg mogelijkheden.

[lenwar]

Klopt. Tegenwoordig wel. Veel kan in containers. Sommige dingen redelijkerwijs nog niet. Applicaties zijn ook historisch gegroeid en doorontwikkeld op bestaande systemen.

Zodra je met internationale wetgeving te maken hebt, is er ook ineens heel veel niet meer mogelijk. Zodra je bijvoorbeeld met Singapore handelt en hun Centrale Bank (de MAS) te maken hebt, gaat er ineens een wereld voor je open aan regels en rapportages, beperkingen, restricties, enz. (tot op het niveau dat je letterlijk uitzonderingen moet aanvragen om 'op afstand' toegang te mogen hebben op een server voor beheerdoeleinden. Ik heb het nooit gecontroleerd, maar ze hebben vast ook een mening over het gebruik van containers.) Maar ook de DNB en de ECB ook concrete eisen voor bepaalde typen data en de verwerking hiervan.

Er is in de praktijk niets algemeens te zeggen over de bruikbaarheid van containers in alle gevallen.

Het ligt ook heel erg aan de aard van de applicatie en hoe de softwareleverancier de applicatie (ooit) heeft ontwikkeld.

Dit gezegd hebbende zag tot een paar jaar terug ook wel veel weerstand tegen containers in mijn omgeving. "Dat kan niet in een container", waar het voornamelijk onbekendheid van het mechanisme was. Ik heb ook een periode gezien dat alles te pas en te onpas, maar in containers werd gegooid waar het weinig toevoegde en alleen maar complexiteit aan mechanismen geïntroduceerd werd.

Het verschilt gewoon heel erg per use-case en applicatie.

Vroeger (jaren 90 - 00) zag je vaak dat de databaseserver naast de applicatieserver op een stuk ijzer draaide. ("Mijn server" vond het betreffende applicatieteam.) Tegenwoordig zie je veel meer gecentraliseerde database servers (Oracle RAC, DAAS in de cloud, enz.) en draaien allerlei applicaties direct op VMs in (private) clouds of inderdaad in containers.
Ik zie tegenwoordig overigens nog steeds applicatieservers die direct op hardware draaien. (dus geen VMs). Servers met 32 of meer CPUs (cores) en daar hele straten van. Dat is eenmaal hoe de applicatie draait en ooit ontwikkeld is.
Het zal technisch vast mogelijk zijn dat de softwareleverancier de applicatie functioneel helemaal op knipt en de workloads verdeeld over honderden/duizenden containers en dat het dan ook prima (misschien nog wel beter dan nu) werkt. Goede kans dat het over 10-15 jaar er ook zo uit. Maar voor nu is dat niet.

N.B. Het zijn wel de uitzonderingen, hoor. Maar ik zie ze nog steeds.

[joker1977]

Begrijp je dat systemen soms een erfenis hebben van soms wel decennia-lang ?

Het is niet alsof (storage-)systemen elk jaar even tegen het licht worden gehouden om daarin te worden aangepast naar de huidige stand van zaken ?

Als de applicatie-beheerder uiteindelijk iets heeft bedacht dan kun je vaak praten als brugman, maar daar hebben veel de energie voor. Dus flikker er maar tegenaan wat gevraagd wordt en laat de volgende persoon er over 3-5 jaar maar over nadenken hoe dat gemigreerd dient te worden.

[dmantione]

Ehm.... BTRFS kan gemount verkleind worden?

[lenwar]

Ik zie het. Bedankt!!
Dan is btrfs het eerste gratis bestandssysteem op Linux dat ik ken dat dat kan.

[Cergorach]

Je krijgt nu al keuzestress als je Linux installeert...

Hadden we dat niet al voordat we beslissen welke Linux distributie te kiezen? Er zijn meer dan 600 actieve Linux distributies! Hoeveel filesystems hebben we voor Linux?

[downtime]

Gelukkig is het ontwikkelen van een bruikbaar filesystem heel wat moeilijker dan het forken van een Linux distro.

[svennd]

Niemand klaagt toch over het aantal warme bakkers ? Dat de concurrentie eenheidsworst is geworden dat is niet per definitie goed. We zien nu dat er 'maar' 2 grote spelers meer zijn Red Hat en Ubuntu zwaaien de plak, de rest volgt, want daar komt het geld vandaan

[TheVivaldi]

Je krijgt nu al keuzestress als je Linux installeert door het aantal file systems wat ze aanbieden.

Welke Linux-distributie installeer jij dan? Want bij de meest gangbare heb je die keuze niet en bepaalt het systeem voor je (en krijg je dus meestal ext4, xfs of btrfs).

[kabelmannetje]

Zoveel zijn er niet. Ex4 en vooral BTRFS zijn de norm. De rest zijn voor niche, server en (oude) compatibiliteit. Dit FS wil de beste features van een FS combineren en de nieuwe standaard neerzetten. Snelheid, betrouwbaarheid, gemak, veiligheid en uitbreidbaarhied. Daar zet deze subsidie dus op in.

[arnova]

Goed om te horen. Zeker aangezien btrfs nooit meer echt stable lijkt te worden.

Maar wat bedoelt men in vredesnaams met "waarbij geen geheugen verloren gaat tijdens het kopiëren van bestanden" ?

[GertMenkel]

Geheugen in de vorm van opslag, in dit geval. Copy-on-write zit in best veel andere bestandssystemen en houdt in dat als je op "kopieer" klikt, er wel een nieuwe entry wordt aangemaakt in de bestandstabel van je bestandssysteem, maar er geen data wordt gekopieerd. Zodra je begint nieuwe data toe te voegen of andere data te overschrijven, wordt alleen dat verschil opgeslagen.

Dit lijkt een beetje op hard links, maar hij hard links wordt het origineel aangepast zodra je de "kopie" begint te bewerken. Bij CoW kun je de kopie gewoon aanpassen, en alleen de onbewerkte data blijft naar het origineel verwijzen. Pas je het origineel aan, dan werkt het natuurlijk andersom, en schrijf je voor het origineel alleen de verschillen weg.

Een voorbeeld van wat ik zelf heb gedaan op BTRFS: stel, je wil een kopie van Skyrim maken, eentje met mods en eentje zonder. Je kopieert de hele map van Skyrim naar Skyrim-mods. Vervolgens begin je textures te vervangen en bestanden toe te voegen. Op het eerste oog lijkt het alsof je nu twee keer zoveel opslag + de inhoud van je mods in gebruik hebt genomen, maar doordat het kopiëren van de map met CoW gedaan is, was die operatie 1) in milliseconden klaar en 2) refereert de meeste data van Skyrim-mods nog naar de bits op de schrijf die eigenlijk aan de map Skyrim toebehoren.

Effectief betekent dat dat de kopie enkele kilobytes aan metadata in beslag neemt + de mods die zijn toegevoegd. Zo kun je op één SSD tientallen of honderden verschillende mod-configuraties maken die allemaal hooguit een paar honderd MB innemen, en niet zoals bij ext4/NTFS/FAT32 allemaal vele gigabytes groot zijn.

Overigens kan NTFS dit trucje ook, maar zit dit volgens mij alleen inbegrepen bij serveredities van Windows.

Wil je hiermee experimenteren, en heb je een Linuxinstallatie draaien, zou ik zeggen: formatteer eens een schijf als BTRFS (en in geloof ook zfs, maar dan moet je even Googlen hoe dat exact werkt want ik gebruik dat niet zo) en speel wat met kopiëren en plakken. Helaas snappen de meeste tools voor het weergeven van schijfgebruik deze feature niet zo, dus je moet vooral de vrije ruimte in de gate houden, of bestandsysteemspecifieke tools gebruiken om te zien hoeveel ruimte er écht wordt gebruikt (bijvoorbeeld "btrfs fi du" in plaats van "du").

Een andere leuke truc die je hiermee kan uitvoeren, is dat je achteraf bestanden kan dedupliceren op deze manier. Zo heeft Steam de neiging alle kopieën van Proton opnieuw te downloaden en in mapjes naast elkaar te zetten, en de meeste bestanden zijn inhoudelijk allemaal hetzelfde. Ik heb duperemove er overheen gegooid, en nu gebruikt iedere installatie van Proton eigenlijk alleen één versie plus de verschillen die tussen de versies aanwezig zijn qua schijfruimte.

Dit hoeft natuurlijk niet alleen over spellen te gaan, je kunt ook je foto's en dergelijke op die manier dedupliceren en ze op verschillende plekken in submappen neerzetten zonder dat ze extra schijfruimte opeten, en kunt naar hartenwens specifieke bestanden bewerken zonder dat de andere bestanden worden aangetast zoals je bij hard links/soft links zou hebben.

[Jerie]

(en in geloof ook zfs, maar dan moet je even Googlen hoe dat exact werkt want ik gebruik dat niet zo)

Natuurlijk kan ZFS dit ook. Dedup heet het. En het was één van de redenen dat NetApp Sun aanklaagde (ivm WAFL patent). Maar het is niet gratis, het heeft een performance impact. ZFS kan erg veel, en kon ook erg veel als (defacto) eerste ofwel eerste middels een 'vrije Unix'. Maar helaas, de licentie heh. Oracle kan het morgen uitbrengen onder GPLv2 of GPLv2 or later maar dat doen ze niet.

Btrfs CLI tools zijn weer anders (die van ZFS ook hoor) dan wat je gewend bent en je zit met RAID5 (en soortgelijke) write hole dat nog steeds niet opgelost schijnt te zijn. ZFS en Ext4FS hebben daar geen last van.

Ik lees in dit topic ook mensen die zeggen 'Ext4FS is goed genoeg' terwijl in situaties voor huis- tuin- en keukengebruikers alsmede in bedrijfskritische toepassingen een filesystem als ZFS veel geld en tijd zou kunnen besparen. Met overhead die verwaarloosbaar is tov wat je terugkrijgt. Dwz: een feature als snapshotting / CoW kost dusdanig weinig overhead dat deze het dubbel en dwars waard is, terwijl dedup een performance impact heeft. Ik dacht idem op btrfs.

[Maurits van Baerle]

Oracle kan het morgen uitbrengen onder GPLv2 of GPLv2 or later maar dat doen ze niet.

Oracle zou OracleZFS onder GPL kunnen uitbrengen maar veel schiet je daar niet mee op. OracleZFS is een beperkt onderhouden fork van de twintig jaar oude SUN Microsystems codebase en zal alleen op Unix (OpenSolaris bijv.) draaien, niet op Linux.

Wat je wil is OpenZFS. Dat is ook een fork van de oude SUN codebase maar daar is in de tussentijd ontzettend veel aan gedaan door een heleboel marktpartijen. Bijvoorbeeld het geschikt gemaakt voor SSD’s (want die bestonden nog niet in de Sun tijd), het toevoegen van block cloning, distributed RAID (dRAID), het kunnen draaien in Linux, en nog een heleboel dingen die we in de Sun tijd niet konden bedenken maar nu graag willen.

En de OpenZFS code is voor het grootste deel eigendom van de verschillende developers die hebben meegewerkt aan OpenZFS of voorgangers, daar heeft Oracle niets over te zeggen.

[Jerie]

Met OpenZFS kun je niet eens iedere Linux kernel draaien. Effectief zit je op een fork. Of je dat wil is de vraag. Ideal is het zeker niet.

En OpenZFS kent nog zat andere nadelen zie Jerie in 'NLnet geeft subsidie voor ontwikkeling van Linux-bestandssysteem Bcachefs'

Helaas is het wel m.i. de beste keus op dit moment. Hopelijk zorgt deze impulse voor verbetering maar dan hoop ik ook cross-platform.

[GertMenkel]

Ik ging ervan uit dat ZFS het kan, maar als ik het niet zeker weet ga ik het ook niet zeker claimen

Ik snap wel dat sommige mensen naar simpele oplossingen snakken, maar snapshotting (en de bijbehorende gemakken wat betreft backups) maken echt een hele hoop dingen zoveel makkelijker. Ik ga niet meer terug naar ext4 in elk geval. Ik gebruik zelf BTRFS omdat het in-tree zit en omdat het minder afhankelijk is van een geheugenbuffer van ZFS (wat ten koste gaat van performance en andere dingen natuurlijk), maar ik beschouw beiden als equivalenten die in net iets andere use cases uitblinken.

[hbvdh]

XFS op linux en ReFS op Windows doen hetzelfde.

[GertMenkel]

Zit ReFS nog in een normale versie van Windows?

XFS is ook een goede, ik wil nog wel eens van het bestaan daarvan vergeten. Ik kan me niet zo heugen wat daar ook alweer de voor en nadelen van waren.

[hbvdh]

ReFS zit in de server versie en de Workstation versie van Windows. Ik geloof dat je via cli nog wel ReFS kan gebruiken in de normale Pro van Windows, maar weet dat niet zeker.

XFS gebruiken we voor Veeam Backup "hardend" repositories.

[gibsonsg400]

Hallo Arnova,

Voordat je dit soort ruis verspreid kijk eerst naar de documentatie van btrfs.
Deze is opgebouwd uit modules en als je louter de stabiele modules gebruikt heb je geen problemen met betrouwbaarheif tenzij je b.v. niet afdoende scrubbed of niet afdoende geheugen hebt voor sexy features die je allemaal aanzet..
Of als je geen ecc geheugen gebruikt net als voor zfs is dat eigenijk een requirement.

Ter additie btrfs is de install standaard voor Sles een enterprise Linux distributie.
Dat Er bij Redhat Btrfs als onstabiel genoemd word omdat ze zelf de kennis niet in huis hebben wil nog niet zeggen dat je dat allemaal maar moet herhalen zonder je hierin te verdiepen.

[arnova]

Nou ik heb mij er best behoorlijk in verdiept hoor aangezien ik al ca. 25 jaar Linux admin ben en ik de meest gangbare filesystemen (ext2, ext3, ext4, xfs, btrfs, zfs) inmiddels wel een keer gebruikt heb. M.a.w. ik herhaal niks, ik geef mijn mening gebaseerd op wat ik door de jaren heen gelezen/gezien heb. Overigens ben ik ook geen fan van XFS omdat ik daar ook veel problemen mee heb gezien, maar dat terzijde.

Het is vooral onbegrijpelijk dat ze na tig jaar nog steeds die RAID5/6 problemen in btrfs niet kunnen oplossen. Daarnaast heb ik met btrfs wel dataloss issues gezien, die ik met zfs of ext4 niet tegen gekomen ben.

Dat verhaal over de "vereiste" van ECC geheugen met zfs/btrfs is ook een fabeltje. Tuurlijk is het beter, maar stellen dat je zonder ECC overgeleverd bent aan de goden is ook onzin.

[gibsonsg400]

Je bent niet aan de goden overgeleverd (heb ik trouwens ook niet zo gesteld) zonder ECC want je hebt gewoon meer last van bitrot,
Wel vaker scrubben en een fatsoenlijke backup/restore strategie ontwerpen en het gaat prima inderdaad.

Gefeliciteerd met je mooie carriere dat is niet een ieder gegeven

Ik ontwerp en implementeer regelmatig oplossingen voor klanten specifieke oplossingen waar door de jaren heen het fs/devicemanger cruciaal is gebleken voor het slagen van het project of niet.
B.V. LVM onderstuent een cache device maar werkt op de lange duur niet zo voordelig qua caching als bijvoorbeeld zfs-chache/bcache/bcachefs.
Als het lvm caching device volzit gaat het performance verliezen onder stress vanwege het clearen van cached objects.

Raid5/6 zou ik nu de huidige status niet van weten qua btrfs, de laatste keer dat ik checlte stonden ze ook niet als stabiel aangemerkt in hun documentatie.

Maar vaak gaat het mis met zaken als dedup plus compress aanzetten met 8GB geheugen en dan is btrfs/zfs niet stabiel terwijl daar duidelijke recomendations over zijn waar met implementatie geen rekening word gehouden.

Dus iets niet stabiel is wat bij andere organisaties wel succevol is geimplenteerd zelfs de distro standaard kijk dan eens naar hoe het geimplenteerd is. Daar kan vaak de kneep zitten.

[Q]

Zonder ECC vaker scrubben heeft geen zin want je kunt niet weten dat er rotte data is weggeschreven. En die rotte data zit dan ook in je backups.

Voor thuis gebruik dit risico accepteren snap ik maar in een bedrijfsomgeving onverdedigbaar, misschien hooguit voor hele kleine tokos.

[Ceaus]

Zonder ECC vaker scrubben heeft geen zin want je kunt niet weten dat er rotte data is weggeschreven.

Dat weet je wel ivm checksums die als meta data beschikbaar zijn. ZFS houdt dat netjes bij.

[Q]

Als je rotte data uit memory wegschrijft met checksum klopt het checksum als je de data later terugleest maar is je data rot.

ZFS bijvoorbeeld is niet ontwikkeld of bedoeld als mitigatie tegen rot geheugen of bit flips in geheugen. Niets is daar tegen bestand, het is een fundamenteel ding.

[Ceaus]

Ik begrijp je punt. Die is deels valide, maar toch wel te makkelijk. Zie https://jrs-s.net/2015/02...n-ecc-ram-kill-your-data/

[Q]

Ik begrijp je punt. Die is deels valide, maar toch wel te makkelijk. Zie https://jrs-s.net/2015/02...n-ecc-ram-kill-your-data/

Dat verhaal is al zo oud maar verandert niets aan de risico’s. Het artikel gaat vooral in op het idee dat zfs kwetsbaarder zou zijn voor memory bit flips of niet, maar dat is een andere discussie

Of je die risico’s klein vind of niet moet je zelf maar bepalen, het is mijn data niet.

ZFS is niet gevoeliger voor non-ecc geheugen maar heeft het nét zo hard nodig als ieder ander FS als je echt om data integriteit geeft

[Reactie gewijzigd door Q op 22 juli 2024 18:04]

[asing]

Ook Fedora installeert sinds kort standaard als btrfs. Volgens mij al 2 releases. Ik heb na jaren een verse install gedaan van Fedora 39 en die heeft btrfs met de default instellingen. Tot nu toe geen issues gehad.

[Jerie]

Het aantal mensen dat Fedora met RAID5 gebruikt is waarschijnlijk met 1 hand te tellen. RAID5 gebruikt men niet op de desktop. Hoogstens vroeger op high end workstations waar men flink data verstouwde. Hebben we het over jaren 90, in de tijd van SCSI en nog voor SATA.

[Dennisb1]

Wat is hier nou het voordeel uit naast btrfs ?
Deze doet zoals het artikel ook al zegt het zelfde als bcachefs

[Llopigat]

Btrfs is verre van simpel, dat is ook een doel van deze makers.

[Katsunami]

BTRFS is ook verre van stabiel, als je de pagina's erover in de Debian-wiki moet geloven.

Ik zou graag overstappen op iets dat meer mogelijkheden biedt dan EXT4 (waaronder snapshots, etc), maar ik heb geen zin om een bestandssysteem in de terminal te beheren alsof het 1981 is. Ik wil gewoon in KDE Partition Manager of Gnome Partition Editor (PartEd) alles kunnen doen wat nodig is om bestandssystemen te maken, en het aanmaken ervan (met alle opties beschikbaar in een GUI) dient ook mogelijk te zijn tijdens de installatie van het OS. Je kunt BTRFS op Debian gebruiken, maar na het aanmaken tijdens de installatie moet je in de command-line nog dingen regelen. Doe je dat niet, dan heb je het bestandssysteem niet volgens "best practice" in gebruik.

Zolang dat soort dingen niet op orde zijn, zelfs niet nadat een bestandssysteem al 10 jaar in de kernel zit, blijf ik lekker bij EXT4.

[GertMenkel]

Ik heb de Debian-wiki niet zo gelezen, maar BTRFS is al tijden de standaard voor OpenSUSE en ook Fedora zet je partitie standaard op BTRFS tegenwoordig. Ik geloof ook dat veel installaties van EndeavourOS op BRTFS draaien, want Timeshift is toch verdomde handig.

Uitgebreide BTRFS-opties ontbreken uit de GUI van KDE en Gnome (maar datzelfde geldt voor ext4, ik kan me niet heugen dat er een vinkje was om journaling uit te zetten of het aantal backup superblocks te verhogen), je zult helaas naar externe GUIs moeten om uitgebreide features te configureren als CoW en andere zaken die in ext4 ontbreken.

Als je liever bij ext4 blijft, moet je dat vooral doen, maar ik zie tegenwoordig het probleem niet meer met BTRFS. Het lijkt me juist handig voor beginners, omdat het een soort "system restore" kan toevoegen na mislukte updates waar je bij ext4 meteen mag grijpen naar een recoveryomgeving met eventueel een chroot om je systeem weer werkend te krijgen.

Ik gebruik het zelf ook op de Steam Deck op mijn geheugenkaartjes (al moet ik die helaas in de desktop GUI mounten) vanwege de compressiemogelijkheid en het werkt helemaal prima in mijn ervaring.

[Jerie]

Timeshift bestaat ook voor Rsync. Dan kun je het bovenop Ext4FS draaien.

ZFS ondersteunt ook gewoon dergelijke snapshots, die je in Pacman bijvoorbeeld (of APT of whatever) kunt hooken. Heb ik notabene zelf op Arch gedraaid (waar EndeavourOS op gebaseerd is). Enige dat ik niet had was een mooi GUItje maar ik denk dat dat ook niet zo mooi werkt (zie bijvoorbeeld TimeMachine).

Als je liever bij ext4 blijft, moet je dat vooral doen, maar ik zie tegenwoordig het probleem niet meer met BTRFS.

Ik heb een NAS met 4 schijven RAID-Z2 (ZFS) en ik heb een NAS met 2 schijven (Ext4FS). Die laatste draait DSM dus Btrfs of Ext4FS. Voorheen draaide ik Btrfs erop maar ik was ontevreden over de performance. Dit zijn dan ook die debiele 'NAS' HDDs van WD (de schoften). ZFS gaat niet draaien op DSM, en enkel op oudere Linux kernels. Maar Btrfs zou ook niet te gebruiken zijn eerdergenoemde RAID setup.

Overigens heeft OpenZFS genoeg problemen. Kijk maar eens naar alle bug reports, bijvoorbeeld mbt zfs send / receive. De native cryptografie is afgeraffeld. Maar OpenZFS is er wel voor Windows en macOS, read/write zelfs. Btrfs is er voor Windows read/write maar niet voor macOS. Hoe het met bcachefs gaat zijn, geen idee. Hoe dan ook zit het er allemaal niet native er in, en GPLv2 voorspelt dat het niet native in macOS / Windows kernel gaat zitten.

[Reactie gewijzigd door Jerie op 22 juli 2024 18:04]

[GertMenkel]

De rsync timeshift is helaas niet zo instantaan als wat je met snapshots bereikt. Bij grotere bestandssystemen heb je het risico dat je daarmee inconsistentie krijgt (bijvoorbeeld omdat werkbestand 1 de transactie wel heeft afgerond ten tijde van de snapshot maar werkbestand 2 niet), en dat kan heel onhandig zijn.

Ik verwacht van Apple en Microsoft niet dat ze Linux-beatandssystemen in de kernel zullen draaien. APFS en NTFS voldoen voor die systemen en daar is de bestandssysteem-API ook naar ingericht, dus of de drivers nu GPLv2 of MIT zijn, je zult ze als gebruiker altijd zelf moeten installeren.

Ik weet niet waarom niemand de moeite heeft genomen om een BTRFS-drivers voor macOS te schrijven, maar als je macOS gebruikt zie ik sowieso het voordeel niet zo in van BTRFS of ZFS of XFS. Op Windows is de driver ook niet compleet (bijvoorbeeld geen ondersteuning voor subvolumes de laatste keer dat ik keek). Alternatieve bestandssystemen en proprietary software, zelfs met Darwin, gaat gewoon niet zo lekker samen, mede doordat filesystem drivers schrijven echt klotewerk is.

[webhalla]

Next best thing: draai wsl2 op Windows 10 of beter, mount de ext4 disk via powershell en voila de disk is zichtbaar in explorer bij de Windows schijven.

https://www.bleepingcompu...xt4-filesystems-in-wsl-2/

[Jerie]

Is WSL nog steeds zo belabberd met I/O?

[webhalla]

Wsl was een soort emulator naar de Windows kernel routines, wsl2 is een virtuele machine constructie die gebruik maakt van hyper-v. Volgens specs van Microsoft is wsl2 20 keer sneller in read/write dan wsl. Ook zou wsl 2 95% van native Ubuntu snelheid hebben.

[The Zep Man]

BTRFS is ook verre van stabiel, als je de pagina's erover in de Debian-wiki moet geloven.

Hou er rekening mee dat dat enkel om de exotische functionaliteit van btrfs gaat, zoals RAID5/6-ondersteuning. Als je enkel de "OK"-functies gebruikt, dan is btrfs stabiel. Als je naar "Mostly OK" kijkt, dan zie je bijvoorbeeld dat voor defragmenteren je rekening moet houden dat extent sharing niet veilig gesteld wordt, waardoor je potentieel meer diskruimte gebruikt. Dat is afhankelijk van:

1. Je degfragmenteert überhaupt. Met SSD's is daar geen noodzaak toe.
2. Je maakt wel eens een lightweight copy van bestanden.
3. Je maakt je zorgen over dat je een hoeveelheid bespaarde opslagruimte door een combinatie van punt 1 en 2 verliest.

Als één van die drie punten niet van toepassing is, dan is de "Mostly OK" voor defragmenteren effectief een "OK".

Een tegenvoorbeeld vanuit mijzelf:
Ik heb wel eens een notebook gebruikt waarvan een geheugenbank kapot was gegaan. Geen ECC (want een normale notebook), dus het systeem weet dit zelf niet. Ik kwam hierachter door de controle en de rapportage die btrfs doet over (corrupte) zaken die weggeschreven worden naar disk. Die controle wordt niet gedaan door een filesystem zoals ext4, waarmee het probleem waarschijnlijk langer had kunnen bestaan.

Afijn, eem ramtest gedaan ter bevestiging, beide geheugenbanken vervangen (als de één kapot gaat is de ander ook niet meer betrouwbaar), backup hersteld, en weer door.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:04]

[PolarBear]

(als de één kapot gaat is de ander ook niet meer betrouwbaar)

En wat is de onderbouwing daar bij? En als ik 4 geheugenreepjes heb moet ik ze dan alle 4 vervangen?

[DataGhost]

Waarschijnlijk dat meerdere geheugenreepjes vaak uit dezelfde set komen die weer uit dezelfde batch van de fabriek komt, en ze krijgen beide ook hetzelfde toegangspatroon voor hun kiezen (want dualchannel). De kans is dus groot dat beide modules ongeveer rond hetzelfde moment kapot zullen gaan.

[The Zep Man]

De notebook werd af-fabriek geleverd met twee reepjes uit dezelfde batch. De vervangingswaarde van RAM was in de tijd dat dit incident zich voordeed insignificant. Liever neem ik het zekere voor het onzekere. Verder is een exact hetzelfde reepje terugvinden uit dezelfde serie duurder t.o.v. het vervangen van beide bankjes, en zitten er ook risico's aan het gebruik van verschillende reepjes uit verschillende series/van verschillende merken. Dan maar alles in één keer vervangen. Een beetje meer geld uitgeven om veel tijd en hoofdpijn te besparen is mij het wel waard.

Er zijn een aantal onderdelen van computers die ik serieuzer neem dan andere onderdelen. RAM valt in die eerste categorie.

En als ik 4 geheugenreepjes heb moet ik ze dan alle 4 vervangen?

Ik weet niet wat jij doet of moet doen. Ik ken jou, je use cases en je risk appetite niet.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 18:04]

[gibsonsg400]

Hallo Katsunami,

Bcachefs is meer dan alleen een fs zoals ext4 niet mee te vergelijken: https://bcachefs.org/bcachefs-principles-of-operation.pdf

Je bekijkt dit als een gebruiker die zijn systeem voor zijn eigen gebruik inricht.
Ik moet er niet aan denken om in een compleet serverlandschap ook nog eens kde te installeren om bcachefs of wat dan ook te managen via een gui. Dat is 1999 style.
Dit soort dingen worden voor specifieke toepassingen gebruikt en via automation provisioned. De gemiddelde thuisgebruiker zal hier niet echt voordeel bij hebben om dit toe te passen.

Bcachefs is geevalueerd vanuit bcache, en deze code is stabiel en betrouwbaar.
Bcachefs heeft een aantal zaken die andere filesystems niet hebben eignelijk is het net als zfs/btrfs veel m eer dan een fs louter voor een disk.
Een superieur manier van cachen en ook nog eens tweakable naar je specifieke behoefte.

Alle testen vergelijken qua cache( it is in the name) die ik gedaan heb al dan niet met enterprise hardware was bachefs de oplossing voor de bottleneck waar we naar zochten.

Ja lvm, btrfs, zfs heeft deze opties ook maar dit is niet toegespitst op het cachen en dan ook nog highly tweakable. En qua caching leggen ze het af tov bcachefs.

Je hebt gelijk dat je het voor je standalone pc/laptop niet gebruikt het heeft geen meerwaarde voor je.

[flapr00m]

Een btrfs systeem opzetten gaat simpel met manjaro of iedere andere distro die calamares gebruikt.
Bij het maken van de partities kan gelijk al voor btrfs gekozen worden. Vervolgens na de installatie de tooling kiezen. De wiki's per distro geven daar voldoende info over.

Met de btrfs-assistant is het grafisch mogelijk naar een snapshot terug te gaan.
Ja natuurlijk vergt het kennis dus moeite. De zin "Zolang dat soort dingen niet in orde zijn" klopt gewoon niet met de werkelijkheid.

[vt220]

Ik heb nooit zo goed begrepen waarom je snapshots in een filesysteem zou willen. Dat doe je toch op de laag eronder? LVM of op de storage zelf?

[dmantione]

Juist niet, want je dan kan je geen delta's maken en serialiseren, twee functies die cruciaal zijn voor een incrementele backup. ZFS en BTRFS kunnen zonder overhead een verschil tussen twee snapshots genereren, want je als bestand naar een andere server kunt toepassen en zo nieuwere snapshot efficiënt naar backupserver verplaatsen, dat is zowel efficiënt kwa diskgebruik als netwerkverkeer. Zoiets werkt enorm veel beter dan backupsoftware, die het hele bestandsysteem moet doorzoeken naar gewijzigde bestanden en geen garantie op een atomaire backup heeft (er kunnen zaken veranderen op het systeem terwijl de backup loopt, geen last van bij snapshots).

Dit is ook het grote probleem met het Red Hat Stratis, wat ze als alternatief voor BTRFS en ZFS naar voren hebben geschoven, maar je hebt er geen reet aan, omdat het op blockdeviceniveau werkt. En omdat het geen bestandssysteem is, nog op veel meer punten deficiënt is, maar dat valt buiten deze discussie.

[Omega]

Edit: dit was bedoeld als reactie op mijn naamgenoot @Dennisb1 .

Dat klopt niet. Btrfs is prima stabiel, men dat het heeft over instabiliteit van Btrfs heeft het altijd specifiek over RAID5 en RAID6. En het probleem hier is niet Btrfs, het is dat niemand geïnteresseerd genoeg is in deze feature om het correct te implementeren. Het heeft dan wel initieel een tijdje geduurd voordat deze features allemaal stabiel werden, maar Btrfs is dan ook het "billion dollar filesystem", het is een complex monster.

Daarnaast gebruiken veel grote corporate Linux distros zoals Fedora en (Open)SUSE dit als default filesystem, als het problemen had dan hadden zij dit niet gedaan.

Zie hier de Btrfs feature stabiliteit status; https://btrfs.readthedocs.io/en/latest/Status.html

Bcachefs zal hoogstwaarschijnlijk tegen deze zelfde problemen aanlopen, als het wil doen wat Btrfs doet wordt dit op termijn ook een complex monster.

[Reactie gewijzigd door Omega op 22 juli 2024 18:04]

[N8w8]

Ja de RAID5/6 issues zijn bekend maar RAID1 is ook niet alles.
Als je een btrfs RAID1 set hebt waarvan er eentje faalt, dan kan je die alleen mounten door expliciet aan te geven dat ie degraded mag mounten.
(Het wordt afgeraden om in te stellen dat ie altijd degraded mag mounten, lang verhaal).
Dus heb je root op een degraded btrfs RAID1, en doe je n normale reboot, dan start ie niet meer.
Nou is dit by design en als je daar rekening mee houdt dan hoeft dit ook geen probleem te zijn, dus wordt dit mss niet als stabiliteit bug aangemerkt.

Maar onze server wil ik zo min mogelijk hoeven pamperen, die staat 50km verderop dus kan ik niet zomaar even iets intypen in grub (hangt normaal niet eens een tobo/monitor aan).
Daarom juist gebruik ik ook RAID1, zodat alles blijft werken als n disk uitvalt.
En reboot ie automatisch zodra er een kernel security bugfix is.

Met "normale" software RAID (dm/md/lvm) werkt dat allemaal prima, vlgs mij heeft ZFS hier ook geen last van dus blijkbaar kan dat best wel met CoW RAID. Maar btrfs RAID1 vergt handmatig ingrijpen, tenminste, als het je te doen is om de uptime.

[novasurp]

Btrfs is niet betrouwbaar genoeg gebleken.

[gibsonsg400]

Hallo novasurp,

Voordat je dit soort ruis verspreid kijk eerst naar de documentatie van btrfs.
Deze is opgebouwd uit modules en als je louter de stabiele modules gebruikt heb je geen problemen met betrouwbaarheif tenzij je b.v. niet afdoende scrubbed of niet afdoende geheugen hebt voor sexy features die je allemaal aanzet..
Of als je geen ecc geheugen gebruikt net als voor zfs is dat eigenijk een requirement.

[WeiserMaster]

Voordat je dit soort ruis verspreid kijk eerst naar de documentatie van btrfs.
[...]
Of als je geen ecc geheugen gebruikt net als voor zfs is dat eigenijk een requirement.

De ironie..
Een andere bron met nog scenarios :)

[gibsonsg400]

Heb je de andere reacties in dit en de Documentatie van btrfs zelf nou al gelezen in de afgelopen twee minuten ?
Btrfs lang geleden is niet btrfs vandaag de dag.

Btrfs word op grote schaal succevol toegepast in de enterpise wereld.

Btw: van jouw link de Ironie(Ironisch genoeg )
citaat:
###
If your backup and recovery strategy relies on ZFS using ECC RAM, you should rework your backup strategy. After you do not need ECC RAM, you can buy it as a matter of convenience to save time troubleshooting and/or restoring from the backup.
###

Dus ja het kan zonder ECC maar dan moet je wel het eea op orde hebben vooral je backup en restore strategie. En vaak scrubben ter preventie van bitrot. Zie docuemntatie van ZFS/BTRFS zelf !
Nationale storing: " ja ff backup terugzetten" gaat hem niet worden natuurlijk

En de tweede link bevestigt dat je om vaker moet scrubben met non-ecc geheugen.

Probeer je nu tegen te spreken of te bevestigen ?
Het lijkt op het laatste. Lees de huidige zfs/btrfs documentatie zoals elders in dit draadje aangegeven.

Succes!

[downtime]

Maar is dat een fundamenteel probleem of een probleem wat oplosbaar is als er maar genoeg tijd (en subsidiegeld) in wordt gestoken?

[Xander2]

Sja, dat hangt even ervan af met welke bril je ernaar kijkt.

Ik gebruik BtrFS al jaren zonder problemen of dataverlies voor PCs/laptops, alle FAT en NT/HPFS varianten kennen ook zo hun problemen.

Ook problemen gehad met XFS, ext3/4 deletes wat een serverfarm omlaag trok, een NTFS lock die de rest vastzette, een ZFS die ruzie maakte met de RAID controller....

Om daar nou een FS op te beoordelen, perfect bestaat gewoon niet maar als je BtrFS op je laptop gebruikt zul je er waarschijnlijk nooit een probleem mee ondervinden...

[himlims_]

heb jij Ceph al stuk gekregen?

[dmantione]

BTRFS is super betrouwbaar, er wordt een hoop onzin over verspreid vanuit met name Red Hat. De programmeur van BTRFS, Chris Mason werkte aanvankelijk bij SuSE, later bij Oracle en beiden waren de vijand.

Als je kijkt naar de featurelijst dan is alleen de ingebouwde RAID niet productierijp en daar loopt het op achter t.o.v. ZFS. Dat is kan, niet elk systeem hoeft dezelfde feastures te hebben. De ingebouwde RAID van ZFS heb je verder ook weinig aan, die kan niet overweg met grote RAID-arrays, we draaien het op het werk vaak bovenop hardware RAID, volgens ZFS-envangelisten heiligschennis is, maar wel de beste oplossing is.

Dan vervalt het veschil tussen ZFS en BTRFS op dit gebied. Gewoon op je laptop op desktop is BTRFS een veel betere optie, omdat BTRFS geïntegreerd is en je BTRFS dan ook gewoon bij de installatie van je Linuxdistributie kunt selecteren (en is de standaardkeuze bij OpenSuSE en Fedora).

[Cyberpuppy]

Goed plan. We hadden toch nog geen keuze -> https://en.wikipedia.org/wiki/List_of_file_systems

[muppet99]

gelukkig staat Bcachefs al op de lijst

[latka]

Ja, stel je voor dat je wat kon kiezen. Waren we maar op fat12 gebleven

[lenwar]

Lang niet ieder bestandssysteem in die lijst is natuurlijk geschikt voor ieder besturingssysteem of draagmedia. Sterker nog. Er staan zelfs virtuele bestandssystemen tussen. En verkijk je ook niet op de duplicaten er in hè?

Zo staat bijvoorbeeld ReFS zowel bij de 'disk file systems' als de 'File systems with built-in fault-tolerance'

Maar eerlijk is eerlijk... Het is een mooi lijstje aan het worden

[etrans]

"Het is niet duidelijk hoe hoog de subsidie is die Bcachefs krijgt. "

Je kan een grant vragen bij NLnet van tussen de 5000 en 50.000 EURO.

[Jim80]

https://xkcd.com/927/

[GertMenkel]

Bcachefs is acht jaar oud en probeert helemaal geen nieuwe standaard te worden. Het kiest andere afwegingen dan de bestaande bestandssystemen en is slechts een alternatief.

Die strip werkt niet als je hem plaatst bij ieder nieuw stuk software.

[Seraoh]

Hoef de URL niet eens te openen om te weten welke comic _dit_ is...

[matty___]

ZFS is verre van perfect maar stabiel en betrouwbaar is het wel.

[gibsonsg400]

Een goede ontwikkeling, wat ik alleen een beejte mis is wat NLnet nu verwacht welke richting de ontwikkeling opgaat.

Maar goed nieuws.

[ahbart]

De Nederlandste stichting NLnet

Interessant Dat is de meest Nederlandse stichting?
@IdrizV

[Reactie gewijzigd door ahbart op 22 juli 2024 18:04]

[IdrizV]

Voor het geval de afkorting niet duidelijk was
Aangepast!

[ari2asem]

heeft dit fs ook de beperkingen van zfs? dat je jouw storage pool niet uitbreiden met extra hdd erbij? en dat je dus 2de pool moet gaan inrichten?

want dit is het GROOTSTE nadeel van zfs

[Tuxwielder]

Euh, dat kan ZFS wel (per aantal disks dat je je in een VDEV hebt natuurlijk).

[ari2asem]

zfs kun je niet expanden zoals dat in hardwarematige raid-6 gaat. dit is wat ik bedoelde.

stel: je hebt een vdev met 4 hdd en dit wil je met 3 schijven uitbreiden zodat je in totaal een vdev met 7 schijven. dit gaat dus niet.
je kunt wel een andere vdev met 3 hdd maken.
dus dan heb je 2 vdev's, niet hetgeen wat ik bedoelde

[Reactie gewijzigd door ari2asem op 22 juli 2024 18:04]