Het BTRFS ervaringen topic

[EJPostema]

Ik zit er al geruime tijd over na te denken om een htpc/nas te kopen en na veel research ben ik er uit.

Ik ga een ubuntu server draaien met BTRFS. Op tweakers is hier nog vrij weinig info te vinden en ik vroeg me dus af of er interesse voor is om een 'BTRFS ervaringen topic' of 'het grote btrfs topic' te openen.

ik ga mijn systeem waarschijnlijk ergens in april kopen en inelkaar zetten en met wat hulp wil ik best een dergelijk topic openen (heb zoiets nog nooit gedaan, dus wat hulp zou graag welkom zijn)

Ik ben me er uiteraard van bewust dat BTRFS nog niet zover is als ZFS, maar voor mij bied het persoonlijk een aantal voordelen en de data die erop komt is niet heel erg als dat een keer verdwijnt. Het lijkt me gewoon leuk er wat mee te kloten en die ervaringen te delen

[Ultraman]

Ik heb het in de zomer van 2012 een kans gegeven. Dat was ervaring genoeg om er voorlopig nog van weg te blijven. Het was niet sneller dan ext4, de tools vond ik nog erg onhandig aanvoelen en het was duidelijk nog niet klaar. Ook snapshots vond ik een stuk minder handig werken dan op ZFS.
Uiteindelijk heb ik er zelfs dataverlies mee ervaren tijdens een experiment, dus ik wacht het nog minstens een jaar af voordat ik weer een poging doe.

Het is wel een leuk filesystem om mee te spelen, en ik verwacht dat het ook wel toekomst heeft. De tools zullen vast verbeteren of iemand schrijft er een handige wrapper voor.
Dit klinkt vast uitermate kritisch in de oren voor iemand die er enthousiast over is. Begrijp mij niet verkeerd, ik zie btrfs graag slagen. Maar er is nog zeker werk voor de boeg. Het wordt echt interessant zodra het betrouwbaar is, de self-healing goed werkt en je leuke dingen kunt doen met de snapshots zoals boot-environments (zoals in Solaris en FreeBSD) op een "simpele" manier. Het kan nu ook, maar het is nog allemaal handwerk voor zover mij bekend is.
Mocht er in de laatste paar maanden wat veranderd zijn, dan wordt ik graag verbeterd

[EJPostema]

Ja, het is zeker nog niet perfect. Maar ik ben vooral benieuwd, zal er vanaf april wel wat mee gaan kloten. Als er echt dingen verbeterd zijn dan hoor je het wel

[Robinski]

Ik ben zelf aan het orrienteren op een nieuwe opslag omgeving voor thuis.

Op het moment heb ik met Windows 2003 en DFS een en ander uitgevoerd zodat bestanden op drie machines staan (waarvan twee thuis en een bij ouders) zodat als een disk het begeeft ik niet gelijk alles kwijt ben (daarnaast heb ik voor heel belangrijke dingen backups naar cloud of andere disks).

Ik wil echter naar een simpelere oplossing op basis van (software)RAID zodat het aantal machines naar totaal twee gereduceerd kan worden.

Op dit moment ben ik mij aan het orrienteren op een eventueel bestandsysteem (en bijbehorend OS) om alles op te baseren.

Ik ben derhalve zeer benieuwd naar de robuustheid van BTRFS, mede omdat er daarnaast volgens mij maar twee 'alternatieven' zijn en wel ZFS en Windows Storage Spaces.

[EJPostema]

Robinski schreef op vrijdag 22 maart 2013 @ 15:32:
Ik ben zelf aan het orrienteren op een nieuwe opslag omgeving voor thuis.

Op het moment heb ik met Windows 2003 en DFS een en ander uitgevoerd zodat bestanden op drie machines staan (waarvan twee thuis en een bij ouders) zodat als een disk het begeeft ik niet gelijk alles kwijt ben (daarnaast heb ik voor heel belangrijke dingen backups naar cloud of andere disks).

Ik wil echter naar een simpelere oplossing op basis van (software)RAID zodat het aantal machines naar totaal twee gereduceerd kan worden.

Op dit moment ben ik mij aan het orrienteren op een eventueel bestandsysteem (en bijbehorend OS) om alles op te baseren.

Ik ben derhalve zeer benieuwd naar de robuustheid van BTRFS, mede omdat er daarnaast volgens mij maar twee 'alternatieven' zijn en wel ZFS en Windows Storage Spaces.

Als je op internet zoekt dan zijn er best veel mensen die BTRFS zonder problemen draaien.
BTRFS is echter nog niet zover als ZFS. Dus wil je echt safe zitten zou ik voor ZSF gaan. Of de kritieke data ook op een andere locatie opslaan.

[EJPostema]

ik heb het nu een paar weken draaien en het draait allemaal prima . Nog niet heel erg mee geëxperimenteerd maar vooralsnog wel nice

[Q]

ZFS on Linux is nu stable en zou op dit moment mijn eerste keuze zijn.

[Anoniem: 321370]

Ik vind het grootste nadeel van ZFS ten opzichte van BTRFS dat je de pool niet met disks kan uitbreiden. Data pool van 4disks blijven 4disks. Je kan niet achteraf er nog 2 bij hangen zodat je pool groter word

[ Voor 19% gewijzigd door Anoniem: 321370 op 11-02-2014 13:13 ]

[Anoniem: 15758]

Dat kan wel.

# enkele disk toevoegen
zpool add tank gpt/disk5

# nieuwe vdev toevoegen
zpool add tank raidz2 gpt/disk5 gpt/disk6 gpt/disk7 gpt/disk8

Wat niet kan is een raidz vdev horizontaal uitbreiden met een extra disk; wat wel kan is verticaal uitbreiden of horizontaal met RAID0 en mirror uitbreiden. Kortom, alles kan, behalve een 4-disk RAID-Z een 5-disk RAID-Z maken bijvoorbeeld.

[Q]

Anoniem: 15758 schreef op dinsdag 11 februari 2014 @ 17:33:
Dat kan wel.

Dus dat kan niet.

Je weet dondersgoed wat mensen als DigitalTux willen.

Wat mensen willen is gewoon losse diskjes toevoegen en hun array uitbreiden naar behoefte. Maar dat kan helemaal niet met ZFS en dat is super jammer voor consumenten.

Je bent gedwongen om een nieuwe vdev met eigen parity disks toe te voegen, dus dat kost je zo 2 disks (RAIDZ2) die je anders als opslag er bij had gekregen.

Het punt is voornamelijk dat BTRFS niet klaar is voor productie en dat duurt nog wel een jaar of wat. ZFS is dat wel. Dus ZFS is de veiligste & beste keuze voor je data, maar ook de 'duurste'.

[ Voor 18% gewijzigd door Q op 11-02-2014 18:59 ]

[sphere]

Een moderator zou er eens wat van moeten zeggen. Oh wacht...

[LukyLX]

Anoniem: 321370 schreef op dinsdag 11 februari 2014 @ 13:10:
Ik vind het grootste nadeel van ZFS ten opzichte van BTRFS dat je de pool niet met disks kan uitbreiden. Data pool van 4disks blijven 4disks. Je kan niet achteraf er nog 2 bij hangen zodat je pool groter word

Dit vindt ik voor de gemiddelde 'hobby' gebruiker inderdaad ook een behoorlijk voordeel van BTRFS tov ZFS.
Zelf gebruik ik nu zo'n 2 jaar BTRFS en mijn ervaringen ermee zijn bijzonder goed. Ik gebruikte hiervoor ext4 op LVM en dat was een behoorlijke ramp.
Ik gebruik nu slechts een redundant profiel voor metadata (RAID1), voor data gebruik ik gewoon het single profiel, dus geen redundantie.
Mijn insteek hierbij is om een bestandssysteem te hebben dat in ieder geval nagenoeg altijd consistent is (vandaar dat metadata in RAID1 staat) en voor lief te nemen dat er eventueel een blokje data corrupt kan raken. Dit is te monitoren door scrubs met enige regelmaat uit te (laten) voeren en de SMART gegevens in de gaten te (laten) houden. In verreweg de meeste gevallen zul je ver voordat een harde schijf overlijdt al signalen van onvolkomenheden zien in de SMART gegevens (en vaak is er dan nog geen data verloren) en de betreffende schijf daarom vervangen. Dit is volgens mij niet anders dan wanneer je een RAID5/6 profiel zou hebben.
Daarnaast is natuurlijk het maken van een dagelijkse backup van de meest belangrijke gegevens onontbeerlijk, ook dit is niet anders dan voor RAID5/6 profielen. De overige (voornamelijk multimedia) gegevens worden bij mij zo af en toe uitgewisseld met vrienden welke een soortgelijke configuratie hebben waardoor zelfs voor minder belangrijke gegevens geldt dat er eenvoudig weer aan te komen is in noodgevallen.

Ik ben zeer tevreden over de stabiliteit van het bestandssysteem; tot op heden ben ik nog geen gegevens verloren en ik heb ondertussen al heel wat (online) wijzigingen aan mijn volume toegebracht. Zo ben ik begonnen met een enkele 2TB schijf en heb hier vervolgens een 2e, 3e en vierde 2TB aan toegevoegd waarna een 3TB schijf volgde. Vervolgens heb ik de 2TB schijven gaandeweg vervangen door 3 4TB exemplaren, dit alles online. Ik zit nu dus op een volume van 15TB.
De stabiliteit van de tooling liet tot vorig jaar nog wel iets te wensen over (defragmentatie of conversie van raid profiel die vast leek te lopen) maar ook hier zijn het afgelopen jaar grote stappen gemaakt en bovendien had dit geen gevolgen voor het bestandssysteem zelf.

Als 'hobby' gebruiker geloof ik eigenlijk ook niet zo in de restricties die je jezelf oplegt met RAID5 / RAID6 / RAID-Z / RAID-Z2 doordat het slechts werkt met schijven van gelijke grootte. Wanneer je dan je volume wilt uitbreiden, zal dit gepaard gaan met een flinke investering. Ook is de kans dat schijven gelijktijdig aan het eind van hun leven komen een stuk groter (bij gelijke MTBF) dan wanneer je gaandeweg uitbreidt. Doordat je met een single profiel voor data, schijven van verschillende grootte kunt gebruiken, kun je bij het gaandeweg uitbreiden bovendien optimaal gebruik maken van de voortschrijdende capaciteitstoename van harde schijven.
Tegenwoordig kun je met BTRFS het profiel voor data online converteren naar RAID5 of RAID6 (of terug naar single) mocht je dat willen . Op dit moment wordt dit nog als experimenteel gezien en werkt de scrub nog niet, maar hier lijkt in de nabije toekomst ook verbetering in te komen.

Ik vind ZFS en BTRFS beide ontzettend goede bestandssystemen, maar de flexibiliteit van BTRFS en standaard ondersteuning onder linux spreken mij meer aan dan de absolute betrouwbaarheid van ZFS (met raidz / raidz2).

[Q]

LukyLX schreef op woensdag 12 februari 2014 @ 12:30:
[...]
In verreweg de meeste gevallen zul je ver voordat een harde schijf overlijdt al signalen van onvolkomenheden zien in de SMART gegevens (en vaak is er dan nog geen data verloren) en de betreffende schijf daarom vervangen.

Mijn ervaring is totaal anders en ook het onderzoek van Google laat zien dat SMART waarden slechts een beperkte voorspellende waarde hebben.

Ik heb vaak genoeg gehad dat disks zonder enige SMART waarschuwing plotseling uitvielen.

SMART kan je voortijdig waarschuwen, dus het is zeker waardevol, maar biedt vaak niet de advanced-warning die je in staat zal stellen om je data tijdig te verplaatsen.

Ik zit nu dus op een volume van 15TB.

Zonder Parity RAID dus BTRFS equivalent van RAID 5 of RAID 6?

You like living dangerously...

[LukyLX]

Q schreef op woensdag 12 februari 2014 @ 19:01:
[...]
Mijn ervaring is totaal anders en ook het onderzoek van Google laat zien dat SMART waarden slechts een beperkte voorspellende waarde hebben.

Ik heb vaak genoeg gehad dat disks zonder enige SMART waarschuwing plotseling uitvielen.

SMART kan je voortijdig waarschuwen, dus het is zeker waardevol, maar biedt vaak niet de advanced-warning die je in staat zal stellen om je data tijdig te verplaatsen.

Bedankt voor deze nuttige toevoeging!

Ik had mijn insteek gebaseerd op mijn eigen ervaring met harde schijven uit het verleden. Ik heb er ondertussen al heel wat gezien en ook zien sneuvelen, maar eigenlijk altijd wel nadat SMART dit op één of andere manier kenbaar maakte. Het blijkt maar weer dat resultaten uit het verleden geen garantie bieden voor de toekomst.

Ik heb daarom net het betreffende onderzoek van Google (http://research.google.com/archive/disk_failures.pdf ) maar eens doorgebladerd en moet inderdaad concluderen dat het wellicht toch verstandig is om eens te kijken naar een veiliger alternatief voor mijn 'single' profiel.
Omdat mijn ervaringen met BTRFS toch onverminderd goed zijn, denk ik dat ik de implementatie van parity logging en scrub support nog even afwacht die er aan zitten te komen. Daarna zal ik waarschijnlijk (online) overstappen op een raid 5 profiel met een extra schijfje erbij.
Het leuke bij BTRFS is wel dat de schijven ook dan niet van dezelfde grootte hoeven te zijn en parity gewoon verdeeld wordt over fysiek beschikbare ruimte. Wanneer de 3TB schijf vol is en dus een schijf minder beschikbaar is, wordt gebruik gemaakt van de overgebleven ruimte op de overige schijven. Even snel gerekend kom ik dan met een extra 4TB schijfje (dus totaal 4x4TB + 3TB) op een beschikbare ruimte uit van 15TB (4*3+3*1), dus precies wat ik nu ook heb :-).
Eventueel is een overstap naar RAID6 daarna ook snel gemaakt na toevoeging van weer een extra schijfje.

[Q]

En dat is dus precies een illustratie waarom BTRFS voor consumenten een betere optie is dan ZFS omdat je veel flexibeler bent en performance niet uitmaakt.

Zodra BTRFS met alle gewenste features stable is, is er geen enkele reden meer voor thuis-gebruikers om ZFS boven BTRFS te verkiezen. Niets ten kwade van ZFS, maar voor consumenten is het niet dynamisch kunnen uitbreiden van je array gewoon een serieus obstakel.

Helaas zal dat nog wel een jaar of wat gaan duren.

Bij ZFS moet je trouwens ook altijd 2^x drives + <aantal parity drives> aan disks in een vdev stoppen want anders stort je performance in en belangrijker: verlies je significante opslagcapaciteit.

Naar mijn weten heeft BTRFS hier helemaal geen last van. Dit is ook iets wat consumenten dus veel meer flexibiliteit geeft. Gewoon capaciteit toevoegen wanneer je er aan toe bent, zonder overhead.

Ik zal zelf wel aan ZFS moeten want op dit moment is er geen alternatief voor ZFS op Linux met dezelfde features + stable.

[ Voor 15% gewijzigd door Q op 13-02-2014 08:43 ]

[Ultraman]

Ik laat er nog wel minstens een jaar of twee overheen gaan voordat ik het ook maar ga wagen om dingen die ik nu op ZFS heb staan aan btrfs toe te vertrouwen. Flexibiliteit is hartstikke mooi, maar de reden dat ik voor ZFS heb gekozen is zekerheid en die kan btrfs voorlopig nog niet geven. Misschien over 2 jaar, misschien eerder/later, we zullen wel zien.
Mijn standpunt van anderhalf jaar geleden is nog onveranderd: de toekomst op Linux is btrfs en ik zie het graag slagen, maar het is er nog niet en er is nog veel werk te verrichten.

Wat ik wel ga doen is, anderhalf jaar na mijn eerdere serieuze poging, btrfs weer eens proberen. Ik ben van plan eens Fedora 20 (of Debian unstable) op een verse SSD te installeren en als filesystem btrfs te gebruiken. Hopelijk ook zonder ext4 /boot als dat gaat, maar dat wordt even spelen met voor-/nadelen en beschikbare opties.
Ik ben benieuwd hoeveel verder het is gekomen en hoe het op dit moment werkt.

Ik wil graag gebruik maken van de features zoals snapshots en transparant compression.
Voorheen moest ik vooral niks van de speciale features gebruiken en btrfs behandelen alsof het ext4 was anders ging of mijn data toedeledokie of de performance stortte na een periode in. Zeer benieuwd of dat inmiddels is verholpen.

Nog tuning tips voor een SSD? Om precies te zijn een Samsung 840 EVO 250GB.
Ik zat zelf te denken aan mount opties: discard, space_cache, ssd ; en natuurlijk de I/O scheduler naar deadline of noop. Waarbij ik ook compress=lzo wil gaan toepassen in veel gevallen of ik wacht op LZ4 compressie zodra dat beschikbaar komt en een beetje goed werkt, want dat is nou eenmaal flink sneller qua decompressie.

[edit]
Ik zie op de btrfs wiki trouwens het volgende staan:

Coming in v3.14 (highlights or user visible changes)

• optional incompat disk format improvemnt aiming speedup, removing file hole representation, named no-hole

Hmm... Wellicht even wachten op kernel 3.14?

[ Voor 14% gewijzigd door Ultraman op 15-02-2014 11:42 ]

[Q]

Laat er geen twijfel over bestaan, ZFS is het beste wat nu beschikbaar is. Maar ZFS heeft voldoende fundamentele nadelen om uit te kijken naar alternatieven en daarom is jouw ervaring ook interessant.

[Anoniem: 321370]

Wat ik me afvraag, is er bij btrfs in singel disk mode een vorm van parity van de disks. Word alle data van van een disk verdeeld over de rest van de disks? of heb je dan nog een vorm van raid1,5,6,10 nodig onder de btrfs om parity te krijgen. Als dat zo is, dan moet je dus als nog een 4x3TB set bouwen in plaats van bijvoorbeeld 3x1TB en 1x3TB samen.

[Ultraman]

Als je met "parity" redundantie bedoeld: Ja, dan heb je ten minste een mirror nodig of een hoger btrfs RAID level. Maar volgens mij is hier nog niet alles af.

Btw. Ik draai nu een week of twee btrfs op mijn desktop onder Fedora. Single disk SSD en ik ben tot nu toe nog geen data kwijt. Dus er is zeker vooruitgang geboekt, want anderhalf jaar geleden had ik het nu al stuk gekregen.

[_JGC_]

Bij archlinux gebruiken we btrfs op de buildserver, tot nu toe hebben we dat ook nog niet heel erg stuk gekregen. Wel zo nu en dan enge meldingen in dmesg, maar is alweer tijdje terug dat ik die heb gezien.

We gebruiken vnml btrfs vanwege subvolumes en snapshots voor het bouwen in chroots. Voorheen gebruikten we ext4 en werd er gewerkt op een kopie van een chroot, maar als je een aantal van die dingen hebt en dan ook een paar ontwikkelaars die tegelijk gaan bouwen, ben je heel snel door je inodes heen.

[Anoniem: 321370]

Ultraman schreef op maandag 03 maart 2014 @ 11:08:
Als je met "parity" redundantie bedoeld: Ja, dan heb je ten minste een mirror nodig of een hoger btrfs RAID level. Maar volgens mij is hier nog niet alles af.

Btw. Ik draai nu een week of twee btrfs op mijn desktop onder Fedora. Single disk SSD en ik ben tot nu toe nog geen data kwijt. Dus er is zeker vooruitgang geboekt, want anderhalf jaar geleden had ik het nu al stuk gekregen.

Dus singel disk mode bij BTRFS is het zelfde als JBOD. Valt een disk weg dan ben je alleen die data kwijt. En je hebt geen snelheids winst omdat er geen striping plaats vind.

Ik denk dat ik dan toch voor 4x3TB raid5 ga en een disk gebruik voor parity. en later nog met 1 a 2 3TB disks uit zal breiden. 6x3TB in totaal waarvan dan 1 parity disk zal zijn. efectief dus 15 TB in tegestelling. RAID-6 is natuurlijk ook een optie, maar dan ben ik 2 disks kwijt aan parity en dan zit ik op 12TB tenopzichte van raid-5.

[ Voor 8% gewijzigd door Anoniem: 321370 op 03-03-2014 11:56 ]

[idef1x]

Ik krijg de indruk dat btrfs redelijk volwassen begint te worden als ik zo e.e.a. op internet lees hierover. Alleen in dit forum topic (of andere over btrfs) op tweakers gebeurd niet zoveel. Betekend dit dat het niet leeft onder de tweakers?

Afijn ik ben sinds kort op mijn laptop maar eens overgestapt van ext4 naar btrfs voornamelijk wegens de snapshot features. Nu heb ik op mijn Kubuntu 14.10 systeem een encrypted home (geen luks) in een btrfs subvolume (@home in ubuntu) en maak daar regelmatig een snapshot van (met de snapper tool die oorspronkelijk in OpenSuse te vinden was ). Werkt allemaal leuk en aardig, doch wanneer ik zeg 1 file wil terughalen uit een snapshot valt deze niet te bekijken in zowel snapper als wanneer ik de snapshot mount onder een andere directory (bijvoorbeeld : mount /dev/sda5 -o subvol=@home_snapshot /mnt)....beide geven een geencrypte filenaam en inhoud weer, dus dat schiet niet op.

De vraag is dan ook of iemand anders hier hier ervaring mee heeft of er ook tegenaangelopen is en hopelijk een oplossing weet? Het enige dat ik nu kan bedenken is uitloggen, gevolgd door de snapshot mounten onder /home ipv de huidige en dan de gewenste file ergens heen kopieren en dan weer terug de originele @home mounten onder /home....klinkt een beetje omslachtig, maar als het niet anders kan.....

edit: zal wel te warm hier zijn, want de oplossing is simpel bedacht ik me net: mount de snapshot en doe een "sudo ecryptfs-recover-private" en volg de aanwijzingen voor de juiste mounted directory

[ Voor 7% gewijzigd door idef1x op 17-02-2015 20:14 . Reden: te warm hier denk ik ;) ]

[Thralas]

Volgens mij heb je een eCryptfs-probleem (tenminste, dat gokken we maar even, je zegt niet wat je gebruikt), en heeft het verder niet bijzonder veel met btrfs te maken. Misschien iets voor een eigen topic?

Ik zou eens goed de manual van eCryptfs gaan doorlezen; ik heb er geen ervaring mee, maar gezien het feit dat eCryptfs een layer bovenop je filesystem is kun je daar het antwoord ongetwijfeld vinden.

Een alternatief is om over te stappen naar LUKS/dm-crypt (als je dat nog niet had overwogen). Dat versleutelt de boel net iets grondiger (lekt geen info via file metadata) en is daarnaast compleet transparant voor je filesystem, dus ook btrfs. Dan heb je ook iets aan o.a. de compression features van btrfs.

Betekend dit dat het niet leeft onder de tweakers?

Jawel, na een aantal maanden geleden enige tijd een rootfs op btrfs te hebben gedraaid met wat nare ervaringen tot gevolg (omstreeks ~v3.14) - denk aan kernel lockups (kwam door een bug mbt. compression) en een filesystem dat in stukken lag na een powercycle (#btrfs & btrfsck boden de oplossing) heb ik sinds vorige week de boel weer draaien op een raid1 volume icm. v3.19. Vooralsnog werkt dat allemaal prima.

[SanderH_]

Q schreef op donderdag 18 april 2013 @ 17:18:
ZFS on Linux is nu stable en zou op dit moment mijn eerste keuze zijn.

Waarom geen FreeNas of ZFSGuru als ik vragen mag? Ik ben al een tijdje aan het rondspeuren en beiden lijken mij wel een leuke afwisseling na X aantal jaar rondneuzen in mijn Linux shell. Het beheer wordt denk ik een stuk makkelijker met gelijk welk van deze 2 platformen. En indien een bepaalde plugin niet beschikbaar is / niet goed werkt kan je toch nog altijd zelf wat knutselen via CLI, of zie ik dat verkeerd?

Welke zaken mis je bijvoorbeeld bij die 2 die je wel bij ZFS on Linux kan krijgen?

[Thralas]

Welk punt probeer je te maken? Je betrekt er nu twee appliance-achtige oplossingen bij, dat is fundamenteel anders dan een 'kale' Linuxdistro of FreeBSD. Ik zie de relevantie van Linux in je vraag niet, je suggereert alsof die er wel is.

Ik heb geen GUI nodig om m'n filesystem te beheren, dus ik zie persoonlijk weinig heil in een systeem waar je ook nog eens de controle over je OS uit handen dient te geven. Voor de een is dat een voordeel, voor de ander een gruwelijk nadeel.

Om dan toch nog een ontopic-vergelijking te maken; hoewel btrfs bij lange na niet zo volwassen is als ZFS, lijkt het inmiddels toch best aardig te werken. Het zal nog een geruime tijd een afweging van voor- en nadelen van beide oplossingen blijven; feit is dat brfs onder Linux uiteindelijk 'wint' omdat het integreert op een manier die simpelweg onmogelijk is voor ZFS (losse modules door licensing, SPL ipv. native ingebed in de Linux kernel en userspace).

Vooralsnog lijkt er nog een duidelijke tweedeling te zijn; voor desktop use onder Linux heeft btrfs het reeds gewonnen; raid0/1 is (naar zeggen van de developers, zie ook mijn vorige post) aardig stabiel, zaken als systemd integreren er steeds dieper mee. Ik zie op desktopvlak weinig redenen om toch voor ZFS te kiezen.

Op servergebied (al dan niet als NAS) ligt dat anders, de raid5/6 modes van btrfs zijn pas sinds v3.19 fatsoenlijk te scrubben en rebuilden. Als beschikbaarheid een ding is en je hebt niet de mogelijkheid om je complete filesystem te backuppen zou ik daar vooralsnog vanaf blijven. Durf je dat wel aan, dan pik je mooi wat voordeeltjes tov. ZFS mee (flexibiliteit!), maar ik zou niet vreemd opkijken als het spontaan in duizend stukken breekt.

Je bevindt je overigens in een topic over btrfs

[Q]

Thralas schreef op dinsdag 17 februari 2015 @ 23:37:
Ik heb geen GUI nodig om m'n filesystem te beheren, dus ik zie persoonlijk weinig heil in een systeem waar je ook nog eens de controle over je OS uit handen dient te geven. Voor de een is dat een voordeel, voor de ander een gruwelijk nadeel.

Dat was het punt van mijn 2 jaar oude opmerking. Ik heb niets met FreeNAS of ZFSguru want ik beheer de boel prima met de command line en kan het systeem daardoor extreem kaal en stabiel houden.

[Freeaqingme]

Kickje...

Ik heb me van de week eens ingelezen in btrfs, moet zeggen dat ik de verbeteringen die in de afgelopen linux kernel versies hoopvol vindt. Indruk die ik krijg is dat de huidige featureset in principe klaar is voor productie, mits je niet al te grote raid-sets gebruikt.

Nog geen oplossing voor volumes van 100 Tb, maar als je geintresseerd bent in snapshotting en het kunnen versturen van filesystems van de ene host naar de andere host allicht al een prima fs.

Dus allemaal even Linux 4.1 bouwen, laatste versie van btrfs-tools installeren, en gaan

[vanaalten]

Ik ben zelf in december begonnen met ZFS, twee 6TB disken in mirror-configuratie (en een SSD voor boot & OS). En op zich werkte dat prima en wordt ZFS overal wel genoemd als superieur t.o.v. BTRFS, maar ik ben toch omgegaan naar BTRFS.

Debian 'Jessie' als OS op een NAS-only machine en ik wilde de boel zo 'schoon' mogelijk houden, geen 'vreemde' repositories - en daarom dus over op BTRFS. En dat ging eigenlijk heel probleemloos:
1) ZFS 1 disk van de mirror er uit halen;
2) die disk formatteren als BTRFS volume;
3) data van ZFS naar BTRFS kopieeren;
4) ZFS systeem helemaal off-line halen en die tweede disk toevoegen aan het BTRFS systeem als mirror.
5) ZFS-repository uit m'n apt sources.list.

En sindsdien draait het alweer een maand of twee zonder problemen. Voor m'n gevoel is BTRFS in elk geval beter geintegreerd in het OS: automatisch mounten na boot was een hoop gedoe bij ZFS, nu is het enkel een regeltje toevoegen in /etc/fstab.
Leuke bijkomstigheid: een BTRFS 'scrub' is een paar uurtjes sneller dan een ZFS scrub.

Edit: da's dus met linux 3.16 en btrfs-tools 3.17 - je hoeft dus niet persé de laatste versie te hebben voor een stabiel systeem.

[ Voor 6% gewijzigd door vanaalten op 29-06-2015 18:30 ]

[Thralas]

vanaalten schreef op maandag 29 juni 2015 @ 18:29:
Edit: da's dus met linux 3.16 en btrfs-tools 3.17 - je hoeft dus niet persé de laatste versie te hebben voor een stabiel systeem.

RAID01/single modes zouden aardig moeten werken onder v3.16, maar RAID56 kun je wel vergeten (voor zover je dat uberhaupt wilt draaien).

[Pantagruel]

Thralas schreef op maandag 29 juni 2015 @ 19:42:
[...]


RAID01/single modes zouden aardig moeten werken onder v3.16, maar RAID56 kun je wel vergeten (voor zover je dat uberhaupt wilt draaien).

Een lekkere spuit 11 reactie, ik weet 't, de btrfs thread is nogal een weeskindje.

Mijn vraag is: heb je t eigenlijk wel eens geprobeerd R5/6?

Zelf draai ik een test bak draaien (Ubuntu 14.04LTS) dus alle data mag verloren gaan.

code:

root@Buttercup:/scripts# uname -va
Linux Buttercup 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

code:

root@Buttercup:/scripts# btrfs version
Btrfs v3.12

Ik weet t enigszins bejaard tov de 15.x desktop release.

De data staat in RAID5 verband en de meta-data in RAID1

code:

root@Buttercup:/scripts# ./btrfs-space
Data, RAID5: total=134.00GiB, used=125.58GiB
System, RAID1: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=167.44MiB

Vanavond er 2 disks extra bij gehangen (was 6 x 320 GB SATA, nu 1x 300 GB + 6 x 320 GB + 1x 400 GB SATA in R5) en de balance van de ca. 126 GB aan data was snel gedaan. De daarop volgende scrub deed er ca. 30 min over.

Vooralsnog geen problemen gehad ondanks dat de array al 5x zijn volledige capaciteit heeft bereikt en gewist is geweest.

[Borromini]

vanaalten schreef op maandag 29 juni 2015 @ 18:29:
Ik ben zelf in december begonnen met ZFS, twee 6TB disken in mirror-configuratie (en een SSD voor boot & OS). En op zich werkte dat prima en wordt ZFS overal wel genoemd als superieur t.o.v. BTRFS, maar ik ben toch omgegaan naar BTRFS.

Debian 'Jessie' als OS op een NAS-only machine en ik wilde de boel zo 'schoon' mogelijk houden, geen 'vreemde' repositories - en daarom dus over op BTRFS. En dat ging eigenlijk heel probleemloos:
1) ZFS 1 disk van de mirror er uit halen;
2) die disk formatteren als BTRFS volume;
3) data van ZFS naar BTRFS kopieeren;
4) ZFS systeem helemaal off-line halen en die tweede disk toevoegen aan het BTRFS systeem als mirror.
5) ZFS-repository uit m'n apt sources.list.

En sindsdien draait het alweer een maand of twee zonder problemen. Voor m'n gevoel is BTRFS in elk geval beter geintegreerd in het OS: automatisch mounten na boot was een hoop gedoe bij ZFS, nu is het enkel een regeltje toevoegen in /etc/fstab.
Leuke bijkomstigheid: een BTRFS 'scrub' is een paar uurtjes sneller dan een ZFS scrub.

Edit: da's dus met linux 3.16 en btrfs-tools 3.17 - je hoeft dus niet persé de laatste versie te hebben voor een stabiel systeem.

Hoe is je ervaring momenteel? Ik compileer momenteel zelf nog m'n ZFS pakketten (nu ZoL eindelijk jessie ondersteunt met hun repo moet ik misschien maar es switchen), maar op lange termijn lijkt BTRFS mij wel interessanter, Oracle kennende gaan ze geen sikkepit meer aan de opensource-versie toevoegen.

[Thralas]

Pantagruel schreef op dinsdag 22 september 2015 @ 00:10:
Mijn vraag is: heb je t eigenlijk wel eens geprobeerd R5/6?

Nee; althans, niet op een kernel pre-3.19. RAID56 rebuild en scrub support zit er pas in vanaf v3.19 namelijk (bron), dus als je filesystem aan stukken ligt heb je pech.

Los daarvan draai je btrfs op een kernel van meer dan anderhalf jaar oud; daar hebben de developers ook wat over te zeggen:

The Btrfs code base is under heavy development. Every effort is being made to keep it stable and fast. Due to the fast development speed, the state of development of the filesystem improves noticeably with every new Linux version, so it's recommended to run the most modern kernel possible.

v3.12 stamt nog uit de tijd dat ik meermaals een filesystem had dat aan stukken lag na een unclean shutdown. Ik betwijfel zelfs of de fsck uit de tools behorende tot v3.12 uberhaupt iets doet.

Zelfs voor testdata is je setup wel erg experimenteel.

That said, de laatste paar maanden zijn m'n ervaringen met single-disk btrfs prima (Arch, dus ~latest stable kernels). Eenmalig een gekkigheidje met blocks die op zijn zonder dat een rebalance helpt, maar een reboot werkte daarentegen weer prima. En ik ben onverminderd blij met het makkelijke snapshotten; maakt backuppen een fluitje van een cent.

[Pantagruel]

Thralas schreef op dinsdag 22 september 2015 @ 17:45:
[...]


Nee; althans, niet op een kernel pre-3.19. RAID56 rebuild en scrub support zit er pas in vanaf v3.19 namelijk (bron), dus als je filesystem aan stukken ligt heb je pech.

Los daarvan draai je btrfs op een kernel van meer dan anderhalf jaar oud; daar hebben de developers ook wat over te zeggen:


[...]


v3.12 stamt nog uit de tijd dat ik meermaals een filesystem had dat aan stukken lag na een unclean shutdown. Ik betwijfel zelfs of de fsck uit de tools behorende tot v3.12 uberhaupt iets doet.

Zelfs voor testdata is je setup wel erg experimenteel.

Ach een beetje onder t mom van "If it ain't broke, don't fix it", maar idd is de kernel etc wel aftands aan t worden dus een update is wel aan de orde:

code:

user@Buttercup:~$ uname -av
Linux Buttercup 3.19.0-28-generic #30~14.04.1-Ubuntu SMP Tue Sep 1 09:32:55 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
user@Buttercup:~$ btrfs version
btrfs-progs v4.2.1

Zo toen waren we weer bij de tijd.

That said, de laatste paar maanden zijn m'n ervaringen met single-disk btrfs prima (Arch, dus ~latest stable kernels). Eenmalig een gekkigheidje met blocks die op zijn zonder dat een rebalance helpt, maar een reboot werkte daarentegen weer prima. En ik ben onverminderd blij met het makkelijke snapshotten; maakt backuppen een fluitje van een cent.

Doe je dingen als snapshots e.d. vanaf de cli of gebruik je een gui a la snapper?

[idef1x]

Als je dan toch aan het updaten gaat, waarom dan niet gelijk de kernel naar 4.2.1? Dat wordt wel geadviseerd wanneer je met btrfs bezig bent. Toevallig gisteren nog nagevraagd in de mailinglist.
Overigens lijkt raid5 inmiddels ook bruikbaar,want ik vind niets meer terug over instabiliteit/onbruikbaaheid hiervan. Raid6 is nog een ander verhaal

En snapshots maak ik gewoon met de commandline.snapper lijkt leuk,maar na een tijdje toch maar de btrfs progs zelf gaan gebruiken. Ter lering ende vermaak en heb meer controle (vind ik) over wanneer exact snapshots worden gemaakt,hoe ze heten en waar geplaatst. Kan vast met snapper ook allemaal,maar toch

[ Voor 30% gewijzigd door idef1x op 25-09-2015 14:24 ]

[Thralas]

Ik heb ook even gespeeld met snapper, maar momenteel doe ik het ook allemaal handmatig. M'n laptop backup ik naar een externe drive, snapper past daar voor m'n gevoel niet echt handig bij.

Wat wel weer vervelend is aan enkel cli is dat je expliciet snapshot parents voor incrementals moet opgeven, en dat dat niet iets is dat btrfs-utils voor je kan uitzoeken (als je een snapshot van het ene naar het andere fs verplaatst).

[idef1x]

Hangt ervan af hoe je het bekijkt lijkt me? btrfs utils weet toch niet of je een incremental snapshot wil tussen snapshot 4 en 5 of tussen 1 en 5? Of ik begrijp niet wat je bedoeld?

[Thralas]

Klopt helemaal. Maar in het simpelste scenario is 'het vorige snapshot' altijd de parent.

Of, beetje zoals git werkt, 'move snapshot X naar destination, en kijk maar wat destination al heeft om het zo efficient mogelijk te doen'.

[idef1x]

Heb het zelf nog niet geprobeerd, maar zou "btrfs send -c <clone-src>" niet doen wat je wil? Als ik zo de help ervan lees:

It is allowed to omit the
'-p <parent>' option when '-c <clone-src>' options are given, in
which case 'btrfs send' will determine a suitable parent among the
clone sources itself.

zie : btrfs send --help

[A1AD]

Leuk topic! Ik ben op mijn werk laptop nu ook over naar BTRFS op LUKS (arch).

Ik ben nu aan het uitzoeken waarvoor ik de snapshots ga gebruiken. Pacman pre/post, snapshot bij succesvol starten, home subvol met timer... Send / receive naar usb hdd.

Ik ben er echt niet uit. Hoe ziet jullie root-btrfs er uit? En waarvoor gebruiken jullie de snapshots?

Kwestie van wat leven in het topic te blazen

[vanaalten]

Ik gebruik echt maar heel weinig van de mogelijkheden. Heb 1 SSD met EXT4 als boot & root van het systeem en 2 harde schijven van elk 6TB als btrfs-mirror, opslag voor m'n films & series.

Het staat wel op het wensenlijstje om eens naar snapshots te kijken, voor voornamelijk 1 reden: als er op m'n windows-machine ransomware binnenkomt die via Samba m'n films/series zou gaan versleutelen. Zou dan toch leuk zijn als het een kwestie is van een snapshot terugzetten om de schade te herstellen.

Maar, tijd enzo.

[EJPostema]

vanaalten schreef op woensdag 03 februari 2016 @ 22:44:
Ik gebruik echt maar heel weinig van de mogelijkheden. Heb 1 SSD met EXT4 als boot & root van het systeem en 2 harde schijven van elk 6TB als btrfs-mirror, opslag voor m'n films & series.

Het staat wel op het wensenlijstje om eens naar snapshots te kijken, voor voornamelijk 1 reden: als er op m'n windows-machine ransomware binnenkomt die via Samba m'n films/series zou gaan versleutelen. Zou dan toch leuk zijn als het een kwestie is van een snapshot terugzetten om de schade te herstellen.

Maar, tijd enzo.

Zelfde hier. Heb een ubuntu server staan, die op een usb stick draait. De echte opslag zijn een aantal harde schijven met een btrfs filesysteem. Heb toen voor btrfs gekozen omdat ik me er wat in wilde verdiepen (nooit gedaan) en omdat het makkelijk schaalbaar is. Maar het prutsen met de server doe ik echt bijna nooit meer en als ik het doe dan meer met wat nieuwe software oid.

Draait overigens 24/7 zonder problemen

[idef1x]

A1AD schreef op woensdag 03 februari 2016 @ 22:34:
Ik ben er echt niet uit. Hoe ziet jullie root-btrfs er uit? En waarvoor gebruiken jullie de snapshots?

Snapshots voornamelijk voor roll-backs voor het geval dat een upgrade niet goed/zoals gewenst gaat: snapshot maken voor de upgrade, upgraden etc...

Mijn NAS draait overigens Ubuntu met ZFS nu totdat RAID5/6 productierijp is, maar daar gebruik ik snapshots ook als backup door deze te sturen naar mijn backup NAS (ook zfs nu) en eventueel rollback (van een virtuele machine bijvoorbeeld die daarop draait).

[EJPostema]

Bedoel je raid 5/6 op een btrfs systeem? Heb je maar niet zo in verdiept, maar zag er toen der tijd niet echt de meerwaarde van...

De standaard raid in btrfs biedt toch precies hetzelfde in de praktijk?

[A1AD]

EJPostema schreef op vrijdag 05 februari 2016 @ 14:24:
Bedoel je raid 5/6 op een btrfs systeem? Heb je maar niet zo in verdiept, maar zag er toen der tijd niet echt de meerwaarde van...

De standaard raid in btrfs biedt toch precies hetzelfde in de praktijk?

Wat? Ik snap met de beste bedoeling echt niets van wat je zegt

[EJPostema]

Haha, was @idef1x gericht

[idef1x]

Ja raid5/6 in btrfs. Die is nog niet echt productierijp.
Wat versta jij onder "standaard" raid? raid0 en 1 (en varianten hierop) zijn prima te gebruiken met brtrfs, maar voel er niet veel voor om 50% van mijn capaciteit op te geven voor redundantie. Daarbij komt dat ik met raid6 (raidz2 genaamd in zfs) 2 willekeurige disks kan verliezen zonder schade en bij een raid1 opstelling niet.

[EJPostema]

idef1x schreef op dinsdag 09 februari 2016 @ 13:44:
Ja raid5/6 in btrfs. Die is nog niet echt productierijp.
Wat versta jij onder "standaard" raid? raid0 en 1 (en varianten hierop) zijn prima te gebruiken met brtrfs, maar voel er niet veel voor om 50% van mijn capaciteit op te geven voor redundantie. Daarbij komt dat ik met raid6 (raidz2 genaamd in zfs) 2 willekeurige disks kan verliezen zonder schade en bij een raid1 opstelling niet.

Zoals ik het heb begrepen, al moet ik toegeven niet echt op de hoogte te zijn, is standaard btrfs de metadata redundant (raid 1) en alle overige data wordt gesplit over alle schijven, dus soort van raid 0.

Dit is in praktijk volgens mij hetzelfde als RAID 5 (iig bij btrfs). Bij RAID 6 heb inderdaad een voordeel dat er nog een schijf extra kapot kan gaan

[idef1x]

Nope...de metadata is wel gemirrored standaard, maar je data dus niet. Dus valt zeg 1 disk uit van een 2 disk setup, ben je gewoon je data kwijt. Dat ze de metadata mirroren is omdat als je metadata stuk is je alles kwijt zou zijn, terwijl als je data stuk is je dat wellicht nog met een scrub kan repareren of dan tenminste je kan achterhalen welke bestanden stuk zijn. Maar fysiek 1 disk stuk, dan is het einde oefening.

Dat is tenminste hoe ik hun verhaal op de wiki interperteer

Bij raid 5 (minimaal 3 disks) kun je 1 willekeurige disk verliezen zonder problemen

[EJPostema]

hmm idd ja. Ik dacht dat je mbv je metadata je dataverlies kan rebuilden na een disk failure.
Maar nu ik het zo lees heb je inderdaad gelijk

[Kortfragje]

Iemand recente ervaringen met btrfs? Ik begreep dat Raid 5/6 scrubs en replace nu in de 3.19 kernel zitten (8 februari). Dus wellicht is het nu meer productie rijp?

[Q]

File systems moet je altijd eerst een jaar laten rijpen na de laatste features zijn toegevoegd.
Net als met oude kaas en wijn.

[Thralas]

Kortfragje schreef op vrijdag 12 februari 2016 @ 15:59:
Iemand recente ervaringen met btrfs? Ik begreep dat Raid 5/6 scrubs en replace nu in de 3.19 kernel zitten (8 februari). Dus wellicht is het nu meer productie rijp?

We zitten inmiddels op v4.4, kernel v3.19 is al een jaar oud.

Q schreef op vrijdag 12 februari 2016 @ 19:20:
File systems moet je altijd eerst een jaar laten rijpen na de laatste features zijn toegevoegd.
Net als met oude kaas en wijn.

Komt dat even goed uit

[lordfragger]

Kortfragje schreef op vrijdag 12 februari 2016 @ 15:59:
Iemand recente ervaringen met btrfs? Ik begreep dat Raid 5/6 scrubs en replace nu in de 3.19 kernel zitten (8 februari). Dus wellicht is het nu meer productie rijp?

Er zijn nog grote problemen met rebalance voor een deel van de gebruikers. Heb je er last van duurt een rebalance weken tot maanden.

Ook zijn quota nog onbruikbaar (is btrfs algemeen) en zijn er problemen met grote aantallen snapshots (250+ als ik me niet vergis).

Het begint te stabiliseren, maar zolang deze problemen niet opgelost geraken zou ik het zeker nog niet proctierijp noemen.

Als je geen raid 5/6, quoa of veel snapshots gebruikt kan het zo stilaan dienen voor productiedoeleinden. Gebruik je een van die features zou ik een alternatief gebruiken.

[Kortfragje]

Nee mijn punt exact, ik dacht na een jaar sudderen? Maar niet helemaal dus...

[Q]

Wat lordfragger schrijft: je moet dat jaar gaan laten tellen totdat deze issues zijn opgelost. Ik denk dat BTRFS hooguit pas in 2017 productie rijp gaat worden.

[A1AD]

Ik had ergens gelezen (weet niet meer waar en te lui om met GSM op te zoeken) dat zeer binnenkort (zoals: de volgende gen.) Synology btrfs gaat gebruiken als FS.

[hans_lenze]

Ze gebruiken het al maar nog niet op alle modellen https://www.synology.com/nl-nl/dsm/Btrfs netgear doet er ook al dingen mee https://www.netgear.com/i...OS%206_9May1318-76105.pdf

[ Voor 24% gewijzigd door hans_lenze op 13-02-2016 15:07 ]

[idef1x]

Zo dan! Even met btrfs send/receive aan het "spelen" en vond de snelheid bar tegenvallen (ongeveer 100Mbps op een 1Gbps link). Daar ik met ZFS veel hogere snelheden haalde wilde ik niet geloven dat btrfs zo slecht was, dus even onderzoek gedaan. Wat blijkt? quota support aan hebben staan brengt het geheel op de knieen??
Na dat het weer uit stond ging de snelheid naar een acceptabele 800Mbps!

Hmm backupscript maar uitbreiden dan om quota uit te zetten voor de backup en weer aan na de backup (wil toch wel een beetje kunnen zien wat mijn subvolumes/snapshots verbruiken)..

[lordfragger]

Er zijn nog veel (en vrij zware) problemen met quota. Eigenlijk is de raad geen quota te gebruiken tot dat opgelost is. In een aantal gevallen wordt een rebalance bvb ook oertraag (enkele dagen tot weken voor een paar TB) als je quota gebruikt.

Er wordt momenteel wel gewerkt aan een paar verbeteringen waardoor dit opgelost zou moeten worden.

Voor wie interesse heeft in de ontwikkeling van btrfs (of in veel voorkomende problemen) is de btrfs mailinglist wel interessant.

[idef1x]

Hmm ja moet die mailinlist subscruptie maar weer eens activeren.
Beter dus helemaal geen quota te gebruiken.
Zijn er nog andere manieren dat je weet om te zien hoeveel je snapshots in gebruik hebben?

[lordfragger]

Geen idee, ik volg de mailinglist om de stabiliteit in het oog te houden, maar ik gebruik zelf nog nergens btrfs. Wanneer raid 5 en 6 productierijp zijn wil ik het wel gaan gebruiken, maar momenteel is dat (imo) nog onbruikbaar. Geen detectie van een kapotte schijf verslaat het nut van pariteit nogal. Daar zijn ook weer mensen mee bezig en er bestaan al wat vroege patches, dus het zit er wel zo stilaan aan te komen.

[idef1x]

ik gebruik btrfs op mijn laptop en zet de btrfs snapshots op mijn ZFS nas (ubuntu). Wanneer raid6 inderdaad betrouwbaar is met btrfs, dan ga ik wel over denk ik.

[A1AD]

idef1x schreef op vrijdag 15 april 2016 @ 13:35:
ik gebruik btrfs op mijn laptop en zet de btrfs snapshots op mijn ZFS nas (ubuntu).

Heb je zin om dit even kort uit te leggen?

[idef1x]

Ik heb een NAS die ubuntu draait met ZFS on Linux. Hierop heb ik een volume gemaakt (ZVOL in ZFS termen), welke ik als btrfs heb geformateerd. Vervolgens maak ik regulier op mijn laptop (die met btrfs draait) btrfs snapshots, welke ik vervolgens naar die NAS stuur (met btrfs send & receive) als backup.

Bedoelde je zoiets of ander soort uitleg?

[idef1x]

Na poging 3 maar gestopt met een btrfs-convert op mijn VPS. Elke keer gaat de rebalance de mist in (en maakt systeem unbootable) nadat ik de converted image subvol heb verwijderd. Wellicht te weinig geheugen in de VPS om dat on-line te doen, maar vind het wel genoeg nu. Dan maar op ext4 laten en blijven backuppen met dump

[Brent]

Eindelijk officiële bevestiging: BTRFS Raid5/6 is onveilig: http://phoronix.com/scan....m&px=Btrfs-RAID-56-Is-Bad

[vanaalten]

Auw... als het klopt, dan vraag ik mij af of dit de doodsteek voor BTRFS is. Als een volledige re-write nodig is, klinkt dat voor mij best ingrijpend - de eerste nieuwe versie zal vast nog niet productierijp zijn. Op deze manier gaat ZFS het stokje wel overnemen.

Vooralsnog geen negatieve adviezen voor BTRFS mirror-config van twee disks.

[dcm360]

Mweh. Heb ik eens een BTRFS-raidset, komt dit naar buiten... Dan maar eens gaan uitdenken wat een goede vervanger kan zijn, want BTRFS was al tweede keuze (nadat ZFS niet installeerde).

[lordfragger]

Zeer jammer dit. ZFS is op zich wel leuke technologie, maar voor thuisgebruik is array expansion toch echt handig (en voor velen een must have).

Het zag er helaas al wel een tijdje niet zo goed uit, op de mailinglist kwamen regelmatig toch wel ernstige problemen naar boven die je in dit stadium niet meer zou mogen zien.

Eigenlijk vreemd dat het toch zo traag gaat, als je ziet naar de bedrijven die achter btrfs zitten...

[Q]

Waarschuwing | BRRFS + RAID 5/6 = DATA LOSS

http://www.phoronix.com/s...m&px=Btrfs-RAID-56-Is-Bad

https://btrfs.wiki.kernel.org/index.php/RAID56

[ Voor 14% gewijzigd door Q op 06-08-2016 01:15 ]

[Brent]

Jij dacht, laat ik een bericht van 3 posts terug nog eens herhalen

Een vraagje: ik kan niet vinden of ik in een BTRFS volume het aantal copies op 2 (of meer) kan zetten. Zodat een scrub niet alleen fouten vind, maar deze ook repareert (en dus zonder RAID). In ZFS gaat dat prima, vroeg me af of dat ook met BTRFS kan.

[lordfragger]

Voor zover ik weet ondersteunt btrfs geen mirroring met meer dan 1 kopie. Staat al lang op de lijst met geplande features, maar heeft schijnbaar geen al te hoge prioriteit.

[Brent]

Ik bedoel ook niet mirroring (als in RAID1), gewoon dat het fs op een volume N kopieen opslaat.

[Thralas]

Volgens mij wel (met n=2), kwestie van het dup-profiel ipv. single gebruiken.

btrfs rebalance -dconvert=dup

[Brent]

Thanks! Is een recente toevoeging zie ik. Vraagje: zal scrub gebruikt maken van die twee files (gezien de nieuwigheid van dup op 1 volume) of doet die dat nog niet?

[Q]

Brent schreef op zaterdag 06 augustus 2016 @ 11:33:
Jij dacht, laat ik een bericht van 3 posts terug nog eens herhalen

Ha, niet goed opgelet.

[A1AD]

Q schreef op zaterdag 06 augustus 2016 @ 22:36:
[...]

Ha, niet goed opgelet.

Je waarschuwing is wel mooier

[Q]

Ik vraag me af wat dit alles betekent voor de toekomst voor Btrfs. Ik heb geen vertrouwen voor de komende 2 jaar om RAID5/6 aan te raken, dat is zeker. Verder vraag ik me af wie nu werkelijk Btrfs echt 'draagt'.

[analogworm]

Dat is jammer, ik dacht juist een raid6 set te bouwen op een synology nas met btrfs, ook vanwege de snapshots.

Raid 10 via storagespaces op main machine én de backup via btrfs op synology gaat zoveel disks kosten.

[SmiGueL]

analogworm schreef op maandag 08 augustus 2016 @ 10:10:
Dat is jammer, ik dacht juist een raid6 set te bouwen op een synology nas met btrfs, ook vanwege de snapshots.

Raid 10 via storagespaces op main machine én de backup via btrfs op synology gaat zoveel disks kosten.

Wat betreft BTRFS + Raid5/6 is er goed nieuws van o.a. Synology: (bron HWI)

"Vandaag hebben alle NAS-fabrikanten die Btrfs aanbieden gereageerd. Ze blijken een extra beveiligingslaag te gebruiken waardoor de bug waarschijnlijk ongevaarlijk is voor de apparaten.

In plaats van Btrfs direct op de schijven te draaien, gebruikt het merk normale Linux-RAID om alle schijven samen te voegen tot één partitie. Voor deze software-RAID wordt de Linux-utility mdadm gebruikt. Daarbovenop kan de consument kiezen tussen het conventionele ext4-formaat of Btrfs. Het bestandssysteem weet echter niet beter dan dat er één groot volume aanwezig is."


Btrfs-RAID (links) en Btrfs met software-RAID van Synology (rechts).

[analogworm]

SmiGueL schreef op dinsdag 09 augustus 2016 @ 21:03:
[...]


Wat betreft BTRFS + Raid5/6 is er goed nieuws van o.a. Synology: (bron HWI)

"Vandaag hebben alle NAS-fabrikanten die Btrfs aanbieden gereageerd. Ze blijken een extra beveiligingslaag te gebruiken waardoor de bug waarschijnlijk ongevaarlijk is voor de apparaten.

In plaats van Btrfs direct op de schijven te draaien, gebruikt het merk normale Linux-RAID om alle schijven samen te voegen tot één partitie. Voor deze software-RAID wordt de Linux-utility mdadm gebruikt. Daarbovenop kan de consument kiezen tussen het conventionele ext4-formaat of Btrfs. Het bestandssysteem weet echter niet beter dan dat er één groot volume aanwezig is."

[afbeelding]
Btrfs-RAID (links) en Btrfs met software-RAID van Synology (rechts).

Dat is dan wel weer nice. Werkt de error correctie van Btrfs dan wel nog steeds?

[dcm360]

Nee, want btrfs heeft zelf niet de extra benodigde data om de correctie uit te voeren. Het kan nu echter wel detecteren dat de raid-laag eronder een fout op de verkeerde manier heeft opgelost...

[SmiGueL]

analogworm schreef op dinsdag 09 augustus 2016 @ 21:06:
Dat is dan wel weer nice. Werkt de error correctie van Btrfs dan wel nog steeds?

Hoe ik begrepen heb dat het bij Synology werkt: *

De error detectie werkt niet real-time, maar wel bij de wekelijkse/maandelijke scan (instelbaar)
De error correctie werkt alleen voor de metadata, want hiervan worden 2 kopieën (bron) per volume opgeslagen.

*Dit was wat ik enkele maanden geleden heb kunnen vinden op het Synology forum en de Synology website. Graag verbeteren indien incorrect.

[ Voor 20% gewijzigd door SmiGueL op 09-08-2016 21:44 ]

[Thralas]

Errorcorrectie voor data haal je dan ook uit de md partity disk. Het grootste nadeel is dat md minder efficient is dan btrfs bij rebuilds (de hele disk ipv. enkel in-use blocks). Ongetwijfeld zijn er nog andere subtiele verschillen, maar nu blijkt in ieder geval dat conservativisme zich uitbetaalt - Synology kon ook niet anders, die sleutelen hier al veel langer aan voordat BTRFS RAID56 uberhaupt 'af' was.

Verder verandert er natuurlijk niets qua errordetectie - bij zowel md RAID als BTRFS zul je moeten scrubben om silent corruption of bad sectors (waarschijnlijker) te detecteren, on-access kom je er sowieso achter.

[dcm360]

Een vrij niet subtiel verschil tussen md en btrfs is dat btrfs vast kan stellen welke data er incorrect is, en dat md aannames moet maken. Als er van een stripe een block verkeerd is, heeft btrfs het voordeel dat het met een checksum kan bepalen welk block uit de stripe het is, waar md dat niet kan.

[Brent]

Natuurlijk ook de reden dat ZFS zo enorm aan is geslagen: deze gelaagdheid stamt uit een ander tijdvak, en het blijkt bijzonder productief en veilig (in het geval van ZFS) deze lagen samen te voegen. BTRFS 'boft' dat het in ieder geval mogelijk is haar 'rotte' deel te vervangen met zo'n oude laag, maar erg efficiënt, praktisch of modern is het niet.

[DXaroth]

Wel leuk en aardig, btrfs gebruiken on top of md, maar haalt dit niet het hele error correctie onderuit? btrfs/zfs maken juist gebruik van parity data op andere disks, om zo te voorkomen dat je data kwijt kan raken als 1 disk er uit trapt... als je ze vervolgens maar 1 (grote) disk voert, hebben ze nergens om die correctie data op te slaan, en kan het hele error correctie process niks doen.

Dus het komt er op neer dat ze enkel btrfs gebruiken voor de snapshot functionaliteit, voor de rest ben je gebonden aan de 'slechtere' raid van md...

[SmiGueL]

DXaroth schreef op woensdag 10 augustus 2016 @ 10:01:
Dus het komt er op neer dat ze enkel btrfs gebruiken voor de snapshot functionaliteit, voor de rest ben je gebonden aan de 'slechtere' raid van md...

Mwah, afgezien van dat metadatacorrectie gewoon werkt (want hiervan maakt hij 2 kopieën per volume) is de detectie van fouten toch ook een super groot voordeel. Het had inderdaad beter kunnen zijn. (vervang beter door slechter sinds dit debacle )

Een post op het Synology BTRFS forum die is blijven hangen:

"I've read closely, and a data integrity check is better than no check at all. I'd much rather know that a file was rotten, so that I can restore it from another saved copy, than let bitrot go undetected. Sure it would be great if the Synology could autorepair the damage, and I really hope that comes soon, but as with most problems, early detection is the key. This is an important first step, and a great improvement upon the zero visibility we had before, and therefore something I'll welcome even with the understanding that it's not enough by itself.

Even if the Synology can't recover a good copy of the file, I can. And if I can't, that tells me I need more copies of my data."

[ Voor 4% gewijzigd door SmiGueL op 10-08-2016 10:35 ]

[Q]

Ik denk dat de kans op bitrot kleiner is dan dat de huidige BTRFS ellende je data opvreet. De kans op bitrot is al heel erg klein. Btrfs in RAID1 vertrouw ik nog wel, maar RAID 5/6 zeker niet.

[vanaalten]

Is er eigenlijk nog een kans dat door dit soort incidenten, de druk op ZFS-ontwikkelaars groter wordt om de licentie daarvan wat vrijer te maken? Dat ZFS probleemloos geintegreerd kan worden in Debian, bijvoorbeeld?
(ja, ik weet dat de volgende Debian-versie ZFS aan boord heeft - maar via 'contrib', niet op een gebruikelijke manier)

[dcm360]

Q schreef op woensdag 10 augustus 2016 @ 10:36:
Ik denk dat de kans op bitrot kleiner is dan dat de huidige BTRFS ellende je data opvreet.

Dat weet ik eigenlijk zo net nog niet. Voordat de huidige ellende daadwerkelijk je data opvreet, is er een trigger zoals bitrot nodig, gevolgd door nogmaals falen van een block in dezelfde stripe. Bij md begint het kansspel al bij de trigger zelf...

vanaalten schreef op woensdag 10 augustus 2016 @ 11:10:
Is er eigenlijk nog een kans dat door dit soort incidenten, de druk op ZFS-ontwikkelaars groter wordt om de licentie daarvan wat vrijer te maken? Dat ZFS probleemloos geintegreerd kan worden in Debian, bijvoorbeeld?
(ja, ik weet dat de volgende Debian-versie ZFS aan boord heeft - maar via 'contrib', niet op een gebruikelijke manier)

Wellicht niet de discussie voor hier, maar de licentie moet juist restrictiever gemaakt worden om compatibel te worden met de GPL.

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 10:36:
Ik denk dat de kans op bitrot kleiner is dan dat de huidige BTRFS ellende je data opvreet.

Dat is nu officieel zo, maar in praktijk was dit al bekend (elk tweede bericht op de BTRFS mailinglist ging hier zo'n beetje over). Inderdaad, met RAID0/1 is er geen reden om te vrezen, geen officieel bericht en nauwelijks zulke gebruikservaringen.

Mocht het je om RAID5/6 te doen zijn, dan zit er niets anders op dan ZFS (en dan RAIDZ).

[Q]

Ik begin steeds meer na te denken over MDADM + daarover een laagje Btrfs of ZFS voor de flexibiliteit. Je hebt nog steeds je kanarie in de kolenmijn, maar niet de gevaren van Btrfs of de inflexibiliteit van ZFS.

Volgens mij hier al genoemd, maar ik vind het zo gek nog niet.

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 11:28:
Ik begin steeds meer na te denken over MDADM + daarover een laagje Btrfs of ZFS voor de flexibiliteit. Je hebt nog steeds je kanarie in de kolenmijn, maar niet de gevaren van Btrfs of de inflexibiliteit van ZFS.

Volgens mij hier al genoemd, maar ik vind het zo gek nog niet.

ZFS mensen raden laagjes onder ZFS sterk af (in principe voor elk 'modern' FS dat de daadwerkelijk staat van schijfsectoren moet weten). Bij mijn weten los het ook niets op van de inflexibiteit van ZFS, wat ik overigens reuze mee vind vallen, je moet misschien ietsjes beter plannen.

[HollowGamer]

Q schreef op woensdag 10 augustus 2016 @ 11:28:
Ik begin steeds meer na te denken over MDADM + daarover een laagje Btrfs of ZFS voor de flexibiliteit. Je hebt nog steeds je kanarie in de kolenmijn, maar niet de gevaren van Btrfs of de inflexibiliteit van ZFS.

Volgens mij hier al genoemd, maar ik vind het zo gek nog niet.

Zou ik niet doen, kies dan voor enkel ZFS mocht je druk maken over Btrfs.
De reden is dan ZFS nogal wat performance kost, en daar een laag bovenop weet ik niet of dit per definitie beter is.

Wat bedoel je precies met inflexibiliteit van ZFS?

[dcm360]

ZFS kan je (bijvoorbeeld) niet uitbreiden door 1 disk toe te voegen aan een raid-z-array. Met md daaronder kan dat wel met raid5/6 (? Denk ik, geen ervaring mee) en kan ZFS daarna de extra vrije ruimte wel gebruiken (net als dat je een array wel kan vergroten door alle schijven te vervangen door grotere exemplaren). In tegenstelling tot BTRFS met de rebalance feature.

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 11:32:
[...]

ZFS mensen raden laagjes onder ZFS sterk af (in principe voor elk 'modern' FS dat de daadwerkelijk staat van schijfsectoren moet weten). Bij mijn weten los het ook niets op van de inflexibiteit van ZFS, wat ik overigens reuze mee vind vallen, je moet misschien ietsjes beter plannen.

ZFS mensen roepen zoveel, het is geen probleem om ZFS op MDADM te draaien.

MDADM raid array is niets anders dan een enkele disk vanuit het perspectief van ZFS. Rotte sectoren die tot RAID array corruptie kunnen leiden zullen alleen opgemerkt kunnen worden maar zullen niet gerepareerd kunnen worden.

Dat zou voor mij persoonlijk al goed genoeg zijn. Als ergens een enkele RAID stripe naar de kloten is, is dat niet erg, dat is hooguit een of enkele files die rot zijn.

Ik verwacht ook helemaal geen performance problemen, eerder performance winst. MDADM = sneller dan een ZFS vdev.

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 11:54:
[...]


ZFS mensen roepen zoveel,

Ik heb het vermoeden dat je geen idee hebt waarom. In dat geval kunnen we je niet verder helpen.

het is geen probleem om ZFS op MDADM te draaien.

Dat zegt ook niemand. Het is alleen niet zo slim, en de kans dat jij het echt beter weet dan fs experts en precies die niche hebt waar het misschien niet zo dom is, is gering

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 12:02:
[...]


Ik heb het vermoeden dat je geen idee hebt waarom. In dat geval kunnen we je niet verder helpen.


[...]


Dat zegt ook niemand. Het is alleen niet zo slim, en de kans dat jij het echt beter weet dan fs experts en precies die niche hebt waar het misschien niet zo dom is, is gering

In plaats van een argument from authority te gebruiken, wat is er mis met bovenstaande redenatie?

Bovendien lost het juist de inflexibiliteit van ZFS op omdat je gewoon de MDADM laag met 1 disk per keer kunt uitbreiden en dan ZFS kunt autoexpanden. Scheelt je weer 'ZFS tax'.

Natuurlijk verlies je de optie dat ZFS corrupte data kan herstellen, maar dat neem ik voor lief. De kans op data corruptie is toch klein.

De context hier is nog steeds een thuis nas.

[ Voor 25% gewijzigd door Q op 10-08-2016 12:11 ]

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 12:08:
[...]


In plaats van een argument from authority te gebruiken, wat is er mis met bovenstaande redenatie?

Sorry, maar ik ga de ontwikkelingen van de laatste 10-15 jaar niet samenvatten. Dit is het fundamentele verschil van fses als ZFS en BTRFS met de rest: ze voegen alle traditionele lagen samen omdat dat voordelen oplevert. Ondermijn je dat (letterlijk), dan heb je te maken met eventuele performance penalties of betrouwbaarheidspenalties. Het fs heeft geen informatie meer over de locatie van een rotte bit met MDADM ertussen bijvoorbeeld.

Of je neemt het aan, of je weet waarom het in jouw geval geen dom idee is en je deze vuistregel kunt negeren, en dan horen we het graag.