Het grote ZFS topic

[CurlyMo]

Compizfox schreef op woensdag 02 december 2015 @ 09:25:
Huh, hoe werkt dat dan? Ik zie dat niet echt voor me. Gaan zijn dan in jouw VPS kijken hoeveel snapshots jij hebt gemaakt?

Je draait bij hun (afhankelijk van je wens) gewoon ZFS op ZFS. Ik heb hier bijvoorbeeld een FreeBSD ZFS-on-root VPS bij hun draaien. Binnen die omgeving maak ik gewoon mijn eigen snapshots (gratis). Maar TransIP kan ook snapshots maken van mijn VPS als geheel (€ 5,-). Beetje Inception dus.

[DRAFTER86]

CurlyMo schreef op woensdag 02 december 2015 @ 10:04:
[...]

Je draait bij hun (afhankelijk van je wens) gewoon ZFS op ZFS. Ik heb hier bijvoorbeeld een FreeBSD ZFS-on-root VPS bij hun draaien. Binnen die omgeving maak ik gewoon mijn eigen snapshots (gratis). Maar TransIP kan ook snapshots maken van mijn VPS als geheel (€ 5,-). Beetje Inception dus.

Ah ja, ik snap hem.
Gebruik je dan in je ZFS setup binnen je VPS gewoon een single disk/partition zonder redundancy/striping etc?
Aangezien de redundancy/bitflip protectie al door TransIP geregeld wordt...
Uiteindelijk gebruik je je VPS ZFS dan gewoon als veredelde snapshot tool, of mis ik iets?

[FireDrunk]

Dat kan, maar je kan daarna ook zfs send en receive gebruiken voor backups

Snapshot maken van je root, en je root partitie senden naar iets buiten je VPS

[jacovn]

idef1x schreef op woensdag 02 december 2015 @ 08:44:
[...]

Kaal Freebsd of of versie a la ZFSguru, freenas, nas4free?

ZFSGuru

[narotic]

CurlyMo schreef op woensdag 02 december 2015 @ 10:04:
[...]

Je draait bij hun (afhankelijk van je wens) gewoon ZFS op ZFS. Ik heb hier bijvoorbeeld een FreeBSD ZFS-on-root VPS bij hun draaien. Binnen die omgeving maak ik gewoon mijn eigen snapshots (gratis). Maar TransIP kan ook snapshots maken van mijn VPS als geheel (€ 5,-). Beetje Inception dus.

Hoeveel geheugen heeft je VPS?

Ik zit al een tijdje te twijfelen mijn XS VPS met 1GB geheugen te migreren naar ZFS, maar de vele waarschuwingen (o.a. zelfs kernel lockups) met weinig geheugen houden me vooralsnog tegen. In een virtuele machine lokaal draait ZFS nog ok met maar 512MB geheugen, maar dat is uiteraard een andere situatie dan een systeem wat 24/7 stabiel moet draaien.

[InflatableMouse]

Ik heb ineens een probleempje ...

Zoals hierboven te lezen is heb ik een paar dingetjes gewijzigd, zoals een log en cache toegeveogd. Dat heb ik ondertussen ongedaan gemaakt.

laatste wat ik heb gedaan is de recordsize aangepast van 128k naar 16k. Ik ben nu per volume een en ander heen en weer aan het kopieren, maar merk dat m'n PC bagger traag wordt. Als ik nu naar CPU kijk wordt er tijdens de copy slag 99% door system opgesnoept. M'n muis cursor begint er van te stotteren ...

Throughput kakt ook helemaal in, tot secondenlang 0, naar paar honderd kilobytes ...terug naar 0 ...

Wat is er in hemelsnaam aan de hand? Hoe kom ik daar achter?

EDIT:

Grrrr ... het lijkt windows wel. Na een reboot is het weg.

[ Voor 5% gewijzigd door InflatableMouse op 02-12-2015 20:46 ]

[CurlyMo]

narotic schreef op woensdag 02 december 2015 @ 20:20:
[...]


Hoeveel geheugen heeft je VPS?

Ik zit al een tijdje te twijfelen mijn XS VPS met 1GB geheugen te migreren naar ZFS, maar de vele waarschuwingen (o.a. zelfs kernel lockups) met weinig geheugen houden me vooralsnog tegen. In een virtuele machine lokaal draait ZFS nog ok met maar 512MB geheugen, maar dat is uiteraard een andere situatie dan een systeem wat 24/7 stabiel moet draaien.

code:

# grep memory /var/run/dmesg.boot
real memory  = 4294967296 (4096 MB)
avail memory = 4099801088 (3909 MB)

[Bonthouse]

Beste ZFS guru's, na veel zoekwerk zie ik de bomen door het bos niet meer en wil toch eens hier aankloppen met mijn vraag.
Ik heb recentelijk een Thecus i8500 met 12TB aan ruimte op de kop kunnen tikken via V&A. Luidruchtig machientje maar behoorlijk wat opslag ruimte, en daar gaat het om.
Het is ook m'n eerste ervaring met iSCSI waardoor ik toch tegen een aantal leermomentjes aanloop.
De Thecus wil ik mounten in een Ubuntu Server 14.04 omgeving en graag aansturen met ZFS omdat ik dat op het moment toch al gebruik voor de andere opslag in de Ubuntu bak.

Met flink wat Google pogingen krijg ik eigenlijk alleen maar resultaten betreft hoe je van een ZFS pool een iSCSI target kunt maken maar nog niks relevants gevonden met betrekking tot wat ik wil, vandaar dat ik mijn vraag dan toch maar eens hier stel

Ik heb al geprobeerd een RAID5 virtual disk in de Thecus aan te maken en die dan vervolgens te mounten in Ubuntu, maar zodra ik "zpool create zfs/thecus /dev/sdg" invoer (slechte manier van aanmaken, I know ) krijg ik vrij matige read/write speed (90MBps/70MBps) ten opzichte van wanneer ik er een EXT4 partitie van maak middels Parted (118MBps/116MBps).

Kan/wil/gaat ZFS niet goed samen met iSCSI targets of zijn er toch andere manieren om een iSCSI disk aan te spreken met ZFS?

[FireDrunk]

Je kan geen filesystems schrijven op mountpoints. Je moet verwijzen naar het block device.
Vaak is dat iets in /dev/disk/*

Voorbeeldje

Hier hebben ze het over /dev/disk/by-path/*openfiler*

[ Voor 4% gewijzigd door FireDrunk op 03-12-2015 08:28 ]

[Dutch2007]

Bonthouse schreef op woensdag 02 december 2015 @ 22:42:
Beste ZFS guru's, na veel zoekwerk zie ik de bomen door het bos niet meer en wil toch eens hier aankloppen met mijn vraag.
Ik heb recentelijk een Thecus i8500 met 12TB aan ruimte op de kop kunnen tikken via V&A. Luidruchtig machientje maar behoorlijk wat opslag ruimte, en daar gaat het om.
Het is ook m'n eerste ervaring met iSCSI waardoor ik toch tegen een aantal leermomentjes aanloop.
De Thecus wil ik mounten in een Ubuntu Server 14.04 omgeving en graag aansturen met ZFS omdat ik dat op het moment toch al gebruik voor de andere opslag in de Ubuntu bak.

Met flink wat Google pogingen krijg ik eigenlijk alleen maar resultaten betreft hoe je van een ZFS pool een iSCSI target kunt maken maar nog niks relevants gevonden met betrekking tot wat ik wil, vandaar dat ik mijn vraag dan toch maar eens hier stel

Ik heb al geprobeerd een RAID5 virtual disk in de Thecus aan te maken en die dan vervolgens te mounten in Ubuntu, maar zodra ik "zpool create zfs/thecus /dev/sdg" invoer (slechte manier van aanmaken, I know ) krijg ik vrij matige read/write speed (90MBps/70MBps) ten opzichte van wanneer ik er een EXT4 partitie van maak middels Parted (118MBps/116MBps).

Kan/wil/gaat ZFS niet goed samen met iSCSI targets of zijn er toch andere manieren om een iSCSI disk aan te spreken met ZFS?

Kan je niet eenvoudiger mountpoints aanmaken (en zo de size beheren) en gebruik maken van NFS ?

Heb je niet alleen file acces via de thecus, maar ook op de client waar je de volumepoint op hebt..
Met als extra voordeel dat je dan in ZFS gewoon de limit kan instellen en ONLINE, dus zonder downtime de grote kan aanpassen, want dan pas je inprincipe het quota van dat voluma aan..

Bij iscsi, dien je dat volume eerst los te koppelen, extenden en daarna pas kan je de disk extenden... al dat is niet nodig bij NFS3 (of als het kan direct NFS4.1 gebruiken)

NFS4+ werkt met acl list qua netwerk bereik en toegankelijkheid...

[FireDrunk]

De Thecus doet zelf geen ZFS he, hij moet dus lokaal ZFS doen op de volumes die hij van de Thecus geleverd krijgt. Als hij NFS zou gaan gebruiken kan hij dus geen ZFS meer gebruiken.

[Dutch2007]

waarom zou je dan nog ZFS willen gebruiken? als het storage apparaat geen ZFS doet, kan je toch nog steeds altijd bit-rot krijgen? (ook al zou je iets kunnen doen als per disk een raid0 aanmaken, daar per volledig volume een iscsi op aanmaken en van dan 3 of meer een RAIDZ1 (of hoger) van maken op de client...

de onderste laag die doet dan geen ZFS... dus alles wat daar bovenligt gaat wel d'r van uit dat het onderste het doet...

Lokaal ZFS kan in deze situatie, waar de echte storrage op staat, hooguit als voordeel hebben dat je die optie aanzet dat een file op 2 (of meer) plekken wordt opgeslagen voor added redundancy, maar dan nog blijft bitrot een issue imo....

[ Voor 3% gewijzigd door Dutch2007 op 03-12-2015 11:32 ]

[FireDrunk]

Je kan bitrot niet oplossen maar wel detecteren. Maar je hebt zeker een valide punt.
ZFS op een iSCSI volume op een Thecus is een beetje een tractor op sleeptouw nemen met een Lamborghini...

[narotic]

FireDrunk schreef op donderdag 03 december 2015 @ 11:47:
Je kan bitrot niet oplossen maar wel detecteren.

Zolang je redundancy hebt (copies>=2, mirror, raidz) lost ZFS bitrot ook voor je op hoor. In dit geval lijkt me dat de copies property makkelijker en wellicht netter is dan een mirror/raidz richting dezelfde iscsi target.

[ Voor 15% gewijzigd door narotic op 03-12-2015 21:38 ]

[FireDrunk]

Oh zeker, maar het ging hier over de context van ZFS op iSCSI. Omdat hij dan geen redundancy heeft kan hij niet zomaar bitrot repareren.

Copies=2 is eventueel wel een oplossing, maar ik weet niet zo goed hoe dat werkt icm een single disk pool. Als ZFS die copies gewoon achter elkaar zet, vraag ik me af hoe effectief dat is icm iSCSI.

[narotic]

Sorry, ik had je volgens mij dan niet helemaal goed begrepen.

ZFS will spread the ditto blocks across the vdev or vdevs to provide spatial diversity. Bill Moore has previously blogged about this, or you can see it in the code for yourself. From a RAS perspective, this is a good thing. We want to reduce the possibility that a single failure, such as a drive head impact with media, could disturb both copies of our data.

bron.

In de praktijk zal copies redelijk veilig zijn en je hebt de vrijheid om het per dataset in te stellen. Je kunt echter niet garanderen dat de kopieen ook op verschillende fysieke schijven worden opgeslagen, wat bij RAIDZ en mirrors natuurlijk wel altijd het geval is.

[FireDrunk]

Precies, en icm een raid engine van een hokkiewokkie NAS zou ik er niet vanuit gaan dat ZFS goed werkt

[InflatableMouse]

Vraagje. Ik heb geheugen uitgebreid naar 32GB. Nu heb ik zfs_arc_min op 4294967296 gezet. Kan ik checken via 'cat /sys/module/zfs/parameters/zfs_arc_min'.

Als ik free -h doe, zie ik dat echter niet terug.

Als m'n systeem niet aangeef dat er nu 4GB minder te gebruiken is, gaan applicaties (Virtualbox) dat dan toch niet proberen te gebruiken?

[FireDrunk]

ZFS kan niet zo 'hard' geheugen claimen dat de rest van het systeem het niet meer ziet. ZFS is wat dat betreft ook gewoon een 'applicatie'.

Enige verschil is wel dat ZFS in de kernel draait en dus iets harder om geheugen kan zeuren dan andere applicaties.

Maar als VirtualBox echt veel geheugen gaat alloceren zal ZFS daar nog steeds last van hebben.

Je kan niet zomaar hard geheugen alloceren aan een toepassing helaas
Je zult gewoon op moeten letten met wat je doet.

[InflatableMouse]

Oke, duidelijk.

Maar wat voor nut heeft die zfs_arc_min dan precies? Dat tie het minder snel vrijgeeft als iets anders er om vraagt?

[FireDrunk]

zfs_arc_min is wat ZFS direct aan geheugen inneemt voor ARC bij boot.
zfs_arc_max is wat ZFS maximaal aan geheugen inneemt voor ARC.

In mijn geval:

code:

[thijs@NAS ~]$ cat /etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=17179869184
options zfs zfs_vdev_cache_size=16777216
options zfs zfs_vdev_min_pending=1
options zfs zfs_vdev_max_pending=1

[ Voor 46% gewijzigd door FireDrunk op 06-12-2015 16:21 ]

[InflatableMouse]

Hm. Oke. Dan snap ik denk ik niet waarom die optie bestaat, want ZFS pakt toch standaard het merendeel van het geheugen?

Edit: Niet om eigenwijs te willen doen maarre ... hier staat het vrij duidelijk:

When a system's workload demand for memory fluctuates, the ZFS ARC caches data at a period of weak demand and then shrinks at a period of strong demand. However, ZFS does not shrink below the value of zfs_arc_min. The default value of zfs_arc_min is 12% of memory on large memory systems and so, can be a significant amount of memory. If a workload's highest memory usage requires more than 88% of system memory, consider tuning this parameter.

Src: http://docs.oracle.com/cd...817-0404/gjheb/index.html

Ik heb het bij mij zo staan na m'n geheugenuitbreiding:

code:

options zfs zfs_arc_min=8589934592
options zfs zfs_arc_max=17179869184

[ Voor 81% gewijzigd door InflatableMouse op 06-12-2015 21:25 ]

[Verwijderd]

Hallo mede tweakers

Ik heb de volgende vraag Ik heb een ZFS 5 disk RaidZ setup van 5x1TB En 1 een singel 4TB disk Nu is me een 1TB schijf defect gegaan en wil ik deze vervangen voor een 4TB ( deze word natuurlijk als 1TB aangesproken ) Nu vroeg ik me af; als ik alle 5 de 1TB disks uiteindelijk heb vervangen door 4TB disks. Kan ik dan uiteindelijk de pool vergroten naar 16TB zodat alle 5 4TB disks volledig benut worden? Ik begrijp dat het niet mogelijk is om de pool van 5 disks uit te breiden is naar 6 disks. Of is dit inmiddels wel mogelijk met ZFS?

Grz....

[maomanna]

ik dacht dat je 1TB schijf wel kon vervangen voor een 4tb schijf.
Een poos terug had ik erover gelezen in een blog.
zoek hier even bij mijn posts.

[VorCha]

Verwijderd schreef op maandag 07 december 2015 @ 13:36:
Hallo mede tweakers

Ik heb de volgende vraag Ik heb een ZFS 5 disk RaidZ setup van 5x1TB En 1 een singel 4TB disk Nu is me een 1TB schijf defect gegaan en wil ik deze vervangen voor een 4TB ( deze word natuurlijk als 1TB aangesproken ) Nu vroeg ik me af; als ik alle 5 de 1TB disks uiteindelijk heb vervangen door 4TB disks. Kan ik dan uiteindelijk de pool vergroten naar 16TB zodat alle 5 4TB disks volledig benut worden? Ik begrijp dat het niet mogelijk is om de pool van 5 disks uit te breiden is naar 6 disks. Of is dit inmiddels wel mogelijk met ZFS?

Grz....

Volgens mij is zodra je alle disk vervangen hebt is direct de volledige ruimte beschikbaar. Je pool uitbreiden van 5 naar 6 disk gaat niet (dit kun je alleen bereiken door de pool opnieuw aan te maken, maar dan gaat wel de data verloren).

[FireDrunk]

InflatableMouse schreef op zondag 06 december 2015 @ 16:40:
Hm. Oke. Dan snap ik denk ik niet waarom die optie bestaat, want ZFS pakt toch standaard het merendeel van het geheugen?

Edit: Niet om eigenwijs te willen doen maarre ... hier staat het vrij duidelijk:


[...]


Src: http://docs.oracle.com/cd...817-0404/gjheb/index.html

Ik heb het bij mij zo staan na m'n geheugenuitbreiding:

code:

options zfs zfs_arc_min=8589934592
options zfs zfs_arc_max=17179869184

Dat spreekt toch niet tegen wat ik zei? Dat is een beetje wat ik bedoelde met bij boot.
Het is de initiële hoeveelheid geheugen die "allocated" wordt (ook al is er nog niks om er in te stoppen.)
Je hoeft dus niet bang te zijn dat applicaties ARC geheugen in gaan nemen.

MAAR, zfs gebruikt nog meer geheugen dan alleen ARC. Voor transacties moet er ook nog genoeg geheugen zijn, alleen is dat vluchtig geheugen. Als je applicaties alle geheugen innemen op alleen het ARC na, dan heeft ZFS daar nog steeds last van

Dat is wat ik bedoelde

[Paul]

Verwijderd schreef op maandag 07 december 2015 @ 13:36:
Ik begrijp dat het niet mogelijk is om de pool van 5 disks uit te breiden is naar 6 disks.

Ja en nee. Ja het kan, nee, het is niet wat jij wil

Een pool bestaat uit minimaal één vDev, en in jouw geval is een RAID-Z vDev met 5 schijven. Die vDev kun je niet uitbreiden, wel kun je de pool uitbreiden met extra vDev's. Als je dat echter doet met een vDev van één schijf, dan ga je stripen over een RAID-Z en een enkele disk, waardoor je alles kwijt kunt raken als die ene schijf stuk gaat. (of blokjes ervan niet meer te lezen zijn).

Schijven (één voor een, en dan iedere keer resilveren) vergroten gaat wel, en inderdaad kun je dan op het einde de boel van 4 naar 16 TB vergroten. Als je er voldoende aansluitingen voor hebt en de te vervangen schijf werkt nog wel (hangt van het defect af. Tikkend geluid + niet meer te zien versus S.M.A.R.T.-waarden die wat hoog zijn bijvoorbeeld ) dan kun je ze er beter tegelijkertijd in hangen en tegen ZFS zeggen dat je de schijf wilt replacen. Dat geeft de meeste bescherming van je data omdat je de hele tijd met een 'optimale' array draait. Haal je de 1 TB eruit en voeg je dan pas de 4 TB toe dan draai je sowieso degraded.

[InflatableMouse]

FireDrunk schreef op maandag 07 december 2015 @ 15:04:
[...]

Dat is wat ik bedoelde

Dan had ik je verkeerd begrepen .

Kan je wel vertellen dat de settings een groot verschil maken wanneer m'n systeem onder druk komt te staan. VM's worden wel wat trager omdat er dan 10 staan te lezen en te schrijven, maar m'n hele systeem blijft responsive. Dat was voorheen niet.

[Verwijderd]

Paul schreef op maandag 07 december 2015 @ 15:44:
[...]
Ja en nee. Ja het kan, nee, het is niet wat jij wil

Een pool bestaat uit minimaal één vDev, en in jouw geval is een RAID-Z vDev met 5 schijven. Die vDev kun je niet uitbreiden, wel kun je de pool uitbreiden met extra vDev's. Als je dat echter doet met een vDev van één schijf, dan ga je stripen over een RAID-Z en een enkele disk, waardoor je alles kwijt kunt raken als die ene schijf stuk gaat. (of blokjes ervan niet meer te lezen zijn).

Schijven (één voor een, en dan iedere keer resilveren) vergroten gaat wel, en inderdaad kun je dan op het einde de boel van 4 naar 16 TB vergroten. Als je er voldoende aansluitingen voor hebt en de te vervangen schijf werkt nog wel (hangt van het defect af. Tikkend geluid + niet meer te zien versus S.M.A.R.T.-waarden die wat hoog zijn bijvoorbeeld ) dan kun je ze er beter tegelijkertijd in hangen en tegen ZFS zeggen dat je de schijf wilt replacen. Dat geeft de meeste bescherming van je data omdat je de hele tijd met een 'optimale' array draait. Haal je de 1 TB eruit en voeg je dan pas de 4 TB toe dan draai je sowieso degraded.

De array is nu al degraded de 1 TB disk start niet meer op, ook niet meer met andere voeding en kabels. Ik heb de array RO gemaakt voor de zekerheid. Wil dat er niemand meer naar schrijft. Tijdelijk een RW share naar de singel 4TB gelinkt die gebruik normaal voor backup.

Ik ga de 1TB disks in ieder geval voor een 4TB vervangen en dan als ze allemaal vervangen zijn kijken of ik de volume van 4 naar 16 kan krijgen. Ik begrijp dat dat de beste optie is

[ Voor 84% gewijzigd door Verwijderd op 07-12-2015 18:07 ]

[idef1x]

Ik heb de klepel horen luiden en begreep dat je VOOR het vervangen van de 1e disk de optie/feature auto_expand op true moet zetten?

[Verwijderd]

Volgens mij hoeft dat niet. Maar mogelijk is het nodig om een export + import te doen voordat hij de pool echt groter maakt.

[idef1x]

nog even gegoogeld en het lijkt een of of te zijn:
http://docs.oracle.com/cd...819-5461/githb/index.html

[Verwijderd]

idef1x schreef op maandag 07 december 2015 @ 21:47:
nog even gegoogeld en het lijkt een of of te zijn:
http://docs.oracle.com/cd...819-5461/githb/index.html

Dankje voor de link. Dit is duidelijke taal

[_-= Erikje =-_]

Hmm, op mijn werk stiekem eens aan het kijken wat een Supermicro 2028U-TNR4T+ met wat schijfjes, HBA en 4x NVMe SSD als ZIL/cache zou moeten kosten :-)

[Bigs]

_-= Erikje =-_ schreef op dinsdag 08 december 2015 @ 11:46:
Hmm, op mijn werk stiekem eens aan het kijken wat een Supermicro 2028U-TNR4T+ met wat schijfjes, HBA en 4x NVMe SSD als ZIL/cache zou moeten kosten :-)

Wat is je use case? Ik vind het zo jammer dat je met ZFS altijd een single point of failure hebt omdat je maar één host voor je storage hebt staan. Oracle verkoopt HA ZFS oplossingen met twee controllers (passief/actief) die allebei verbonden zijn aan een of meer JBODs maar ik zie in de OpenZFS wereld hier weinig concrete voorbeelden van die ik echt in productie zou durven gebruiken (vaak is het iets van pacemaker/corosync met een fragiel import/export proces en een virtueel IP voor NFSv3 waarvan onduidelijk het is hoe bv VMware hierop reageert).

[ Voor 3% gewijzigd door Bigs op 08-12-2015 13:08 ]

[_-= Erikje =-_]

Bigs schreef op dinsdag 08 december 2015 @ 13:05:
[...]


Wat is je use case? Ik vind het zo jammer dat je met ZFS altijd een single point of failure hebt omdat je maar één host voor je storage hebt staan. Oracle verkoopt HA ZFS oplossingen met twee controllers (passief/actief) die allebei verbonden zijn aan een of meer JBODs maar ik zie in de OpenZFS wereld hier weinig concrete voorbeelden van die ik echt in productie zou durven gebruiken (vaak is het iets van pacemaker/corosync met een fragiel import/export proces en een virtueel IP voor NFSv3 waarvan onduidelijk het is hoe bv VMware hierop reageert).

iSCSI storage voor VmWare en/of Xen (oracle VM bijvoorbeeld). An sich is een enkele host wel redelijk HA te maken, maar we overwegen snapshots te syncen naar een 2e host, je zou dan met bv heartbeat kunnen zorgen dat je iSCSI ip's mee gaan

[Bigs]

_-= Erikje =-_ schreef op dinsdag 08 december 2015 @ 13:10:
[...]


iSCSI storage voor VmWare en/of Xen (oracle VM bijvoorbeeld). An sich is een enkele host wel redelijk HA te maken, maar we overwegen snapshots te syncen naar een 2e host, je zou dan met bv heartbeat kunnen zorgen dat je iSCSI ip's mee gaan

'Redelijk HA' bestaat niet.. het is HA of niet Het probleem is dat iSCSI stateful is dus je kunt dat niet zomaar omgooien naar een ander IP. Bovendien ga je met snapshots altijd terug in de tijd dus zo'n failover kun je niet gebruiken om bv software updates uit te voeren op je storage server. Voor een goede iSCSI oplossing met hoge beschikbaarheid moet je een MPIO oplossing moeten hebben en dat is volgens mij erg lastig in combinatie met ZFS omdat het totaal geen cluster support heeft.

Als je VM cluster ook geen HA gaat doen is het natuurlijk allemaal niet zo relevant

[_-= Erikje =-_]

Bigs schreef op dinsdag 08 december 2015 @ 13:15:
[...]


'Redelijk HA' bestaat niet.. het is HA of niet Het probleem is dat iSCSI stateful is dus je kunt dat niet zomaar omgooien naar een ander IP. Bovendien ga je met snapshots altijd terug in de tijd dus zo'n failover kun je niet gebruiken om bv software updates uit te voeren op je storage server. Voor een goede iSCSI oplossing met hoge beschikbaarheid moet je een MPIO oplossing moeten hebben en dat is volgens mij erg lastig in combinatie met ZFS omdat het totaal geen cluster support heeft.

Als je VM cluster ook geen HA gaat doen is het natuurlijk allemaal niet zo relevant

Tsja, uiteindelijk staat het toch op 1 locatie :-) maar idd het is ook gewoon een kwestie van kosten/baten uitzetten. Natuurlijk wil iedereen dikke Purestorage arrays maar ja daar is niet altijd de businesscase voor

[Bigs]

Klopt maar een entry level iSCSI of SAS SAN is niet heel duur en heeft een veel lagere beheerslast dan een ZFS oplossing, vandaar dat ik mensen altijd aanraad om goed na te gaan of ZFS wel echt bij hun specifieke wensen aansluit.

[ Voor 12% gewijzigd door Bigs op 08-12-2015 13:25 ]

[_-= Erikje =-_]

True, al kost zelfs een HP P2000 G3 MSA al rond de 8k ex btw zonder schijven (en vendor lock-in qua disks)

[Q]

Voor die schamele 8K krijg je een oplossing die in alle opzichten beter is dan een zelfbouw bak met ZFS.

Vergeet niet dat die enterprise SAN machines dual-controller draaien, HA support ingebouwd hebben en dat die enterprise disks grotere secoren met parity hebben (data integriteit!).

Je koopt een kant-en-klare oplossing zodat jij je bezig kan houden met een bedrijf te runnen in plaats van IT-er te spelen.

Voor een beetje bedrijf is 8K niet veel geld maar dat hangt meestal ook wel weer samen met de head-count.

Heb laatst gehad met een van onze MSAs (Productie) dat een controller ECC errors gaf en vervangen moest worden. Dat kan dus live terwijl het systeem aan staat.

En dat voor 8K. Die 2040 serie met support voor SSDs lijkt mij super.

Het grote verschil met het grotere spul (3PAR) is het gebrek aan (auto) tiering (naast performance en schalbaarheid, maar dat is vaak niet zo'n issue).

[ Voor 7% gewijzigd door Q op 08-12-2015 14:35 ]

[_-= Erikje =-_]

Voor die schamele 8k zit er alleen nog geen enkele drive in :-)
Ga je 'm een klein beetje aankleden met StorageTiering, 2x 400G ssdtjes en 14x 1.8Tbyte SAS drives zit je gelijk tegen de 30k aan te hikken, dat blijft toch veel geld. (lees ga ik niet door de budgetering krijgen)

[Q]

Vergeet je support contract ook niet, ook weer een paar K

Tja het is ook een beetje wat voor verhaal je er bij hebt natuurlijk. Want met zelfbouw krijg je nooit wat een MSA je gaat leveren in termen van betrouwbaarheid en support. En jouw zelfbouw FTEs zijn ook niet gratis. Maar als dit soort bedragen niet in verhouding staat met de business dan snap ik dat ook wel weer.

Maar dan zou ik eerder kijken naar een mooie server met Windows 2012 R2 en de ingebouwde storage tiering. Wel met de pro-schijven (sas spul). Met consumenten schijven krijg je dan niet de databescherming die je wel met een SAN of ZFS zou hebben.

Als het om bedrijven gaat dan is bij mij de regel dat alles toch keer twee gaat zodra je een beetje een redelijke RTO & RPO wilt. 1 server = geen server. Zo is het ook met storage.

[FireDrunk]

Net als 1 backup is geen backup

[_-= Erikje =-_]

Uiteraard kost support ook weer een stapel geld (en vervolgens ben je afhankelijk van een bedrijf dat zegt 24x7x4hr te doen, maar praktijk moet dan altijd nog maar blijken. Ja je had een mailtje terug binnen 4hr )

Maar goed, het idee is duidelijk. Het hangt ook gewoon af van welke bedrijfstak je zit. Als tech bedrijf bestaande uit een flinke club techneuten maakt het minder uit dan dat Piets Schilderkwasten op de hoek wat neerzet. Maar ik leid ons een aardig stukje af van de uiteindelijke discussie, zfs dus

[Q]

Wat ik niet zo goed snap is dat je aan de ene kant wel Oracle spul wilt gaan draaien wat meestal wel $$$ is, maar dat opeens de hardware niets mag kosten. Nu weet ik niet wat een db licentie oid kost tegenwoordig bij Oracle, maar Larry kennde .....

Het is juist wel weer interesant om na te denken hoe je dan als je voor zelfbouw gaat met ZFS je bepaalde RPO en RTO requirements haalt. Een Thuis ZFS bakje neerzetten is 1 ding. Professioneel ZFS draaien is toch heel iets anders denk ik.

[FireDrunk]

Ik denk dat je het eerder moet zoeken door meerdere ZFS instanties te maken waarna je een platform gebruikt wat op een hoger niveau High Availability verzorgt.

Als je echt groot wil denken qua high available storage, zou ik aan een CEPH of GlusterFS oplossing denken op ZFS building blocks.

[ Voor 4% gewijzigd door FireDrunk op 09-12-2015 12:17 ]

[_-= Erikje =-_]

Q schreef op woensdag 09 december 2015 @ 12:06:
Wat ik niet zo goed snap is dat je aan de ene kant wel Oracle spul wilt gaan draaien wat meestal wel $$$ is, maar dat opeens de hardware niets mag kosten. Nu weet ik niet wat een db licentie oid kost tegenwoordig bij Oracle, maar Larry kennde .....

Het is juist wel weer interesant om na te denken hoe je dan als je voor zelfbouw gaat met ZFS je bepaalde RPO en RTO requirements haalt. Een Thuis ZFS bakje neerzetten is 1 ding. Professioneel ZFS draaien is toch heel iets anders denk ik.

Oracle VM is gratis (gebaseerd op Xen) Oracle db daarintegen Maar idd, ik beweer ook niet dat het ideaal is :-) kijk als het geld van de muren druipt is het wat anders

[Q]

Misschien is het ergens extreem,maar aan de andere kant niet gek: CEPH zoals genoemd door FireDrunk zou best wel een beter passende oplossing kunnen zijn voor jullie. Helaas is dat weer geen ZFS talk

CEPH is gaaf omdat het schaalbaar is in capaciteit en performance en fault-tollerance is (100% automatisch). Of er nu een disk of een hele host stuk gaat, ceph handelt het af zonder dat je wat hoeft te doen.

Je begint met twee doosjes en je voegt doosjes doe met disks naar gelang de behoefte.

Ceph heeft wel een serieuze leercurve, maar het kost niets behalve tijd. Het zit standaard in iedere Linux kernel.
En het het beschermt data met CRC32, niet zo goed als ZFS, maar goed genoeg voor het doel.

Ik speel er zelf mee, ik heb een clustertje met 4 nodes thuis draaien, erg interessant.

[ Voor 7% gewijzigd door Q op 09-12-2015 12:59 ]

[FireDrunk]

Ik heb zowel met Gluster als met CEPH gewerkt, en ik vond een groot voordeel van Gluster dat je data nog gewoon intact op het onderliggene filesystem staat. Mocht je dus van Gluster af willen, kan je gewoon Gluster de-installeren en de originele data op het onderliggende filesystem uitlezen.

CEPH is daarentegen een kernel filesystem waardoor het vele malen sneller is dan Gluster (als ik het internet mag geloven).

[Q]

Ceph is in de core object-storage maar daaroverheen hebben ze verschillende laagjes en een daarvan is 'raw block device' of RDB support.

Ik ben niet zo bekend met Gluster, maar volgens mij is dat een heel ander soort oplossing.

Ik kan nu bijvoorbeeld een RBD block device rechtstreeks via LIO exporteren als iscsi target, voor machines die geen ceph rbd ondersteunen. XEN doet RBD native.

RBD is eigenlijk de ZVOL van ZFS maar dan distributed. Een ZVOL kun je alleen lokaal op de machine benaderen of via iSCSI exporteren.

Native RBD houdt in dat een VM host met alle nodes in het cluster direct kan praten, geen iscsi nodig en direct toegang tot de storage waarbij acceess dus gestriped kan worden over de nodes = betere performance.

Maar wat ik wel vergeet te zeggen is dat je met CEPH ook minimaal 3 monitor nodes moet runnen (cluster requirement). Dat hoeft niet zo'n spannende hardware te zijn, maar het komt er wel bij.

[ Voor 41% gewijzigd door Q op 09-12-2015 15:29 ]

[CAPSLOCK2000]

Q schreef op woensdag 09 december 2015 @ 14:36:
Maar wat ik wel vergeet te zeggen is dat je met CEPH ook minimaal 3 monitor nodes moet runnen (cluster requirement). Dat hoeft niet zo'n spannende hardware te zijn, maar het komt er wel bij.

Dat is waar maar die monitoren hoeven niet op aparte machines te draaien, die kun je ergens bij zetten. Als je geen drie machines hebt dan heeft CEPH ook geen zin.

[InflatableMouse]

Ik heb een fuck up gemaakt en m'n pool moeten rebuilden. Dat heb ik nu gedaan, maar er is iets geks. Ik heb 3 x 4 TB disks. Voorheen met een raidz1 zag ik 7,6TB beschikbaar ongeveer, nu zie ik 10,2. Er is 3,8 per disk beschikbaar dus ik zou 7,6 moeten zien. Ik had eerst vergeten raidz1 parameter mee te geven maar daarna dus weer opnieuw gedaan (had nog niets gekopieerd) maar hij laat nog steeds 10 zien.

Hoe kan dat?

[InflatableMouse]

Ben gaan copieren en er een disk uitgetrokken. Alles blijft werken en bij terug inpikken kan ik een scrub en clear van de error doen, alles is weer goed.

Ik snap niet waarom er zoveel ruimte beschikbaar is hoor...

[HyperBart]

Ben je niet aan het verwarren met zfs list en zpool list? Die twee outputs geven andere waardes, de ene rekent pariteit mee in de capaciteit, de andere niet...

[InflatableMouse]

Zpool iostat - v

Oh duhuh... Hahaha!

Knuppel dat ik ben. Das allocated en free. Niet totaal. Er stond 2,nogwat op voorheen waardoor het ongeveer gelijk was aan 'available' met zfs list.

[ Voor 96% gewijzigd door InflatableMouse op 09-12-2015 21:05 ]

[Fr0zenFlame]

InflatableMouse schreef op maandag 30 november 2015 @ 14:23:
Uit een van de linkjes hierboven:
[...]
Ben me er ook iets meer aan het verdiepen nu omdat ik dus ook behoorlijk wat misopvattingen had over ZIL. het lijkt me dus meer zoiets als een SQL transaction log, da's ook geen cache.

ZFS is ook vanuit die filosofie ontwikkeld, er is ook vanuit de database wereld (SUN/Oracle) gekeken naar de huidige filesystems en hoe dit beter kan/moet.

Als je iets met ZFS gaat doen, zeker zakelijk zou ik je aanraden onderstaande twee video's van Linda Kately goed te bekijken dan wordt je een stuk duidelijk hoe ZFS in elkaar steekt en hoe je de maximale performance eruit krijgt. Op internet kom je zoveel misverstanden tegen m.b.t. ZIL, SLOG, Wel/niet hardware raid gebruiken etc.. allemaal vrij essentiële dingen die je echt moet weten.

Open-ZFS Bootcamp
YouTube: Open-ZFS Bootcamp

Why use zfs for virtual machines??
YouTube: Why use zfs for virtual machines??

Momenteel ben ik zelf bezig samen met een collega met het inrichten van een Storage Repository waar VMs op komen ste staan van het type RDS (XenApp). Dit alles draait op XenServer hypervisors.

De configuratie van deze machines bestaat uit:

• 2x Formfactor: HP Proliant DL380p Gen8
• DriveBay: Hot Swap capable (Wel even disks offline zetten )
• 2x Intel® Xeon® Processor E5-2650 v2 (20M Cache, 2.60 GHz)
• 2x 64GB ECC mem per host, dit moet in de toekomst naar 2x 128GB ECC aangezien FreeNas daar behoorlijk wat voordelen aan kan hebben.
• 2x 12 Samsung SM863 - 480GB SSDs > voor de storage pool (volume01).
• 2x Samsung 850 Pro > voor het FreeNas OS (overkill, geen redundantie gewoon export van config naar share en hotstandby OS op interne USB stick).
• 4x LSI 9201-16e @ IT Firmware (JBOD), twee per host om de maximale bandbreedte te kunnen benutten en enige vorm van redundantie.
• 2x 10GB Fiber (1 per host, dit moeten er twee worden maar momteenl hebben we te weinig 10GB glas porten beschikbaar om LACP (IEEE 802.3ad) toe te passen .
• 4x 750w voeding, tweek per host
• 2x PCI-e kaart met 2x 1GB rj45 aansluiting voor management interface, willen geen management vlan over de glas verbinding, deze is voor voor het NFS storage netwerk.

ZIL op SLOG
In bovenstaande configuratie maken we geen gebruik van een SLOG voor de ZIL ondanks het feit dat NFS gebruik maakt van SYNC writes omdat de hele pool uit SSDs bestaat en een SLOG is alleen handig als je nog snellere media inzet zoals bijvoorbeeld Fusion I/O. Bovendien zijn twee SM863 SSDs in mirror een vertragende factor op de totale pool van 12 en in de toekomst 24 SSDs.

Pool Configuratie
De pool configuratie bestaat momenteel uit 6 mirrors (0~5) van twee SSDs elk op een andere controller zodat je optimale redundantie hebt op controller niveau. ZFS stiped de data vanuit nature over alle 6 de vDEVs (elke mirror is 1 vDEV) waardoor je er in onze optiek optimale performance uit krijgt en ook nog een redelijke mate van redundantie.

Redundantie
Uit veiligheids overwegingen hebben we er voor gekozen alleen ons RDS servers (Front-End) op deze storage te gaan plaatsen, deze servers zijn immers vervangbaar. Bovendien varen deze VMs extra goed op dit soort storage vanwege de vele random I/O die users genereren.

NFS vs. iSCSI (andddddd... fight!)
We hebben gekozen voor NFS in tegenstelling tot iSCSI.
Uit ervaring en uit tests is gebeleken dat iSCSI een verwaarloosbare snelheid winst opleverd, een stuk complexer is en het geheel beheerbaar moet zijn voor iedereen op de afdeling. Ook heb ik mn vraagtekens bij het plaatsen van meedere VMs op een share LUN (exclusive access), om dit te omzeilen zou je per VM een LUN kunnen toevoegen maar dat wordt erg rommelig in XenCenter.

Extra zekerheid
Als extra voorzorg maatregel plaatsen wij de even RDS servers op de ene host en de oneven hosts op de andere. In de toekomst willen we eigenlijk alle hosts op 1 SR plaatsen, hier vervolgens snapshots op activeren en deze synchroniseren naar de andere host. Ik weet dat in FreeBSD de Highly Available Storage (HAST) functionaliteit zit, maar deze is nog vrij experimenteel en bovendien niet ondersteund in FreeNas 9.3.1-Stable.

DEDUP& Compression
We hebben er voor gekozen geen DEDUP toe te passen omdat dit een behoorlijk deel van het geheugen kaapt, het de prestaties daarnaast niet te goede komt en dat was nou net onze goal. De ingabakken LZJB compressie leverd overigens gewoon een compressie ratio van 1.55x op wat best goed is en geen impact heeft op de prestaties (CPU > Storage).
* Al zou in ons geval DEDUB wel een hoop ruimte opleveren als je 30 dezelfde VMs hebt

Resultaat:
Momenteel zijn we nog aan het testen in acceptatie, maar ik moet zeggen het blaast vooruit, de RDS servers reageren veel beter, bijna geen latency het is bijna native storage voor mn gevoel (ondanks dat het een NAS i.p.v. SAN topology is). Als ik vervolgens kijk naar de GSTAT, IOSTAT, zpool iostat -v1 lijken de individuele "disks" het met twee vingers in de neus aan te kunnen... nou is het niet helemaal eerlijk omdat een groot deel gewoon in het geheugen wordt gecached maar toch ziet er prima uit! Zelfs wanneer ik met DD, FIO of een simpele mount + CP de disks extreem belast merk ik daar niets van in mn user sessie op de RDS servers, en sommige SSDs staan dan echt op hun max te stampen (zn 14K IOPs).

Ik ben FAN!

* Owhja de ingebouwde checksums ofwel het "Self Healing File System" is helemaal een prettige bijkomstigheid! Geen bitflip of bitrot meer WhoeeeI! Tenzij je natuurlijk wel iSCSI (SAN) gaat doen en file systems uit de oertijd los laat op je blocks.

[ Voor 4% gewijzigd door Fr0zenFlame op 10-12-2015 16:53 ]

[Q]

Hoe ga je nu om met hardware failure?
Wat als een van de twee ZFS storage machines de geest geeft?

[Fr0zenFlame]

Q schreef op donderdag 10 december 2015 @ 16:52:
Hoe ga je nu om met hardware failure?
Wat als een van de twee ZFS storage machines de geest geeft?

Disks
Disks zijn gemirrored, dus Hot Swapp.
Natuurlijk is het belangrijk dit snel te doen, want als je hele mirror down is ben je gelijk je hele volume kwijt!

PSU
Deze is dubbel uitgevoerd, net als de kabels.

10GB Netwerk
Nu nog single maar wordt IEEE 802.3AD wanneer we extra porten beschikbaar hebben.

OS Disks
Het OS draait in het geheugen en zal geen hinder ondervinden van een defecte OS disks (SSD), pas bij een reboot. De config wordt opgeslagen op het netwerk, er kan vervolgens geboot worden van een interne hot-standby USB stick waarop je de config importeerd tot de OS disk is vervangen. Overigens wordt die OS disk nagenoeg niet beschreven omdat alles in het geheugen draait, deze zal denk ik nooit het maximaal aantal writes halen.

HBA
Dubbele LSI 9201-16e controllers, vaak is dit er maar 1
En als er 1 uitvalt is de helft van elke mirror down, dat kan dus.

Overige hardware
Overige hardware kan ook stuk gaan, maar dat kan net zogoed gebeuren bij een 3Par, Netapp of EMC. Dan zijn er dus maximaal 15 VMs (lees: RDS servers) down.
Wanneer de SYNC functionaliteit geimplementeerd is of HAST dan kan het zelfs nog beter denk ik.

[CurlyMo]

Op mijn externe backup locatie krijg ik regelmatig deze foutmeldingen:

code:

[231760.224231] WARNING: Pool 'backup' has encountered an uncorrectable I/O failure and has been 
suspended.

en

code:

cannot open 'backup': pool I/O is currently suspended

Het gaat hier om een ARM Hummingboard met 1GB Ram. Iemand ideeën waar het aan kan liggen? Nu is telkens een reboot nodig voordat het geheel weer werkt.

[Q]

Fr0zenFlame schreef op donderdag 10 december 2015 @ 17:00:
Overige hardware
Overige hardware kan ook stuk gaan, maar dat kan net zogoed gebeuren bij een 3Par, Netapp of EMC. Dan zijn er dus maximaal 15 VMs (lees: RDS servers) down.
Wanneer de SYNC functionaliteit geimplementeerd is of HAST dan kan het zelfs nog beter denk ik.

Het ging mij eigenlijk alleen om de machine als geheel.
Zijn de machines nu elkaars failover of werkt dat anders?

Als je RDS = remote desktop services? draait dan wil je toch wel weer snel in business zijn lijkt me, hoe realiseer je dat?

Een traditioneel SAN doet ofwel sync writes dus verlies je geen byte. Of je doet periodiek snapshots met Veeam of VMware native of de Xen equivalent. Dan verlies je wel wat state maar het hangt een beetje van je VMs af of dat erg is.

Doe je iets met zfs snapshots en send/receive?

CurlyMo schreef op donderdag 10 december 2015 @ 17:20:
Op mijn externe backup locatie krijg ik regelmatig deze foutmeldingen:

code:

[231760.224231] WARNING: Pool 'backup' has encountered an uncorrectable I/O failure and has been 
suspended.

en

code:

cannot open 'backup': pool I/O is currently suspended

Het gaat hier om een ARM Hummingboard met 1GB Ram. Iemand ideeën waar het aan kan liggen? Nu is telkens een reboot nodig voordat het geheel weer werkt.

Ik kan alleen wat open deuren intrappen:

- ARM specifiek issue?
- Test hardware / Memtest?
- Disk I/O errors in logs?

[ Voor 30% gewijzigd door Q op 10-12-2015 18:14 ]

[CurlyMo]

De schijf is zeker niks mis mee.
Memtest is niet makkelijk op dat platform Zou het ook door te weinig memory kunnen komen? Ik heb wel compressie en dedup aan staan namelijk.

[FireDrunk]

Het klinkt als een ZFS interne melding (vanwege het woordje "pool").
Misschien eens in de source code kijken waar die "state" vandaan komt?

Kan bijvoorbeeld dat er teveel processen zijn? (van die z_txg processen).

[ Voor 21% gewijzigd door FireDrunk op 10-12-2015 20:45 ]

[CurlyMo]

Er zijn inderdaad wel veel zfs processen actief.

[FireDrunk]

https://github.com/zfsonl...libzfs/libzfs_util.c#L417

Het komt hier vandaan.

[CurlyMo]

De foutmelding lijkt inderdaad weer te geven wat er met EAGAIN bedoeld wordt

[FireDrunk]

Ik zit eens te zoeken, maar kan weinig vinden over waarom de pool suspended zou worden, anders dan dat I/O's (in de vorm van ZIO transacties) gefaald zijn.

Maar dat zou je dan wel weer ergens in terug moeten zien...

[CurlyMo]

Owja, het gaat om een USB schijf. Was ik nog vergeten te vermelden.

[FireDrunk]

https://github.com/zfsonl...9e/module/zfs/zio.c#L1543

code:

void
zio_suspend(spa_t *spa, zio_t *zio)
{
    if (spa_get_failmode(spa) == ZIO_FAILURE_MODE_PANIC)
        fm_panic("Pool '%s' has encountered an uncorrectable I/O "
            "failure and the failure mode property for this pool "
            "is set to panic.", spa_name(spa));

    cmn_err(CE_WARN, "Pool '%s' has encountered an uncorrectable I/O "
        "failure and has been suspended.\n", spa_name(spa));

    zfs_ereport_post(FM_EREPORT_ZFS_IO_FAILURE, spa, NULL, NULL, 0, 0);

    mutex_enter(&spa->spa_suspend_lock);

    if (spa->spa_suspend_zio_root == NULL)
        spa->spa_suspend_zio_root = zio_root(spa, NULL, NULL,
            ZIO_FLAG_CANFAIL | ZIO_FLAG_SPECULATIVE |
            ZIO_FLAG_GODFATHER);

    spa->spa_suspended = B_TRUE;

    if (zio != NULL) {
        ASSERT(!(zio->io_flags & ZIO_FLAG_GODFATHER));
        ASSERT(zio != spa->spa_suspend_zio_root);
        ASSERT(zio->io_child_type == ZIO_CHILD_LOGICAL);
        ASSERT(zio_unique_parent(zio) == NULL);
        ASSERT(zio->io_stage == ZIO_STAGE_DONE);
        zio_add_child(spa->spa_suspend_zio_root, zio);
    }

    mutex_exit(&spa->spa_suspend_lock);
}

De enige reden kan dus zijn als er I/O failures zijn. Geen idee waar failure_mode gezet wordt.

Oh, dat viel wel mee, het is een zpool property:

https://github.com/zfsonl.../zcommon/zpool_prop.c#L60

code:

static zprop_index_t failuremode_table[] = {
        { "wait",   ZIO_FAILURE_MODE_WAIT },
        { "continue",   ZIO_FAILURE_MODE_CONTINUE },
        { "panic",  ZIO_FAILURE_MODE_PANIC },
        { NULL }
    };

[ Voor 12% gewijzigd door FireDrunk op 10-12-2015 21:10 ]

[FireDrunk]

In jou geval zal hij blijkbaar op wait of panic staan.

code:

[thijs@NAS ~]$ sudo zpool get failmode
NAME      PROPERTY  VALUE     SOURCE
VM_TIER1  failmode  wait      default
VM_TIER2  failmode  wait      default
archive   failmode  wait      default
[thijs@NAS ~]

_{Ik moet niet reposten}

[ Voor 71% gewijzigd door FireDrunk op 10-12-2015 21:11 ]

[CurlyMo]

code:

backup  failmode                    wait                            default

De ZFS gerelateerde process list:

code:

root      2065  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_null_iss]
root      2066  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_null_int]
root      2067  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_iss]
root      2068  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_0]
root      2069  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_1]
root      2070  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_2]
root      2071  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_3]
root      2072  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_4]
root      2073  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_5]
root      2074  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_6]
root      2075  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_rd_int_7]
root      2076  0.4  0.0      0     0 ?        S<   21:19   0:00 [z_wr_iss]
root      2077  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_iss_h]
root      2078  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_0]
root      2079  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_1]
root      2080  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_2]
root      2081  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_3]
root      2082  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_4]
root      2083  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_5]
root      2084  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_6]
root      2085  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_7]
root      2086  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_wr_int_h]
root      2087  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_0]
root      2088  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_1]
root      2089  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_2]
root      2090  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_3]
root      2091  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_4]
root      2092  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_5]
root      2093  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_6]
root      2094  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_iss_7]
root      2095  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_fr_int]
root      2096  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_cl_iss]
root      2097  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_cl_int]
root      2098  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_ioctl_iss]
root      2099  0.0  0.0      0     0 ?        S<   21:19   0:00 [z_ioctl_int]
root      2100  0.0  0.0      0     0 ?        S<   21:19   0:00 [metaslab_group_]
root      2104  0.0  0.0      0     0 ?        S    21:19   0:00 [z_iput]
root      2114  0.0  0.0      0     0 ?        S    21:19   0:00 [txg_quiesce]
root      2115  0.0  0.0      0     0 ?        S    21:19   0:00 [txg_sync]
root      2284  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2286  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2288  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2290  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2292  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2294  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2296  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2298  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2300  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2302  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2304  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2306  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2308  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2312  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2314  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2316  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2318  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2320  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2322  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2324  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2326  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2328  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2330  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2332  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2334  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2336  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2338  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2340  0.0  0.0      0     0 ?        S    21:20   0:00 [zil_clean]
root      2341  0.0  0.0      0     0 ?        S<   21:20   0:00 [z_fr_iss_4]
root      2343  0.0  0.0      0     0 ?        S<   21:20   0:00 [z_fr_iss_1]
root      2344  0.0  0.0      0     0 ?        S<   21:20   0:00 [z_fr_iss_1]
root      2345  0.0  0.0      0     0 ?        S<   21:20   0:00 [z_fr_iss_1]

[FireDrunk]

Heb je veel snapshots?

[Bigs]

De het enige moment waarop die zio_suspend functie wordt aangeroepen is als het wegschrijven van een of meer van de uberblocks wegschrijft (zie je als je vanuit de code van FireDrunk wat verder terug zoekt). Het lijkt mij echt een I/O / geheugen probleem als ik de code zo kijk. Helaas is de exacte foutcode niet te achterhalen.

[ Voor 10% gewijzigd door Bigs op 10-12-2015 21:34 ]

[CurlyMo]

Ik heb de failmode even op continue gezet zodat een tijdelijk instabiliteit niet direct tot een suspended pool zorgt. Ik werk tenslotte niet met een hardware raid controllen

FireDrunk schreef op donderdag 10 december 2015 @ 21:25:
Heb je veel snapshots?

Wil je het echt weten?

code:

# zfs list -t snapshot -r backup | wc -l
9304

[FireDrunk]

Dat is denk ik het probleem. Ik las dat er (onder BSD in ieder geval) voor elk snapshot een process opgestart wordt...

Ik kan me voorstelln dat een Hummingbird daar wat last van heeft...

Doe voor de grap eens:

ps -eLf | wc -l

Vergelijkingsmateriaal:

[root@NAS ~]# ps -eLf | wc -l
1430

[ Voor 30% gewijzigd door FireDrunk op 10-12-2015 21:37 ]

[CurlyMo]

Dus het geheugen loopt te vol ondanks mijn geheugen tweaks?:

code:

options zfs zfs_arc_max=167772160 zfs_vdev_cache_size=2621440 zfs_prefetch_disable=1 zfs_txg_timeout=1 zvol_threads=1

[FireDrunk]

Je kan ook nog min en max pending op 1 zetten. Dan leven je txg's wat korter en sterven de processen misschien sneller af.

[CurlyMo]

Welke zijn dat?

[Cruise Control]

CurlyMo schreef op donderdag 10 december 2015 @ 19:13:
Ik heb wel compressie en dedup aan staan namelijk.

CurlyMo schreef op donderdag 10 december 2015 @ 21:37:
Dus het geheugen loopt te vol ondanks mijn geheugen tweaks?:

Dedup? Met 1GB RAM? Dan lijkt geheugengebrek me voor de hand liggen, ja.

[ Voor 25% gewijzigd door Cruise Control op 10-12-2015 21:42 ]

[CurlyMo]

Mijn aanname was dat wanneer je het geheugengebrek limiteert alle geheugenintensieve taken tergend langzaam worden, maar dat is voor mijn geen probleem aangezien het om een offsite backup gaat.

[FireDrunk]

Monitor je het geheugen ergens mee? Misschien voor de grap eens een klein tooltje voor installeren?

[ Voor 47% gewijzigd door FireDrunk op 10-12-2015 21:46 ]

[CurlyMo]

Nope, dat ding staat gewoon stilletjes zijn werk te doen.

[FireDrunk]

[CurlyMo]

1. Memory logging staat aan
2. Dedup staat uit.
3. failmode staat op continue.

We gaan zien of het werkt.

[idef1x]

Kan me niet voorstellen dat het klopt, maar ik krijg met het commando:

code:

zfs send -R tank@20151211.8pm | ssh -C <remote server> "zfs receive -F tank"

slechts een 150Mbps data overdracht over een 1Gb link, terwijk als ik gewoon de bestanden met rsync doe ik rond de 650Mbps uitkom? Een rsync van een nfs share komt rond de 750Mbps uit.
De load op beide machines ten tijde van zfs send/receive versus rsync zijn ongeveer gelijk en kan het makkelijk aan. Iemand enig idee of dit kan kloppen?

[Ultraman]

Hoe is de snelheid zonder die -C vlag? Want dat is gzip compressie, welke vziw single threaded wordt uitgevoerd.

[idef1x]

Zonder -C scheelt dat wel enorm inderdaad.
Ik kom nu rond de 535Mbps uit...Nog wel steeds een stuk langzamer dan rsync dus.

[FireDrunk]

Je kan er nog een memory buffer tussen zetten. Even googlen hoe dat moet. Dat scheelt ook aanzienlijk.

http://www.mceith.com/blog/?p=183

[ Voor 17% gewijzigd door FireDrunk op 12-12-2015 10:31 ]

[narotic]

idef1x schreef op zaterdag 12 december 2015 @ 09:28:
Zonder -C scheelt dat wel enorm inderdaad.
Ik kom nu rond de 535Mbps uit...Nog wel steeds een stuk langzamer dan rsync dus.

Om goede throughput te halen met SSH (en rsync) moet je over het algemeen:

• compressie uitschakelen
• de lichtste cipher gebruiken
• een memory buffer ertussen plaatsen

Zelf gebruik ik bijvoorbeeld

code:

ssh -c arcfour -o Compression=no

en daarmee haal ik zelfs zonder memory buffer tegen de 800mbit/s met een relatief langzame server. Of arcfour als cipher toegestaan is hangt af van zowel de client als de server, maar dit kan als ik me niet vergis in je ssh config aangepast worden. Voor de beste performance is er ook een cipher none, maar die wordt in mijn ervaring vaak niet meer in ssh gecompileerd in de gangbare distributies.

[idef1x]

FireDrunk schreef op zaterdag 12 december 2015 @ 10:31:
Je kan er nog een memory buffer tussen zetten. Even googlen hoe dat moet. Dat scheelt ook aanzienlijk.

http://www.mceith.com/blog/?p=183

Oef! Dat scheelt een stuk zeg! Nu is ie zelfs een 100Mbps sneller dan rsync met nfs!
Dank voor de tip!

@narotic: dank voor de tips, die ga ik dan wel in mijn rsync scriptjes toepassen
op ubuntu 14.04 is arcfour128 nog ondersteund

[ Voor 5% gewijzigd door idef1x op 12-12-2015 11:45 . Reden: arcfour support op ubuntu toegevoegd ]

[F-Tim]

Inmiddels zijn alle onderdelen voor de NAS besteld, dus zodra alles binnen is is het een kwestie van in elkaar bouwen en gaan genieten van een prima DIY pakketje!

Ik ben voornemens om ZFSGuru te draaien, starten met versie 0.3.1.... so far so good! De eerste tests heb k al gedraaid met een VM om te kijken hoe ik een ZFS met memory disks kon initialiseren, dus de eerste installatie van de pool gaat goed. Ook al een resilver geprobeerd, dus k weet ongeveer wat ik kan verwachten.

In de VM heb ik 1 grote pool genaamd /Tank aangemaakt met alle disks in RAID-Z2, aangezien dit ook de situatie gaat zijn zoals hoe het straks in de praktijk gebruikt wordt, al dan niet met een andere naam

Waar ik nog een beetje tegenaan loop is het hele Root-on-ZFS deel.... Door CiPHER werd afgeraden om het op een USB stick te draaien, en ook op diverse sites lees ik dat door storage degradatie het niet slim is om te doen.

Wat is daar nou de slimste oplossing voor? Immers, het kan zijn dat ZFS Guru helemaal opnieuw geinstalleerd dient te worden mocht een versie niet meer backwards compatible zijn straks; of dat ik ooit een keer van distro wil wisselen.

Een installatie op de VM leerde me iig dat de installatie in /Tank/zfsguru wordt uitgevoerd. Maar na een crashende install wilde ik via de Command Line (met Root privileges) deze map verwijderen. Helaas kan ik deze map niet verwijderen (met het commando rm -R /Tank/zfsguru) omdat ik de melding krijg device busy. Terwijl op dat moment van de LiveCD is geboot.

Ik begreep (van CiPHER) dat het slim is om een partitie aan te maken van xGB en daarop te installeren. Ik gok op 4GB, een ZFSGuru installatie kost tussen de 300MB en 900MB, dus dan zou ik met 4GB voldoende plek hebben ook in de toekomst als een en ander groeit of een andere distro meer ruimte heeft?.Of is het aan te raden om een grotere ruimte te reserveren? Alleen hoe kan ik dit doen? Moet dit vóór of ná de installatie van de vdev? Of kan ik ook op de vdev een bootable installatie draaien?

Maar ik ben nog een beetje zoekende naar het hele hoe en wat van een goede installatie, vooral ook omdat ik geen echte tutorial kan vinden hiervan, en voornamelijk dignen als jails en ZVOL's tegenkom, en langzaam weer iets met "bomen en bos" ga merken

[Verwijderd]

Je kunt ZFSguru gewoon op de pool installeren; je kunt meerdere installaties doen. Als je opnieuw wilt installeren kun je gewoon een 2e installatie doen. Bij de laatste installatiestap moet je de naam van de installatie aanpassen als deze al bestaat - dit wordt met rode tekst aangegeven.

Indien je van distro wilt wisselen, kan dit prima. Je kunt FreeNAS een USB stick gebruiken en de pool importeren. Dat ZFSguru op die pool is geïnstalleerd, maakt verder niets uit. Het is gewoon een pol voor FreeNAS.

Een aparte pool maken door met partities te werken kan ook, er zijn soms redenen dat dit wenselijk is. Bijvoorbeeld als je Root-on-ZFS wilt maar wel spindown wilt gebruiken. Heb je bijvoorbeeld 20 schijven, dan kun je beter partitioneren zodat ZFSguru op een mirror pool draait op 2 of 3 schijven, zodat de overige 17 in spindown kunnen. Ook kun je alle features op je data pool activeren terwijl ZFSguru gewoon bootable blijft. Ook kun je multi-vdev pools gebruiken die normaliter niet bootable zijn; je boot dan van een aparte pool zodat je van al die beperkingen geen last hebt. Bedenk wel dat je door de partities een beetje ruimte op elke disk kwijt bent. 4GB is opzich prima maar bedenk wel dat service addons meer in beslag kunnen nemen. Je kunt achteraf de grootte van de partities niet echt aanpassen omdat je dan je data pool moet verwijderen. De keuze is dus semi-permanent.

Je probeerde ZFSguru te verwijderen door een 'rm' commando te gebruiken. Dat werkt niet, omdat het een ZFS filesystem betreft en geen gewone map. Een 'zfs destroy -r tank/zfsguru' werkt wel. Maar je kunt makkelijker op de System->Booting tab oude installaties verwijderen zodra je de pool hebt geïmporteerd op de Pools pagina.

[F-Tim]

Verwijderd schreef op maandag 14 december 2015 @ 09:45:
Je kunt ZFSguru gewoon op de pool installeren; je kunt meerdere installaties doen. Als je opnieuw wilt installeren kun je gewoon een 2e installatie doen. Bij de laatste installatiestap moet je de naam van de installatie aanpassen als deze al bestaat - dit wordt met rode tekst aangegeven.

Klopt, vandaar dat k de oude map ook wilde verwijderen. Tijdens de installatie heeft hij zich ergens in verslikt waardoor de installatie niet voltooide (heeft 45m staan draaien).

...
Een aparte pool maken door met partities te werken kan ook, er zijn soms redenen dat dit wenselijk is. Bijvoorbeeld als je Root-on-ZFS wilt maar wel spindown wilt gebruiken. Heb je bijvoorbeeld 20 schijven, dan kun je beter partitioneren zodat ZFSguru op een mirror pool draait op 2 of 3 schijven, zodat de overige 17 in spindown kunnen. Ook kun je alle features op je data pool activeren terwijl ZFSguru gewoon bootable blijft. Ook kun je multi-vdev pools gebruiken die normaliter niet bootable zijn; je boot dan van een aparte pool zodat je van al die beperkingen geen last hebt. Bedenk wel dat je door de partities een beetje ruimte op elke disk kwijt bent. 4GB is opzich prima maar bedenk wel dat service addons meer in beslag kunnen nemen. Je kunt achteraf de grootte van de partities niet echt aanpassen omdat je dan je data pool moet verwijderen. De keuze is dus semi-permanent.

Oke, dus dan toch ietsjes meer dan 4GB, 32GB zou wel voldoende moeten zijn toch? En, hoe kan ik dan de partitie aanmaken? Met mijn windows kennis moet dit vóórdat het OS erop komt, dus k gok dat dat bij ZFSGuru ook zo is? Kan dit via de UI van dia het "Create ZFS pool" scherm? Dus dan éérst een 32GB mirror op 2 devices aanmaken, en dan een Z2 op de resterende ruimte op alle devices aanmaken? Of moet dit persé commandline?

...
Je probeerde ZFSguru te verwijderen door een 'rm' commando te gebruiken. Dat werkt niet, omdat het een ZFS filesystem betreft en geen gewone map. Een 'zfs destroy -r tank/zfsguru' werkt wel. Maar je kunt makkelijker op de System->Booting tab oude installaties verwijderen zodra je de pool hebt geïmporteerd op de Pools pagina.

Helaas, de installatie crashte... dus hij staat niet op de booting tab En het commando zfs destroy werkt dus ook niet, want dan vindt hij daar niets geldigs. Gelukkig is het een trial run op een VM

[Verwijderd]

Als de 'zfsguru' filesystem niet bestaat, heb je ook geen installatie. Je kunt gewoon installeren op de pool. Desnoods de naam wijzigen dat hoort altijd te werken. Een oude installatie kan niets in de weg zitten tenzij je dezelfde naam hergebruikt. Die naam kies je bij de laatste installatiestap (stap 3).

Formatteren doe je op de Disks pagina. Klik op een disk en je ziet een gekleurde balk met partities. Daar kun je mee spelen door meerdere partities te maken. Eventueel huidige partitie verwijderen en nieuwe aanmaken met de juiste grootte - gebruik de slider. Schakel javascript in indien je NoScript gebruikt.

[F-Tim]

Verwijderd schreef op maandag 14 december 2015 @ 10:07:
Als de 'zfsguru' filesystem niet bestaat, heb je ook geen installatie. Je kunt gewoon installeren op de pool. Desnoods de naam wijzigen dat hoort altijd te werken. Een oude installatie kan niets in de weg zitten tenzij je dezelfde naam hergebruikt. Die naam kies je bij de laatste installatiestap (stap 3).

Formatteren doe je op de Disks pagina. Klik op een disk en je ziet een gekleurde balk met partities. Daar kun je mee spelen door meerdere partities te maken. Eventueel huidige partitie verwijderen en nieuwe aanmaken met de juiste grootte - gebruik de slider. Schakel javascript in indien je NoScript gebruikt.

Thanks voor die reactie! Daar heb ik helemaal overheen gekeken!

Heb even het volgende (achteraf zéér leerzame) scenario doorlopen in een VM

• Ik heb 4x 8GB disk aangemaakt (ada0 t/m ada3) en 2x 6GB (ada4 en ada5)
• Op ada0 en ada1 heb ik een 2GB partitie aangemaakt in mirror waarop ik ZFS middels Root-On-ZFS wil installeren
• ada0 en ada1 zijn ook als enige GPT + Boot partition, de rest is enkel GPT
• Op alle 6 disks heb ik een 6GB partitie aangemaakt in Z2
• Op de mirror partitie (van 2GB) heb ik Root-On-ZFS geinstalleerd, liveCD verwijderd en van geboot
• De 6GB disks vervangen door 8GB disks, en dan partities met maximale grootte aangemaakt en geresilvered
• Partities op disks ada3 en ada4 gemaximaliseerd
• Disk ada0 vervangen door een grotere 12GB disk, waarbij de mirror partitie qua grootte gelijk blijft, maar de zfs partitie gemaximaliseerd is
• Disk ada1 vervangen zoals ada0

En daaruit heb ik flink wat (nieuwe) leerpunten gehaald:

• De mirror partities moeten als eerste aangemaakt zijn op de disks, anders wil ie van tank booten
• Gemixte groottes, respectievelijk 6/6/8/8/6/6, geeft een foutmelding bij het aanmaken van de pool
• Na install van de Root-on-ZFS moest ik de configuratie (users/shares/2de pool) even opnieuw doen
• Van een bestaande pool kan ik wél de partitie grootte naar de max van een disk vergroten (pool selecteren > disk offline > destroy partitie > create partitie > disk online)
• een "share" filesysteem mag altijd verwijderd worden, óók van de boot partitie
• resilver gaat per pool, niet per disk
• Auto expand moet eerst aangezet worden met zpool set autoexpand=on tank
• Na een auto expand moet de pool wijzigen alvorens de nieuwe grootte gezien wordt (disk offline > disk online bv)

Aangezien ik al eerder wist hoe ik een pool moest aanmaken met een memory disk, heb ik nu in ieder geval een werkend scenario voor de bouw van de NAS. Ik heb wel het gevoel dat een en ander nog omslachtig gaat in mijn werkwijze... maar vooruit, het lijkt erop dat alles inmiddels werkend is in een test-scenario Inclusief de partities én dus support voor disk-spindown!

Edit: ZFSGuru verstuurt geen status mails toch? Ook niet als het geconfigureerd wordt als via deze link? Of interpreteer ik dat nu verkeerd?

Reden dat ik dit vraag is heel simpel, hoe weet ik als een disk crasht? Hangt ZFSGuru zich dan simpelweg op en moet ik een keer rebooten waarna ik de log inkijk? Of merk ik er niks van gedurende dagelijks gebruik en moet ik gewoon regelmatig controleren wat de status van de disks is?

[ Voor 10% gewijzigd door F-Tim op 14-12-2015 15:40 ]

[Verwijderd]

F-Tim schreef op maandag 14 december 2015 @ 15:24:
Gemixte groottes, respectievelijk 6/6/8/8/6/6, geeft een foutmelding bij het aanmaken van de pool

Dit is een feature van ZFS. Je kunt bij het aanmaken van de pool de 'Apply force' checkbox aanvinken en dan kun je pools maken op disks van verschillende grootte of mixed redundancy. Deze -f parameter is gedeeld met Force, wat bestaande pools overschrijft. Zodoende kan ook ZFSguru geen onderscheid maken. Altijd Force gebruiken is onwenselijk omdat dit User Error in de hand werkt. Maar er kan wel extra uitleg bij de checkbox gegeven worden. Dat is nog een punt van verbetering.

Na install van de Root-on-ZFS moest ik de configuratie (users/shares/2de pool) even opnieuw doen

Na elke (her)installatie moet je opnieuw configureren. Je Samba users en shares en services. Alleen zaken die met je ZFS pool te maken hebben, blijven behouden. Dit verandert overigens met de komende versie van ZFSguru die de Migration Manager functionaliteit toevoegt. Hiermee maak je een soort backup van de configuratie die je kunt meenemen naar nieuwe installaties. Upgraden betekent dus een verse installatie maar wel met behoud van de configuratie die je wenst mee te nemen.

Auto expand moet eerst aangezet worden met zpool set autoexpand=on tank

Je kunt ook expanden met 'zpool online -e' - ik weet even niet of ZFSguru dit al via de Web-interface ondersteunt.

Edit: ZFSGuru verstuurt geen status mails toch? Ook niet als het geconfigureerd wordt als via deze link? Of interpreteer ik dat nu verkeerd?

Reden dat ik dit vraag is heel simpel, hoe weet ik als een disk crasht? Hangt ZFSGuru zich dan simpelweg op en moet ik een keer rebooten waarna ik de log inkijk? Of merk ik er niks van gedurende dagelijks gebruik en moet ik gewoon regelmatig controleren wat de status van de disks is?

Status mails is iets wat ZFSguru nog mist; eigenlijk de laatste must-have feature voor een NAS. Dit betekent dat je zelf regelmatig dient te kijken of je pool status nog 'ONLINE' is. Dit doe je op de Pools pagina. Je kunt ook zelf wat knutselen met een script. De link die je geeft doet daar niets aan maar verandert de mail-instellingen van de server zodat je via Gmail kunt mailen. Maar het stuurt geen status mails.

FreeBSD - het onderliggende OS van ZFSguru - heeft al wel ZFS status mails. Heel newbie vriendelijk is het niet, dus een eigen script zou beter zijn.

Het zal nog tot versie 0.6 duren voordat ZFSguru deze feature volautomatisch krijgt, aangezien deze leunt op de Task Manager functionaliteit. Die versie kun je pas in de 2e helft van volgend jaar verwachten.

[secretdk]

Ik zit met onderstaande melding dat pool storage1 gebruik maakt van een non-native block size van 512B. Nu geeft de storage2 pool deze melding niet en deze maakt ook gebruik van een 512B block size.

Los ik dit alleen op door de pool opnieuw aan te maken? Waarom heeft storage1 hier wel last van en storage2 niet? Allemaal WD Reds. Bij voorbaat dank!

code:

pool: storage1
 state: ONLINE
status: One or more devices are configured to use a non-native block size.
        Expect reduced performance.
action: Replace affected devices with devices that support the
        configured block size, or migrate data to a properly configured
        pool.
  scan: scrub repaired 0 in 4h27m with 0 errors on Thu Dec 10 00:46:16 2015
config:

        NAME               STATE     READ WRITE CKSUM
        storage1           ONLINE       0     0     0
          raidz1-0         ONLINE       0     0     0
            gpt/DISK1_2TB  ONLINE       0     0     0  block size: 512B configured, 4096B native
            gpt/DISK2_2TB  ONLINE       0     0     0  block size: 512B configured, 4096B native
            gpt/DISK3_2TB  ONLINE       0     0     0  block size: 512B configured, 4096B native
            gpt/DISK4_2TB  ONLINE       0     0     0  block size: 512B configured, 4096B native
            gpt/DISK5_2TB  ONLINE       0     0     0  block size: 512B configured, 4096B native
        cache
          gpt/cache1       ONLINE       0     0     0

code:

    pool: storage2
 state: ONLINE
  scan: scrub repaired 0 in 5h3m with 0 errors on Thu Dec 10 01:22:06 2015
config:

        NAME               STATE     READ WRITE CKSUM
        storage2           ONLINE       0     0     0
          raidz1-0         ONLINE       0     0     0
            gpt/DISK3_3TB  ONLINE       0     0     0
            gpt/DISK2_3TB  ONLINE       0     0     0
            gpt/DISK4_3TB  ONLINE       0     0     0
            gpt/DISK1_3TB  ONLINE       0     0     0
            gpt/DISK5_3TB  ONLINE       0     0     0
        cache
          gpt/cache2       ONLINE       0     0     0

errors: No known data errors

[FireDrunk]

Pool aangemaakt onder ZFSonLinux of BSD?

[secretdk]

FireDrunk schreef op maandag 14 december 2015 @ 19:29:
Pool aangemaakt onder ZFSonLinux of BSD?

ZFSGuru > FreeBSD

[Verwijderd]

Dit kun je achteraf niet aanpassen nee. Heel erg is het niet want je hebt een optimale configuratie; RAID-Z1 met 5 disks. Dus dat betekent dat bij het schrijven van grote bestanden je aan de 128K blocksize zit en dat houdt in dat je 128 / (5 - 1) = 32KiB per disk doet en dat is een veelvoud van 4KiB. Kortom, lekker zo laten. Alleen voor kleinere I/O groottes zul je een performance hit ervaren, en dan alleen voor writes is dat significant.