Het BTRFS ervaringen topic

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 15:14:
[...]


Je hoeft mij niet te vertellen hoe ZFS en BTRFS werken en waarom het wordt toegepast,

Je vroeg erom:

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?

Q schreef op woensdag 10 augustus 2016 @ 12:08:
[...]
het lijkt meer dat je mijn positie niet snapt. Je doet plots alsof ik een idioot ben maar lees eens een paar blog artikeltjes, van me, ik denk dat dit wel mee valt.

Het spijt me zeer, maar nee

BTRFS/ZFS bitrot detectie is fundamenteel niet te garanderen met lagen eronder. Je weet niet of die laag op goed moment besluit wat sectoren te verplaatsen bijv. Maargoed, ga je gang, je weet het kennelijk beter dan wij en de makers van dergelijke filesystems

[Q]

Het spijt me zeer, maar nee

Het is jammer dat je er een soort van persoonlijke aanval van maakt en een discussie in een manier giet waarbij je mensen belachelijk maakt zonder inhoudelijk iets toe te voegen.

Graag hoor ik inhoudelijk van je wat er allemaal niet deugt aan mijn blog posts.

Brent schreef op woensdag 10 augustus 2016 @ 15:32:
BTRFS/ZFS bitrot detectie is fundamenteel niet te garanderen met lagen eronder. Je weet niet of die laag op goed moment besluit wat sectoren te verplaatsen bijv. Maargoed, ga je gang, je weet het kennelijk beter dan wij en de makers van dergelijke filesystems

Het hele idee achter ZFS is dat het geen bal meer uitmaakt wat er onder zit qua lagen aan hardware en software. Het kan en zal conceptueel altijd data corruptie detecteren.

Als een laag er onder wat sectoren verplaatst dan gaat ZFS toch gewoon over de zeik, net als dat dit zou gebeuren waarbij een enkele schijf wat sectoren worden verhaspeld of stuk maakt?

En met over de zeik bedoel ik: dan krijg je CRC errors enzo.

[ Voor 16% gewijzigd door Q op 10-08-2016 17:01 ]

[Q]

dcm360 schreef op woensdag 10 augustus 2016 @ 15:28:
[...]

Het deel dat ik dikgedrukt heb gemaakt lijkt echter wel te impliceren dat de beoordeling onvolledig of niet deterministisch (mogelijk) was. Dat is met BTRFS en ZFS toch ruim beter geregeld.

Dat is zeker waar, maar het feit is dat de soep niet zo heet wordt gegeten.

[dcm360]

Q schreef op woensdag 10 augustus 2016 @ 17:03:
[...]


Dat is zeker waar, maar het feit is dat de soep niet zo heet wordt gegeten.

Dan heb je vast bronnen met harde cijfers voor dat feit? Anders is het meer een onderbuikgevoel dan een feit, en tot zover ontbreekt het behoorlijk aan harde cijfers in deze discussie.

[ Voor 20% gewijzigd door dcm360 op 10-08-2016 17:04 ]

[Q]

dcm360 schreef op woensdag 10 augustus 2016 @ 17:03:
[...]

Dan heb je vast bronnen met harde cijfers voor dat feit?

Lees dat artikeltje eens van mij hierboven laat me weten wat je er van vind.
Grappig hoe mensen altijd achteraf pas opeens gaan vragen om cijfers en getallen.

Niet alles gaat om getallen, het gaat ook om gewoon nadenken en beredeneren.

Door de ZFS/BTRFS mensen wordt altijd gedaan alsof je enorme gevaren en risico's loopt door bijvoorbeeld MDADM te gebruiken en dat valt allemaal prima mee thuis. Voor 'hun' standpunt is juist geen bewijs.

[ Voor 43% gewijzigd door Q op 10-08-2016 17:11 ]

[dcm360]

Q schreef op woensdag 10 augustus 2016 @ 17:07:
[...]


Lees dat artikeltje eens van mij hierboven laat me weten wat je er van vind.
Grappig hoe mensen altijd achteraf pas opeens gaan vragen om cijfers en getallen.

Niet alles gaat om getallen, het gaat ook om gewoon nadenken en beredeneren.

Dat artikeltje gaat totaal niet over het behouden van een consistent filesystem en data bij een rebuild.

En haha, wat grappig, je hebt dus blijkbaar geen getallen om mee te onderbouwen (Oftewel: laat die steek maar zitten. En leg eens uit waarom wat ik stel geen probleem is in plaats van het weg te lachen).

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 16:59:
[...]


Het is jammer dat je er een soort van persoonlijke aanval van maakt en een discussie in een manier giet waarbij je mensen belachelijk maakt zonder inhoudelijk iets toe te voegen.

Het spijt me dat je het verschil tussen kritiek en persoonlijke aanvallen niet ziet.

Het hele idee achter ZFS is dat het geen bal meer uitmaakt wat er onder zit qua lagen aan hardware en software. Het kan en zal conceptueel altijd data corruptie detecteren.

Dit is een misvatting, en een hele diepe.

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 17:16:
Dit is een misvatting, en een hele diepe.

Als je dit niet kunt uitleggen en toelichten dan is dit een loze opmerking die niets betekent.
Toon aan dat jij de kennis en kunde bezit die je claimt te hebben en onderwijs ons.

Kun je technisch precies uitleggen waar het mis gaat?

[ Voor 42% gewijzigd door Q op 10-08-2016 17:21 ]

[Brent]

Q schreef op woensdag 10 augustus 2016 @ 17:19:
[...]


Als je dit niet kunt uitleggen en toelichten dan is dit een loze opmerking die niets betekent.
Toon aan dat jij de kennis en kunde bezit die je claimt te hebben en onderwijs ons.

Je herhaalt nu voor minstens de vierde keer dat foute punt op en verwar je kritiek met een persoonlijke aanval.

Je roept om uitleg, en dan doe ik dat en lees ik je de les.

Vervolgens stel jij iets voor waarvan het expliciet afgeraden wordt, door ons hier en de ZFS docs zelf, en dan moeten wij ons verklaren?

Daaag

[dcm360]

Sorry Brent, maar in sluit me aan bij Q. Foutdetectie kan ZFS (en BTRFS) altijd doen, ongeacht de laag er onder. Foutcorrectie is een ander verhaal, daarvoor moeten beiden meer controle hebben over hoe de data op lagen eronder geschreven wordt: door bijvoorbeeld zelf pariteit of redundantie te gebruiken. Laat je pariteit of redundantie over aan onderliggende lagen, dan werkt de correctie niet (op het BTRFS/ZFS niveau).

[ Voor 3% gewijzigd door dcm360 op 10-08-2016 17:28 ]

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 17:23:
[...]

Je herhaalt nu voor minstens de vierde keer dat foute punt op en verwar je kritiek met een persoonlijke aanval.

Je roept om uitleg, en dan doe ik dat en lees ik je de les.

Vervolgens stel jij iets voor waarvan het expliciet afgeraden wordt, door ons hier en de ZFS docs zelf, en dan moeten wij ons verklaren?

Daaag

Je bluft, je kunt het zelf technisch niet uitleggen en daarom doe je het niet. Want je zit fout, je weet zelf niet hoe het zit. Maar als het in de docs zelf staat hoe het wel zit, kun je daar toch even naar verwijzen?

dcm360 schreef op woensdag 10 augustus 2016 @ 17:24:
Sorry Brent, maar in sluit me aan bij Q. Foutdetectie kan ZFS (en BTRFS) altijd doen, ongeacht de laag er onder. Foutcorrectie is een ander verhaal, daarvoor moeten beiden meer controle hebben over hoe de data op lagen eronder geschreven wordt: door bijvoorbeeld zelf pariteit of redundantie te gebruiken. Laat je pariteit of redundantie over aan onderliggende lagen, dan werkt de correctie niet.

Dat is precies mijn punt. Het is dus duidelijk waarom ZFS mensen ZFS op MDADM afraden want je verliest de mogelijkheid om data corruptie te herstellen. Het is niet dat de auteurs geen gelijk hebben. Het is meer dat het afhankelijk van je behoefte thuis een mooie midden weg kan zijn: flexibiliteit en als er wat fout gaat dan weet je welke data het betreft.

[ Voor 39% gewijzigd door Q op 10-08-2016 17:30 ]

[Brent]

dcm360 schreef op woensdag 10 augustus 2016 @ 17:24:
Sorry Brent, maar in sluit me aan bij Q. Foutdetectie kan ZFS (en BTRFS) altijd doen, ongeacht de laag er onder.

Q schreef op woensdag 10 augustus 2016 @ 17:27:
[...]


Je bluft, je kunt het zelf technisch niet uitleggen en daarom doe je het niet. Want je zit fout, je weet zelf niet hoe het zit. Maar als het in de docs zelf staat hoe het wel zit, kun je daar toch even naar verwijzen?

http://open-zfs.org/wiki/Hardware#Hardware_RAID_controllers
En ter info is deze ook aardig: http://serverfault.com/qu...with-hardware-raid#545475

Algemeen bekend.

[dcm360]

Brent schreef op woensdag 10 augustus 2016 @ 17:30:
[...]


[...]

http://open-zfs.org/wiki/Hardware#Hardware_RAID_controllers
En ter info is deze ook aardig: http://serverfault.com/qu...with-hardware-raid#545475

Algemeen bekend.

Sluit niet aan bij de discussie, die ging over foutdetectie, dit gaan met name over foutcorrectie (en wat andere dingen die ook niet met foutdetectie in ZFS te maken hebben).

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 17:30:
[...]


[...]

http://open-zfs.org/wiki/Hardware#Hardware_RAID_controllers
En ter info is deze ook aardig: http://serverfault.com/qu...with-hardware-raid#545475

Algemeen bekend.

Kun je uitleggen hoe deze linkjes jouw stelling verdedigen, want ik lees hier ook niets nieuws of wat mijn positie onderuithaalt. edit: wat dcm360 schrijft.

[Q]

dcm360 schreef op woensdag 10 augustus 2016 @ 17:14:
[...]

Dat artikeltje gaat totaal niet over het behouden van een consistent filesystem en data bij een rebuild.

En haha, wat grappig, je hebt dus blijkbaar geen getallen om mee te onderbouwen (Oftewel: laat die steek maar zitten. En leg eens uit waarom wat ik stel geen probleem is in plaats van het weg te lachen).

Nou het punt is dat de hele consumer wereld op Synology en Qnaps draait die onder de motorkap gewoon MDADM enzo gebruiken, en ik lees weinig problemen op internet het is ook in dit forum niet zo'n heet topic dat mensen aan de lopende band hun arrays kwijt raken.

Daarnaast hebben we in de IT ook veel op hardware RAID gedraait dat net als MDADM ook geen weet heeft van bovenliggende file systems maar dat gaat ook vrijwel altijd goed.

Het hele idee achter RAID is dat het een rotte / uitvallende disk kan opvangen, waarbij filesystem en data integer blijft en alles goed blijft functioneren en dat lukt ook in de meeste gevallen.

Dat is waarom ik denk dat het scenario wat jij schetst misschien best kan voorkomen, maar dat die kans niet zo groot is. Je zou eigenlijk jouw situatie moeten kunnen repliceren op een MDADM array en dan kijken hoe die het had opgelost. Ik weet niet of jouw voorbeeld dus zo'n goede illustratie was/is van de meerwaarde van ZFS/BTRFS. etc

[ Voor 3% gewijzigd door Q op 10-08-2016 17:45 ]

[Brent]

dcm360 schreef op woensdag 10 augustus 2016 @ 17:33:
[...]

Sluit niet aan bij de discussie, die ging over foutdetectie, dit gaan met name over foutcorrectie (en wat andere dingen die ook niet met foutdetectie in ZFS te maken hebben).

Het fundamentele punt is dat je niet weet waar de fout zit op de disk, en daardoor niet betrouwbaar kunt restoren, maar niet eens betrouwbaar kunt zeggen welke files rot zijn (wie weet heeft de controller, of MDADM al wat sectoren rondgeschoven). Daar zit het hem in voor zover ik begrijp. Dan gaan die argumenten dus voor alles op.

Q schreef op woensdag 10 augustus 2016 @ 17:44:
[...]


Nou het punt is dat de hele consumer wereld op Synology en Qnaps draait die onder de motorkap gewoon MDADM enzo gebruiken, en ik lees weinig problemen op internet het is ook in dit forum niet zo'n heet topic dat mensen aan de lopende band hun arrays kwijt raken.

Daarnaast hebben we in de IT ook veel op hardware RAID gedraait dat net als MDADM ook geen weet heeft van bovenliggende file systems maar dat gaat ook vrijwel altijd goed.

Het hele idee achter RAID is dat het een rotte / uitvallende disk kan opvangen, waarbij filesystem en data integer blijft en alles goed blijft functioneren en dat lukt ook in de meeste gevallen.

Dat is waarom ik denk dat het scenario wat jij schetst misschien best kan voorkomen, maar dat die kans niet zo groot is. Je zou eigenlijk jouw situatie moeten kunnen repliceren op een MDADM array en dan kijken hoe die het had opgelost. Ik weet niet of jouw voorbeeld dus zo'n goede illustratie was/is van de meerwaarde van ZFS/BTRFS. etc

Je moet echt wat aan je bril doen: er zegt niemand dat het niet werkt of niet goed werkt. Men zegt dat het verder niets extras biedt boven gewoon ext4 oid draaien.

[CurlyMo]

Ik sluit me toch aan bij Q. ZFS werkt prima als bovenlaag alleen kan je niet alle mogelijkheden gebruiken die ZFS je te bieden heeft (aan de zpool kant). Ik heb bijvoorbeeld zelf ZFS op ZFS draaien bij TransIP. TransIP biedt VPS'en aan die draaien op ZFS. Binnen die VPS draai ik mijn eigen OS met ZFS-on-Root. De reden daarvoor is dat ik dan de mogelijkheid behoud van snapshots, clones, compressie enz. De daadwerkelijke foutcorrectie wordt gedaan door de laag eronder (in dit geval ook ZFS). Thuis draai ik via bhyve verschillende gevirtualiseerde machines met ZFS-on-Root op een ZVOL. Ook dat gaat prima.

MDADM gaat dus ook zonder problemen werken als onderlaag (of welk FS dan ook). Je mist een aantal features van ZFS, maar die worden door MDADM afgehandeld. Daarnaast behoud je de mogelijkheid die ik eerder heb genoemd. Dat MDADM een minder geavanceerde software RAID controller is, dat neem je dan maar voor lief. Je krijg er inderdaad wel flexibiliteit voor terug.

Je moet dus gewoon afwegen wat bepaalde features je waard zijn. Vertrouw je voldoende op MDADM, maar wil je de flexibiliteit van ZFS als FS, dan doe je dat. Vertrouw je het niet, dan draai je 100% ZFS, maar heb je minder flexibiliteit.

Dus ofwel MDADM kan een fout helemaal oplossen en (Z)FS heeft de fout zelf nooit gezien of MDADM crasht en daarmee (Z)FS ook.

[Q]

Brent schreef op woensdag 10 augustus 2016 @ 17:56:
[...]

Het fundamentele punt is dat je niet weet waar de fout zit op de disk, en daardoor niet betrouwbaar kunt restoren, maar niet eens betrouwbaar kunt zeggen welke files rot zijn (wie weet heeft de controller, of MDADM al wat sectoren rondgeschoven). Daar zit het hem in voor zover ik begrijp. Dan gaan die argumenten dus voor alles op.

Dit is niet juist, een bitrot sector op een fysieke disk vertaalt zich naar een 'rotte' sector in de virtuele MDADM disk en dat zal door ZFS worden opgemerkt wat tot resultaat heeft dat ZFS jou precies gaat vertellen welke files corrupt zijn geraakt.

Je moet echt wat aan je bril doen: er zegt niemand dat het niet werkt of niet goed werkt. Men zegt dat het verder niets extras biedt boven gewoon ext4 oid draaien.

Nou nou nou zeg, doe toch eens wat liever tegen mensen.

Ik weet niet precies waarom je op deze quote van mij reageert maar ZFS op MDADM geeft je alsnog error detectie en dan weet je dus welke files je moet herstellen van backup. Dat is voor mij al waardevol genoeg.

[ Voor 38% gewijzigd door Q op 10-08-2016 18:22 ]

[CurlyMo]

Q schreef op woensdag 10 augustus 2016 @ 18:11:
Ik weet niet precies waarom je op deze quote van mij reageert maar ZFS op MDADM geeft je alsnog error detectie en dan weet je dus welke files je moet herstellen van backup. Dat is voor mij al waardevol genoeg.

Is het niet zo dat ZFS ofwel een fout ziet (MDADM kan een probleem niet oplossen) of geen fout ziet (MDADM heeft het probleem al opgelost)?

[dcm360]

Brent schreef op woensdag 10 augustus 2016 @ 17:56:
[...]

Het fundamentele punt is dat je niet weet waar de fout zit op de disk, en daardoor niet betrouwbaar kunt restoren, maar niet eens betrouwbaar kunt zeggen welke files rot zijn (wie weet heeft de controller, of MDADM al wat sectoren rondgeschoven). Daar zit het hem in voor zover ik begrijp. Dan gaan die argumenten dus voor alles op.

Alles wat een onderliggende laag aanpast aan de data die gepresenteerd wordt aan de laag erboven (het fs) kan door (BTR|Z)FS gedetecteerd worden. (BTR|Z)FS kan altijd achterhalen bij welk bestand (of bij welke metadata) de gewijzigde data hoort, want het heeft daar checksums voor. Het is hetzelfde als (bijvoorbeeld) de MD5 van een gedownload bestand controleren: als de MD5 niet matcht, weet je dat dat bestand dat opgeslagen is niet correct is. Waar het fout gegaan is maakt niet uit.

CurlyMo schreef op woensdag 10 augustus 2016 @ 18:41:
[...]

Is het niet zo dat ZFS ofwel een fout ziet (MDADM kan een probleem niet oplossen) of geen fout ziet (MDADM heeft het probleem al opgelost)?

Volgens mij is het eerder: Als ZFS een fout ziet heeft MDADM een probleem gevonden maar deze incorrect opgelost. In het geval van een mirror: je hebt A op schijf 1 en A op schijf 2. Het raakt corrupt en er staat nu B op schijf 1, MDADM merkt het verschil op en besluit schijf 2 te corrigeren naar B (verkeerde keuze).

[ Voor 23% gewijzigd door dcm360 op 10-08-2016 18:51 ]

[Q]

@CurlyMo, wat dcm360 schrijft.

MDADM kan conceptueel geen onderscheid maken tussen de originele sector en de corrupte sector. Het kan bij een scrub wel zien dat er een verschil is tussen parity en data. Of tussen de ene disk in een mirror en de andere. Maar het is onmogelijk om te weten wie gelijk heeft. Je hebt een 3e bron nodig om dat te bepalen, of gewoon checksums

Met RAID6 zou MDADM wel kunnen bepalen welke sector stuk is (data blok, parity block 1 of parity blok 2). Maar dat zit er helaas niet in.

[ Voor 6% gewijzigd door Q op 10-08-2016 19:12 ]

[Thralas]

Maar, hoewel md op basis van enkel de data niet weet welke disk stuk is, is een 'foutconditie' in de praktijk meestal een complete disk failure of een bad sector die een read error oplevert.

In dat laatste geval weet md dus wel degelijk waar de fout zit en valt het meteen op te lossen met een write van de juiste data.

Slechts in het geval van omvallende bits (op 1 disk) zonder read error weet je echt niet meer welke disk er stuk is (maar kun je het wel repareren). Het was al eerder genoemd, maar ik ben het er mee eens dat het risico op bitrot verwaarloosbaar lijkt tov. alle andere risico's (maar dat is enkel een onderbuikgevoel).

[Q]

Dat is de context en nuance die ik zelf zoek. Of je het risico verwaarloost is iets wat mensen uiteindelijk zelf moeten bepalen, maar het risico is zeker weten zo klein dat als je er voor kiest om het te verwaarlozen, dat je een redelijke en rationele keuze maakt.

[CurlyMo]

Zojuist geprobeerd (in FreeBSD):

1. 2 bestanden gemaakt via dd
2. via mdconfig loop devices gemaakt van beide bestanden
3. met gvinum een mirror gemaakt van beide loop devices
4. zpool gemaakt op de gvinum mirror
5. bestandje in de root van mijn test pool gezet.
6. eerste bestandje overschrijven met random data
7. gvinum geeft geen krimp (hoe forceer je een check? ), zfs doet zijn ding na een scrub, bestandje is nog steeds leesbaar.
8. tweede bestandje overschrijven met random data
9. gvinum geeft geen krimp (hoe forceer je een check? ), zfs loopt compleet vast tijdens de scrub (en daarmee al mijn zfs commando's).

Volgende test is met MDADM.

Conclusie: niet alle software raid is geschikt als basis voor ZFS

---

Ook even getest met MDADM in Ubuntu

1. 2 bestanden gemaakt via dd
2. via fdisk een partitie gemaakt in beide bestanden
3. via kpartx loop devices gemaakt van beide bestanden
4. met mdadm een mirror gemaakt van beide loop devices
4. zpool gemaakt op de mdadm mirror
5. bestandje in de root van mijn test pool gezet.
6. eerste bestandje overschrijven met random data
7. zpool scrub ziet meteen problemen, maar kan het herstellen.
8. mdadm kan ook de problemen herstellen.
9. zpool scrub geeft geen problemen meer na de mdadm resilver.
10. beide bestanden gedeeltelijk corrumperen.

11. zfs geeft problemen weer en kan het vanzelfsprekend niet meer herstellen.
12. mdadm geeft geen krimp bij een geforceerde check.

13. beide bronbestanden hernoemen.
14. zpool ziet het niet meer zitten en geeft mega veel fouten
15. mdadm is best optimistisch
16. pool export en import werkt ook niet meer wegens teveel I/O fouten.

Conclusie: De ZFS corruptie detectie werkt nog altijd perfect en zolang mdadm de zooi kan repareren is ZFS ook weer blij.

[ Voor 46% gewijzigd door CurlyMo op 10-08-2016 23:29 ]

[Q]

CurlyMo schreef op woensdag 10 augustus 2016 @ 21:20:
Zojuist geprobeerd (in FreeBSD):

1. 2 bestanden gemaakt via dd
2. via mdconfig loop devices gemaakt van beide bestanden
3. met gvinum een mirror gemaakt van beide loop devices
4. zpool gemaakt op de gvinum mirror
5. bestandje in de root van mijn test pool gezet.
6. eerste bestandje overschrijven met random data
7. gvinum geeft geen krimp ( ), zfs geeft geen krimp, bestandje is nog steeds leesbaar.
8. tweede bestandje overschrijven met random data
9. gvinum geeft geen krimp ( ), zfs loopt compleet vast (en daarmee al mijn zfs commando's).


Volgende test is met MDADM.

Conclusie: niet alle software raid is geschikt als basis voor ZFS

Bij 7 zou je een scrub moeten doen op ZFS. Waarschijnlijk is je bestandje leesbaar omdat het uit RAM cache komt en wordt de disk niet aangesproken. Dus de conclusie die je daar trekt is denk ik niet juist.

Of draai een BSD equivalent van sync of iets wat je caches invalideert.

---

Ook even getest met MDADM in Ubuntu

Conclusie: De ZFS corruptie detectie werkt nog altijd perfect en zolang mdadm de zooi kan repareren is ZFS ook weer blij.

Deze test lijkt conform de voorspelling uit te pakken, begrijp ik dat goed?

[CurlyMo]

Q schreef op woensdag 10 augustus 2016 @ 23:21:
Bij 7 zou je een scrub moeten doen op ZFS. Waarschijnlijk is je bestandje leesbaar omdat het uit RAM cache komt en wordt de disk niet aangesproken. Dus de conclusie die je daar trekt is denk ik niet juist.

Ik bedoel hier "geen krimp" als in "kan er met een scrub goed mee omgaan". Ik beide gevallen heb ik een zfs scrub gedraaid. Hoe je een check forceert in gvinum weet ik niet.

---

Deze test lijkt conform de voorspelling uit te pakken, begrijp ik dat goed?

Yep. Er zijn twee staten:
1. MDADM lost het succesvol op. ZFS accepteert de oplossing en schrapt de gevonden fouten als false positives.
2. MDADM kan het niet oplossen. ZFS ziet fouten, maar kan het niet zelf repareren.

[ Voor 6% gewijzigd door CurlyMo op 11-08-2016 07:05 ]

[Q]

CurlyMo schreef op woensdag 10 augustus 2016 @ 23:25:
[...]

Ik bedoel hier "geen krimp" als in "kan er met een scrub goed mee omgaan". Ik beide gevallen heb ik een zfs scrub gedraaid. Hoe je een check forceert in gvinum weet ik niet.

Raar, maar ik verdenk nog steeds caching of iets anders. Want als ZFS geen corruptie ziet, dan moet die BSD RAID laag data aan ZFS geven die gewoon klopt.

Mogelijk ziet die laag de corruptie van 1 van de 2 mirrors en komt in die test alle data van de 'goede' mirror.
Dat zou verklaren waarom ZFS niets merkt in je 1e test, de BSD raid lost het op.

Het is wel ander gedrag, maar het klopt allemaal prima zover ik kan zien.

Yep. Er zijn twee staten:
1. MDADM lost het succesvol op. ZFS accepteert de oplossing en schrapt de gevonden fouten als false positives.
2. MDADM kan het niet oplossen. ZFS ziet fouten, maar kan het niet zelfs repareren.

Klinkt goed

Ik vind het ook leuk dat je zelf even test en niemand hier op zijn/haar woord gelooft

[ Voor 4% gewijzigd door Q op 11-08-2016 00:30 ]

[dcm360]

Ook ik ben even gaan testen De setup is net wat anders maar redelijk vergelijkbaar: 2 bestanden (images in het vervolg tegen verwarring) aan een loop-device geknoopt, daarop een MDADM mirror geplaatst en daar bovenop BTRFS gezet. Die vervolgens gemount en er een bestand met willekeurige data op gezet, en daarna 1 van de 2 images 'gesloopt' door halverwege willekeurige data weg te schrijven. (tussendoor wat unmounten en opnieuw mounten om raar gedrag met caching te omzeilen).

Mijn conclusies:

1. 'Sloop' ik image 2, dan gaat er volgens BTRFS niets fout. MDADM kan image 2 herstellen
2. 'Sloop' ik image 1, dan gaat het goed mis volgens BTRFS. Poog je dit te herstellen met MDADM, wordt echter image 2 'hersteld'.

Inderdaad geen verrassingen.

[ Voor 5% gewijzigd door dcm360 op 11-08-2016 01:44 ]

[CurlyMo]

Q schreef op donderdag 11 augustus 2016 @ 00:29:
Raar, maar ik verdenk nog steeds caching of iets anders. Want als ZFS geen corruptie ziet, dan moet die BSD RAID laag data aan ZFS geven die gewoon klopt.

Mogelijk ziet die laag de corruptie van 1 van de 2 mirrors en komt in die test alle data van de 'goede' mirror.
Dat zou verklaren waarom ZFS niets merkt in je 1e test, de BSD raid lost het op.

Het is wel ander gedrag, maar het klopt allemaal prima zover ik kan zien.

Waarschijnlijk omdat ik geen zak van gvinum snap

Ik vind het ook leuk dat je zelf even test en niemand hier op zijn/haar woord gelooft

Ik snap ook niet dat dit niet eerder gebeurt in het algemeen. Ook in andere topics blijft het vaak te lang bij woorden zonder gewoon even te testen.

1. 'Sloop' ik image 2, dan gaat er volgens BTRFS niets fout. MDADM kan image 2 herstellen
2. 'Sloop' ik image 1, dan gaat het goed mis volgens BTRFS. Poog je dit te herstellen met MDADM, wordt echter image 2 'hersteld'.

Dus zoals in je eerdere voorbeeld wordt bij test 2 je A - A nu B - B?

[ Voor 16% gewijzigd door CurlyMo op 11-08-2016 07:05 ]

[Q]

Als ik dcm360's test goed lees dan is MDADM best 'dom' als het om data corruptie gaat en ziet MDADM de 1e schijf in een mirror altijd als bron en de 2e als backup. Dus bij fouten is de 1e schijf lijdend en dan krijg je dus gedonder als die schijf corrupt wordt gemaakt, precies zoals voorspeld.

Er mag dus geen twijfel over bestaan dat bij data corruptie op de 'verkeerde' disk MDADM bijna meer een liability is dan een hulp. Maar de kans dat je ooit silent data corruptie op een schijf meemaakt is zeer klein.

[dcm360]

CurlyMo schreef op donderdag 11 augustus 2016 @ 06:58:
[...]

Dus zoals in je eerdere voorbeeld wordt bij test 2 je A - A nu B - B?

Inderdaad

Q schreef op donderdag 11 augustus 2016 @ 09:26:
Als ik dcm360's test goed lees dan is MDADM best 'dom' als het om data corruptie gaat en ziet MDADM de 1e schijf in een mirror altijd als bron en de 2e als backup. Dus bij fouten is de 1e schijf lijdend en dan krijg je dus gedonder als die schijf corrupt wordt gemaakt, precies zoals voorspeld.

Er mag dus geen twijfel over bestaan dat bij data corruptie op de 'verkeerde' disk MDADM bijna meer een liability is dan een hulp. Maar de kans dat je ooit silent data corruptie op een schijf meemaakt is zeer klein.

Wat ik zo her en der tegenkwam aan documentatie over MDADM is het ook precies waarvoor er op diverse wiki's gewaarschuwd wordt (o.a. die van Arch, exacte links kan ik bij interesse daarvoor nog wel terugvinden zodra ik bij mn pc ben). Die wiki's had ik ook wel nodig, want dit was de eerste keer dat ik iets met MDADM deed.

Als aanvullende conclusie valt dus eigenlijk te stellen dat zodra BTRFS (bovenop MDADM) fouten vindt bij een scrub, dat in principe de data nog te redden valt tenzij er al gepoogd is een reparatie uit te voeren met MDADM.

[Q]

Ik weet niet of ik het eens ben met de aanvullende conclusie.

Stel nu dat er corruptie is op een van de twee disks in een MDADM mirror. Als MDADM geen scrub doet en je vraagt een file op wiens data in die rotte sector staat, dan heb je 50% kans op data corruptie. Komt de sector van disk B dan gaat het goed, komt hij van disk A dan gaat het fout. (RAID1 = dubbele lees performance)

Vroeg of laat ga je dus toch wel corruptie tegen komen en die data is dan verloren. Ga je een scrub doen dan zal MDADM een verschil zien en de goede sector op disk B overschrijven met de rotte sector van disk A en dan is je dataloss 100%.

Je zou dus wel kunnen stellen dat je nog 50% kans hebt op 'goede' data zolang je geen MDADM scrub doet, maar je hebt er geen controle over dus ik weet niet hoeveel dat echt waard is. Maar misschien mis ik wat.

Met MDADM als laag onder BTRFS/ZFS zal silent data corruptie gewoon altijd tot dataverlies leiden. Het enige (maar wel waardevolle) wat BTRFS/ZFS dan biedt is dat je weet welke files je moet restoren van backup.

[dcm360]

Dat is inderdaad een heel erg goed punt. Mijn test is enkel sequentiële I/O, waarbij het nutteloos is om blokken om en om van de twee schijven te lezen (kost een berg seeks of de schijf besluit gewoon alles sequentieel te lezen). Met een meer random access pattern ga je inderdaad de I/O over beide schijven spreiden, waarbij de kans inderdaad 50% wordt dat een fout op een van de schijven gevonden wordt.

Wat je nog wel zou kunnen doen is de raid-set degraded maken, en van alle combinaties degraded sets pogen de data terug te krijgen (in het geval van de mirror dus 2 combinaties). (Z|BTR)FS kan je vertellen welke combinatie de fout niet geeft. Terugzetten uit een backup lijkt me echter eenvoudiger.

[Q]

Volgens mij wordt bij een lees actie altijd data gestriped gelezen. Dus blok 1 komt van disk 1, blok 2 van disk 2, blok 3 van disk 1 en blok 4 van disk 4.

Ongeacht of het patroon sequentieel of random is.

[dcm360]

Dat is echter in tegenspraak met mijn situatie 1. In mijn tests had ik 2 'schijven' van 1GB en is er bij situatie 1 100MB aan rommel weggeschreven op schijf 2 met een offset van 500MB. Als er daadwerkelijk gestriped gelezen zou worden, had ook die test moeten opleveren dat BTRFS verkeerde data kreeg.

[Q]

Je hebt helemaal gelijk.

http://superuser.com/ques...formance-with-linux-mdadm

[albatross]

Verwijderd 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

Het echte nadeel van ZFS is dat je eigenlijk ECC geheugen nodig hebt (en ook behoorlijk wat: ca. 1G per 1T). Dat betekent dus dat je je oude machine niet gewoon als NAS kunt gebruiken, en eigenlijk gewoon een heel nieuw systeem moet kopen.

[dcm360]

De discussie over ECC ga ik me hier niet aan branden, daar is een heel topic aan gewijd. Wat betreft geheugen is dat wellicht nodig als je het daadwerkelijk in een SAN gaat inzetten, maar zelf ondervind ik niet echt nadelen met 16T/8GB opslag/geheugen op 1 machine en 10T/4GB op een andere.

[albatross]

dcm360 schreef op donderdag 11 augustus 2016 @ 17:15:
De discussie over ECC ga ik me hier niet aan branden, daar is een heel topic aan gewijd. Wat betreft geheugen is dat wellicht nodig als je het daadwerkelijk in een SAN gaat inzetten, maar zelf ondervind ik niet echt nadelen met 16T/8GB opslag/geheugen op 1 machine en 10T/4GB op een andere.

Probeerde geen sh*t te starten of zo. Noemde meer voor mijzelf op waarom ik voorlopig ZFS niet zo zie/zag zitten. Zal dat ECC topic eens doornemen. Bedankt!

[dcm360]

albatross schreef op donderdag 11 augustus 2016 @ 17:18:
[...]


Probeerde geen sh*t te starten of zo. Noemde meer voor mijzelf op waarom ik voorlopig ZFS niet zo zie/zag zitten. Zal dat ECC topic eens doornemen. Bedankt!

Geen probleem hoor, het is meer dat het er dus al zeer uitgebreide discussie over is geweest zodanig dat er al een heel topic voor is Overigens moet ik wel toegeven dat ik met het bouwen van de apparaten de verhoudingen 6T/8GB en 4T/4GB had, maar dat de verhoudingen een beetje veranderd zijn met wat uitbreiding en vervanging. En ik zit nu ook met een BTRFS raid5-setje opgescheept omdat ik op deze machine ZFS niet aan de slag kreeg...

[PulsatingQuasar]

Ik heb inmiddels een heel stuk gelezen over de mdraid data scrubbing die synology gebruikt, de mdraid die wordt gebruikt voor je raid op Synology en de enkele BTRFS volume die dan wordt gebruikt waardoor je wel kunt detecteren en niet repareren.

Raid 5/6 werkt tot op heden nog onstabiel als je de wiki van btrfs mag geloven.

Had Synology niet beter de mogelijkheid kunnen bieden om gewoon 2 schijven rechtstreeks door te lussen zodat je in elk geval een btrfs raid mirror kunt maken? Want dat werkt wel stabiel en heb je alle voordelen van BTRFS.

[ShaneV]

PulsatingQuasar schreef op dinsdag 3 januari 2017 @ 11:53:
Ik heb inmiddels een heel stuk gelezen over de mdraid data scrubbing die synology gebruikt, de mdraid die wordt gebruikt voor je raid op Synology en de enkele BTRFS volume die dan wordt gebruikt waardoor je wel kunt detecteren en niet repareren.

Raid 5/6 werkt tot op heden nog onstabiel als je de wiki van btrfs mag geloven.

Had Synology niet beter de mogelijkheid kunnen bieden om gewoon 2 schijven rechtstreeks door te lussen zodat je in elk geval een btrfs raid mirror kunt maken? Want dat werkt wel stabiel en heb je alle voordelen van BTRFS.

Vanaf dsm 6.1 wordt detectie en herstel ondersteunt. https://www.synology.com/nl-nl/beta/2017_DSM61Beta

[SmiGueL]

PulsatingQuasar schreef op dinsdag 3 januari 2017 @ 11:53:
Raid 5/6 werkt tot op heden nog onstabiel als je de wiki van btrfs mag geloven.

Daarom gebruikt Synology deze ook niet.
(bron HWI)

"...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).

En idd in DSM 6.0 werkt alleen data detectie, maar sinds DSM 6.1 (momenteel nog beta) wordt ook de correctie ondersteund.

[ Voor 11% gewijzigd door SmiGueL op 03-01-2017 12:45 ]

[PulsatingQuasar]

Dat 6.1 dat gaat ondersteunen had ik inmiddels gezien( en dat er geen BTRFS RAID wordt gebruikt in 6.0 ook) maar de vraag is hoe?

Door je de mogelijkheid te bieden 2 schijven in Btrfs RAID te zetten? Als ik hun was zou ik zeker nog niet de optie bieden Btrfs RAID 5/6 te ondersteunen zolang de makers zelf zeggen dat de RAID 5/6 code niet goed is.

Of gebruiken ze een of andere vage constructie in combinatie met mdraid? Want de vraag is daarbij dan, hoe robuust is dat?

Wat ik me ook afvraag bij normaal RAID5/6 en MDRAID 5/6. Is er bij dat parity blok geen ruimte meer om een checksum op te nemen?

Wat ik begrijp van een mdraid scrub( na het lezen van de wiki) is dat het een data blok pakt en de parity en daar dan de ontbrekende blok van berekend en zo controleert of het klopt.

https://wiki.archlinux.or...re_RAID_and_LVM#Scrubbing

Maar als alle blokken goed gelezen worden maar de parity berekening wijst uit dat het niet klopt dan is het niet duidelijk welke van de blokken fout is. mdraid repareert dan niets maar signaleert het probleem.

The check operation scans the drives for bad sectors and mismatches. Bad sectors are automatically repaired. If it finds mismatches, i.e., good sectors that contain bad data (the data in a sector does not agree with what the data from another disk indicates that it should be, for example the parity block + the other data blocks would cause us to think that this data block is incorrect), then no action is taken, but the event is logged (see below). This "do nothing" allows admins to inspect the data in the sector and the data that would be produced by rebuilding the sectors from redundant information and pick the correct data to keep.

1) Dat issue zou er niet zijn als er een checksum in de parity verwerkt was in bijvoorbeeld een header
2) Hoe lost Synology dat dan op? Er is geen informatie dat vertelt welke van de blokken goed is. Wat ik lees is dat het me hierover zou moeten informeren maar gebeurd dat ook?

[dcm360]

Een checksum in de parity verwerken lukt sowieso niet, want een parity-block is net als een data-block geheel gevuld met data. Een block heeft ook geen headers.

Een optie die Synology mogelijk toe kan passen om data te repareren heb ik eerder eens beschreven:

dcm360 schreef op donderdag 11 augustus 2016 @ 11:26:
Wat je nog wel zou kunnen doen is de raid-set degraded maken, en van alle combinaties degraded sets pogen de data terug te krijgen (in het geval van de mirror dus 2 combinaties). (Z|BTR)FS kan je vertellen welke combinatie de fout niet geeft. Terugzetten uit een backup lijkt me echter eenvoudiger.

Dit proces (nouja, die laatste zin even daarbuiten) is automatiseerbaar als je weet waar je mee bezig bent. Om het een beetje efficient te houden is wel vrij veel kennis van de werking van btrfs vereist (want iedere keer een volledige scrub kost veel tijd).

[Pierre_nr1]

Vandaag ontvang ik de DS916+(8GB) met de DX513. Deze gaan mijn DS412+ vervangen. De afgelopen dagen heb ik veel proberen te lezen en dan hoofdzakelijk over Btrfs. We zijn weer een tijdje verder, en een aantal DSM versies later. Kan iemand mij adviseren of een duwtje in de richting geven?

Ik heb de volgende hardware:
- DS916+(8GB)
- 4x4TB voor de DS916+ en 5x4TB voor de DX513

Ik wil er het volgende mee doen:
- Opslag van video en muziek. Video speel ik met Plex of via een Samba share
- Downloads met NZBget
- Foto's opslag. (Hier maak ik dagelijks een externe incremental backup van.)

Vragen:
- Welk filesysteem raden jullie mij aan? Btrfs of Ext4?
- 1 groot Raid5 volume? (dus 9x4=36, waarvan 32TB netto te gebruiken)

Wat is wijsheid op dit moment voor een geheel nieuw installatie?

[HollowGamer]

Pierre_nr1 schreef op maandag 22 mei 2017 @ 10:08:
Vandaag ontvang ik de DS916+(8GB) met de DX513. Deze gaan mijn DS412+ vervangen. De afgelopen dagen heb ik veel proberen te lezen en dan hoofdzakelijk over Btfrs. We zijn weer een tijdje verder, en een aantal DSM versies later. Kan iemand mij adviseren of een duwtje in de richting geven?

Ik heb de volgende hardware:
- DS916+(8GB)
- 4x4TB voor de DS916+ en 5x4TB voor de DX513

Ik wil er het volgende mee doen:
- Opslag van video en muziek. Video speel ik met Plex of via een Samba share
- Downloads met NZBget
- Foto's opslag. (Hier maak ik dagelijks een externe incremental backup van.)

Vragen:
- Welk filesysteem raden jullie mij aan? Btfrs of Ext4?
- 1 groot Raid5 volume? (dus 9x4=36, waarvan 32TB netto te gebruiken)

Wat is wijsheid op dit moment voor een geheel nieuw installatie?

Ext4 en Btrfs kun je niet met elkaar vergelijken; beide hebben een ander doel en features.

RAID-5 schijnt nog altijd niet stabiel te zijn op Btrfs, misschien beter om naar ZFS te kijken.

[Pierre_nr1]

HollowGamer schreef op maandag 22 mei 2017 @ 10:19:
[...]

Ext4 en Btrfs kun je niet met elkaar vergelijken; beide hebben een ander doel en features.

RAID-5 schijnt nog altijd niet stabiel te zijn op Btrfs, misschien beter om naar ZFS te kijken.

Zal ik doen, bedankt voor de tip!

Welk filesysteem past het beste in mijn situatie?

[ Voor 7% gewijzigd door Pierre_nr1 op 22-05-2017 11:40 ]

[SmiGueL]

HollowGamer schreef op maandag 22 mei 2017 @ 10:19:
RAID-5 schijnt nog altijd niet stabiel te zijn op Btrfs, misschien beter om naar ZFS te kijken.

Misschien handig om je eerst even in te lezen.

1: Op die Synology kun je geen ZFS draaien.
2: Synology maakt geen gebruik van de (onveilige) RAID5 implementatie van BTRFS, zie ook dit nieuwsbericht.

[ Voor 3% gewijzigd door SmiGueL op 22-05-2017 13:14 ]

[Pierre_nr1]

SmiGueL schreef op maandag 22 mei 2017 @ 13:12:
[...]


Misschien handig om je eerst even in te lezen.

1: Op die Synology kun je geen ZFS draaien.
2: Synology maakt geen gebruik van de (onveilige) RAID5 implementatie van BTRFS, zie ook dit nieuwsbericht.

Is Btrfs dan de betere keus t.o.v. Ext4? Voor wat ik er mee doe.

[rikadoo]

Pierre_nr1 schreef op maandag 22 mei 2017 @ 16:14:
[...]


Is Btrfs dan de betere keus t.o.v. Ext4? Voor wat ik er mee doe.

Lekker btrfs nemen, werkt prima. En synology heeft een super support mocht het toch ooit misgaan.

[HollowGamer]

SmiGueL schreef op maandag 22 mei 2017 @ 13:12:
[...]


Misschien handig om je eerst even in te lezen.

1: Op die Synology kun je geen ZFS draaien.
2: Synology maakt geen gebruik van de (onveilige) RAID5 implementatie van BTRFS, zie ook dit nieuwsbericht.

Dacht dat ZFS inmiddels ook aanwezig was als module.

Is deze workaround dan niet langzamer?

[Q]

Whoa!

Red Hat: BTRFS has been depricated.
https://news.ycombinator.com/item?id=14907771

Ik denk dat dit wel significant is.

[ Voor 17% gewijzigd door Q op 02-08-2017 07:25 ]

[HollowGamer]

@Q zie ook http://phoronix.com/scan....at-Deprecates-Btrfs-Again

Draait hier al jaren zonder problemen in RAID-1. Hoewel ZFS misschien beter mag zijn, was en is het niet in de kernel aanwezig.

Gelukkig zijn er nog grote partijen als FB die volop zetten op Btrfs en zit Oracle volgensmij ook niet stil. Achteraf gezien is het misschien een foute beslissing geweest om niet volledig voor één te kiezen en ZFS een nogal .. licentie te geven.

[twingels]

Zoals het 'Again' al aangeeft, duikt een dergelijk bericht zo af en toe op. Gelukkig geeft Josef Bacik 'zelf' waardevol commentaar. Sinds de patches van Josef in linux kernel 4.8 werken een aantal zaken merkbaar sneller (en ook betrouwbaarder).

Ik heb alle Btrfs raid varianten wel gebruikt en ook ZFS raidz op zowel Linux als FreeBSD. Heb Btrfs ook wel bovenop mdadm gebruikt, maar dan verdwijnt toch een hoop vrijheid als 'disk-jockey'. Onlangs nog een 4TB disk vrijgemaakt uit een raid10 array (en eerst omgezet naar raid1), alles op afstand via remote login. Vooral snapshots, reflinks en send|receive clonen is super! En het werkt ook out-of-the-box op RasberryPI achtige boards.

Verder door Btrfs gebruik (block CRC-checks) falende SDRAM modules in 2 computers ondekt. Ook heb ik jaren terug een paar keer een tijdlang met bitrotte plekken in een DVD image te kampen gehad, zonder dat ik dat doorhad. Toen er echt een verschil bleek tussen de image en de originele DVD was besluit om over te stappen op Btrfs vrij gemakkelijk.

[ Voor 5% gewijzigd door twingels op 06-08-2017 15:13 ]

[Q]

HollowGamer schreef op woensdag 2 augustus 2017 @ 08:45:
@Q zie ook http://phoronix.com/scan....at-Deprecates-Btrfs-Again

Draait hier al jaren zonder problemen in RAID-1. Hoewel ZFS misschien beter mag zijn, was en is het niet in de kernel aanwezig.

Gelukkig zijn er nog grote partijen als FB die volop zetten op Btrfs en zit Oracle volgensmij ook niet stil. Achteraf gezien is het misschien een foute beslissing geweest om niet volledig voor één te kiezen en ZFS een nogal .. licentie te geven.

Het is wat het is.

Maar het RAID debacle met Btrfs gecombineerd met het feit dat Btrfs al zeer lang in ontwikkeling is maar nog lang niet op het niveau van ZFS zit vind ik zelf een reden om Btrfs de komende drie jaar in ieder geval gewoon te negeren.

Gewoon ZFS of MDADM + XFS (met eventueel LVM alls je dat wilt). Prima verder.

[HollowGamer]

Q schreef op zondag 6 augustus 2017 @ 18:59:
[...]


Het is wat het is.

Maar het RAID debacle met Btrfs gecombineerd met het feit dat Btrfs al zeer lang in ontwikkeling is maar nog lang niet op het niveau van ZFS zit vind ik zelf een reden om Btrfs de komende drie jaar in ieder geval gewoon te negeren.

Gewoon ZFS of MDADM + XFS (met eventueel LVM alls je dat wilt). Prima verder.

Ligt eraan wat je bedoeld met niveau en wat voor jou belangrijk is.

Btrfs is stabiel, en werkt prima met RAID 0/1.
Voor andere RAID-configuraties wordt doorgaans dm-raid gebruikt (zie o.a. Synology, die ook al jaren probleemloos met btrfs werkt).

XFS wordt inderdaad steeds belangrijker, maar heb begrepen dat Red Hat gaat inzetten op hun eigen FS dat eigenlijk een soort mix wordt van XFS, btrfs en ZFS (al zal het nog jaren gaan duren). Vlak daarnaast ook ext4 niet uit, hoewel 'verouderd' (ook volgens de maintainer(s)) nog steeds mainstream en enorm stabiel.

ZFS heeft ook zijn tekortkomingen, waarvan Oracle misschien wel de grootste is.

[ Voor 16% gewijzigd door HollowGamer op 06-08-2017 20:04 ]

[A1AD]

HollowGamer schreef op zondag 6 augustus 2017 @ 20:01:
[...]

Ligt eraan wat je bedoeld met niveau en wat voor jou belangrijk is.

Btrfs is stabiel, en werkt prima met RAID 0/1.
Voor andere RAID-configuraties wordt doorgaans dm-raid gebruikt (zie o.a. Synology, die ook al jaren probleemloos met btrfs werkt).

XFS wordt inderdaad steeds belangrijker, maar heb begrepen dat Red Hat gaat inzetten op hun eigen FS dat eigenlijk een soort mix wordt van XFS, btrfs en ZFS (al zal het nog jaren gaan duren). Vlak daarnaast ook ext4 niet uit, hoewel 'verouderd' (ook volgens de maintainer(s)) nog steeds mainstream en enorm stabiel.

ZFS heeft ook zijn tekortkomingen, waarvan Oracle misschien wel de grootste is.

Werkt synology al jaaaren met BTRFS??

[dcm360]

HollowGamer schreef op zondag 6 augustus 2017 @ 20:01:
[...]
Btrfs is stabiel, en werkt prima met RAID 0/1.
Voor andere RAID-configuraties wordt doorgaans dm-raid gebruikt (zie o.a. Synology, die ook al jaren probleemloos met btrfs werkt).

Mwa... Met enkele jaren ervaring met single-disk BTRFS zou ik het een afrader noemen. Het OS wat ik gebruik (OpenSuse) maakt gretig gebruik van de snapshot-functionaliteit van BTRFS, en dat levert me ongeveer eens per maand een read-only filesystem op. De reden: de gereserveerde ruimte voor metadata is te krap bemeten en zit vol. Een betere oplossing dan snapshots verwijderen ben ik nog niet tegengekomen... (Fun-fact: op dat punt segfault bash ook op tab-completion. Best naar). Helaas zie ik het nog niet gebeuren dat er hier een oplossing voor komt.

XFS wordt inderdaad steeds belangrijker, maar heb begrepen dat Red Hat gaat inzetten op hun eigen FS dat eigenlijk een soort mix wordt van XFS, btrfs en ZFS (al zal het nog jaren gaan duren). Vlak daarnaast ook ext4 niet uit, hoewel 'verouderd' (ook volgens de maintainer(s)) nog steeds mainstream en enorm stabiel.

Een interessante vraag gaat dan zijn welke ontwerpkeuzes er voor het nieuwe FS gemaakt gaan worden. En dan met name in hoeverre tekortkomingen in de ontwerpkeuzes voor de bestaande filesystems worden meegenomen, gevolgd door welke doelgroepen er gekozen worden. Ik denk ook dat met name dat het voor enterprise-gebruik lastig gaat zijn om ZFS te overtreffen, waarbij de gewone consument binnentrekken relatief eenvoudig kan zijn bij gebrek aan huidige oplossingen met een laag 'net-niet'-gehalte.

ZFS heeft ook zijn tekortkomingen, waarvan Oracle misschien wel de grootste is.

Vanwege de licentie? Daar kan Oracle naar mijn idee niets aan doen, om de simpele reden dat de huidige licentie minder restrictief is dan de GPL. Er zijn ZFS-stakeholders die er belang bij hebben dat de licentie vrijheden van de CDDL blijft houden, en de licentie omzetten is een alles-of-niets-verhaal: iedereen moet in één keer mee. Juist vanwege de verschillen kunnen er niet een GPL- en CDDL-versie met actieve ontwikkeling (waarbij bugs corrigeren in dit geval ook onder valt) naast elkaar bestaan zonder dat er een juridisch wespennest ontstaat. Daarmee is de licentie veranderen naar mijn idee zelfs de efficiëntste manier om ZFS zo snel mogelijk geschiedenis te maken.

[Tortelli]

A1AD schreef op zondag 6 augustus 2017 @ 22:35:
[...]


Werkt synology al jaaaren met BTRFS??

BTFRS is sinds een dik jaartje te gebruiken op Synology voor zover ik weet.

[A1AD]

Tortelli schreef op maandag 7 augustus 2017 @ 08:25:
[...]


BTFRS is sinds een dik jaartje te gebruiken op Synology voor zover ik weet.

Ja dat dacht ik ook

[CurlyMo]

BTRFS wordt ook al tenminste 2 jaar gebruikt op de Raspberry Pi XBMC distro XBian. Daar werkt het ook prima op.

[twingels]

dcm360 schreef op maandag 7 augustus 2017 @ 00:13:
[...]
Mwa... Met enkele jaren ervaring met single-disk BTRFS zou ik het een afrader noemen. Het OS wat ik gebruik (OpenSuse) maakt gretig gebruik van de snapshot-functionaliteit van BTRFS, en dat levert me ongeveer eens per maand een read-only filesystem op. De reden: de gereserveerde ruimte voor metadata is te krap bemeten en zit vol. Een betere oplossing dan snapshots verwijderen ben ik nog niet tegengekomen... (Fun-fact: op dat punt segfault bash ook op tab-completion. Best naar). Helaas zie ik het nog niet gebeuren dat er hier een oplossing voor komt.

Je kan snapper de-installeren of gewoon de configuraties in /etc/snapper aanpassen naar wens. Het aanmaken en opruimen van snapshots is zeer goed te configureren en gaat helemaal automatisch. De 10 jaar history die standaard in de config files is te vinden is nogal van de zotte inderdaad, maar is bij nieuwe installs van opensuse (met name tumbleweed rolling release) allang niet meer an de orde. Verder is het out of metadata probleem in kernel >=4.8 opgelost, maar niet rolling release gebruikt 4.4.x

Ikzelf gebruik al 2 jaar de combinatie van bcache en btrfs (dus SSD en HDD) De HDD zorgt voor ruime en goedkope capaciteit, de SDD voor snelheid. Met SSD van b.v. 200GB op 4TB HDD merk je na het 'warmlopen' van de cache vrijwel geen verschil tussen alleen SSD. Caching bij ZFS zit ingebouwd, maar na reboot is de cache weer invalid en kun je weer opnieuw beginnen, dat maakte ZFS voor mij veel te langzaam voor thuisgebruik.

[twingels]

CurlyMo schreef op maandag 7 augustus 2017 @ 11:12:
BTRFS wordt ook al tenminste 2 jaar gebruikt op de Raspberry Pi XBMC distro XBian. Daar werkt het ook prima op.

Ik heb een maand of wat geleden van een oorsponkelijk kaal install image voor BananaPi pro op een 64GB SDkaartje al het ext4 omgezet naar btrfs (behalve bootloader gedeelte). Deze Pi heeft Sata en Gbit ethernet en is ARM/linux DeviceTree geschikt, dus zonder omkijken en gedoe de laatste kernel. Ideaal als simpel extra servertje zoals b.v. die WDbooks van een tijdje terug.

[dcm360]

twingels schreef op dinsdag 8 augustus 2017 @ 17:35:
[...]


Je kan snapper de-installeren of gewoon de configuraties in /etc/snapper aanpassen naar wens. Het aanmaken en opruimen van snapshots is zeer goed te configureren en gaat helemaal automatisch. De 10 jaar history die standaard in de config files is te vinden is nogal van de zotte inderdaad, maar is bij nieuwe installs van opensuse (met name tumbleweed rolling release) allang niet meer an de orde. Verder is het out of metadata probleem in kernel >=4.8 opgelost, maar niet rolling release gebruikt 4.4.x

Hm, oke, interessant, daar moet ik dan eens induiken wat er nog mis loopt. De kernel die ik heb zou nieuw genoeg moeten zijn (namelijk 4.12), maar het is wel Opensuse 42.2 welke ooit begonnen is als 13.1, en dat is denk ik het issue dan. Of ik laat het zitten, aangezien ik van plan ben deze maand een nieuwe pc te bouwen

[twingels]

dcm360 schreef op woensdag 9 augustus 2017 @ 00:40:
[...]

Hm, oke, interessant, daar moet ik dan eens induiken wat er nog mis loopt. De kernel die ik heb zou nieuw genoeg moeten zijn (namelijk 4.12), maar het is wel Opensuse 42.2 welke ooit begonnen is als 13.1, en dat is denk ik het issue dan. Of ik laat het zitten, aangezien ik van plan ben deze maand een nieuwe pc te bouwen

Inderdaad, je gebruikt nog steeds de oude config files van 13.1 denk ik. Ook wellicht nog een oude subvolume structuur. De nieuwe subvolume structuur (tumbleweed mid 2016) is zodanig dat het geheel voor allerhande architecture, bootmethodes etc min of meer portable is. Wordt door gebruikers die ook hun eigen admin zijn soms als overdaad gezien. Ikzelf heb o.a. virtuele machine images niet in rootfilesystem en heb uiteindelijk voor bestaande en ook weer nieuwere installs wel de zelfde basisstructuur aangehouden, dus apenstaartje in root van filesystem etc, maar verder simpelweg de complete roottree zoals bij ext4 in 1 subvolume gekopieerd/gekloond en dat als default subvolume gezet. grub2 even draaien en voila. Je kan dan ook superefficent installaties van bestaande PC's clonen naar nieuwe (met gebruikmaking van differential send receive o.a.).

[CurlyMo]

En je kan makkelijk booten van een ander filesystem zoals bij ZFS.

[chronoz]

Zou dit moeten helpen bij het snel houden van de raid array? Want bij mijn vorige Synology erg hij enorm traag, maar dan heeft ook duizenden historische snapshots gehad.

Ik wilde de commando's ook wel draaien op /volume1, maar dat zijn SSD's en die hebben al genoeg writes gehad.

[twingels]

chronoz schreef op woensdag 16 augustus 2017 @ 05:39:
Zou dit moeten helpen bij het snel houden van de raid array? Want bij mijn vorige Synology erg hij enorm traag, maar dan heeft ook duizenden historische snapshots gehad.

Ik wilde de commando's ook wel draaien op /volume1, maar dat zijn SSD's en die hebben al genoeg writes gehad.

Scrub checkt alle blokken op checksum error, kan dus 'bitrot' detecteren, maar her-ordent niks.

Defragment maakt bestand extents weer sequentieel, standaard niet uitputtend, maar waar ervaringsgewijs zin heeft. Op SSD heeft dat dus weinig zin.

Balance doet op een lager niveau (de laag tussen bestanden en blockdevice) een compactie van (meestal 1GiB grote) chunks. Het balance mechanisme is primair bedoelt om allocatie tussen raid-members onderling (weer) gelijkmatig te maken, nadat b.v. een disk is toegevoegd aan array.

Bij een vrij nieuw bestandssysteem heeft een balance van aleen de datachunks ook tot gevolg dat de fragmetatie in de metadata chunks toeneemt, wat seektijden (op HDD) doet toenemen.

Te veel snapshots en reflinks kunnen btrfs bestandsysteem en acties erg traag maken. Meestal is een paarhonderd snapshots goed te doen, maar duidenden, vooral als het HDD is zonder vorm van SSD caching o.i.d., is vragen om moeilijkheden. Snapshots maken is heel snel en 'goedkoop', maar dan b.v. een zoekopdracht over hele bestandssysteem kan dan zeer lang duren. Kortom, verwijder alle snapshots niet echt nodig zijn; Hoe ouder hoe groter de afstand in de tijd is het devies. Er zijn tools voor die dat prima automatisch doen, ik weet niet of die ook in Synology ingebed zijn.

[Verwijderd]

Weet iemand hoe dat zit met "data integrity" features voor wat betreft BTRFS op een enkele schijf? Moet je hier altijd RAID voor gebruiken?

Ik twijfel tussen EXT4 en BTRFS maar vraag me af of BTRFS voordelen voor mij bied. Ik wil 3 schijven in een NAS stoppen en geen RAID toeppassen (JBOD).

[CurlyMo]

Als je checksums, snapshots en copy-on-write ook als onderdeel van data integriteit ziet dan heb je die voordelen ook bij een enkele schijf.

[Verwijderd]

CurlyMo schreef op dinsdag 12 september 2017 @ 07:20:
Als je checksums, snapshots en copy-on-write ook als onderdeel van data integriteit ziet dan heb je die voordelen ook bij een enkele schijf.

Checksums zijn volgens mij dan overbodig in mijn geval, want waar wordt redundante data vandaan gehaald voor herstel als die niet aanwezig is. Volgens een stukje tekst van Synology wat ik heb gevonden heb je daar RAID voor nodig. Snapshots vind ik meer beschikbaarheid maar ik snap je punt. Copy-on-write heb ik niet nodig want ik ben de enige gebruiker .

[ Voor 8% gewijzigd door Verwijderd op 12-09-2017 17:35 ]

[CurlyMo]

Verwijderd schreef op dinsdag 12 september 2017 @ 17:33:
[...]

Checksums zijn volgens mij dan overbodig in mijn geval, want waar wordt redundante data vandaan gehaald voor herstel als die niet aanwezig is.

Hangt van de oorzaak van je datacorruptie af. Als er meerdere copieën van je metadata zijn (zoals je dat bij ZFS wel kan instellen), dan kan data ook in een enkele schijf opstelling gecorrigeerd worden. Daarnaast is het natuurlijk ook fijn om te weten of bepaalde data corrupt is (ondanks dat het wel of niet automatisch hersteld kan worden). Dat kan BTRFS je sowieso vertellen.

Volgens een stukje tekst van Synology wat ik heb gevonden heb je daar RAID voor nodig. Snapshots vind ik meer beschikbaarheid maar ik snap je punt.

Hangt er vanaf wat je data-integriteit aantast. Dat kan ook een virus zijn. Dan helpen snapshots daar wel tegen.

Stukje over foute uitleg CoW weggehaald om geen verkeerde informatie te verspreiden

[ Voor 33% gewijzigd door CurlyMo op 12-09-2017 20:10 ]

[Thralas]

Die uitleg raakt kant noch wal voor wat betreft CoW. Traditionele filesystems onderhouden gewoon een journal om zaken als powerloss te ondervangen en 'atomic' updates te bieden, dus daar biedt het echt niets nieuws.

Copy on Write (CoW) van de BTRFS wiki is een stuk duidelijker dan ik het kan verwoorden.

Je kunt met CoW zaken als snapshots een stuk makkelijker implementeren. Zeggen dat je CoW niet 'nodig' hebt is mal, het is een van de pijlers waarop BTRFS gebouwd is. Het is alleen zinnig om het (selectief) uit te zetten bij grote files (virtual machine disks ed.) om fragmentatie te voorkomen.

[twingels]

Verwijderd schreef op dinsdag 12 september 2017 @ 17:33:
Checksums zijn volgens mij dan overbodig in mijn geval, want waar wordt redundante data vandaan gehaald voor herstel als die niet aanwezig is.
[...]

Op een enkele schijf worden systeem en metadata standaard dubbel weggeschreven, dus als er b.v. in de eerste copie van een metadata blok een bad sector optreedt, kan btrfs dat automatisch fixen aan de hand van de 2de copie die pseudo random ergens anders op de harddisk gelocatliseerdt is.

Verder kun je met
mkfs.btrfs -d dup <blockdevice>

tegenwoordig ook data dubbel forceren, wat dan een soort raid1 op 1 harde schijf bewerkstelligt. Je hebt dan natuurlijk maar de helft van de capaciteit meer over, maar b.v. op een grote oude hardeschijf met al wat bitrot hier en daar kan dat handig zijn, b.v. als cold storage / extra backup.

[jantje112]

Ik wil mijn storage opnieuw inrichten. Ik kom nu van een Xpenology en een Synology 115j als backup.

Zijn er al enigszins betrouwbare BTRFS oplossingen? Het niet kunnen uitbreiden bij ZFS is voor mij een enorm minpunt..

[CaDje]

jantje112 schreef op dinsdag 28 mei 2019 @ 15:04:
Ik wil mijn storage opnieuw inrichten. Ik kom nu van een Xpenology en een Synology 115j als backup.

Zijn er al enigszins betrouwbare BTRFS oplossingen? Het niet kunnen uitbreiden bij ZFS is voor mij een enorm minpunt..

Je kunt eens naar Unraid kunnen kijken.

[jantje112]

CaDje schreef op dinsdag 28 mei 2019 @ 15:10:
[...]


Je kunt eens naar Unraid kunnen kijken.

Jaren geleden met Unraid gewerkt. Op zich een redelijk systeem, maar het heeft niet de performance van een echte Raid setup.

[CaDje]

jantje112 schreef op dinsdag 28 mei 2019 @ 15:29:
[...]


Jaren geleden met Unraid gewerkt. Op zich een redelijk systeem, maar het heeft niet de performance van een echte Raid setup.

Dat klopt, je kunt met de plugin Turbo Write Mode de schrijf snelheid wel verhogen, en cache SSD's helpen ook enorm.

Ik weet even niet wat de huidige status is van RAID 5/6 op BTRFS, anders is volgens mij Rockstor wellicht een optie.

[dnzm]

CaDje schreef op dinsdag 28 mei 2019 @ 15:36:
[...]
Ik weet even niet wat de huidige status is van RAID 5/6 op BTRFS, anders is volgens mij Rockstor wellicht een optie.

RAID5/6 op BTRFS is al een tijdje "mostly stable, behalve als...". Iemand heeft de moeite genomen om ZFS, BTRFS en MDADM+DM-integrity naast elkaar te leggen. TL;DR: als er één schijf uitklapt is er niks aan de hand, maar na een unclean shutdown een ook nog een schijf verliezen kan tot dataverlies lijden. Het beruchte write-hole dus, en daar is BTRFS niet eens uniek in.

Persoonlijk draai ik nu al een beste tijd Rockstor met RAID1 (over 3 schijven), maar ik ga binnenkort wel over op RAID5, aangezien ik de kans op een dubbel-fuckup niet zo heel groot acht, en RAID5 dan wel weer efficiënter met de ruimte omgaat dan RAID1.

Rockstor zelf draait verder wel OK, al is de zichtbare ontwikkeling momenteel wat traag - standaard zit je nog steeds met een vrij oude kernel, bijvoorbeeld. Het is wel mogelijk om zelf een nieuwere kernel te installeren, en de ontwikkelaars zijn druk doende om het systeem om te batterijen van een CentOS-basis naar een OpenSUSE-basis, waarna updates ook weer makkelijker zouden moeten worden.

[twingels]

dnzm schreef op maandag 15 juli 2019 @ 09:26:
[...]

Persoonlijk draai ik nu al een beste tijd Rockstor met RAID1 (over 3 schijven), maar ik ga binnenkort wel over op RAID5, aangezien ik de kans op een dubbel-fuckup niet zo heel groot acht, en RAID5 dan wel weer efficiënter met de ruimte omgaat dan RAID1.

Rockstor zelf draait verder wel OK, al is de zichtbare ontwikkeling momenteel wat traag - standaard zit je nog steeds met een vrij oude kernel, bijvoorbeeld. Het is wel mogelijk om zelf een nieuwere kernel te installeren, en de ontwikkelaars zijn druk doende om het systeem om te batterijen van een CentOS-basis naar een OpenSUSE-basis, waarna updates ook weer makkelijker zouden moeten worden.

Ik heb me altijd nogal verbaasd over Rockstor, dat als BTRFS storage de kern van je product is, er dan een distro wordt gekozen/gebruikt waarbij de BTRFS code dan altijd achter loopt vanwege een niet mainline kernel. Maargoed, men wist toen men begon wellicht niet dat BTRFS in 3.x kernels niet echt solide was.

Kwa raid56 of RAID in het algemeen, heb je wel eens overwogen om geen RAID te gebruiken maar de redundancy met clone (send | receive) te doen?

[dnzm]

twingels schreef op dinsdag 6 augustus 2019 @ 20:48:
[...]

Ik heb me altijd nogal verbaasd over Rockstor, dat als BTRFS storage de kern van je product is, er dan een distro wordt gekozen/gebruikt waarbij de BTRFS code dan altijd achter loopt vanwege een niet mainline kernel. Maargoed, men wist toen men begon wellicht niet dat BTRFS in 3.x kernels niet echt solide was.

Nee, volgens mij was dat toen allemaal nog niet allemaal even ver uitgekristalliseerd. Het zal ongetwijfeld ook de reden zijn dat men nu aan het overstappen is van CentOS naar SUSE.

Kwa raid56 of RAID in het algemeen, heb je wel eens overwogen om geen RAID te gebruiken maar de redundancy met clone (send | receive) te doen?

Hm, nee. Wat zou daar het voordeel van zijn t.o.v. RAID?

Overigens heb ik dat RAID5-plan laten varen, de winst in schijfruimte is leuk, maar het grotere risico (hoe miniem ook) en het feit dat het op een simpel Celeronnetje waarschijnlijk geen snelheidsrecords gaat breken als er eens gerepareerd of gerebalanced moet worden, houdt me toch een beetje tegen.

Het is nou ook niet meteen zo dat ik tientallen terabytes over een dozijn schijven heen heb slingeren, of zo.

[twingels]

dnzm schreef op dinsdag 6 augustus 2019 @ 22:08:
[...]
Hm, nee. Wat zou daar het voordeel van zijn t.o.v. RAID?

Overigens heb ik dat RAID5-plan laten varen, de winst in schijfruimte is leuk, maar het grotere risico (hoe miniem ook) en het feit dat het op een simpel Celeronnetje waarschijnlijk geen snelheidsrecords gaat breken als er eens gerepareerd of gerebalanced moet worden, houdt me toch een beetje tegen.

Het is nou ook niet meteen zo dat ik tientallen terabytes over een dozijn schijven heen heb slingeren, of zo.

Ik had in 2014 ook BTRFS raid5, dat was toen wel snel omdat het infeite RAID0 was (3x 2TB). Er viel in de praktijk namelijk weinig te repareren omdat dat nog nauwelijk geimplementeerd was. Maar ook later met 3x 500GB als test was een balance een kwestie van dagen. Dus mocht een schijf kapot gaan, dan was er gewoon geen werkende NAS en was de backup op XFS de NAS.
Hetzelfde met de huidige implementatie van raid56 is denk ik niet meer zo traag, maar dat weet je pas na een jaar ofzo als er flink wat fragmentatie is.

Als ik zo bekeek aan schijven die ik had (en heb), is het in de praktijk met BTRFS raid nog nooit echt tot auto-repair gekomen. BTRFS kent geen bad sectors, als dan 2x HDD raid1 profile de HDD firmware van een bepaalde sector echt niet meer correcte bits binnen 7 of 30 of 180 seconden kan ophoesten, heb je lang gewacht en komt het gelukkig van de andere HDD. Maar wat doe je als een HDD met de eerste read fail en sector remapping op de proppen komt. Policy is vaak dat schijven al ruim van te voren vervangen worden.
Daarnaast zijn er csums en scrub. Een scrub resultaat zal een besluitmoment zijn voor e.v.t. vervanging van een schijf.
Als je nu maar 1 HDD profile single gebruikt en die cloned (incremental send receive van snapshots) per zoveel uur of dag naar ander HDD single profile, dan worden csums ook gecheckt voor de gelezen data. Mocht de hoofd/master HDD kapot gaan, dan schijven wisselen ( en schijf kopen, nieuwe clone trekken). Dit is natuutlijk niet hotswap zoals bij RAID, maar hoe vaak komt het voor en mag je NAS nooit een keer een kwartiertje uit als het nodig is.
De clone target (computer) kun je in sleep zetten tussendoor, de NAS (master/source) uitrusten met de snelste/nieuwste HDD, e.v.t. met bcache of lvmcache.
Verder is BTRFS raid1 lezen niet parallel per task, dus als het weinig multiuser is, is het kwa snelheid niet echt een voordeel. Grootste snelheidsverlies is fragmentatie. Een nieuwe clone inzetten is ook een soort van defragmentatie. Strak subvol beleid, snapshots en clone-scripts zijn wel essentieel. Maar op die manier is een clone ook gelijk een backup. Vooral als al je data wel op 1 HDD past, werkt dit prima kan ik zeggen.

[dnzm]

Zo, dat is even een best antwoord.

twingels schreef op woensdag 7 augustus 2019 @ 18:02:
[...]

Ik had in 2014 ook BTRFS raid5, dat was toen wel snel omdat het infeite RAID0 was (3x 2TB). Er viel in de praktijk namelijk weinig te repareren omdat dat nog nauwelijk geimplementeerd was. Maar ook later met 3x 500GB als test was een balance een kwestie van dagen. Dus mocht een schijf kapot gaan, dan was er gewoon geen werkende NAS en was de backup op XFS de NAS.
Hetzelfde met de huidige implementatie van raid56 is denk ik niet meer zo traag, maar dat weet je pas na een jaar ofzo als er flink wat fragmentatie is.

Een paar dagen voor een rebalance van 3x500GB vind ik ruimschoots in de categorie "mijn god, dit duurt te lang" vallen. Mogelijk is het intussen iets sneller, maar voor RAID5/6 is het natuurlijk strikt afhankelijk van je CPU (want die moet de parity berekenen) en in mijn geval is dat een tweekoppige Celeron. Au.

Als ik zo bekeek aan schijven die ik had (en heb), is het in de praktijk met BTRFS raid nog nooit echt tot auto-repair gekomen. BTRFS kent geen bad sectors, als dan 2x HDD raid1 profile de HDD firmware van een bepaalde sector echt niet meer correcte bits binnen 7 of 30 of 180 seconden kan ophoesten, heb je lang gewacht en komt het gelukkig van de andere HDD. Maar wat doe je als een HDD met de eerste read fail en sector remapping op de proppen komt. Policy is vaak dat schijven al ruim van te voren vervangen worden. Daarnaast zijn er csums en scrub. Een scrub resultaat zal een besluitmoment zijn voor e.v.t. vervanging van een schijf.

Dat is bij geleidelijke faal, ja Als een schijf om redenen besluit er ineens mee te kappen, dan heb je die waarschuwing niet en dan komt het toch op je parity aan. Ik ben an sich wel met je eens dat je de gezondheid van je schijven een beetje in de gaten moet houden, hoor, en in een bedrijfssetting is dat zeker een noodzaak en een in te plannen dingetje. Voor thuis ligt dat iets lastiger, je hebt niet altijd tijd, je bent eens op vakantie, noem maar wat.

Als je nu maar 1 HDD profile single gebruikt en die cloned (incremental send receive van snapshots) per zoveel uur of dag naar ander HDD single profile, dan worden csums ook gecheckt voor de gelezen data. Mocht de hoofd/master HDD kapot gaan, dan schijven wisselen ( en schijf kopen, nieuwe clone trekken). Dit is natuutlijk niet hotswap zoals bij RAID, maar hoe vaak komt het voor en mag je NAS nooit een keer een kwartiertje uit als het nodig is.
De clone target (computer) kun je in sleep zetten tussendoor, de NAS (master/source) uitrusten met de snelste/nieuwste HDD, e.v.t. met bcache of lvmcache.

Mja, OK, ik snap de methodiek, maar ik zie niet helemaal in hoe dit verschilt van RAID1, behalve dat er meer werk en vertraging in zit. Zeker als je het met een aparte machine gaat doen neigt het IMO meer naar een backup dan naar kale redundantie (maar dat geef je zelf ook al aan).

Verder is BTRFS raid1 lezen niet parallel per task, dus als het weinig multiuser is, is het kwa snelheid niet echt een voordeel. Grootste snelheidsverlies is fragmentatie. Een nieuwe clone inzetten is ook een soort van defragmentatie. Strak subvol beleid, snapshots en clone-scripts zijn wel essentieel. Maar op die manier is een clone ook gelijk een backup. Vooral als al je data wel op 1 HDD past, werkt dit prima kan ik zeggen.

Ik hoor wat je zegt, maar zoals ik hierboven al aangaf, zie ik nog niet echt in wat dan de meerwaarde is t.o.v. RAID1, waarbij RAID1 makkelijker schaalt (ik kan de array met één enkele schijf uitbreiden om er capaciteit bij te krijgen, in jouw scenario moet het per 2).

Dat BTRFS RAID1 niet parallel is, is nieuw voor me. Niet dat ik dat voor mijn workload echt mis, maar wel iets om in het achterhoofd te houden.

In ieder geval bedankt voor je uiteenzetting zover!

[twingels]

dnzm schreef op vrijdag 9 augustus 2019 @ 09:32:
Mja, OK, ik snap de methodiek, maar ik zie niet helemaal in hoe dit verschilt van RAID1, behalve dat er meer werk en vertraging in zit. Zeker als je het met een aparte machine gaat doen neigt het IMO meer naar een backup dan naar kale redundantie (maar dat geef je zelf ook al aan).

Het is zeker meer werk, vooral omdat je scripts moet maken rond 'btrfs sub snap' en 'btrfs send' en 'ssh xhost btrfs receive' enz. Maar met 2 woonlocaties, 1000 kilometer ertussen, slechte / trage internetverbinding en toch niet met harde schijven heen en weer willen slepen bedenk je wel eens wat. Ik had in begin op beide plekken RAID en nog losse backup, dus soort van 6 kopieen, maar jaren terug ging er eerder een BTRFS bestandssysteem kapot/corrupt dan dat een HDD kapot ging, althans dat is mijn ervaring. Ik heb ook wel eens aan de code lopen sleutelen, dan gaat er wel eens wat mis en is een 'kloon-NAS' erg handig

Maar fundamenteel is de redundantie geografisch gescheiden, wat met RAID niet zo is. Wederzijdse synchronisatie lukte wel binnen een nacht kwa veranderingen aan datahoeveelheid. Dus er is redundantie op file-niveau en met minder HDDs. Ik heb ook gekeken naar / getest met glusterfs, maar dat viel af.

[twingels]

dnzm schreef op vrijdag 9 augustus 2019 @ 09:32:
Een paar dagen voor een rebalance van 3x500GB vind ik ruimschoots in de categorie "mijn god, dit duurt te lang" vallen. Mogelijk is het intussen iets sneller, maar voor RAID5/6 is het natuurlijk strikt afhankelijk van je CPU (want die moet de parity berekenen) en in mijn geval is dat een tweekoppige Celeron. Au.

Het was vooral de grote hoeveelheid herlezen van enkele sectoren, het overgrote deel van de tijd is HDD seektime. Ooit had Chris Mason (nu Facebook) een eerste implementatie op enterprise SSDs gedaan, toen viel het niet echt op. Met b.v. 3 schijven en flink fragmentatie krieeg je steeds met de seektijd van de 3 opgeteld te maken voor zover ik mij herininner.
Die parity berekening was vroeger echt een enorme klus, maar is tegenwoordig echt geen bottleneck, als je tenminste de juiste pipelining in het scrub process hebt. Maar je zou het moeten meten voor type Celeron waar het om gaat.

[Keeper of the Keys]

Dit is absoluut geen poging om een flame-war te ontketenen tussen da aanhangers van OpenZFS (ZoL) en btrfs.

Op dit moment ben ik een GlusterFS systeem aan het opzetten en ik wil graag een CoW filesystem gebruiken voor de lokale datastore op de nodes zodat er makkelijke (en goedkope) snapshots zijn, btrfs trekt me meer aan dan ZFS.

Maar ik maak me een beetje zorgen over de toekomst van btrfs, aan de ene kant wordt het goed ondersteund en zit het in de kernel aan de andere kant heeft Red Hat het laten vallen, zou graag de inzichten van jullie willen horen.

[freggy]

Lees dit eens, het gaat over het gebruik van BTRFS binnen Facebook: https://lwn.net/Articles/824855/

Er is ook sprake van dat de volgende Fedora-versie default BTRFS zou gebruiken.

Als je rekening houdt met de gekende beperkingen (gebruik geen COW voor databases, RAID5 is niet stabiel, QGroups hebben op dit moment nog performantieproblemen, dus gebruik ze ook bij voorkeur niet indien niet nodig,...), dan is BTRFS perfect bruikbaar.

[MainframeX]

Waarom dit überhaupt afvragen wanneer je dezelfde features in een toekomst vast systeem als zfs kan krijgen? Waarom spreekt btrfs je meer aan dan ZoL?

[Anthirian]

Ik heb begrepen dat Red Hat btrfs heeft aangemerkt als deprecated omdat ze bij elke nieuwe release een enorme git rebase moesten doen om het in het OS te verwerken. Dat gekoppeld met het feit dat ze zelf te weinig kennis aan boord hebben over btrfs heeft ze dit doen besluiten. Ik kan het artikel even niet terugvinden maar stond volgens mij op Hacker News.

[Cyphax]

@Keeper of the Keys
Ik heb je topic en de reacties verplaatst naar het algemene BTRFS-topic om fragmentatie te voorkomen.

[Q]

Keeper of the Keys schreef op zondag 2 augustus 2020 @ 15:20:
Dit is absoluut geen poging om een flame-war te ontketenen tussen da aanhangers van OpenZFS (ZoL) en btrfs.

Op dit moment ben ik een GlusterFS systeem aan het opzetten en ik wil graag een CoW filesystem gebruiken voor de lokale datastore op de nodes zodat er makkelijke (en goedkope) snapshots zijn, btrfs trekt me meer aan dan ZFS.

Maar ik maak me een beetje zorgen over de toekomst van btrfs, aan de ene kant wordt het goed ondersteund en zit het in de kernel aan de andere kant heeft Red Hat het laten vallen, zou graag de inzichten van jullie willen horen.

Ik begrijp dat GlusterFS (zelf nooit gebruikt) standaard LVM snapshots lijkt te maken, dat is niet wat je wilt?

[_JGC_]

Anthirian schreef op zondag 2 augustus 2020 @ 17:16:
Ik heb begrepen dat Red Hat btrfs heeft aangemerkt als deprecated omdat ze bij elke nieuwe release een enorme git rebase moesten doen om het in het OS te verwerken. Dat gekoppeld met het feit dat ze zelf te weinig kennis aan boord hebben over btrfs heeft ze dit doen besluiten. Ik kan het artikel even niet terugvinden maar stond volgens mij op Hacker News.

Dat is niet de schuld van btrfs.

Redhat bouwt zijn Enterprise versies op zwaar aangepaste kernel versies. RHEL8 is op basis van 4.18, welke geen longterm release is, mogen ze zelf onderhouden. Btrfs wordt ontwikkeld op git master en bugfixes worden gebackport naar eerdere ondersteunde versies. Redhat mag dat dus zelf doen, en dat komt nog bovenop hun eigen kernel aanpassingen. Als ze daar niet de kennis voor in huis hebben wil je dat niet als feature aanprijzen in een enterprise distributie lijkt me.

[Keeper of the Keys]

MainframeX schreef op zondag 2 augustus 2020 @ 16:52:
Waarom dit überhaupt afvragen wanneer je dezelfde features in een toekomst vast systeem als zfs kan krijgen? Waarom spreekt btrfs je meer aan dan ZoL?

Ik heb begrepen dat btrfs volumes wat flexibeler zijn dan zdevs en dit systeem is mogelijk aan veranderingen onderhevig, daarnaast hebben kernel extensies die zoals ZoL worden beheerd (buiten mainline) in het verleden problemen opgeleverd die niet fijn waren.

That being said weet ik dat Lustre tegenwoordig de voorkeur aan ZoL geeft over lustrefs (ext4).

[Keeper of the Keys]

Q schreef op maandag 3 augustus 2020 @ 01:12:
[...]


Ik begrijp dat GlusterFS (zelf nooit gebruikt) standaard LVM snapshots lijkt te maken, dat is niet wat je wilt?

Ik wilde minder abstractie lagen over elkaar leggen maar als btrfs geen goede optie blijkt dan zou het best kunnen dat het LVM+fs wordt.

/Edit - Er is een patch geschreven voor btrfs/zfs snapshots in GlusterFS maar die is kennelijk nooit gemerged en doodgebloed

[ Voor 15% gewijzigd door Keeper of the Keys op 03-08-2020 08:30 ]

[Borromini]

Ik gebruik zelf btrfs als root op m'n laptop en thuisserver. Snapper om de snapshots af te handelen. Dat werkt allemaal netjes, alleen kuist snapper de snapshots niet op (lijkt in veel situaties een bekend probleem te zijn).

Ik heb ook een server met ZFS en snapshotting draaien, dat ding heeft nog nooit lopen klagen dat ie geen ruimte meer had.... Maar goed. BTRFS is in-tree. Ik ga voor m'n root niet beginnen klooien met ZFS.

[Anthirian]

_JGC_ schreef op maandag 3 augustus 2020 @ 01:39:
[...]

Dat is niet de schuld van btrfs.

Redhat bouwt zijn Enterprise versies op zwaar aangepaste kernel versies. RHEL8 is op basis van 4.18, welke geen longterm release is, mogen ze zelf onderhouden. Btrfs wordt ontwikkeld op git master en bugfixes worden gebackport naar eerdere ondersteunde versies. Redhat mag dat dus zelf doen, en dat komt nog bovenop hun eigen kernel aanpassingen. Als ze daar niet de kennis voor in huis hebben wil je dat niet als feature aanprijzen in een enterprise distributie lijkt me.

Klopt, dat wilde ik ook aangeven met mijn post. RHEL heeft dit aan zichzelf te wijten.

EDIT: dit was overigens desbetreffende discussie: https://news.ycombinator.com/item?id=14907771

[ Voor 6% gewijzigd door Anthirian op 03-08-2020 10:22 ]

[Q]

Keeper of the Keys schreef op maandag 3 augustus 2020 @ 06:57:
[...]


Ik wilde minder abstractie lagen over elkaar leggen maar als btrfs geen goede optie blijkt dan zou het best kunnen dat het LVM+fs wordt.

/Edit - Er is een patch geschreven voor btrfs/zfs snapshots in GlusterFS maar die is kennelijk nooit gemerged en doodgebloed

Ik denk dat er niets mis is om gewoon LVM te gebruiken, zeker als dit 100% door GlusterFS gesupport wordt.

[Mars Warrior]

Zijn er hier nog mensen die al wat langere tijd ervaring hebben met BTRFS icm Docker?

Ik heb die combi uitgeprobeerd op een klein Fujitsu bakje met enkel een SSD erin, maar dat levert dus op alle Docker & database volumes een CPU load van ruim 30% op.

Nu heb ik COW niet uitgeschakeld, wat wel had gekund natuurlijk, maar ik ben voor die server weer terug naar het aloude ext4, en dus ook weer terug naar < 1 % CPU load.

Het nut van BTRFS ontgaat mij dus om docker containers/data/volumes/binds met BTRFS te doen en te snapshotten, want deze CPU load is onacceptabel.

Backup wordt dus op de bestaande manier met Duplicati gedaan.

[menn0]

De situatie;

Had 4 hdds btrfs in een bananpi met icebox case.
1,5 tb x3
14tb x1

Nu wiilde ik de 14 tb die voor 6tb vol stond in een ander systeem zetten.
De 3 1,5tb schijven waren voor ongeveer 3GB gevuld.

Ik dacht dat ze JBOD zaten in het systeem en ben met btrfs delete devid 1, devid 2 de 1,5tbs aan het verwijderen.

Toen wilde ik dev 3 (laatste 1,5tb) schijf verwijderen en kreeg ik de melding dat het niet kon omdat het een RAID1 opstelling betrof.

Ok dat wist ik niet meer, maar goed, even doorpakken met het volgende commando;

code:

btrfs balance start -f -sconvert=dup -mconvert=dup -dconvert=single /STORAGE

Dit ratelt nu al lekker 2 dagen,
Achteraf, was er nou iets wat ik beter had kunnen doen? Had ik een soort van balance of actie kunnen uitvoeren waardoor ik veel sneller de system en meta data en 'echte' data van de laatste 1,5tb naar de grote schijf had kunnen moven?

Ik begrijp overigens ook niet helemaal hoe de data toen zo slecht verdeeld was over de schrijven, data op deze opslag was een soort vault. Dus zo goed als nooit gebruikt.