Het grote ZFS topic

[BartNL]

Verwijderd schreef op zaterdag 12 maart 2016 @ 13:23:
Dus nee dank je. We leven in 2016 - ik wil betrouwbare opslag. Dat betekent per definitief een 3e generatie filesystem zoals ZFS. Kom nou toch, dat ga je toch niet bagatelliseren?!

nou dat doen Microsoft en Apple wel voor mij

Ik heb al een tijd een ZFS systeem draaien onder Freenas en de nadelen (specifiek write performance die voor mijn 10Gb netwerk niet volstaat) wegen voor mij tot dusver zwaarder dan bovenstaand voordeel. Mijn FreeNas server is tot dusver niet meer dan een probeersel. Wanneer ik 1Gb ok zou vinden, of FreeNas 10Gb zou bijhouden, was ik waarschijnlijk wel om.

[Brent]

Q schreef op zaterdag 12 maart 2016 @ 14:49:
[...]


Die link gaat naar informatie die niet specifiek is betreffende harde schijven maar gaat over alle componenten. Ik ken die bronnen.

Doet dat er wat toe?

Dat is waar, maar waar zijn de harde bronnen. Een van de onderzoeken waar je op uit zult komen is die van NetApp en een van Cern. Die van Cern had te maken met een firmware bug in een disk. Dat is een uitzonderlijke situatie die zelden voor komt.

Die firmware bug is weer een andere studie, die valt niet onder de 1kB/1TB/6maand die ik noemde.

Er wordt redelijk wat gepubliceerd op het gebied van data integriteit, hier een statistiek van 1bit/M:
http://lekythos.library.u...19/ECDL038.pdf?sequence=1

Anekdotisch is er ook bewijs zat, zoals hier wel vermeld.

De scope hier is silent data corruptie door rotte storage, RAM geheugen valt hier buiten.

De scope is corruptie wmb, onderdeel doet er niet toe.

Ik heb blijkbaar onder een steen gelegen wat silent data corruptie betreffende disks betreft.

Ik heb grofweg een petabyte aan scrubs gedaan over mijn hardware en nog nooit een CRC issue gezien. Ik kan geen bronnen vinden die bewijzen dat de risico's waar ZFS tegen meent te beschermen echt substantieel zijn. Zo substantieel, dat ik er als thuis gebruiker mij zorgen over zou maken.

CERN dus over 97PB.

Je insinueert dat NTFS, EXT4, XFS met legacy hardware/software RAID anno 2016 niet (meer) betrouwbaar is en dat is niet waar. Voor thuis gebruik zijn die platformen ook acceptabel. Het is niet zo goed als ZFS, maar acceptabel.

Als je bitrot acceptabel vind.

Ik vind disk failure een stuk acceptabeler. Temeer de kosten van een checksum zo laag zijn.

In dit topic wordt vaak gedaan alsof je gek bent geworden als je geen ZFS toepast en alsof je enorme risico's neemt, maar dat is niet zo.

Dit is natuurlijk het ZFS topic, en sysadmins zijn vaak religieus, niet wetenschappelijk. Maar ik ben het zeker eens met de stelling van er geen goede reden is om niet te checksummen, net zoals er geen goede reden is om geen ECC ram te gebruiken. Waarom dan toch niet? Slechte support, misschien ook op basis van oud denken. Met 10GB schijven was het idd geen issue.

Voor die mensen die besluiten dat hun data het waard is om in ZFS te investeren, je moet tenslotte de hardware bouwen, het platform en de technologie leren, een keuze maken over je VDEV layout (investering) zoals hierboven - voor die mensen is ZFS echt een verbetering. Zij zijn ook echt beter af met ZFS.

Je kunt het gewoon met 1 drive draaien, je hoeft echt geen sysadminnetje te spelen om iets aan bitrot te doen Leuk speelgoed natuurlijk, maar niet nodig.

[narotic]

BartNL schreef op zaterdag 12 maart 2016 @ 15:20:
[...]
Ik heb al een tijd een ZFS systeem draaien onder Freenas en de nadelen (specifiek write performance die voor mijn 10Gb netwerk niet volstaat) wegen voor mij tot dusver zwaarder dan bovenstaand voordeel. Mijn FreeNas server is tot dusver niet meer dan een probeersel. Wanneer ik 1Gb ok zou vinden, of FreeNas 10Gb zou bijhouden, was ik waarschijnlijk wel om.

Dit vind ik wel apart, heb je meer info? In je vorige posts in dit topic leek dit eerder aan samba/netwerk te liggen dan aan ZFS an sich. Met een stripe van 2 SATA SSD's haal ik met ZFS gewoon de ~1GB/s sequential read/write die je ervan zou verwachten.

[Q]

Brent schreef op zaterdag 12 maart 2016 @ 15:31:
[...]

Doet dat er wat toe?

Ja, want de scope van mijn betoog en de discussie was over de file system keuze. Niet over RAM en ECC.

Die firmware bug is weer een andere studie, die valt niet onder de 1kB/1TB/6maand die ik noemde.

Er wordt redelijk wat gepubliceerd op het gebied van data integriteit, hier een statistiek van 1bit/M:
http://lekythos.library.u...19/ECDL038.pdf?sequence=1

Kun je uitleggen waarom dit paper relevant is voor de discussie? Dit gaat alleen maar over in hoeverre file format bestand zijn tegen data corruptie, zover ik kan zien.

Anekdotisch is er ook bewijs zat, zoals hier wel vermeld.

Dat iets kan voorkomen is niet de discussie, maar wel de frequentie en het risico.
Het risico is klein genoeg dat het prima acceptabel is om geen ZFS te draaien.

Met anekdotes bewijs je verder niets. De meervoud van anekdotes is geen 'data'.

CERN dus over 97PB.

http://www.zdnet.com/arti...n-is-worse-than-you-know/

Slechts 3% van de nodes is getroffen.

Als we de firmware issues er uit filteren dan komen we op 100 errors in 2.5 petabyte van data als ik het goed uitreken. Dat is een enkele fout per 25 TB aan data.

Echter het lijkt er op dat de meeste fouten zich concentreren op een klein aantal nodes. 97% van de nodes had geen issues met data corruptie. En dat aantal wordt waarschijnlijk beter als je die firmware issues er uit haalt.

Dit artikel toont met name aan dat op schaal je je zeker druk moet maken over bitrot, maar thuis?

Als je bitrot acceptabel vind.

Ik heb liever geen bitrot, maar het risico is zo te zien erg klein.

We hadden 187 auto doden in 2014, maar we accepteren dat risico en stappen allemaal toch in onze autos.

Dit is natuurlijk het ZFS topic, en sysadmins zijn vaak religieus, niet wetenschappelijk. Maar ik ben het zeker eens met de stelling van er geen goede reden is om niet te checksummen, net zoals er geen goede reden is om geen ECC ram te gebruiken. Waarom dan toch niet? Slechte support, misschien ook op basis van oud denken. Met 10GB schijven was het idd geen issue.

Er is nog steeds geen bewijs dat bitrot met grote schijven voor thuis gebruikers een substantieel risico vormt.

Je kunt het gewoon met 1 drive draaien, je hoeft echt geen sysadminnetje te spelen om iets aan bitrot te doen Leuk speelgoed natuurlijk, maar niet nodig.

Dat kan zeker, maar je gaat hier helemaal voorbij aan de context van dit topic en dit forum. Mensen hangen geen enkele disks met ZFS aan een machine. ZFS wordt hier 99% van de gevallen toegepast voor een NAS.

[BartNL]

narotic schreef op zaterdag 12 maart 2016 @ 16:11:
[...]


Dit vind ik wel apart, heb je meer info? In je vorige posts in dit topic leek dit eerder aan samba/netwerk te liggen dan aan ZFS an sich. Met een stripe van 2 SATA SSD's haal ik met ZFS gewoon de ~1GB/s sequential read/write die je ervan zou verwachten.

Ik denk nog steeds dat CIFS het probleem is maar dat denk ik nodig te hebben omdat ik Windows 10 gebruik.

[narotic]

Heb je samba 4.x inmiddels al geprobeerd? Versie 4.3 is nu ook al in de ports verkrijgbaar (iig op vanilla FreeBSD...).

Q schreef op zaterdag 12 maart 2016 @ 16:20:
[...]
Dat kan zeker, maar je gaat hier helemaal voorbij aan de context van dit topic en dit forum. Mensen hangen geen enkele disks met ZFS aan een machine. ZFS wordt hier 99% van de gevallen toegepast voor een NAS.

Erg jammer, imho, want behalve de lastige installatie zie ik niet in waarom je ZFS ook niet gewoon op je Linux desktop of laptop zou gebruiken met single disks.

[Brent]

Q schreef op zaterdag 12 maart 2016 @ 16:20:
[...]
Met anekdotes bewijs je verder niets. De meervoud van anekdotes is geen 'data'.

Nope, maar gelukkig zijn alle anekdotes en data in overeenstemming, behalve jouw anekdote

[...]


http://www.zdnet.com/arti...n-is-worse-than-you-know/

Slechts 3% van de nodes is getroffen.

Als we de firmware issues er uit filteren dan komen we op 100 errors in 2.5 petabyte van data als ik het goed uitreken. Dat is een enkele fout per 25 TB aan data.

Gek, het artikel concludeert dat op elke 1TB consumerschijf 3 files corrupt zijn.

Echter het lijkt er op dat de meeste fouten zich concentreren op een klein aantal nodes. 97% van de nodes had geen issues met data corruptie. En dat aantal wordt waarschijnlijk beter als je die firmware issues er uit haalt.

Je haalt steeds zaken eruit die jij niet relevant vind, maar als we het over consumentenopslag hebben, moeten we alles meetellen. Mijn moeder heeft de luxe niet te foute firmwares weg te filteren.

Dit artikel toont met name aan dat op schaal je je zeker druk moet maken over bitrot, maar thuis?

Inderdaad.

[...]


Ik heb liever geen bitrot, maar het risico is zo te zien erg klein.

We hadden 187 auto doden in 2014, maar we accepteren dat risico en stappen allemaal toch in onze autos.

Voor risicoberekening moet je risico met kosten van de oplossing vermenigvuldigen. De riem is op ritbasis een overbodig instrument, maar toch doen we hem om omdat het nauwelijks wat kost en als ie helpt, dan helpt ie goed.

[...]


Er is nog steeds geen bewijs dat bitrot met grote schijven voor thuis gebruikers een substantieel risico vormt.

Je herhaalt je zelf-geconstrueerde conclusies, en schuift alle data en anekdotes hier aan te kant. Prima, maar je overtuigt niemand denk ik

[...]


Dat kan zeker, maar je gaat hier helemaal voorbij aan de context van dit topic en dit forum. Mensen hangen geen enkele disks met ZFS aan een machine. ZFS wordt hier 99% van de gevallen toegepast voor een NAS.

Je begon er zelf mee dat men in dit topic allesbehalve ZFS afraadt. Ik betoog dat je je niet bij de conventional wisdom in dit topic hoeft neer te leggen, en ZFS (of welk FS dan ook) kunt gebruiken zoals je wil.

Tip: je hebt vast een ouwe laptop/desktop met een single drive en 'dom' filesystem ergens. Checksum eens wat data erop (een paar honderd GB ofzo) en test over een maandje eens. Nog beter, doe het op een machine van familie/vrienden. Je gaat ze vinden hoor

[Q]

Brent schreef op zaterdag 12 maart 2016 @ 16:50:

Tip: je hebt vast een ouwe laptop/desktop met een single drive en 'dom' filesystem ergens. Checksum eens wat data erop (een paar honderd GB ofzo) en test over een maandje eens. Nog beter, doe het op een machine van familie/vrienden. Je gaat ze vinden hoor

Ja doe dat eens, je gaat niets vinden. Je zult versteld staan hoe betrouwbaar schijven echt zijn.

Het enige wat je mogelijk tegen gaat komen is corruptie door bad blocks, maar dat is niet het risico waar we het over hebben. Want daar beschermt geen enkel file system tegen.

We hebben het over *silent* data corruptie.

En met meer dan een petabyte aan scrubs over mijn schijven over verschillende systemen heb ik nog geen enkele checksum error gezien. Maar dit is een anekdote.

Je haalt steeds zaken eruit die jij niet relevant vind, maar als we het over consumentenopslag hebben, moeten we alles meetellen. Mijn moeder heeft de luxe niet te foute firmwares weg te filteren.

Je moeder (waarom zijn het altijd moeders, nooit vaders) zal een foute firmware nooit mee maken, want de kans dat zoiets zich voordoet is erg klein.

Je doet precies zelf waar je mij van beschuldigt. Je moet juist heel zorgvuldig kijken naar de context van een consument en alleen mee tellen wat voor een consument relevant is.

Voor risicoberekening moet je risico met kosten van de oplossing vermenigvuldigen. De riem is op ritbasis een overbodig instrument, maar toch doen we hem om omdat het nauwelijks wat kost en als ie helpt, dan helpt ie goed.

Maar ZFS kost niet nauwelijks wat. Het werkt niet onder Windows. Het werkt met gekloot onder Mac OS X. Het werkt prima onder Linux of BSD, maar dat vergt meer moeite en kennis. Heb je die kennis of wil je daarin investeren, dan is het geen issue. Maar alles heeft een prijs.

Natuurlijk is het simpel om FreeNAS of ZFSGuru te installeren, totdat er iets fout gaat, en de gemiddelde bezoeker hier die weinig Linux/BSD ervaring heeft, mag dan zich aan een console wagen.

Dan hebben we de harde euro kosten die ZFS met zich mee brengt.
http://louwrentius.com/th...fs-for-your-home-nas.html

ZFS draaien is niet zo simpel als een gordel om doen.

Je herhaalt je zelf-geconstrueerde conclusies, en schuift alle data en anekdotes hier aan te kant. Prima, maar je overtuigt niemand denk ik

Dat moeten mensen zelf maar bepalen. Zelf denk ik dat mijn positie juist een stuk redelijker en genuanceerder is dan het pure ZFS-kamp dat een indruk probeert te wekken dat je gek bent en onverantwoord bezig bent als je geen ZFS draait.

Ja ZFS is 'beter', maar legacy file systems en raid oplossingen zijn nog steeds goed genoeg voor thuis gebruik.

Ik zou zeggen laat je niet gek maken door de ZFS mensen. Bedenk dat 9/10 van de mensen een Synology of QNAP koopt en daar ook prima mee draait en nooit zal weten over ZFS.

Als je bereid bent om de 'kosten' van ZFS te betalen, dan maak je ook een goede keuze en een goede setup op basis van ECC en ZFS biedt een veiligere omgeving voor je data dan legacy file systems, RAID of QNAPS.

[wopie]

Q schreef op zaterdag 12 maart 2016 @ 17:58:
[...]
Ik zou zeggen laat je niet gek maken door de ZFS mensen. Bedenk dat 9/10 van de mensen een Synology of QNAP koopt en daar ook prima mee draait en nooit zal weten over ZFS.

Als je bereid bent om de 'kosten' van ZFS te betalen, dan maak je ook een goede keuze en een goede setup op basis van ECC en ZFS biedt een veiligere omgeving voor je data dan legacy file systems, RAID of QNAPS.

Amen to that

Ervaring:
Ik draai sinds een 3 jaar geleden nu ZFS voor mijn foto's, met name omdat die niet opnieuw gemaakt kunnen worden. Ik heb meerdere malen ervaren dat oudere (+10 jaar terug) foto's "defect" waren (halve afbeeldingen, grijze plaatjes, etc). Voor mij was dat onacceptabel. Nu euro's eraan gespendeerd om ECC ZFS te draaien. Vogens mij is het net als met security etc gewoon hoe paranoia je bent over je data (paranoia mag geld kosten).

[Q]

@Wopie, volgens mij ben je het dus juist erg oneens met mijn eerste paragraaf.

[wopie]

Q schreef op zaterdag 12 maart 2016 @ 18:49:
@Wopie, volgens mij ben je het dus juist erg oneens met mijn eerste paragraaf.

Ik denk dat je de paragraaf over silent data-corruption die nooit voorkomt bedoeld?

Zoals ik eerder al aangaf, ik ben geen file-system expert, dus ik ga hier niemand de les lezen in wat er wel en niet statistisch waar of onwaar is volgens welke definitie dan ook.

Ik heb voor de nieuwsgierigheid dat artikel van CERN gelezen en daar staat een hoop informatie in, echter voor mij niet altijd even duidelijk wat dat nou betekend. Ik heb mijn eigen ervaringen, en dan zegt mijn paranoia-stemmetje.. hmmm, dat ZFS is niet voor niets uitgevonden, er zijn een hoop slimme mensen die daar goed over nagedacht hebben en mijn inziens snijd de uitleg over next generation file-system hout en dus maak ik daar graag gebruik van (ook omdat er voor mij niet echt een penalty is, de extra kosten kan ik dragen). Dat ik vervolgens mogelijk silent-data-corruption bestrijdt, dat vind ik alleen maar mooi meegenomen (ik weet niet of het bij mij voorkomt, ik weet alleen dat het wel eens voorkomt, dat is voor mij genoeg).
Als vergelijk, ik draai thuis een Palo Alto firewall, dit noemen ze een next-generation firewall, het verschil met een traditionele firewall is dat een next-generation-firewall in je verkeer kijkt en het kan herkennen waar je vervolgens firewall-rules voor kan maken. Omdat ik de mogelijkheden heb dit te draaien gebruik ik het, niet omdat een traditionele firewall slecht is (het gros van de wereld draait nog traditionele port-based firewalls). Ik zie wel dat langzaam alle enterprise's overgaan op next-gen firewalls, dus de nieuwe ontwikkeling snijdt hout. Ik vertaal dit zelf ook naar ZFS en consorten, het is gewoon de volgende stap, en het is slim er gebruik van te maken als je het nut ervan in kan zien.

Ik heb dus geen mening over jouw paragraaf, daar ontbreekt het mij aan kennis van, ik denk dat eenieder de keus voor zichzelf kan/moet maken.

[CurlyMo]

Mijn inbreng dan maar. Ik draai ZFS niet louter om de data-zekerheid die het wel of niet biedt. Snapshots, delta send/receive, ACL's flexibiliteit, compressie enz zijn voor mij net zo belangrijk.

[XAEROCOOL]

Hallo, Ik heb een aantal vragen:

Na volgende suggestie van CiPHER:
So, the best partition scheme might be:

1) Bootstrap partition (automatically created by ZFSguru) 1MiB
2) SWAP partition: 4GiB to maximum of RAM size
3) sLOG partition for sLOG (dedicated ZIL) of your HDD pool: 4GiB
4) L2ARC partition for your HDD pool: 60GiB
5) System partition for ZFSguru and your VM images: 120GiB

heb ik mijn ssd als volgt gepartitioneerd in zfsguru:


Is dit correct? Hiermee bedoel ik of sLOG en L2ARC freebsd-zfs moet zijn, zien jullie hier dingen die niet correct zijn?
Ik heb als boundries 4k gekozen bij creatie van deze partities, was dit slim of had ik sectors of mb moeten kiezen?
Ik heb de grootte van de partities ook een beetje aangepast, ik weet niet of dit helemaal correct is.

Verder als ik een pool creer voor 5 hardeschijven voor data opslag wordt er ook automatisch een boot sector voor elk hdd gecreerd met zfsguru, is het de bedoeling om deze zo te houden of kan ik de boot secties verwijderen (het is mogelijk in zfsguru)?

EDIT: Nog een vraag: Ik wil de hdds voornamelijk voor opslag gebruiken, maar moet ik een pool aanmaken met de hele grootte van hdds of zijn er ook situaties waarbij het handig kan zijn om het toch te verdelen in verschillende pools?

Alvast bedankt.

[ Voor 9% gewijzigd door XAEROCOOL op 13-03-2016 12:19 ]

[Verwijderd]

Allereerst: is die MX200 SSD een M.2 versie? Want alleen de M.2 500GB versie kun je als SLC gebruiken door de helft niet te partitioneren. Voor de SATA versie geldt dat de DWA (Dynamic Write Acceleration) feature enkel ingeschakeld is voor de 250GB versie. Dus als je 500GB SATA hebt gekocht dan heeft het niet veel zin de helft vrij te laten.

Qua partitioneren en grootte heb je het denk ik wel goed gedaan, behalve:

Ik heb als boundries 4k gekozen bij creatie van deze partities, was dit slim of had ik sectors of mb moeten kiezen?

Ik raad je aan dit soort geavanceerde instellingen allemaal default te laten, om diverse redenen. Dus nog even met een schone lei beginnen en opnieuw de partities aanmaken.

Verder als ik een pool creer voor 5 hardeschijven voor data opslag wordt er ook automatisch een boot sector voor elk hdd gecreerd met zfsguru, is het de bedoeling om deze zo te houden of kan ik de boot secties verwijderen (het is mogelijk in zfsguru)?

Misschien heb je het niet strikt nodig. Maar er is weinig reden ze te verwijderen en mocht je in de toekomst ooit willen booten van je HDD pool (want: je SSD is stuk ofzo) dan heb je ze dan wel nodig. 1 megabyte opofferen mag geen bezwaar zijn, denk ik ook.

EDIT: Nog een vraag: Ik wil de hdds voornamelijk voor opslag gebruiken, maar moet ik een pool aanmaken met de hele grootte van hdds of zijn er ook situaties waarbij het handig kan zijn om het toch te verdelen in verschillende pools?

Ik zou voor één pool gaan. ZFS houdt ervan dat je veel vrije ruimte hebt en dan is het niet handig als je die vrije ruimte over meerdere pools gaat verdelen. Want je komt dan regelmatig dat de ene pool best wel vol is maar de andere nog aardig wat ruimte heeft. Dus gewoon lekker één pool lijkt mij het beste.

[Q]

CurlyMo schreef op zondag 13 maart 2016 @ 11:10:
Mijn inbreng dan maar. Ik draai ZFS niet louter om de data-zekerheid die het wel of niet biedt. Snapshots, delta send/receive, ACL's flexibiliteit, compressie enz zijn voor mij net zo belangrijk.

Lijkt mij een hele goede reden om ZFS te draaien, als jij dergelijke features graag wilt benutten.

wopie schreef op zondag 13 maart 2016 @ 11:04:

Ik heb dus geen mening over jouw paragraaf, daar ontbreekt het mij aan kennis van, ik denk dat eenieder de keus voor zichzelf kan/moet maken.

Ok, helder verhaal.

[ Voor 25% gewijzigd door Q op 14-03-2016 00:27 ]

[narotic]

XAEROCOOL schreef op zondag 13 maart 2016 @ 12:16:
EDIT: Nog een vraag: Ik wil de hdds voornamelijk voor opslag gebruiken, maar moet ik een pool aanmaken met de hele grootte van hdds of zijn er ook situaties waarbij het handig kan zijn om het toch te verdelen in verschillende pools?

Alvast bedankt.

Zoals CiPHER al zegt is het in de meeste gevallen met ZFS aan te raden om 1 grote pool te maken. Waar je met EXT en consorten aparte partities had voor /home, /var etc. los je dit met ZFS op door middel van datasets binnen die pool.

De enige reden om meer dan 1 pool op dezelfde schijven te zetten is als je verschillende type pools wilt. In jouw situatie dus bijvoorbeeld per schijf een partitie voor een 4+1 RAIDZ pool (bulk storage) en een tweede partitie voor een stripe van 5 schijven ("scratch"). De RAIDZ pool biedt dan veiligheid, terwijl de stripe hoge random en sequentiele IO levert. Alhoewel dat soms de beste keuze kan zijn, zou je natuurlijk beter af zijn met een scratch op aparte schijven (lees SSD's).

[FireDrunk]

Bovendien stort de performance fenomenaal in als je van de scratch naar je gewone pool dingen heen en weer gaat zetten.

Omdat ZFS denkt dat het verschillende schijven zijn, gaan je queues (je transaction groups) dwars door elkaar heen lopen, en gaan je disks haast random IO doen ipv sequential.

Maar inderdaad, het kan. Ik zeg zelf ook wel vaker, als mensen een 10 Disk RAIDZ2 maken ofzo die ze in spindown willen, maak er dan een mirror pooltje van 2 laptop schijfjes naast voor het binnen laten druppelen van je (langzame) downloads, dat scheelt aanzienlijk in het aantal keer dat je grote pool moet opspinnen en/of zelfs actie blijft.

Dus ja, er zijn wel degelijk use-cases om meerdere pools te maken, maar niet veel. 1 grote is in 90% van de gevallen wenselijk.

[idef1x]

Hmmm heb ik net mijn laptop SSD's op LUKS/ZFS (linux) gezet, blijkt ZFS geen trim te snappen.
Is dit erg? Of juist positief? Ik kom op internet wel iets tegen over een parameter zfs_notrim, maar zie die nergens terug in de zpool parameters.

Mijn root partitie is nog ext4 (op LUKS) en die snapt trim wel, dus luks geeft het goed door lijkt me (discard optie in /etc/crypttab)

[FireDrunk]

TRIM support is er alleen in BSD. ZoL heeft dat nog niet gemerged omdat er performance problemen zijn op het moment dat ZFS een hele disk trimmed (je systeem kan gaan hangen).

BSD heeft dat probleem ook dacht ik, maar hebben een soort "max trim" waarde ingevoerd volgens mij.

https://github.com/zfsonlinux/zfs/pull/1016

Ze wachten op de "generieke" implementatie van Illumos als ik het goed lees (vluchtig )

[ Voor 20% gewijzigd door FireDrunk op 14-03-2016 08:49 ]

[XAEROCOOL]

Bedankt allemaal, het begint nu een beetje vorm te krijgen.

Nu heb ik 1 grote hdd pool aangemaakt met de standaard instellingen in zfsguru.

Verder heb ik ssd partities opnieuw aangemaakt met de standaard instellingen.

Ik neem aan dat ik de cache en log gewoon naar de aangemaakte partitities kan toewijzen met behulp van zfsguru?

Maar bij het installeren van zfsguru op de ssd partititie zie ik ook een optie om swap aan te maken (staat default op 2 GB), wat kan ik het beste hiermee doen? Ik had al een SWAP-1 aangemaakt, moet ik deze optie ook op default 2 GB houden of no swap selecteren omdat dit al aangemaakt is? Zal zfsguru dan automatisch van de aangemaakte swap gebruik maken of moet er aparte handeling uitgevoerd worden?

Bedankt.

[FireDrunk]

Swap wordt gewoon als extra dataset aangemaakt dacht ik (in ZFSguru). Zou er niet teveel aandacht aan spenderen als je genoeg RAM hebt.

[ Voor 5% gewijzigd door FireDrunk op 14-03-2016 09:31 ]

[idef1x]

FireDrunk schreef op maandag 14 maart 2016 @ 08:48:
TRIM support is er alleen in BSD. ZoL heeft dat nog niet gemerged omdat er performance problemen zijn op het moment dat ZFS een hele disk trimmed (je systeem kan gaan hangen).

BSD heeft dat probleem ook dacht ik, maar hebben een soort "max trim" waarde ingevoerd volgens mij.

https://github.com/zfsonlinux/zfs/pull/1016

Ze wachten op de "generieke" implementatie van Illumos als ik het goed lees (vluchtig )

Hmmm op zich is die pull request closed, dus zou je zeggen dat die er nu wel in moeten zitten (dateerd ook uit 2012).

Ik zie hem alleen niet terug als ik "modinfo zfs" doe...Wel een:

code:

parm:           zvol_max_discard_blocks:Max number of blocks to discard (ulong)

Die lijkt wel op die max trim waarde die je noemt, dus zou je toch zeggen dat het er een soort van in zou moeten zitten...

Afijn ben alleen bang dat mijn SSD's nu trager gaan worden zonder trim na verloop van tijd. Lossen jullie dat op door tzt weer eens een verse zfs send te doen naar een ander systeem en dan opnieuw formateren/wipen/e.d en weer terugzetten? Of valt het allemaal wel mee en maakt het voor zfs niet veel uit?

[FireDrunk]

idef1x schreef op maandag 14 maart 2016 @ 10:45:
[...]
Afijn ben alleen bang dat mijn SSD's nu trager gaan worden zonder trim na verloop van tijd. Lossen jullie dat op door tzt weer eens een verse zfs send te doen naar een ander systeem en dan opnieuw formateren/wipen/e.d en weer terugzetten? Of valt het allemaal wel mee en maakt het voor zfs niet veel uit?

Wat je kan doen is gewoon de SLOG en L2ARC verwijderen, hele partitie TRIMen vanuit het OS, en weer toevoegen aan ZFS. Stelt niks voor, is een paar minuutjes werk.

Over TRIM:
https://github.com/zfsonl...a90/module/zfs/zvol.c#L60

Hmm, nu je het zegt. Misschien zit het nog niet in de huidige versie (0.6.5.5).
Even verder kijken...

[ Voor 59% gewijzigd door FireDrunk op 14-03-2016 10:52 ]

[narotic]

idef1x schreef op maandag 14 maart 2016 @ 10:45:
[...]
Afijn ben alleen bang dat mijn SSD's nu trager gaan worden zonder trim na verloop van tijd. Lossen jullie dat op door tzt weer eens een verse zfs send te doen naar een ander systeem en dan opnieuw formateren/wipen/e.d en weer terugzetten? Of valt het allemaal wel mee en maakt het voor zfs niet veel uit?

Als je genoeg overprovisioning toepast dan is TRIM niet echt nodig. Op een pool waar ik maximaal ruimte wil en die af en toe ook flink beschreven wordt los ik het echter op zoals jij zegt: af en toe pool verwijderen, blkdiscard op de vrije ruimte, en dan de backup weer terugsturen.

Edit: Wat ik persoonlijk ook doe op een laptop is swap te gebruiken als "overprovisioning", aangezien swap over 't algemeen toch nauwelijks gebruikt wordt als je genoeg geheugen hebt. Swap mount ik met discard=once waardoor elke boot iig x GB aan vrije blocks beschikbaar is. Dit komt min of meer overeen met de SLOG/L2ARC procedure die FireDrunk hierboven beschrijft.

[ Voor 21% gewijzigd door narotic op 14-03-2016 11:16 ]

[idef1x]

FireDrunk schreef op maandag 14 maart 2016 @ 10:51:
[...]

Wat je kan doen is gewoon de SLOG en L2ARC verwijderen, hele partitie TRIMen vanuit het OS, en weer toevoegen aan ZFS. Stelt niks voor, is een paar minuutjes werk.

Euh ik heb mijn data op die laptop op ZFS gezet, geen aparte SLOG/L2ARC, dus blijft tch over alle data backuppen, trimmen en restoren ben ik bang

[FireDrunk]

Oh sorry, ik dacht dat het alleen om SLOG/L2ARC ging, my bad

Makkelijkste is een volledige ZFS send naar een file te doen, pool verwijderen, SSD's trimmen, nieuwe pool aanmaken, en ZFS restore vanuit de file.

[narotic]

idef1x schreef op maandag 14 maart 2016 @ 11:41:
[...]

Euh ik heb mijn data op die laptop op ZFS gezet, geen aparte SLOG/L2ARC, dus blijft tch over alle data backuppen, trimmen en restoren ben ik bang

Als je swap hebt kun je hetzelfde principe daarop toepassen (zelfs makkelijker). Zie mijn edit hierboven.

[idef1x]

narotic schreef op maandag 14 maart 2016 @ 12:26:
[...]


Als je swap hebt kun je hetzelfde principe daarop toepassen (zelfs makkelijker). Zie mijn edit hierboven.

Hmm ja heb wel swap, maar dat is nu een zvol. En heeft lijkt me niet zo'n zin als je onderlaag een luks encrypted partitie is....

[Mattie112]

Ik krijg van mijn FreeNAS systeempje iedere nacht een "security run" in mijn mailbox. De laatste tijd staat hier (bijna) altijd het volgende in:

code:

(ada1:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 80 48 86 2c 40 27 01 00 00 00 00
(ada1:ahcich2:0:0:0): CAM status: ATA Status Error
(ada1:ahcich2:0:0:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF )
(ada1:ahcich2:0:0:0): RES: 41 10 48 86 2c 40 27 01 00 00 00
(ada1:ahcich2:0:0:0): Retrying command
(ada1:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 38 be 2c 40 27 01 00 00 00 00
(ada1:ahcich2:0:0:0): CAM status: ATA Status Error
(ada1:ahcich2:0:0:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF )
(ada1:ahcich2:0:0:0): RES: 41 10 38 be 2c 40 27 01 00 00 00
(ada1:ahcich2:0:0:0): Retrying command

Het is mij niet helemaal duidelijk óf dit nou een direct probleem is met die disk. De SMART waarden zien er goed uit:

[root@freenas] ~# smartctl --all /dev/ada1
smartctl 6.3 2014-07-26 r3976 [FreeBSD 9.3-RELEASE-p31 amd64] (local build)
Copyright (C) 2002-14, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red
Device Model: WDC WD30EFRX-68EUZN0
Serial Number: WD-WCC4N1066787
LU WWN Device Id: 5 0014ee 25f718117
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Mon Mar 14 14:10:41 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (40860) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 410) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x703d) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 181 178 021 Pre-fail Always - 5916
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 63
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 080 080 000 Old_age Always - 14903
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 58
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 33
193 Load_Cycle_Count 0x0032 193 193 000 Old_age Always - 21283
194 Temperature_Celsius 0x0022 125 105 000 Old_age Always - 25
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 100 253 000 Old_age Offline - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 14580 -
# 2 Short offline Completed without error 00% 13113 -
# 3 Short offline Completed without error 00% 13113 -
# 4 Conveyance offline Completed without error 00% 5247 -
# 5 Conveyance offline Completed without error 00% 5230 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Zit ik nou gewoon verkeerd te kijken naar die SMART waarde of heeft deze melding niks met de disk te maken?

[narotic]

Mattie112 schreef op maandag 14 maart 2016 @ 14:15:
Ik krijg van mijn FreeNAS systeempje iedere nacht een "security run" in mijn mailbox. De laatste tijd staat hier (bijna) altijd het volgende in:

code:

(ada1:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 80 48 86 2c 40 27 01 00 00 00 00
(ada1:ahcich2:0:0:0): CAM status: ATA Status Error
(ada1:ahcich2:0:0:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF )
(ada1:ahcich2:0:0:0): RES: 41 10 48 86 2c 40 27 01 00 00 00
(ada1:ahcich2:0:0:0): Retrying command
(ada1:ahcich2:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 08 38 be 2c 40 27 01 00 00 00 00
(ada1:ahcich2:0:0:0): CAM status: ATA Status Error
(ada1:ahcich2:0:0:0): ATA status: 41 (DRDY ERR), error: 10 (IDNF )
(ada1:ahcich2:0:0:0): RES: 41 10 38 be 2c 40 27 01 00 00 00
(ada1:ahcich2:0:0:0): Retrying command

Het is mij niet helemaal duidelijk óf dit nou een direct probleem is met die disk. De SMART waarden zien er goed uit:


[...]


Zit ik nou gewoon verkeerd te kijken naar die SMART waarde of heeft deze melding niks met de disk te maken?

Aan wat voor SATA controller hangen de schijven?

idef1x schreef op maandag 14 maart 2016 @ 13:29:
[...]

Hmm ja heb wel swap, maar dat is nu een zvol. En heeft lijkt me niet zo'n zin als je onderlaag een luks encrypted partitie is....

Nee, dan heb je er inderdaad niets aan.

[ Voor 11% gewijzigd door narotic op 14-03-2016 14:24 ]

[Mattie112]

narotic schreef op maandag 14 maart 2016 @ 14:24:
[...]


Aan wat voor SATA controller hangen de schijven?

Die hangen aan de onboard controller van mijn Supermicro A1SAM-2750F, ik durf niet te zeggen of deze disk op de sata2 of sata3 poort zit dat zou ik moeten controleren.

[narotic]

Mattie112 schreef op maandag 14 maart 2016 @ 14:39:
[...]


Die hangen aan de onboard controller van mijn Supermicro A1SAM-2750F, ik durf niet te zeggen of deze disk op de sata2 of sata3 poort zit dat zou ik moeten controleren.

Ok, ik vroeg 't omdat de populaire SAS2008 chips met de nieuwste firmware regelmatige vergelijkbare problemen vertonen. Aangezien je geen SMART problemen hebt lijkt het erop dat 't ergens mis gaat tussen de controller en de schijf. Wellicht kun je 't beste met de meest simpele oplossing beginnen: even alle SATA kabels opnieuw goed aan te drukken.

[Mattie112]

Weet je: dat is niet eens een gek idee, ik laat weten of het geholpen heeft

[Kortfragje]

Hebben jullie de volgende mededeling al gezien? Hier wordt druk over gesproken op de ZoL mailing list, het lijkt een ZoL only probleem te zijn...

code:

https://github.com/openzfs/openzfs/pull/37

No announcement has been made yet about this issue on this mailing list, 
but it is important that users be aware and immediately check the integrity of backups.

Note: ZVOL are not affected. Only ZPL datasets are.

In certain circumstances, "zfs send -i" (incremental send) can produce a
stream which will result in incorrect sparse file contents on the
target.

The problem manifests as regions of the received file that should be
sparse (and read a zero-filled) actually contain data from a file that
was deleted (and which happened to share this file's object ID).

Note: this can happen only with filesystems (not zvols, because they do
not free (or reuse) object IDs).

Note: This can happen only if, since the incremental source (FromSnap),
a file was deleted and then another file was created, and the new file
is sparse (i.e. has areas that were never written to and should be
implicitly zero-filled).

We suspect that this was introduced by 4370 (applies only if hole_birth
feature is enabled), and made worse by 5243 (applies if hole_birth
feature is disabled, and we never send any holes).

The bug is caused by the hole birth feature. When an object is deleted
and replaced, all the holes in the object have birth time zero. However,
zfs send cannot tell that the holes are new since the file was replaced,
so it doesn't send them in an incremental. As a result, you can end up
with invalid data when you receive incremental send streams. As a
short-term fix, we can always send holes with birth time 0 (unless it's
a zvol or a dataset where we can guarantee that no objects have been
reused).

Het is mij nog niet duidelijk wat dit concreet betekent (of dat files echt corrupt zijn). Ik loop wel al mn files door, dmv md5 (output op bron en backup naar een file en dan vergelijken).

[Dutch2007]

na 4 jaar trouwe dienst is 1 HDD van me storage toch kaput..

root@michael-server:~ # zpool status
pool: storage1
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning in a
degraded state.
action: Online the device using 'zpool online' or replace the device with
'zpool replace'.
scan: scrub in progress since Sun Mar 13 16:32:08 2016
3.06T scanned out of 6.46T at 12.4M/s, 79h48m to go
539K repaired, 47.41% done
config:

NAME STATE READ WRITE CKSUM
storage1 DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
gpt/raid1 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid2 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid3 ONLINE 0 0 0
17095583079337875306 OFFLINE 0 0 0 was /dev/gpt/raid4
gpt/raid5 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid6 ONLINE 0 0 0

Heb de disk "17095583079337875306" al vervangen fysiek

nieuwe disk is /dev/ada4

whats next zodat de nieuwe Seagate NAS 2TB disk weer aan de raid wordt toegevoegd?

[CyBeR]

zpool replace storage1 gpt/raid4 [nieuw_device als niet dezelfde als eerst]

Overigens kun je eventueel ook autoreplace aan zetten, als je de volgende keer dan een disk vervangt op dezelfde plek dan doet 'ie dat automatisch.

Trouwens,

block size: 512B configured, 4096B native

geen last van kutperformance?

[ Voor 67% gewijzigd door CyBeR op 14-03-2016 22:34 ]

[Dutch2007]

CyBeR schreef op maandag 14 maart 2016 @ 22:31:
zpool replace storage1 gpt/raid4 [nieuw_device als niet dezelfde als eerst]

Overigens kun je eventueel ook autoreplace aan zetten, als je de volgende keer dan een disk vervangt op dezelfde plek dan doet 'ie dat automatisch.

Trouwens,

[...]


geen last van kutperformance?

root@michael-server:~ # zpool replace storage1 17095583079337875306 /dev/ada4
root@michael-server:~ # zpool status
pool: storage1
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scan: resilver in progress since Mon Mar 14 22:27:10 2016
2.28G scanned out of 6.50T at 4.56M/s, 415h19m to go
388M resilvered, 0.03% done
config:

NAME STATE READ WRITE CKSUM
storage1 DEGRADED 0 0 0
raidz1-0 DEGRADED 0 0 0
gpt/raid1 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid2 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid3 ONLINE 0 0 0
replacing-3 OFFLINE 0 0 0
17095583079337875306 OFFLINE 0 0 0 was /dev/gpt/raid4
ada4 ONLINE 0 0 0 block size: 512B configured, 4096B native (resilvering)
gpt/raid5 ONLINE 0 0 0 block size: 512B configured, 4096B native
gpt/raid6 ONLINE 0 0 0

errors: No known data errors

pool: zroot
state: ONLINE
scan: scrub repaired 0 in 0h0m with 0 errors on Fri Aug 28 00:21:10 2015
config:

NAME STATE READ WRITE CKSUM
zroot ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada0p3 ONLINE 0 0 0
ada2p3 ONLINE 0 0 0

errors: No known data errors

Nu dus alleen nog wachten tot de resilvering klaar is toch?

*edit*

Wat noem je je kudtperformance???

[ Voor 10% gewijzigd door Dutch2007 op 14-03-2016 22:38 ]

[CyBeR]

Yep. Daarna verdwijnt die oude disk uit de lijst.

Edit:

Nou je hebt zo te zien een zpool met ashift = 9 op disks die eigenlijk ashift = 12 moeten hebben (dwz, je gebruikt 512e disks met een native sector size van 4K die doen alsof ze 512b zijn.) Dat is niet zo'n punt voor reads maar bij een writes is dat killing voor de performance omdat je bijna altijd met read-modify-write cycles te maken krijgt omdat je OS 512 bytes wil schrijven maar de disk alleen 4K kan schrijven, wat de disk vervolgens oplost door 4K te lezen, de 512b aan te passen en het resultaat weer terug naar disk te schrijven.

[ Voor 97% gewijzigd door CyBeR op 14-03-2016 22:50 ]

[Dutch2007]

moah valt wel mee qua performance tbh

Heb nog 2 disks die wel 512 bytes zijn...

zal ooit wel moeten (of er komt maybe ooit een feature zodat 't geconverted kan worden )

[CyBeR]

Ashift=12 kun je ook op 512n disks gebruiken. Je kunt alleen wel niet een pool converteren. Moet je vers maken.

[ Voor 11% gewijzigd door CyBeR op 15-03-2016 00:35 ]

[Dutch2007]

yup, maar heb de pool al een tijdje, en toen ik begon waren 't allemaal 512byte disks (eerst 4x seagate, toen 2x WD d'r bij) en sindsdien gaat 't langer maar zeker allemaal naar 4K format...

[CyBeR]

Hoe groot zijn die disks? Alles onder 2TB kun je nog gewoon in 512n krijgen namelijk. Daarboven wordt 't moeilijker idd. Ik heb iig speciaal 512n disks uitgezocht bij WD.

[Dutch2007]

CyBeR schreef op dinsdag 15 maart 2016 @ 08:30:
Hoe groot zijn die disks? Alles onder 2TB kun je nog gewoon in 512n krijgen namelijk. Daarboven wordt 't moeilijker idd. Ik heb iig speciaal 512n disks uitgezocht bij WD.

Alles is 2TB (per disk)

[CyBeR]

Wel, dan voor de toekomst en voor ieder ander die op zoek naar 512n drives: zie deze spec sheet van WD bijvoorbeeld: http://www.wdc.com/wdprod...Sheet/ENG/2879-800066.pdf

Daarin vind je voor elk model de 4K-native, 512-emulation en 512-native part nummers indien beschikbaar. (Van de grotere disks zijn er geen 512n drives, van de kleinere geen 4K en 512e). Dat is hun 'Re' series, die bedoeld zijn voor enterprisegebruik waar dit uitmaakt. Ter vergelijking de 'Red' series (die ze marketen voor NAS-gebruik): http://www.wdc.com/wdprod...Sheet/ENG/2879-800002.pdf is allemaal "Advanced Format", beter bekend als 512e.

Het is, m.a.w. een kwestie van even goed uitzoeken wat wat is. Mijn server heeft WD1003FBYZ disks; 1TB 512n.

[ Voor 4% gewijzigd door CyBeR op 15-03-2016 09:43 ]

[Tha_Butcha]

Op het moment heb ik als VM Ubuntu LTS draaien (onder ESXi) met ZFS. Hier heb ik een zpool inhangen bestaande uit 1 vdev met 4 WD Red's (3TB) als RAIDZ. Als HBA gebruik ik een omgebouwde Dell H310. Nu wil ik twee dingen gaan doen:

1) Het geheel als fysiek machine draaien
2) Uitbereiden van storage (op het moment is zo'n 90% in gebruik)

Het uiteindelijk doel is om een grote NAS te hebben met max 16 HD's erin (met ong. 40TB).

Het eerste gedeelte kom ik wel uit, met het tweede heb ik wat hulp nodig qua planning. Omdat mijn portemonnaie het niet trekt om in een keer 12 HD's te kopen, wilde ik de aankopen spreiden.

Zo zou ik nu nog eens 4 HD's kunnen kopen van 3TB, die in een ZRAID vdev gooien en die toevoegen aan de zpool. Uiteindelijk zou ik dan een zpool hebben met 4 ZRAID vdevs. Qua parity laat dat natuurlijk te wensen over, want als 1 HD faalt, gaat de hele pool onderuit.

Vraag is dus: hoe kan ik het beste mijn storage laten groeien, zonder dat ik ineens een hele bak geld uit moet geven en mijn parity in gevaar komt?

[narotic]

Met een stripe van RAIDZ vdevs kun je altijd 1 gefaalde harde schijf hebben. De kans dat je een tweede gefaalde harde schijf kunt hebben is met een stripe van 4 RAIDZ vdevs van 4 schijven dan 80% (van de 15 resterende schijven krijg je problemen slechts bij de 3 resterende schijven in de degraded vdev). De kans dat je ook een derde falende schijf overleeft is 45,7% en een geluksvogel overleeft zelfs een vierde (14,1%). Deze kansen zijn echter ietwat optimistisch, omdat juist de "risico schijven" zwaar belast worden tijdens een resilver.

Overigens gebruik je je ruimte efficienter als je de macht van 2 + parity regel gebruikt. Dus bij RAIDZ van 3 (2+1) of 5 schijven (4+1) in totaal. Ik kan je zo uit mijn hoofd niet vertellen hoeveel extra ruimte je hiermee zou winnen. Als je toch van plan bent er nog een RAIDZ vdev naast te zetten, zou dat in theorie een kans zijn om dit "recht" te trekken.

[ Voor 14% gewijzigd door narotic op 15-03-2016 12:01 ]

[Tha_Butcha]

narotic schreef op dinsdag 15 maart 2016 @ 11:56:
Met een stripe van RAIDZ vdevs kun je altijd 1 gefaalde harde schijf hebben. De kans dat je een tweede gefaalde harde schijf kunt hebben is met een stripe van 4 RAIDZ vdevs van 4 schijven dan 80% (van de 15 resterende schijven krijg je problemen slechts bij de 3 resterende schijven in de degraded vdev). De kans dat je ook een derde falende schijf overleeft is 45,7% en een geluksvogel overleeft zelfs een vierde (14,1%). Deze kansen zijn echter ietwat optimistisch, omdat juist de "risico schijven" zwaar belast worden tijdens een resilver.

Ja klopt, maar als 1vdev onderuit gaat, gaat de hele pool onderuit. Dus dat betekent dat je 1 gefaalde hd kan hebben op 16 hd's (uitgaande van 4 vdev's van RAIDZ). Statistisch niet helemaal correct, maar je begrijpt mijn punt.

Het is ook niet handig om 16 hd's in RAIDZ te gooien, en dat zou ik dan met die 4 vdev's bijna doen. Vandaar mijn "groei" probleem.

[Q]

Tha_Butcha schreef op dinsdag 15 maart 2016 @ 11:30:
Op het moment heb ik als VM Ubuntu LTS draaien (onder ESXi) met ZFS. Hier heb ik een zpool inhangen bestaande uit 1 vdev met 4 WD Red's (3TB) als RAIDZ. Als HBA gebruik ik een omgebouwde Dell H310. Nu wil ik twee dingen gaan doen:

1) Het geheel als fysiek machine draaien
2) Uitbereiden van storage (op het moment is zo'n 90% in gebruik)

Het uiteindelijk doel is om een grote NAS te hebben met max 16 HD's erin (met ong. 40TB).

Het eerste gedeelte kom ik wel uit, met het tweede heb ik wat hulp nodig qua planning. Omdat mijn portemonnaie het niet trekt om in een keer 12 HD's te kopen, wilde ik de aankopen spreiden.

Zo zou ik nu nog eens 4 HD's kunnen kopen van 3TB, die in een ZRAID vdev gooien en die toevoegen aan de zpool. Uiteindelijk zou ik dan een zpool hebben met 4 ZRAID vdevs. Qua parity laat dat natuurlijk te wensen over, want als 1 HD faalt, gaat de hele pool onderuit.

Vraag is dus: hoe kan ik het beste mijn storage laten groeien, zonder dat ik ineens een hele bak geld uit moet geven en mijn parity in gevaar komt?

Je hebt nu 4 disks in RAIDZ. Dan doe je nog een VDEV van RAIDZ met 4 disks er bij. Dan draai je raid50 en je kunt als je mazzel hebt 2 drive failures overleven, maar zoals geschreven, juist de disks van de getroffen vdevs worden het meeste belast.

Je huidige VDEV kun je niet uitbreiden.

Je kunt ook grotere disks kopen en je huidige disks vervangen, dan kun je even vooruit.
Maar extra disks = extra VDEV dus ook extra verspilling aan parity.

Dat is simpelweg de prijs van ZFS.
http://louwrentius.com/th...fs-for-your-home-nas.html

Als geld een issue is, kun je dit doen:

Je koopt 4 extra schijven en zet die in RAID5 (MDADM).
Je zet je data over op deze nieuwe schijven.
Je gooit ZFS pool weg.
Je maakt een RAID6 met 4 schijven en twee missende schijven.
Je zet je data over.
Je haalt 1 disk uit je RAID5 waar de data nog op stond en die voeg je toe aan je nieuwe RAID6. (je draait nu 2 x raid0 effectief maar je data staat op 2 volumes)
Nu ben je redundant en kun je de tijdelijke mdadm raid volume verbreken en de disks toevoegen aan je nieuwe RAID6 array en kun je de array laten groeien op basis van je gebruik.

Hele hoop werk. Gaat zeker lukken. Geen ZFS meer. Maar als je ZFS wilt, moet je dus gewoon geld betalen. Wat is je data je waard? ZFS kost gewoon extra parity overhead en minder totale capaciteit. Of je moet toch alles van te voren in 1x kopen.

[ Voor 4% gewijzigd door Q op 15-03-2016 13:08 ]

[Tha_Butcha]

Basically SoL dus, en doorsparen. Had ik al wel verwacht, maar misschien had hier iemand nog een leuke oplossing.

Interessant artikel trouwens, op je blog, die had ik nog niet gelezen.

Is er trouwens een reden dat je 2 RAIDZ2 vdevs hebt draaien, anders dan performance?

[Q]

Bedankt. De ZFS versie die beschikbaar was toen ik mijn systeem aan het maken was, ondersteund geen large block size, dus je moet je houden aan de 2^N + parity disks regel voor het aantal disks in een VDEV of je krijgt fors capaciteitsverlies. 18 en 6 disks voldoen aan die regel.

Nu zou ik gewoon een 24 disk RAIDZ3 hebben gemaakt met de largeblocks feature ingeschakeld.

[FireDrunk]

Zojuist eens met de ZED (ZFS Event Daemon) zitten spelen. Dat is leuk speelgoed!

Had ook jouw blog gezien Q maar heb het nog iets verder getrokken.
Ik krijg nu een Android Notificatie als er een Scrub klaar is!

[Q]

Dat is trouwens wel een goede: ZED is iets waar ik inderdaad een post over heb gemaakt, maar ik link er volgens mij niet naar in mijn 'things you need to know about zfs' post.

Notificaties is nogal belangrijk, anders weet je pas te laat dat een disk stuk is of dat er andere problemen zijn. Ik durf te wedden dat slecht 1% dit inregelt.

Leuk dat je notificaties er in heb geknutselt. Toch zou ik alleen maar alerts laten piepen want straks denk je dat een scrub klaar is, maar in werkelijkheid is een disk stuk. Je traint jezelf zo om je messages te negeren.

[ Voor 4% gewijzigd door Q op 16-03-2016 12:29 ]

[FireDrunk]

Je kan in NotifyMyAndroid een prio opgeven van -2 tot +2 (5 niveau's).
Ik ga eens kijken of ik dat kan scripten

[Q]

Ah dat is dan wel weer leuk. Dan ook verschillende geluidjes bij de verschillende prio's

[FireDrunk]

Uiteraard

[VorCha]

Ik had in een nfs datastore voor ESXi 4 x 1,5TB disks in raidz2 gezet. Maar ik was niet tevreden over de performance lokaal haalde ik gemiddeld 110MB/s, in een vm 30MB/s. Na wat gelezen te hebben, dacht ik eens een striped mirror uit te proberen. En dat was de moeite waard, lokaal 180MB/s. In een vm 60MB/s.

(/offtopic; Opmerking daarbij trouwens, dat de snelheid in een vm nog beter zou kunnen als er maar 1 vm actief zou zijn en ook de netwerkverbinding moet nog verder getweakt worden. De hardware wordt vervangen en ik ga een aantal hosts van nic bonding voorzien.)

Voor een andere ESXi host ga ik nu hetzelfde toepassen, maar nu heb ik 6 x 1TB disks beschikbaar.

Wat is de betere keuze? een stripe van 3 disks mirroren? of 3 mirrors stripen?

Ik vraag het specifiek in dit forum omdat ik wel het zfs filesystem wil gebruiken.

[FireDrunk]

ZFS kan alleen maar stripen over meerdere VDEV's niet mirroren. Het is dus automatisch een stripe van 3 mirrors.

Overigens heb ik NFS4.1 geprobeerd aan de praat te krijgen icm Multipathing, maar het was niet echt een super succes. Voor async schiet het aardig op, maar voor sync blijft NFS mager icm ZFS.

Ook was de performance niet echt stabiel. Het fluctueerde ernstig. Ik heb een veel betere ervaring met iSCSI.

[Mattie112]

Mattie112 schreef op maandag 14 maart 2016 @ 15:14:
Weet je: dat is niet eens een gek idee, ik laat weten of het geholpen heeft

So far heeft het nog niet geholpen: volgende stap de SATA-kabel vervangen. En mocht dat niet helpen dan wissel ik wel even 2 disks om kijken of het aan de disk of aan de poort ligt.

[Q]

Ik zou zelf ook iSCSI gebruiken boven NFS, heeft ook multipathing ingebouwd, lijkt mij een beter storage protocol.

[FireDrunk]

Ach, het heeft beide zijn voor en nadelen.

[VorCha]

Ik heb voor mijzelf de keuze tussen iSCSI en NFS al gemaakt. Dus geen worries daar

Thanks voor het antwoord FireDrunk.

Performance is niet een hoofdzaak, alles is voor mij een afweging van wat ik beschikbaar heb aan hardware, budget, must-haves en wensen. En gaandeweg ben ik een hoop aan het leren, ook van fouten.

ter extra info, het nieuwe storage systeempje is nr. 5 (verdeeld over 2 locaties)

[Ultra]

Een virtuele machine met een ZVOL als enige disk heeft al twee keer eerder I/O errors gehad, waarna de schijf read-only gemount werd. Dat leek beide keren opgelost te kunnen worden door een file system check.
Vandaag na een reboot van de fysieke server was het file system van die VM weer corrupt. Een fsck kon ik nog draaien, maar die heeft blijkbaar /usr/bin (en meer??) compleet verwijderd.

Datzelfde ZVOL koppelen aan een andere VM gaf al vrij snel ook I/O errors:

[  582.829602] end_request: I/O error, dev xvdc2, sector 8131584
[  582.835917] end_request: I/O error, dev xvdc2, sector 8132608
[  582.844258] end_request: I/O error, dev xvdc2, sector 8133888
[  582.851828] end_request: I/O error, dev xvdc2, sector 8134656
[  582.860279] end_request: I/O error, dev xvdc2, sector 8135936
[  582.871043] Aborting journal on device xvdc2-8.

Er liep op dat moment een lokale zfs send | receive binnen een HDD pool (om naar xattr=sa te gaan). Die had ik voor de reboot gestart, snel afgebroken vanwege een configfout, waarna de twee processen hingen (vandaar voor de zekerheid die reboot).

ZFS draait in dom0, waar geen foutmeldingen zijn. Mogelijk dat de ARC te groot is (4 van de 8GB in dom0)? https://github.com/zfsonlinux/zfs/issues/3236 hint op mogelijke problemen met een relatief grote ARC.


Dit is gelukkig de enige VM die een sparse ZVOL in plaats van een disk image heeft. VM's met disk images hebben er geen last van zo lijkt het. Van die disk images wilde ik af; laat ik dat maar even uitstellen!

[idef1x]

Iemand wel eens met ZFS on Linux en delegatie gewerkt?
Ik probeer dat nu uit, maar krijg als normale user de error terug:

code:

Permission denied the ZFS utilities must be run as root

Ik kan natuurlijk wel mezelf in een /etc/sudoers.d/zfs zetten, maar ja dan krijg ik gewoon root rechten voor die commando's en dat gaat dan toch zijn doel voorbij?

Met mijn allow settings heeft dat lijkt mij nog niet eens te maken, maar die zijn voor de compleetheid:

code:

root@Hoefnix:~# zfs allow data
---- Permissions on data ---------------------------------------------
Local+Descendent permissions:
    user idefix create,destroy,mount,rename,rollback,send,snapshot

[Kortfragje]

Gebruik altijd deze:

code:

Give user permission for status polling of ZFS (tested on Ubuntu 12 / CentOS 6):
This trick allows the user to run zpool status , zfs get (eliminates the need to sudo for quick reference, also allows you to use this cool app )

Perform all of the following as root or using sudo
leafpad /etc/udev/rules.d/91-zfs-permissions.rules

insert the contents:
#Use this to add a group and more permissive permissions for zfs
#so that you don't always need run it as root.  beware, users not root
#can do nearly EVERYTHING, including, but not limited to destroying
#volumes and deleting datasets.  they CANNOT mount datasets or create new
#volumes, export datasets via NFS, or other things that require root
#permissions outside of ZFS.
ACTION=="add", KERNEL=="zfs", MODE="0660", GROUP="zfs"

Adjust "GROUP" and "MODE" to your needs
run the following commands
groupadd zfs
gpasswd -a gertdus zfs

again, adjusting "zfs" to your match group in udev file.

http://blog.gjpvanwesten....rver-zfs-virtual.html?m=1

[idef1x]

Dat is dus niet wat ik bedoel, want dan kun je alle zfs commando's geven en omzeil je de hele allow configuratie van zfs. Ik wil dat een user slechts de zfs commando's mag geven die je met zfs allow toekent.

edit: nog maar even wezen spitten in de issue list op github en het werkt idd nog niet zoals het zou moeten:
https://github.com/zfsonlinux/zfs/issues/434

[ Voor 27% gewijzigd door idef1x op 20-03-2016 09:46 ]

[Kortfragje]

Ow jah dat werkt idd nog niet (liep ik tegenaan icm zfs receive, vandaar bovenstaande dirty hack)

[idef1x]

Die is wel erg dirty ja....dan doe ik het nog liever met een sudoers file, want dan kun je tenminste nog aangeven welke commando's/parameters je exact mag geven..

[FireDrunk]

Die handleiding komt van origine bij Ubuntu gebruikers vandaan. Daar is het bad-practise om iets onder het root account te doen, dus had je nooit zfs toegang zonder dat je sudo deed, zelfs niet met je 'admin' account.

Dit lost dus gewoon op dat je voor elk zfs commando sudo moet typen. Niets meer en niets minder

[idef1x]

Maar je moet met sudo ervoor intikken nog wel je paswoord geven, tenzij je zonder paswoord toestaat via de sudoers file. En dat laatste gaat het me eigenlijk om, zodat ik zfs receive op een mortal user account zou kunnen doen ipv root.

[FireDrunk]

Onder Ubuntu is passwordless de default voor het eerste account dat je aanmaakt (wordt lid van adm groep dacht ik).

[idef1x]

We gaan wel wat off-topic nu, maar ik moet gewoon een paswoord opgeven met sudo hoor en ik ben/heb het 1e account. Het enige wat default is bij ubuntu is dat het 1e account uberhaupt sudo mag doen.

[FireDrunk]

Na het eerste commando zijn opvolgende commando's automatisch geauthenticeerd met dat password (zolang je tty leeft).

Om het terug on topic te maken, compleet passwordless kan je voor ZFS vrij simpel regelen via een file in /etc/sudoers.d/zfs

Daarin doe je iets als:

thijs ALL = (root) NOPASSWD: /usr/bin/zfs

_{Uit mijn hoofd, ymmv}

[ Voor 4% gewijzigd door FireDrunk op 21-03-2016 10:50 ]

[idef1x]

Ja dat weet ik, maar ik wilde het dus eigenlijk zien te bewerkstelligen met zfs allow enzo, maar dat werkt dus nog niet en dan blijven workarounds over als Kortfragje of de sudoers file dus over kennelijk. De sudoers file it is dan maar..

[sam_vde]

Q schreef op zaterdag 12 maart 2016 @ 16:20:
Dat iets kan voorkomen is niet de discussie, maar wel de frequentie en het risico.
Het risico is klein genoeg dat het prima acceptabel is om geen ZFS te draaien.

Je kan helemaal niet beoordelen wat acceptabel is. Die frequentie en risico, daar weet je echt helemaal niets van omdat het net stille corruptie betreft. Er zijn bergen data die vaak decennia meegaan en gekopieerd worden telkens er een nieuwe computer komt, en die jarenlang niemand bekijkt.

Nog 1 opmerking: ik raad niemand commerciële nas boxen zoals Synology aan zolang ze dit probleem niet oplossen en mensen een vals gevoel van veiligheid blijven aanpraten. Dan ben je veel beter af met een offline backup op een externe schijf. Als je dat niet acceptabel vindt, is bitrot in de meeste gevallen een even ernstig probleem.

[sam_vde]

VorCha schreef op woensdag 16 maart 2016 @ 20:47:
Wat is de betere keuze? een stripe van 3 disks mirroren? of 3 mirrors stripen?

Ik vraag het specifiek in dit forum omdat ik wel het zfs filesystem wil gebruiken.

Nooit een stripe mirroren, dat is een aanslag op je systeem als er een disk uitvalt.

Die performantie, dat is een thread op zichzelf waard :-)

[FireDrunk]

sam_vde schreef op dinsdag 22 maart 2016 @ 06:48:
Nog 1 opmerking: ik raad niemand commerciële nas boxen zoals Synology aan zolang ze dit probleem niet oplossen en mensen een vals gevoel van veiligheid blijven aanpraten. Dan ben je veel beter af met een offline backup op een externe schijf. Als je dat niet acceptabel vindt, is bitrot in de meeste gevallen een even ernstig probleem.

Dat is haaks op wat Q zegt in zijn laatste alinea... Als je dat echt meent, moet je dus ook geen auto meer rijden. Daar roepen alle fabrikanten net zo goed dat het veilig is, terwijl er zelfs *doden* vallen...

Hier hebben we het 'maar' over data... Het is een beetje spijkers op laag water zoeken dat het allemaal niet meer "aangeraden mag worden"...

Voor elke use case is er ongeveer wel een apparaat. Zolang je mensen informeert over de risicio's die ze lopen (hoe groot en hoe klein ze ook zijn) kan iemand zelf een afgewogen keuze maken...

Dat doet iedereen in deze wereld op alle vlakken. Er is niets dat data op een disk anders maakt...

[Q]

sam_vde schreef op dinsdag 22 maart 2016 @ 06:48:
[...]


Je kan helemaal niet beoordelen wat acceptabel is. Die frequentie en risico, daar weet je echt helemaal niets van omdat het net stille corruptie betreft. Er zijn bergen data die vaak decennia meegaan en gekopieerd worden telkens er een nieuwe computer komt, en die jarenlang niemand bekijkt.

Ik heb geen hard wetenschappelijk onderzoek gedaan en kan het ook niet vinden. Echter het is niet mijn taak om aan te tonen dat silent data corruptie geen groot probleem is.

Het is aan de mensen die bang zijn voor silent data corruptie om aan te tonen dat het probleem relevant genoeg is voor thuis gebruikers. Kom maar met bewijs. En zoals je hierboven aangeeft, we weten het niet.

Mensen kunnen zich beter druk maken over het idee dat ze een goede (cloud) backup van hun data hebben. Al je data redden lijkt mij belangrijker dan het risico dat je een paar files verliest.

Nog 1 opmerking: ik raad niemand commerciële nas boxen zoals Synology aan zolang ze dit probleem niet oplossen en mensen een vals gevoel van veiligheid blijven aanpraten. Dan ben je veel beter af met een offline backup op een externe schijf. Als je dat niet acceptabel vindt, is bitrot in de meeste gevallen een even ernstig probleem.

Ik denk dat het risico van bitrot helemaal niet zo groot is en dat mensen zich helemaal geen zorgen hoeven te maken over de aanschaf van een Synology. Een zelfbouw systeem met ECC en ZFS kan veiliger zijn voor je data, dat is zeker waar. Maar de kant-en-klare NAS systeempjes krijgen wel een voldoende. ZFS krijgt alleen een hoger cijfer.

Ik krijg een beetje de indruk dat ZFS wordt verspreid op basis van Fear, Uncertainty and Doubt. Een beetje de boel dik aanzetten om het evangelie maar te verspreiden. Zoals ik ooit schreef: ZFS lost problemen en risico's op waarvan we niet eens wisten dat we die hadden.

Maar ik wil niet negatief eindigen over ZFS, het is inderdaad een 'veiliger' file system voor je data en dat de optie er is voor de mensen die graag alle risico's willen wegnemen, dat is natuurlijk geweldig.

[ Voor 5% gewijzigd door Q op 22-03-2016 08:51 ]

[VorCha]

sam_vde schreef op dinsdag 22 maart 2016 @ 06:56:
[...]
Nooit een stripe mirroren, dat is een aanslag op je systeem als er een disk uitvalt.

Die performantie, dat is een thread op zichzelf waard :-)

Volgens FireDrunk kan ZFS dat ook niet

[matty___]

Q schreef op dinsdag 22 maart 2016 @ 08:49:


Maar ik wil niet negatief eindigen over ZFS, het is inderdaad een 'veiliger' file system voor je data en dat de optie er is voor de mensen die graag alle risico's willen wegnemen, dat is natuurlijk geweldig.

Als je kijkt uit welke hoek het vandaan komt dan snap je de zorg om bitrot en hoe het is opgezet: Storage systems van Sun met PB aan data en rekken vol met disks.

Niet die paar disk die wij hier verbruiken.

[FireDrunk]

Uiteraard waar, maar je moet ook weer niet blind zijn voor de risicio's 'omdat je maar een thuisgebruriker bent'. Dat is wat Q ook goed adverteert (en waar ik het mee eens ben), je moet goed de risico's afwegen.
Er is niet per definitie een goede of foute keuze.

[CyBeR]

VorCha schreef op dinsdag 22 maart 2016 @ 09:21:
[...]


Volgens FireDrunk kan ZFS dat ook niet

Jawel maar alleen met een enorme omweg

(Twee zpools, elk met 2 vdevs bestaande uit 1 disk, daarop elk een zvol, die in een mirror vdev in een 3e zpool. Maar je bent een idioot als je dat doet ).

[VorCha]

CyBeR schreef op dinsdag 22 maart 2016 @ 09:49:
[...]
Maar je bent een idioot als je dat doet

Dat probeer ik dus inderdaad dan maar te voorkomen en vraag ik om raad

[soulcrusher]

CyBeR schreef op woensdag 09 maart 2016 @ 13:27:
Je kunt RAID-Z niet uitbreiden nadat je 'm aangemaakt hebt. Maar wat je wel kunt doen is een degraded raid-z2 maken met zes disks (waarvan er één kwijt is) en dan later die laatste disk toevoegen. Dat is niet echt ondersteund (itt bijvoorbeeld mdadm) maar je kunt zfs voor de gek houden door de zesde disk een file te laten zijn die je na het maken van de zpool onmiddelijk uit de vdev haalt.

Dit probeer dit nu te doen en ik voer de stappen uit die hier beschreven staan. Alleen als ik

code:

zpool create -f zfsraid raidz2 ada0 ada1 ada3 ada4 ada5 md0

uitvoer, blijft de server hangen, zelfs webserver reageert niet meer. Wat doe ik hier fout of wat moet ik wel doen?

EDIT: Nevermind, ik wist niet dat je via de interface een pool kon maken met een memory disk. Ik had de memory disk wel aangemaakt maar ik had hem niet geformatteerd.

[ Voor 8% gewijzigd door soulcrusher op 22-03-2016 21:22 ]

[CyBeR]

Wat is md0 daar? Ah nm.

[ Voor 17% gewijzigd door CyBeR op 22-03-2016 21:22 ]

[soulcrusher]

Nog een vraag, bij mijn WD Red's staat dat ze 512 bytes sector size hebben. (Hoe) kan ik dit veranderen naar 4K?

EDIT: 4k schijven worden door OS gezien als 512 bytes

[ Voor 20% gewijzigd door soulcrusher op 22-03-2016 21:37 ]

[Verwijderd]

Soulcrusher, het is bad practise om een ZFS pool aan te maken op ruwe disks. Gebruik altijd GPT partities en geen ruwe disks!

Jouw WD Red schijven zijn zogenaamde Advanced Format hardeschijven. Fysiek hebben die 4096 byte (4K) sectoren, maar ze emuleren 512 byte sectoren. Het OS ziet ze dus ook als 512 byte sector hardeschijven.

Toch hebben BSD operating systems - waaronder FreeNAS - een detectie voor dit soort schijven, waardoor automatisch een pool wordt gemaakt met de juiste optimalisatie. Je kunt uiteindelijk zien of je pool geoptimaliseerd is voor 4K schijven met het volgende commando:

zdb -e <poolnaam> | grep ashift

dit hoort dan iets te geven zoals:
ashift: 12

12 betekent 4K. 9 betekent 512-byte.

[CyBeR]

Verwijderd schreef op dinsdag 22 maart 2016 @ 21:43:
Soulcrusher, het is bad practise om een ZFS pool aan te maken op ruwe disks.

Behalve op Solaris/Illumos waar je dat juist wel moet doen.

[soulcrusher]

Ik had niet ver genoeg gekeken. Ik keek enkel naar disks en daar stond dat ze 512 bytes waren (geformatteerd als GPT). Bij het maken van een ZFS pool stond inderdaad de optie om 4k sectoren te gebruiken. zdb -e geeft inderdaad als resultaat 12

Nu heb ik die nieuwe raidz2 pool met 5 disks en een memory disk gemaakt en daarna de memory disk offline gehaald. Echter groeide mijn pool niet. Dus ik heb het volgende geprobeerd:

code:

 dd if=/dev/zero of=/zfs1 bs=1 count=1 seek=3076G
mdconfig -a -t vnode -S 4096 -f /zfs1

Toen heb ik deze memory disk geformatteerd, toegevoegd aan mijn pool en toen weer offline gehaald en verwijderd. Nu is mijn pool wel gegroeid naar 12TB. Is hier geen handigere manier voor?

In ieder geval bedankt beide voor jullie reacties!

[ Voor 3% gewijzigd door soulcrusher op 22-03-2016 21:59 ]

[Verwijderd]

CyBeR schreef op dinsdag 22 maart 2016 @ 21:54:
[...]


Behalve op Solaris/Illumos waar je dat juist wel moet doen.

Die informatie is incorrect zoals ik van Solaris diehards heb begrepen. Dat had ermee te maken dat de device write cache werd uitgeschakeld, waardoor hardeschijven tegen max 1MB/s kunnen schrijven. Dit werd gedaan omdat bij gebruik van partities mogelijk ook het ouderwetse UFS werd gebruikt en Solaris heeft geen voorzieningen als journalling of Soft Updates zoals BSD wel heeft voor het UFS filesystem. Dat betekent dat het onveilig is, net als FAT onder Windows 95 vroeger, wat continu corrumpeerde. Een oplossing om dat tegen te gaan is het uitschakelen van de device write cache, met flink lagere write performance tot gevolg.

Als je echter weet dat je geen UFS gebruikt en de write cache weer inschakelt, kun je gewoon GPT partities gebruiken onder Solaris en derivatives, zo is mij verteld. Als jij aanvullende informatie hebt, hoor ik dat graag.

soulcrusher schreef op dinsdag 22 maart 2016 @ 21:58:
Nu heb ik die nieuwe raidz2 pool met 5 disks en een memory disk gemaakt en daarna de memory disk offline gehaald. Echter groeide mijn pool niet.

Ik volg je niet helemaal. Wat heeft het aanmaken van een RAID-Z2 pool te maken met het groeien van een pool? Wat probeer je precies te doen? Wat heeft datgene te maken met de memory disk waar je over spreekt?

[ Voor 18% gewijzigd door Verwijderd op 22-03-2016 22:19 ]

[soulcrusher]

Verwijderd schreef op dinsdag 22 maart 2016 @ 22:17:
[...]
Ik volg je niet helemaal. Wat heeft het aanmaken van een RAID-Z2 pool te maken met het groeien van een pool? Wat probeer je precies te doen? Wat heeft datgene te maken met de memory disk waar je over spreekt?

Ik had een mirror van 2 3TB schijven en die wil ik upgraden naar een 6 3TB schijven raidz2. Dit heb ik gedaan door eerst één schijf uit de mirror te halen en van die samen met mijn 4 nieuwe schijven + een memory disk van 12GB een raidz2 pool gemaakt. Die pool was echter maar iets van 30GB groot. Toen heb ik de memory disk eruit gehaald en verwijderd en ik ging ervan uit dat mijn pool dan zou groeien naar 4x3TB zodat ik de data van de overgebleven mirror schijf kon kopiëren naar de nieuwe raidz2 pool. Echter bleef die pool maar iets van 30GB ipv 12TB, tot ik die (virtuele?) memory disk van 3TB had aangemaakt, toegevoegd en weer had verwijderd. Ik hoop dat het zo duidelijk is wat ik wil bereiken.

[Verwijderd]

Ah oke. Is het nu gelukt dan?

Overigens, je kunt het makkelijkste de memory disk heel groot maken, zoals 10 terabyte en voor 'swap' kiezen als backing ipv vnode (file). Bij 'swap' zal er pas RAM gebruikt worden als je daadwerkelijk schrijft. Dus dit is nog een iets makkelijkere route en zorgt ervoor dat je memory disk nooit de kleinste disk kan worden.

[soulcrusher]

Ah bedankt, ik dacht dat de grootte van de memory disk gelimiteerd werd door je hoeveelheid geheugen.

[Verwijderd]

Dat geldt alleen met -t malloc (memory allocation) in combinatie met -o reserve, waarbij alle benodigde ruimte van te voren wordt gereserveerd en niet zoals standaard pas wordt geclaimed als deze ruimte wordt gebruikt door data te schrijven naar de memory disk.

[soulcrusher]

Nog een kleine vraag: Ik ben sinds vannacht via shell access op de nas zelf met zfs send een snapshot van mijn oude pool naar mijn nieuwe pool aan het kopiëren, maar kan ik buiten op het scherm te kijken zien wat de status hiervan is?

[CurlyMo]

code:

zfs send ... | pv | zfs receive ....

Dan zie je hoeveel bytes die heeft gekopieerd.

[soulcrusher]

CurlyMo schreef op woensdag 23 maart 2016 @ 13:28:

code:

zfs send ... | pv | zfs receive ....

Dan zie je hoeveel bytes die heeft gekopieerd.

Bedankt! Dat had ik gevonden maar ik dacht eigenlijk dat dit opnieuw de snapshot zou oversturen.

[narotic]

zfs send en receive hebben beide een -v voor verbose mode die niet alleen de voortgang in bytes aangeeft maar ook de verschillende stappen.

[sam_vde]

sam_vde schreef op dinsdag 22 maart 2016 @ 06:48:
[...]
Het is aan de mensen die bang zijn voor silent data corruptie om aan te tonen dat het probleem relevant genoeg is voor thuis gebruikers. Kom maar met bewijs. En zoals je hierboven aangeeft, we weten het niet.

Je draait alles om. Ik kan aantonen dat het probleem bestaat en dat er een relatief eenvoudige en goedkope oplossing voor is. Jij kan helemaal niet aantonen dat het probleem niet relevant is maar toch blijf je dat maar aanhalen.

Wil jij het risico nemen alhoewel je het eigenlijk helemaal niet kent? Prima. Dat maakt het niet mijn probleem aan jou aan te tonen welk risico je neemt. Je kent de feiten net als ik. Iedereen moet zelf maar uitmaken hoe belangrijk hun data is.

Ik denk dat het risico van bitrot helemaal niet zo groot is en dat mensen zich helemaal geen zorgen hoeven te maken over de aanschaf van een Synology.

Wat ik schreef over Synology had niet direkt te maken met bitrot. De vraag is: als 1 schijf uit je NAS stukgaat, in welke status blijft de andere dan over? Los van bitrot: daar zouden ze heden ten dage voor dat geld veel beter moeten kunnen.

Wat jij omschrijft als FUD zie ik anders. De technologie is al zo lang beschikbaar, dat ik niet kan begrijpen dat de grote jongens ze niet al lang geïmplementeerd hebben (los van zfs).

[sam_vde]

FireDrunk schreef op dinsdag 22 maart 2016 @ 06:59:
[...]

Dat is haaks op wat Q zegt in zijn laatste alinea... Als je dat echt meent, moet je dus ook geen auto meer rijden. Daar roepen alle fabrikanten net zo goed dat het veilig is, terwijl er zelfs *doden* vallen...

Hier hebben we het 'maar' over data... Het is een beetje spijkers op laag water zoeken dat het allemaal niet meer "aangeraden mag worden"...

Voor elke use case is er ongeveer wel een apparaat. Zolang je mensen informeert over de risicio's die ze lopen (hoe groot en hoe klein ze ook zijn) kan iemand zelf een afgewogen keuze maken...

Dat doet iedereen in deze wereld op alle vlakken. Er is niets dat data op een disk anders maakt...

Allereerst: ik zou geen uitspraken doen of data voor iemand belangrijk is of niet. Als alles wat geen doden veroorzaakt per definitie niet meer belangrijk is, stoppen we nu meteen het debat.

Het punt dat ik maak, en waar ik 100% achter sta, is dat de manier waarop consumer NAS boxen vandaag geïmplementeerd zijn haast geen voordeel bieden tov. een offline backup op een externe schijf, en dat er voor die laatste optie zelfs nog iets te zeggen valt qua voordelen. Voor dat geld zouden NAS fabrikanten naar mijn mening veel beter moeten kunnen.

NAS fabrikanten informeren daar amper over, de doorsnee consument weet dat ook niet, de keuze is allerminst weloverwogen. Mensen denken "ik heb 2 schijven ik ben safe" en daar houdt het op.

Wat betreft je vergelijking met auto's: dat is een beetje zoals een wagen kopen die geen enkele officiële test of controle doorstaan heeft, en denken dat je veilig rijdt omdat de fabrikant het zegt. Op zich geen probleem mee: sommigen zullen het doen, anderen niet, ieder zijn keuze. Verschil is wel dat de overheid deze wagens verbiedt op de openbare weg.

[sam_vde]

VorCha schreef op dinsdag 22 maart 2016 @ 09:21:
[...]


Volgens FireDrunk kan ZFS dat ook niet

Klopt :-) Maar je zou gekke dingen kunnen doen zoals een MD stripe in zfs inbrengen, op zich is daar geen moeilijkheid aan.