Het grote ZFS topic

[grotius]

Deze week ga ik een nieuwe server bouwen. Mijn hardware is geschikt voor esxi.
Op mijn eerste vm wil ik zfs draaien. Welk platform is hier het beste voor geschikt?
Ik twijfel tussen zfsguru (stable versie is wat verouderd, freebsd en openindiana

Mijn oude server draaide op freebsd en zfsguru ligt dan meer voor de hand (de screens zagen er erg gebruikvriendelijk uit). Kortom het gemak van zfsguru spreekt mij aan. Echter zfsguru (stable) draait op freebsd 8 (zfs 15). Daarom kijk ik nu naar openindiana. Is hier eenzelfde gebruikersgemak als zfsguru te realiseren?

[CurlyMo]

Wanneer je naar ZFSGuru kijkt dan is met name de webinterface nog niet stable (al heb ik nog nooit ernstige problemen ondervonden met de beta's), dat zal waarschijnlijk deze maand nog wel gebeuren. FreeBSD 9 is is op zichzelf wel stable en is al ruim een maand of 2 uit dus daar hoef je je niet druk over te maken. Als je nu vooral gebruik maakt van de mogelijkheden om te formateren, pools, filesystems en shares aan te maken dan werkt ZFSguru zo stabiel als je het kan hebben.

[matty___]

deuserzondernaam schreef op woensdag 14 maart 2012 @ 09:07:
Wanneer je naar ZFSGuru kijkt dan is met name de webinterface nog niet stable (al heb ik nog nooit ernstige problemen ondervonden met de beta's), dat zal waarschijnlijk deze maand nog wel gebeuren. FreeBSD 9 is is op zichzelf wel stable en is al ruim een maand of 2 uit dus daar hoef je je niet druk over te maken. Als je nu vooral gebruik maakt van de mogelijkheden om te formateren, pools, filesystems en shares aan te maken dan werkt ZFSguru zo stabiel als je het kan hebben.

leuk zo een gui maar
a. het is dood simple in de shell te doen
b. hoe vaak zit je met je zpool en zfs's te prutsen?

en samba / afpd heb je ook zo gefixt.

[FireDrunk]

ZFSGuru heeft ook het ZFS-on-Root. Ik weet dat FreeBSD9 dat (uiteraard) ook kan, maar de installer kan het nog niet voor zover ik gezien heb.

[grotius]

CurlyMo schreef op woensdag 14 maart 2012 @ 09:07:
Wanneer je naar ZFSGuru kijkt dan is met name de webinterface nog niet stable (al heb ik nog nooit ernstige problemen ondervonden met de beta's), dat zal waarschijnlijk deze maand nog wel gebeuren. FreeBSD 9 is is op zichzelf wel stable en is al ruim een maand of 2 uit dus daar hoef je je niet druk over te maken. Als je nu vooral gebruik maakt van de mogelijkheden om te formateren, pools, filesystems en shares aan te maken dan werkt ZFSguru zo stabiel als je het kan hebben.

Dank bedoel je zfsguru 0.19 of 0.20 beta 5?

Waarschijnlijk zak draai ik dan esxi (5) draaien met daaronder zfsguru

Freebsd 9 en werken vanuit de commandline is ook een optie (heb ik het afgelopen jaar gedaan) alleen vind het gebruikersgemak van een webgui toch wel fijn.

[ Voor 16% gewijzigd door _Dune_ op 26-03-2013 21:10 ]

[matty___]

FireDrunk schreef op woensdag 14 maart 2012 @ 09:43:
ZFSGuru heeft ook het ZFS-on-Root. Ik weet dat FreeBSD9 dat (uiteraard) ook kan, maar de installer kan het nog niet voor zover ik gezien heb.

er is ergens een fb9 install iso waar een zfs-to-root script inzit.

[FireDrunk]

Ah, dat wist ik niet! Goed om te weten!

[matty___]

FireDrunk schreef op woensdag 14 maart 2012 @ 11:43:
Ah, dat wist ik niet! Goed om te weten!

http://mfsbsd.vx.sk/
Example: zfsinstall -d /dev/ad0 -t /cdrom/8.2-RELEASE-amd64.tar.xz -s 4G
This will install a GPT partition table and ZFS on /dev/ad0, including a 4 GB GPT freebsd-swap partiton.

[ Voor 34% gewijzigd door matty___ op 14-03-2012 11:49 ]

[FireDrunk]

Maar, dan staat het nog op 1 disk?

[matty___]

FireDrunk schreef op woensdag 14 maart 2012 @ 11:59:
Maar, dan staat het nog op 1 disk?

"-r raidz|mirror : select raid mode if more than one -d provider

"When using swap and raidz/mirror, the swap partition is created on all drives."

[ Voor 36% gewijzigd door matty___ op 14-03-2012 12:47 ]

[FireDrunk]

Ah, duidelijk!

[Pixeltje]

Ik heb een vraag over mijn nog op te zetten NAS. Het begint erop te lijken dat na lang zeuren bij de webshop, ze eindelijk actie gaan ondernemen op het niet leverbare moederbord, dus ik hoop/verwacht dit weekend te kunnen starten met in elkaar zetten en inrichten.

De bedoeling is om FreeNAS te draaien, dat is allemaal niet zo ingewikkeld, waar ik vragen over heb:
- Er staat in de TS van dit topic dat een Raidz volume het beste bestaat uit 3 of 5 schijven, een Raidz2 volume uit 4, 6 etc. schijven. Ik heb 4 schijven, maar wil eigenlijk geen 2 schijven kwijt zijn aan parity (van de 8TB blijft er maar 4 over dan). Hoe problematisch is het om met 4 schijven toch een raidz pool te maken? Het gaat om 4 2TB schijven van seagate, geen 4K sectors.

Andere vraag; ik wil met de NAS het volgende bereiken;
- Time machine backup van een Apple
- Priveopslag voor ongeveer 5 gebruikers
- Muziek streamen met FireFly media server
- Openbare opslag voor iedereen die op mijn netwerk kan
(en nog wat andere dingen, maar die zijn nu nog niet actueel)

Hoe kan ik het beste het zfs volume indelen? Ik kan in freenas een volume maken (van die vier schijven), en dat vervolgens indelen in "datasets". Is het de bedoeling dat ik dat zo inricht?

Niveau 0 is het volume, 1 de dataset, 2 en hoger mappenstructuur
0) Volume
1) Dataset voor Home shares gebruikers (hierin dus ook een user voor firefly)
2) Mappen per gebruiker
3) Eigen invulling gebruiker
1) Dataset voor Time machine
1) Dataset voor openbare storage
2) mappenstructuur

Of begrijp ik nu iets niet?

Alvast bedankt voor het meedenken:)

[FireDrunk]

Hoe problematisch is het om met 4 schijven toch een raidz pool te maken? Het gaat om 4 2TB schijven van seagate, geen 4K sectors.

2 Pagina's terug heb ik dat al gezegd, scheelt een beetje in performance. Meer niet.

Is het de bedoeling dat ik dat zo inricht?

Je kan een Zpool maken, een vdev, en nog weer losse shares op je vdev.
Hoe je dat wil is heel erg afhankelijk van je complete situatie, en is voor ons niet echt zinnig om voor jou te verzinnen, daar ben je prima zelf capabel voor.
Wat je zo neer zet klinkt al prima. Persoonlijk heb ik gewoon 1 share die Data heet waar alles op staat (inc VMWare data store, naast de TV series... Dat maakt geen fluit uit.

[Pixeltje]

FireDrunk schreef op woensdag 14 maart 2012 @ 13:36:
[...]


2 Pagina's terug heb ik dat al gezegd, scheelt een beetje in performance. Meer niet.

Je hebt gelijk, ik heb er overheen gelezen toen ik er net naar op zoek was

[...]

Je kan een Zpool maken, een vdev, en nog weer losse shares op je vdev.
Hoe je dat wil is heel erg afhankelijk van je complete situatie, en is voor ons niet echt zinnig om voor jou te verzinnen, daar ben je prima zelf capabel voor.
Wat je zo neer zet klinkt al prima. Persoonlijk heb ik gewoon 1 share die Data heet waar alles op staat (inc VMWare data store, naast de TV series... Dat maakt geen fluit uit.

Fair enough, ik dacht dat met FreeNAS het sharen niet per map te regelen is (niet uit de GUI in ieder geval), dus vandaar dat ik bovenstaande bedacht had.

[Sleepie]

Ik heb al eens gespeeld met een SSD-tje als L2ARC device.
Toen bleek echter dat voor het huidige gebruik van mijn NAS (voornamelijk opslag voor films en series) dit weinig tot geen verschil maakte, waarschijnlijk omdat het allemaal 'grote' files betreft die slechts eenmalig aangesproken worden.

Nu wil ik echter mijn Hyper-V server gaan vervangen door een ESX machine, waarbij ik de VMs op mijn NAS (NFS share) wil gaan opslaan. Zou het in dat geval nog nuttig zijn om te investeren in SSDs voor L2ARC/ZIL?

Volgens mij zijn Intel 320s nog steeds de beste keuze hiervoor toch (supercap)?
Mijn idee zou dan zijn om 2 x 40GB in 3 partities in te delen:
- 2 x 8GB mirrored voor root-on-zfs install (geen idee eigenlijk hoe groot deze partitie zou moeten zijn?)
- 2 x 4GB mirrored voor ZIL
- 2 x 20GB in stripe voor L2ARC

Nog iemand opmerkingen/aanmerkingen over dit idee? Dus ook of ZIL/L2ARC uberhaupt nuttig is.
(ZFS bak heeft 10 disks in een RAIDZ2 met 16GB RAM, wordt waarschijnlijk nog wel eens uitgebreid naar 20 disks/32GB).

[Femme]

Of een logdevice nuttig is hangt af van de vraag of jouw systeem veel synchrone schrijfacties krijgt te verduren. Als dit niet het geval is heb je er niets aan.

Als je meerdere cachedevices (of partities) toevoegt aan een pool worden ze automatisch gestriped. Het effect is in de praktijk echter wel zeer gering. Ik kon alleen op random i/o met hoge queue-depths in IOMeter een verschil meten tussen één, twee en vier cachedevices.

[Sleepie]

Ik meende gelezen te hebben dat NFS (en iSCSI ook trouwens) juist synchrone schrijf-acties gebruikt, vandaar ook mijn vraag.

Ik kan me zo voorstellen dan een NFS geexporteerde share waar een stuk of 4-5 VMs op draaien wel baat zou hebben bij een ZIL device en (in mindere mate) een L2ARC device.

Verder is een ZIL groter dan 4GB volgens mij sowieso vrij zinloos, met 8GB heb je genoeg voor het OS (zfsguru) en de kleinste Intel320 SSD is volgens mij 40GB. Vandaar dat ik nog 20GB per disk dan als L2ARC zou inzetten, anders blijft het helemaal ongebruikt en da's ook zonde.
(Ik kan me nog herineren eerder uit dit topic dat je zo'n Intel SSD voor een deel ongebruikt wil laten, vandaar dat ik 32 van de 40GB gebruik in mijn voorbeeld).

[iRReeL]

Dadona schreef op maandag 20 februari 2012 @ 15:30:
Google eens op wdidle3, komt door de headpark van WD

thanks! Vond het wat lastig maar nu toch maar gedaan omdat ik opeens ook een warning kreeg. Opeens springt dezelfde disk van 15.951 naar 314.740

23-Feb ada5 Healthy 25°C • 77°F 56 15951 0 0 active • 0 passive 15 days
8-Mrt ada5 Warning 19°C • 66°F 2994 314740 0 0 active • 0 passive 1.2 years

Die SMART waardes moet ik dan ook maar met een korreltje zout nemen? Dat van die 15 dagen kon sowieso al niet maar heeft toch weken dezelfde waardes gegeven. Het begon blijkbaar in Januari met 12/21 uur.

iRReeL schreef op vrijdag 20 januari 2012 @ 12:12:
Volgens SMART disks met 1 bad sectors en 1 disk met 2 bad sectors. 2 disks staat bij dat ze 12/21uur oud zijn, dat kan niet.

[FireDrunk]

Sleepie schreef op woensdag 14 maart 2012 @ 15:49:
Ik meende gelezen te hebben dat NFS (en iSCSI ook trouwens) juist synchrone schrijf-acties gebruikt, vandaar ook mijn vraag.

Ik kan me zo voorstellen dan een NFS geexporteerde share waar een stuk of 4-5 VMs op draaien wel baat zou hebben bij een ZIL device en (in mindere mate) een L2ARC device.

Verder is een ZIL groter dan 4GB volgens mij sowieso vrij zinloos, met 8GB heb je genoeg voor het OS (zfsguru) en de kleinste Intel320 SSD is volgens mij 40GB. Vandaar dat ik nog 20GB per disk dan als L2ARC zou inzetten, anders blijft het helemaal ongebruikt en da's ook zonde.
(Ik kan me nog herineren eerder uit dit topic dat je zo'n Intel SSD voor een deel ongebruikt wil laten, vandaar dat ik 32 van de 40GB gebruik in mijn voorbeeld).

Ik wil maak vooral gebruik van SMB en NFS, maar dat is voor filesharing over netwerk, dus dat is niet echt belangrijk. Wel wil ik graag dat dingen als SabNZBd een beetje vlot werken. Maar of die dus baat hebben bij een ZIL of L2ARC weet ik niet. Misschien koppel ik de VM die Sab gaat doen wel los van mijn ZFS VM, en dan zou het hele verhaal over NFS gaan.

Ik heb ook in mijn hoofd om een flink iSCSI volume aan mijn desktop te geven om wat games op te zetten aangezien mijn SSD's niet echt groot zijn. Dat zal wel wat random IO leveren en dus misschien wel wat baat hebben bij een grote L2ARC.

[CurlyMo]

Als je niet oppast met de load cycles, dan is je schijf binnen no time kapot. Ik had hetzelfde met een WD usb schijf die binnen een maand naar de 100.000 opliep. Jammer genoeg werd wdidle3 niet ondersteund dus heb ik een vervelende oplossing moeten toepassen. Nu schrijft een scriptje elke 3 seconden een bestand weg op de harde schijf waarna die bij de volgende schrijf actie weer verwijderd wordt en opnieuw aangemaakt. Dit zorgt voor genoeg maar minimale actie op de harde schijf wat er voor zorgt dat de koppen niet meer geparkeerd worden. De load cycles voor deze schijf zijn nu al een maand stabiel. Het viel mij op dat het verschil tussen FreeBSD 8 en 9 ook groot was. Voorheen was een activiteit van om de 5 seconden voldoende, na een update naar versie 9 moest dit om de 3 seconden.

Ik zou dus je SMART waarden vooral NIET als korrel zout nemen want anders zijn binnen de kortste keren je schijven kapot.

[matty___]

FireDrunk schreef op woensdag 14 maart 2012 @ 16:00:
[...]


Ik wil maak vooral gebruik van SMB en NFS, maar dat is voor filesharing over netwerk, dus dat is niet echt belangrijk. Wel wil ik graag dat dingen als SabNZBd een beetje vlot werken. Maar of die dus baat hebben bij een ZIL of L2ARC weet ik niet. Misschien koppel ik de VM die Sab gaat doen wel los van mijn ZFS VM, en dan zou het hele verhaal over NFS gaan.

Ik heb ook in mijn hoofd om een flink iSCSI volume aan mijn desktop te geven om wat games op te zetten aangezien mijn SSD's niet echt groot zijn. Dat zal wel wat random IO leveren en dus misschien wel wat baat hebben bij een grote L2ARC.

wat is het nut om alles in een losse vm te flikkeren?
zfs, sabnzb en iscsi target kun je toch op dezelfde machine draaien des noods in jails

[iRReeL]

CurlyMo schreef op woensdag 14 maart 2012 @ 16:00:
Als je niet oppast met de load cycles, dan is je schijf binnen no time kapot. Ik had hetzelfde met een WD usb schijf die binnen een maand naar de 100.000 opliep.
Ik zou dus je SMART waarden vooral NIET als korrel zout nemen want anders zijn binnen de kortste keren je schijven kapot.

Ja dat klopt. Maar in mijn geval kreeg ik dus gewoon totaal verkeerde waardes dus ik dacht dat ik nog iets meer tijd had, ik zag er tegenop op de disks te moeten loskoppelen etc (neemt niet weg dat ik dit zsm had moeten doen).

Misschien moet ik de headparking weer inschakelen zodat deze disk iig nog binnen de garantie dood gaat...

Trouwens bij Napp-it had ik dit wellicht nooit opgemerkt, compliment voor ZFSguru

[FireDrunk]

matty___ schreef op woensdag 14 maart 2012 @ 16:13:
[...]

wat is het nut om alles in een losse vm te flikkeren?
zfs, sabnzb en iscsi target kun je toch op dezelfde machine draaien des noods in jails

Klopt, maar ik draai nog andere VM's (waaronder een paar voor een LAN party die ik altijd mee-organiseer) dus het is ook een hypervisor. Ik ben een beetje tegen het principe om van je hypervisor bijvoorbeeld tegelijkertijd ook je fileserver te maken. (Hoewel het prima zou kunnen met bijvoorbeeld CentOS / Xen.)

Nadeel is dan weer dat Xen (nog) niet 100% draait op FreeBSD. Vandaar dat ik of ESXi of Xen wil draaien met een ZFSguru VM.

[Oid]

ik heb van de freenas nog snapshots die ik niet kan verwijderen:

Failure: execution failed for command: /sbin/zfs destroy tank/backup@auto-20111231_1018-2w

cannot open 'tank/backup@auto-20111231_1018-2w': dataset does not exist

stuk of 30, weet iemand hoe ik dit weg krijg?

[ Voor 21% gewijzigd door Oid op 15-03-2012 08:07 ]

[matty___]

Oid schreef op donderdag 15 maart 2012 @ 08:06:
ik heb van de freenas nog snapshots die ik niet kan verwijderen:

Failure: execution failed for command: /sbin/zfs destroy tank/backup@auto-20111231_1018-2w

cannot open 'tank/backup@auto-20111231_1018-2w': dataset does not exist

stuk of 30, weet iemand hoe ik dit weg krijg?

met de hand?

zfs list -t all tank

desnoods met -r

[Ultraman]

Oid schreef op donderdag 15 maart 2012 @ 08:06:
ik heb van de freenas nog snapshots die ik niet kan verwijderen:

Failure: execution failed for command: /sbin/zfs destroy tank/backup@auto-20111231_1018-2w

cannot open 'tank/backup@auto-20111231_1018-2w': dataset does not exist

stuk of 30, weet iemand hoe ik dit weg krijg?

Als hij niet bestaat, kun je hem ook niet verwijderen.

Kijk eens welke snapshots er bestaan binnen die pool.
zfs list -t snapshot

[matty___]

waar ik me nog steeds aan stoor is dat er maar 1 destroy command is.

zfs destroy bla/zfs1@20120202
of
zfs destry bla/zfs1 is toch een behoorlijk verschil.

zou graag iets van een zfs snapshotdestroy oid zien.

[CurlyMo]

Oid schreef op donderdag 15 maart 2012 @ 08:06:
ik heb van de freenas nog snapshots die ik niet kan verwijderen:

Failure: execution failed for command: /sbin/zfs destroy tank/backup@auto-20111231_1018-2w

cannot open 'tank/backup@auto-20111231_1018-2w': dataset does not exist

stuk of 30, weet iemand hoe ik dit weg krijg?

ZFSGuru heeft in de webgui een bug zitten waardoor hij allerlei karakters vervangt door underscores. Kijk dus even goed in de lijst van ZFSGuru (die overigens wel de juiste namen laat zien) hoe de snapshot heet en verwijder hem dan inderdaad handmatig.

[Ultraman]

matty___ schreef op donderdag 15 maart 2012 @ 10:31:
waar ik me nog steeds aan stoor is dat er maar 1 destroy command is.

zfs destroy bla/zfs1@20120202
of
zfs destry bla/zfs1 is toch een behoorlijk verschil.

zou graag iets van een zfs snapshotdestroy oid zien.

Waarom? Een snapshot is ook gewoon een filesystem, en die ga je slopen.

Bovendien, als bla/zfs1@20120202 bestaat hoef je niet bang te zijn dat je met een tikfout het originele filesystem om zeep brengt. Probeer maar eens:
1. Maak een zfs filesystem, bijvoorbeerd zfs create tank/zandbak
1b. Pleur er voor mij part wat files op om het spannender te maken
2. Maak een snapshot van tank/zandbak: [mono]zfs snapshot tank/zandbak@vers_zand
3. Probeer nu maar eens filesystem tank/zandbak te slopen met destroy.
Daar zal hij niet aan beginnen omdat tank/zandbak nog kinderen (onderliggende filesystems) heeft.
Onderliggende filesystems en snapshots gaan pas zonder gemor ook mee de prullenmand in zodra jij een -r mee geeft. Heb je echter nog indirecte filesystems onder het filesystem liggen die je wilt gaan slopen, zoals clones, dan weigert zelfs -r volgens mij en moet je -R gebruiken.
Maar bij -r wil je dus al oppassen, nee beter: bij destroy wil je al gewoon oppassen

Voorbeeld op mijn machine ziet er als volgt uit:
(zpool tank heeft mountpoint none, tank/home zit op /home, dus vandaar dat ik het daar even in doe)

code:

draak# zfs create tank/home/zandbak
draak# cp disk_temps.sh /home/zandbak/
draak# ls /home/zandbak/
disk_temps.sh
draak# zfs snapshot tank/home/zandbak@vers_zand
draak# zfs list -r -t filesystem,snapshot tank/home/zandbak
NAME                          USED  AVAIL  REFER  MOUNTPOINT
tank/home/zandbak             148K  1.75T   148K  /home/zandbak
tank/home/zandbak@vers_zand      0      -   148K  -
draak# zfs destroy tank/home/zandbak
cannot destroy 'tank/home/zandbak': filesystem has children
use '-r' to destroy the following datasets:
tank/home/zandbak@vers_zand
draak# zfs destroy -r tank/home/zandbak
draak#

Er zit dus wel een safety in voor als jij toch even een oops hebt.
Tenzij je dus -r gebruikt, maar daarom wil je daar dus mee oppassen.
Als je snapshots nemen, en slopen, automatiseert zul je hem bovendien zelden nodig hebben.

[ Voor 4% gewijzigd door Ultraman op 15-03-2012 11:55 ]

[raymonvdm]

Door een fuckupje ben ik bezig om mijn primaire ZFS machine opnieuw op te bouwen maar ik krijg ZFS Send / Receive niet voor elkaar

Ik heb als primaire machine een ESXi VM met FreeNAS 8.0.4 met 6 x 2TB (RDM) en als secondair een XEN VM met 2 x100GB vmdisk.

Dit werkt allemaal goed ik kan op beide machines shares maken en benaderen. Ik kan ook vanaf beide machines password less inloggen. Echter bij het maken van een ZFS send gaat het mis

code:

Hello,
    The system was unable to replicate snapshot tank/foto to 192.168.120.190
======================
warning: cannot send 'tank/foto@auto-20120315.0010-2m': Broken pipe

Ik zag dat dit een probleem was met FreeNAS en heb daarom mijn 8.0.2 secondaire machine geupgrade naar 8.0.4 maar het probleem blijft. Vroeger heeft dit ook gewerkt maar ik ben de config kwijt net zoals de wiki waar de how to in stond.

Ik gebruik deze doc als bron: http://doc.freenas.org/index.php/Replication_Tasks

code:

Mar 15 13:57:02 freenas01 autorepl[59148]: Popen()ing: /sbin/zfs list -Ht snapshot -o name,freenas:state -r -S creation -d 1 tank/foto
Mar 15 13:57:02 freenas01 autorepl[59148]: Destroying remote tank/zfssync/foto
Mar 15 13:57:02 freenas01 autorepl[59148]: Executing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 /sbin/zfs destroy -rRf tank/zfssync/foto
Mar 15 13:57:02 freenas01 autorepl[59148]: Creating tank/zfssync/foto on remote system
Mar 15 13:57:02 freenas01 autorepl[59148]: Executing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 /sbin/zfs create -o readonly=on -p tank/zfssync/foto
Mar 15 13:57:03 freenas01 autorepl[59148]: Executing: (/sbin/zfs send tank/foto@auto-20120315.0010-2m | /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 "/sbin/zfs receive -F -d tank/zfssync && echo Succeeded.") > /tmp/repl-59148 2>&1
Mar 15 13:57:03 freenas01 autorepl[59148]: Popen()ing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 "zfs list -Hr -o name -S creation -t snapshot -d 1 tank/zfssync/foto | head -n 1 | cut -d@ -f2"
Mar 15 13:57:04 freenas01 autorepl[59148]: Replication of tank/foto@auto-20120315.0010-2m failed with warning: cannot send 'tank/foto@auto-20120315.0010-2m': Broken pipe
Mar 15 13:58:02 freenas01 autorepl[59167]: Popen()ing: /sbin/zfs list -Ht snapshot -o name,freenas:state -r -S creation -d 1 tank/foto
Mar 15 13:58:02 freenas01 autorepl[59167]: Destroying remote tank/zfssync/foto
Mar 15 13:58:02 freenas01 autorepl[59167]: Executing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 /sbin/zfs destroy -rRf tank/zfssync/foto
Mar 15 13:58:03 freenas01 autorepl[59167]: Creating tank/zfssync/foto on remote system
Mar 15 13:58:03 freenas01 autorepl[59167]: Executing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 /sbin/zfs create -o readonly=on -p tank/zfssync/foto
Mar 15 13:58:03 freenas01 autorepl[59167]: Executing: (/sbin/zfs send tank/foto@auto-20120315.0010-2m | /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 "/sbin/zfs receive -F -d tank/zfssync && echo Succeeded.") > /tmp/repl-59167 2>&1
Mar 15 13:58:04 freenas01 autorepl[59167]: Popen()ing: /usr/bin/ssh -i /data/ssh/replication -o BatchMode=yes -o StrictHostKeyChecking=yes -q 192.168.120.190 "zfs list -Hr -o name -S creation -t snapshot -d 1 tank/zfssync/foto | head -n 1 | cut -d@ -f2"
Mar 15 13:58:04 freenas01 autorepl[59167]: Replication of tank/foto@auto-20120315.0010-2m failed with warning: cannot send 'tank/foto@auto-20120315.0010-2m': Broken pipe

[ Voor 67% gewijzigd door raymonvdm op 15-03-2012 13:58 ]

[Tsurany]

Hoe zal een moderne i3 met 8GB ram en een recent moederbord presteren met 6x750GB hardeschijven? Levert dat leuke performance op? Twijfel nu of ik, na een hardware upgrade, toch naar FreeNAS/ZFS Guru ga of ga kiezen voor een systeem als OpenMediaVault.

[syl765]

Bij twijfel gewoon eens testen, en kijken wat er voor jou het beste zal presteren.
Maar je moet je ook 'thuis' voelen met een OS.
Als FreeNAS/ZFSGuru jou het gevoel geven geen controle te hebben over je data, of OpenMediaVault geeft je dat gevoel niet dan moet je wat anders zoeken wat jou wel dat gevoel geeft.

Zo is Linux niet mijn Cup of Tea zoals ze dat zeggen, en voel ik mij veel meer vertrouwt met FreeBSD, daarmee niet gezegd dat Linux niks is, het is gewoon niet geheel mijn ding.

Gr
johan

[syl765]

@raymonvdm

heb je het ook al eens vanaf de command line geprobeerd, dus gewoon hand matig een send/receive doen.

Gr
johan

[raymonvdm]

syl765 schreef op donderdag 15 maart 2012 @ 14:13:
@raymonvdm

heb je het ook al eens vanaf de command line geprobeerd, dus gewoon hand matig een send/receive doen.

Gr
johan

Ja maar dat werkt ook niet

[Tsurany]

syl765 schreef op donderdag 15 maart 2012 @ 14:09:
Bij twijfel gewoon eens testen, en kijken wat er voor jou het beste zal presteren.
Maar je moet je ook 'thuis' voelen met een OS.
Als FreeNAS/ZFSGuru jou het gevoel geven geen controle te hebben over je data, of OpenMediaVault geeft je dat gevoel niet dan moet je wat anders zoeken wat jou wel dat gevoel geeft.

Zo is Linux niet mijn Cup of Tea zoals ze dat zeggen, en voel ik mij veel meer vertrouwt met FreeBSD, daarmee niet gezegd dat Linux niks is, het is gewoon niet geheel mijn ding.

Gr
johan

Het lastige met testen is dat het om een systeem gaat wat ik niet thuis heb en wat een half uur heen en een half uur terug rijden is om een herinstallatie uit te voeren.
Me thuis voelen doe ik bij FreeNAS absoluut niet vanwege de zeer vervelende menu's. ZFS Guru ken ik nog niet maar dat ziet er in eerste instantie ook niet ideaal uit. Wat dat betreft voel ik me beter bij OpenMediaVault omdat die interface een stuk eenvoudiger is. Ik hoef ook enkel een array te hebben met een enkele schijf als redundantie en de mogelijkheid om hem als Rsync server in te stellen. Meer niet, het is puur opslag. Wat dat betreft zou OpenMediaVault vanuit management aspect een betere keuze zijn, maar het ZFS principe vind ik wel erg interessant.

[syl765]

Pure opslag!, dan gewoon een normale FreeBSD installatie zonder GUI en tierelantijntjes.
Dat werkt het best, en weet je ook nog eens waarmee je bezig bent!
Vergeet ook nexenta en openindiana niet!

gr
Johan

[syl765]

@raymonvdm

Zijn de pools wel gelijk genaamd op de machines.

doe eens een zfs list op beide machines en het commando dat je gebruikt, en plaats dat eens zodat we weten waar we het over hebben.

Gr
johan

[Tsurany]

syl765 schreef op donderdag 15 maart 2012 @ 14:34:
Pure opslag!, dan gewoon een normale FreeBSD installatie zonder GUI en tierelantijntjes.
Dat werkt het best, en weet je ook nog eens waarmee je bezig bent!
Vergeet ook nexenta en openindiana niet!

gr
Johan

Zonder GUI betekent dat ik me redelijk moet gaan verdiepen in de configuratie, als ik dat vergelijk met OpenMediaVault waarbij ik in een minuut klaar was inclusief Rsync server scheelt dat toch aardig. Denk dat ik dan toch voor OpenMediaVault zal gaan, ondanks dat ZFS redelijk interessant is. Het gaat tenslotte maar om backup storage, niet de hoofdstorage. En daarnaast is er nog de offsite backup.

[raymonvdm]

De pools hoeven niet het zelfde te zijn maar heten in mijn geval wel tank

[Ultraman]

raymonvdm schreef op donderdag 15 maart 2012 @ 14:21:
[...]


Ja maar dat werkt ook niet

Output van zfs list -t snapshot bekijken, hier posten bij voorkeur.
Met dat commando krijg je een lijst van bestaande snapshots.
Het snapshot welke je nu probeert te verwijderen lijkt simpelweg niet te bestaan.

[raymonvdm]

Ik vermoed dat het toch mis gaat op ssh

Ik kan ssh root@2enas doen en dat werkt (zonder password ingelogd)

Doe ik echter het volgende dan vraagt hij toch om wachtwoord

ssh -i /data/ssh/replication 192.168.120.190

Het lukt me niet om deze tekst te begrijpen
http://doc.freenas.org/index.php/Replication_Tasks en voor de volgende regel geeft hoop

THIS PART IS CHANGING -- IGNORE BELOW AS DOES NOT WORK

[ Voor 3% gewijzigd door raymonvdm op 15-03-2012 18:17 ]

[RudolfR]

http://www.freebsd.org/cgi/man.cgi?query=ssh&sektion=1

probeer het met -v (of -vvv) voor verbosity.
Daar staat wel in waarom je identity file wordt afgekeurd.

[raymonvdm]

De doc pagina is anders als de pdf handleiding. Met de pdf handleiding kom ik iets verder maar het werkt nog niet helemaal. Ik rommel nog even verder.

[Oid]

CurlyMo schreef op donderdag 15 maart 2012 @ 11:31:
[...]

ZFSGuru heeft in de webgui een bug zitten waardoor hij allerlei karakters vervangt door underscores. Kijk dus even goed in de lijst van ZFSGuru (die overigens wel de juiste namen laat zien) hoe de snapshot heet en verwijder hem dan inderdaad handmatig.

perfect dank jullie wel hierboven!!

lag dus aan de webgui bug! met de hand gedaan!!

[HyperBart]

Ik heb de review van onze oppertweaker even gelezen, maar snap het verhaal van vdev's pools enz... nog niet zo goed, care iemand om dit even uit te gaan leggen, wat ligt over wat?

[Verwijderd]

Wat begrijp je precies niet?

Een pool is een verzameling van vdevs (minimaal 1), een vdev is een verzameling disks in een bepaalde configuratie (single disk, mirror, raid-z). Als je meer dan één vdev hebt, wordt een RAID0-achtige interleaving toegepast over de vdevs, waarbij het verschil met traditioneel RAID0 is dat er aan load balancing wordt gedaan; snellere vdevs krijgen meer data te verwerken en worden dus niet afgeremd door tragere vdevs.

[Pixeltje]

Verwijderd schreef op vrijdag 16 maart 2012 @ 14:35:
Wat begrijp je precies niet?

Een pool is een verzameling van vdevs (minimaal 1), een vdev is een verzameling disks in een bepaalde configuratie (single disk, mirror, raid-z). Als je meer dan één vdev hebt, wordt een RAID0-achtige interleaving toegepast over de vdevs, waarbij het verschil met traditioneel RAID0 is dat er aan load balancing wordt gedaan; snellere vdevs krijgen meer data te verwerken en worden dus niet afgeremd door tragere vdevs.

Als voorbeeld;

stel dat ik 10 schijven heb, kan ik 5 vdev's maken van elk 2 schijven in stripe of mirror, vervolgens kan ik een ZFS pool (raidz bijvoorbeeld) maken van die 5 vdev's. Dan wordt mijn data verdeeld over de 5 vdev's (want raidz). Hoe zit het dan met parity? Maak ik dan een pool waarvan één vdev kan overlijden zonder dat mijn data in gevaar komt?

En als ik met 4 schijven gewoon een raidz set wil maken van die 4 schijven, heb ik dus één vdev van vier schijven in raidz, die tegelijk ook de pool is? (want de pool bestaat uit minimaal één vdev, in dit voorbeeld de vier schijven in raidz)

[ Voor 11% gewijzigd door Pixeltje op 16-03-2012 14:45 ]

[Verwijderd]

Zoals ik zeg:

Een POOL is een collectie van vdevs, een pool is niet RAID-Z; een vdev is RAID-Z.

Een VDEV is een collectie van disks in een bepaalde (RAID) configuratie, zoals 4 disks in één RAID-Z of 2 disks in een mirror; beide zijn vdevs.

Je begint je pool met één vdev, en kunt vdevs uitbreiden. Voorbeeld:
1. zpool create tank mirror disk1 disk2 mirror disk3 disk4

Nu heb ik een pool "tank" met 4 schijven en 2 vdevs. Beide vdevs zijn mirrors van elk twee schijven.

2. zpool add tank raidz disk5 disk6 disk7

Nu heb ik een pool "tank" met 7 schijven verdeeld over 3 vdevs, eerst twee mirror vdevs en daarna een raidz vdev van drie disks.

[Pixeltje]

Verwijderd schreef op vrijdag 16 maart 2012 @ 14:49:
Zoals ik zeg:

Een POOL is een collectie van vdevs, een pool is niet RAID-Z; een vdev is RAID-Z.

Een VDEV is een collectie van disks in een bepaalde (RAID) configuratie, zoals 4 disks in één RAID-Z of 2 disks in een mirror; beide zijn vdevs.

Je begint je pool met één vdev, en kunt vdevs uitbreiden. Voorbeeld:
1. zpool create tank mirror disk1 disk2 mirror disk3 disk4

Nu heb ik een pool "tank" met 4 schijven en 2 vdevs. Beide vdevs zijn mirrors van elk twee schijven.

2. zpool add tank raidz disk5 disk6 disk7

Nu heb ik een pool "tank" met 7 schijven verdeeld over 3 vdevs, eerst twee mirror vdevs en daarna een raidz vdev van drie disks.

Dat snap ik, maar ik ben benieuwd naar hoe het werkt als je een raidz pool maakt van een aantal vdevs van twee schijven (stripe of mirror, maakt even niet uit voor t voorbeeld). Is dat logisch? En hoe werkt het met falende schijven?

[matty___]

Pixeltje schreef op vrijdag 16 maart 2012 @ 15:00:
[...]


Dat snap ik, maar ik ben benieuwd naar hoe het werkt als je een raidz pool maakt van een aantal vdevs van twee schijven (stripe of mirror, maakt even niet uit voor t voorbeeld). Is dat logisch? En hoe werkt het met falende schijven?

zpool create bla raidz1 ada0 ada1 ada2
zpool add bla raidz1 ada3 ada4 ada5

dit is in feite raid50 bedoel je dat?

zpool create bla mirror ada0 ada1
zpool add bla mirror ada3 ada4

raid10

[ Voor 7% gewijzigd door matty___ op 16-03-2012 15:18 ]

[Pixeltje]

matty___ schreef op vrijdag 16 maart 2012 @ 15:17:
[...]

zpool create bla raidz1 ada0 ada1 ada2
zpool add bla raidz1 ada3 ada4 ada5

dit is in feite raid50 bedoel je dat?

zpool create bla mirror ada0 ada1
zpool add bla mirror ada3 ada4

raid10

Niet helemaal (denk ik)

Wat ik bedoel is meer dit:

zpool create tank mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6 mirror disk7 disk8
zpool create tank1 raiz vdev1 vdev2 vdev 3 vdev4

Dat maakt een Raidz pool tank 1 van 4 vdevs bestaande uit twee mirrored schijven. Is dat gelijk aan raid50, en zoja, hoe zit het met uitvallende schijven; kan ik één schijf uit de raidz pool tank1 kwijtraken, of kan ik per vdev een schijf kwijtraken zonder dat mijn data kwijt is?

[webbier]

Aangezien je pool dan uit allemaal mirrors bestaat mag je uit elke vdev een schijf verliezen.

[Pixeltje]

webbier schreef op vrijdag 16 maart 2012 @ 15:51:
Aangezien je pool dan uit allemaal mirrors bestaat mag je uit elke vdev een schijf verliezen.

Ok. Dat wilde ik weten inderdaad Is wel inefficiënt, want je verliest veel opslagcapaciteit aan parity, maar wel goed voor je datazekerheid lijkt me.

[webbier]

Dat is waar. Al kun je op deze manier natuurlijk wel makkelijker je pool uitbreiden. Je hebt dan maar 2 disks nodig.

[Pixeltje]

webbier schreef op vrijdag 16 maart 2012 @ 15:55:
Dat is waar. Al kun je op deze manier natuurlijk wel makkelijker je pool uitbreiden. Je hebt dan maar 2 disks nodig.

Dat is ook weer waar. Ik zit hieraan te denken omdat ik nu (maar) vier schijven heb, ik zou dus 2 vdevs kunnen maken van 2 schijven in mirror, en die raidz-en tot 1 volume. Als ik wil uitbreiden kan ik met twee schijven af, maak ik gewoon een derde vdev die ik aan de raidz pool toevoeg. Toch?

Ik heb de afgelopen tijd heel-heel veel gelezen en gevraagd over ZFS, maar blijkt maar weer dat lang niet alles blijft hangen. Vandaar deze vragen
Als het goed is krijg ik morgen eindelijk mijn spullen geleverd, dus zou ik dit weekend kunnen gaan bouwen en inrichten.

[matty___]

Pixeltje schreef op vrijdag 16 maart 2012 @ 15:38:
[...]


Niet helemaal (denk ik)

Wat ik bedoel is meer dit:

zpool create tank mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6 mirror disk7 disk8
zpool create tank1 raiz vdev1 vdev2 vdev 3 vdev4

Dat maakt een Raidz pool tank 1 van 4 vdevs bestaande uit twee mirrored schijven. Is dat gelijk aan raid50, en zoja, hoe zit het met uitvallende schijven; kan ik één schijf uit de raidz pool tank1 kwijtraken, of kan ik per vdev een schijf kwijtraken zonder dat mijn data kwijt is?

dat is hetzelfde wat ik je net liet zien
zpool create bla raidz1 ada0 ada1 ada2 in totaal 10gb
zpool add bla raidz1 ada3 ada4 ada5 in totaal 10gb

zpool bla wordt dan 20gb
uit beide sets kun je 1 schijf kwijtraken
je striped over 2 raidz vdevs

[matty___]

Pixeltje schreef op vrijdag 16 maart 2012 @ 16:08:
[...]


Dat is ook weer waar. Ik zit hieraan te denken omdat ik nu (maar) vier schijven heb, ik zou dus 2 vdevs kunnen maken van 2 schijven in mirror, en die raidz-en tot 1 volume. Als ik wil uitbreiden kan ik met twee schijven af, maak ik gewoon een derde vdev die ik aan de raidz pool toevoeg. Toch?

Ik heb de afgelopen tijd heel-heel veel gelezen en gevraagd over ZFS, maar blijkt maar weer dat lang niet alles blijft hangen. Vandaar deze vragen
Als het goed is krijg ik morgen eindelijk mijn spullen geleverd, dus zou ik dit weekend kunnen gaan bouwen en inrichten.

ja dat klopt zo kun je wel makkelijker uitbreiden maar wordt op gegeven moment raidz2 wel aantrekkelijker

omdat het met raidz1/2/3 niet uit maakt welke schijf je kwijt raakt.
raakt je in de raid10 per ongeluk 2 uit dezelfde vdev kwijt ben je alles kwijt.

[ Voor 8% gewijzigd door matty___ op 16-03-2012 16:11 ]

[CurlyMo]

Pixeltje schreef op vrijdag 16 maart 2012 @ 15:38:
[...]


Niet helemaal (denk ik)

Wat ik bedoel is meer dit:

zpool create tank mirror disk1 disk2 mirror disk3 disk4 mirror disk5 disk6 mirror disk7 disk8
zpool create tank1 raiz vdev1 vdev2 vdev 3 vdev4

Dat maakt een Raidz pool tank 1 van 4 vdevs bestaande uit twee mirrored schijven. Is dat gelijk aan raid50, en zoja, hoe zit het met uitvallende schijven; kan ik één schijf uit de raidz pool tank1 kwijtraken, of kan ik per vdev een schijf kwijtraken zonder dat mijn data kwijt is?

Wat je hier probeert te doen kan in de praktijk niet met ZFS. Wanneer je een zpool aanmaakt dan is deze niet opnieuw te gebruiken in een tweede pool. Dus je constructie met een raidz met 4 mirror disks werkt niet. Via allerlei omwegen zou het voor elkaar te krijgen zijn maar dat wil je simpel weg niet.

Bij MDADM is dat anders. Daar maak je een 3 mirrors aan met elk 2 schijven. Deze krijgen vervolgens de naam /dev/md0 /dev/md1 /dev/md2. Deze kan je vervolgens weer gebruiken in een raid5 oplossing. Zodat elke schijf in je raid5 pool ook weer gemirrored zijn. Volgens mij krijg je dan effectief een raid15 oplossing.

Waarom het niet kan, is omdat het totaal geen meerwaarde heeft. Het enige wat je zou kunnen doen is een raid50 oplossing maken door 2 raidz pool samen te voegen tot een pool.

[Ultraman]

Pixeltje schreef op vrijdag 16 maart 2012 @ 16:08:
[...]


Dat is ook weer waar. Ik zit hieraan te denken omdat ik nu (maar) vier schijven heb, ik zou dus 2 vdevs kunnen maken van 2 schijven in mirror, en die raidz-en tot 1 volume. Als ik wil uitbreiden kan ik met twee schijven af, maak ik gewoon een derde vdev die ik aan de raidz pool toevoeg. Toch?

Ik heb de afgelopen tijd heel-heel veel gelezen en gevraagd over ZFS, maar blijkt maar weer dat lang niet alles blijft hangen. Vandaar deze vragen
Als het goed is krijg ik morgen eindelijk mijn spullen geleverd, dus zou ik dit weekend kunnen gaan bouwen en inrichten.

Waarom zou je vier schijven mirroren en vervolgens een (degraded) raidz over die twee draaien om tot 1 volume te komen?

Als je posts lees dan zie ik dat je de begrippen niet volledig beheerst, met name het begrip "zpool".

Een ZFS pool bestaat uit een één of meer vdevs.
Dat is alles. Er is geen "raidz pool", geen "mirror pool", het is gewoon een pool.
Hebben? Mooi.

Een pool bestaat dus uit vdevs.
Wat is een vdev?
Vdev staat voor virtual device. Een virtueel opslag apparaat om het even in gewoon Nederlands om te zetten.
Met deze vdevs kun je een pool vormen.
Wat hier de verwarring schopt is die 'v' denk ik. Het virtuele.

Ja, dat virtuele, wat houdt dat in?
Je kunt het zien als een vorm van abstractie, want daar komt het eigenlijk op neer.
Een vdev is een bouwsteen die zelf weer bestaat uit één of meerdere block devices; wat een file kan zijn, een partitie op een harddisk of een hele harddisk, een USB stick, SD-kaart etc.

Het simpelste vdev bestaat uit 1 apparaat.
Bijvoorbeeld één hard disk, daarmee kun je al een vdev maken.

Willen we een opslagvolume maken, dan is dat heel gemakkelijk en lijkt dit veel op de weg die je waarschijnlijk al kent:
zpool create mijnpool mijndisk
Dit commando maakt een ZFS pool aan, genaamd "mijnpool".
"mijnpool" is opgebouwd uit één vdev, namelijk "mijndisk"
En "mijndisk" is de hard disk in jouw systeem.

Een single disk opslagmedium, klaar voor gebruik.


Ok, maar je wilt leuke truukjes uit gaan halen zoals mirroring en raidz1 (of raidz2 of raidz3).
Al die "magie" vind plaats op het niveau van vdev. Een vdev is zo'n mirror, een vdev is zo'n raidz1.

Mirroring
Een volgend voorbeeld, de mirror, deze kun je vergelijken met RAID1:
Je hebt een systeem waarin twee disken zitten: "disk1" en "disk2" noemen we die even.

Volgens geef je het volgende commando om pool "mijnpool" te maken:
zpool create mijnpool mirror disk1 disk2

Je hebt nu een ZFS pool genaamd "mijnpool", opgebouwd uit één vdev.
Dit is een vdev van het type "mirror".
Deze mirror is opgebouwd uit twee block devices, namelijk disk1 en disk2.
Data op deze pool (en onderliggende file systems) wordt opgeslagen op beide disken.
Je kunt binnen dit vdev één disk verliezen, en dan beschik je nog steeds over al je data in de pool.


raidz1
Dit is vergelijkbaar met RAID-5.
Je neemt drie disken, waarvan de capaciteit van één disk gebruikt wordt voor pariteit data.
Je kunt nu 1 disk missen, dan kun je nog over je data beschikken. Dat is voor raidz1 ook zo.
Wel zitten er verschillen in performance tussen RAID5 en raidz1, maar dat is stof voor een andere keer misschien.

Dus, we hebben nu drie disken: "disk1", "disk2", "disk3"
Hoe maken we dat?
zpool create mijnpool raidz1 disk1 disk2 disk3

Je hebt nu een ZFS pool genaamd "mijnpool", opgebouwd uit één vdev.
Dit is een vdev van type "raidz"
Deze vdev is opgebouwd uit 3 block devices, namelijk disk1, disk2 en disk3.


Dit kun je waarschijnlijk allemaal prima volgen.
Want ik zag je de mist in gaan zodra er meerdere "lagen" ontstonden. RAID10 en RAID50 bijvoorbeeld, ik zal die behandelen.

Striped Mirrors - RAID10
RAID10 is een mooi simpel RAID level, bestaande uit twee mirrors die gestriped worden, en zo één volume vormen. I/O wordt verdeeld over beide mirrors, dat is wat striping doet, waardoor je performance omhoog gaat.

In ZFS kun je ook een volume maken opgebouwd uit meerdere mirrors, net zoals RAID10.
Hiervoor heb je ten minste vier disken nodig. En als je redundant wilt blijven werken en goede performance wilt blijven houden het beste per 2 disken uitbreiden als je meer capaciteit wilt. Dus van vier naar zes disken, acht disken, tien disken, etc.

Hoe maak je een striped mirror met vier disken met ZFS?
zpool create mijnpool mirror disk1 disk2 mirror disk3 disk4
Je hebt nu een ZFS pool genaamd "mijnpool", opgebouwd uit twee vdevs.
vdev1 is een mirror type, opgebouwd uit disk1 en disk2
vdev2 is een mirror type, opgebouwd uit disk3 en disk4.

Striped raidz1 - RAID50
Een RAID50 volume bestaat uit twee (of meer) RAID5 opstellingen die middels striping samen één volume vormen. Voor één RAID5 heb je minstens drie disken nodig, dus voor RAID50 heb je minstens zes disken nodig. We doen het voorbeeld met zes disken.
Ook kun je dit uitbreiden naar negen disken, twaalf disken etc, voor meer capaciteit.

Hoe maak je dat met ZFS?
zpool create mijnpool raidz1 disk1 disk2 disk3 raidz1 disk4 disk5 disk6

Je hebt nu een ZFS pool genaamd "mijnpool", opgebouwd uit twee vdevs.
vdev1 is een raidz1 type, opgebouwd uit disk1, disk2 en disk3
vdev2 is een raidz1 type, opgebouwd uit disk4, disk5 en disk6

Maakt dit meer duidelijk over hoe pools bestaan uit vdevs en wat een vdev is?


Wat jouw opstelling betreft, je hebt vier disken zeg je, en wilt mogelijk uitbreiden naar zes.
Dat is erg vergelijkbaar met mijn situatie: ik ook vier disken voor mijn grote opslag pool in gebruik.
Ik gebruik striped mirrors, dus vergelijkbaar met raid10.
Zo ziet een zpool status er uit van die pool op mijn FreeBSD machine:

code:

$ zpool status tank
  pool: tank
 state: ONLINE
 scan: scrub repaired 0 in 1h38m with 0 errors on Sun Mar 11 04:32:47 2012
config:

    NAME           STATE     READ WRITE CKSUM
    tank           ONLINE       0     0     0
      mirror-0     ONLINE       0     0     0
        ada4p1     ONLINE       0     0     0
        ada1p1     ONLINE       0     0     0
      mirror-1     ONLINE       0     0     0
        ada3p1     ONLINE       0     0     0
        gpt/tank3  ONLINE       0     0     0

errors: No known data errors

Mijn pool "tank" bestaat uit twee vdevs, welke weer bestaan uit elk twee disken.
Dit zijn dus striped mirrors.

Als ik wil uitbreiden, dan koop ik twee nieuwe disken en stop die in mijn machine.
Vervolgens kan ik een deze twee disken als mirror vdev toevoegen aan mijn zpool.
Dat commando zal iets zijn in de trant van:
zpool add tank mirror disk5 disk6
En dan zal er een "mirror-2" vdev bestaande uit disk5 en disk6 aan pool tank toegevoegd worden

[ Voor 7% gewijzigd door Ultraman op 16-03-2012 17:57 . Reden: voorbeeldje van uitbreiding en zpool status tank van mijn machine toegevoegd ]

[Pixeltje]

[b]Ultraman schreef op vrijdag 16 maart 2012 @ 16:51
Knip

Heel helder verhaal, thanks!

Het eerste stuk is inderdaad geen probleem, waar ik de mist in ging is bij de raid10 en 50 achtige oplossingen.

Ik heb een testbak gemaakt waar ik eerst nog even naar hartelust kan proberen voordat ik mijn echte Nas opzet, bedankt voor je uitleg!

[CurlyMo]

Ultraman schreef op vrijdag 16 maart 2012 @ 16:51:
Dit kun je waarschijnlijk allemaal prima volgen.
Want ik zag je de mist in gaan zodra er meerdere "lagen" ontstonden. RAID10 en RAID50 bijvoorbeeld, ik zal die behandelen.

Ter aanvulling hierop. De raid levels uit meerdere "lagen" die ondersteund worden zijn alle RAID*0 oplossing. Dus RAID10, RAID50, RAID60 etc. De andere nested raid levels zoals RAID15 of RAID16 worden niet ondersteund en deze zijn dus ook vrij ongebruikelijk maar theoretisch niet onmogelijk. Het hoe en waarom wordt uitgebreid uitgelegd door Femme.

[FireDrunk]

In Femme's verhaal staat wel heel duidelijk dat een Log device vrijwel nutteloos is voor alleen het delen van files. Alleen voor een synchrone iSCSI LUN zou het zin hebben. L2ARC is dan ook wel leuk, maar voor data die maar 1 keer opgevraagd word (zoals bij mij ) weer nutteloos.

Het ruikt er bij mij dus naar dat ik geen enkele SSD aan ZFS ga geven

[Ultraman]

Pixeltje schreef op zaterdag 17 maart 2012 @ 10:49:
[...]

Heel helder verhaal, thanks!

Het eerste stuk is inderdaad geen probleem, waar ik de mist in ging is bij de raid10 en 50 achtige oplossingen.

Ik heb een testbak gemaakt waar ik eerst nog even naar hartelust kan proberen voordat ik mijn echte Nas opzet, bedankt voor je uitleg!

Fijn dat ik het hebben kunnen verduidelijken

Spelen op een testbak kan ik alleen maar aanraden. Je doet zo ervaring op zonder je zorgen te hoeven maken. Dus test alles wat je wilt weten vrolijk uit. Ik heb een tijdje FreeBSD 8.2 gebruikt op een testmachine om ervaring op te doen. Voornamelijk met ZFS, maar toch ook met FreeBSD, want ik kwam vanuit Linux dit kamp in rollen. Weliswaar vanuit een BSD-achtige Linux, zoals Arch Linux, maar er zit genoeg verschil in kan je vertellen.
Ik ben in de toekomst nu ook meer geneigd om voor FreeBSD te kiezen, vind het een mooi systeem.

FireDrunk schreef op zaterdag 17 maart 2012 @ 11:46:
In Femme's verhaal staat wel heel duidelijk dat een Log device vrijwel nutteloos is voor alleen het delen van files. Alleen voor een synchrone iSCSI LUN zou het zin hebben. L2ARC is dan ook wel leuk, maar voor data die maar 1 keer opgevraagd word (zoals bij mij ) weer nutteloos.

Het ruikt er bij mij dus naar dat ik geen enkele SSD aan ZFS ga geven

Een SSD Log device heeft inderdaad maar beperkt nut.
En L2ARC is inderdaad wel leuk, maar pas als je data hebt die je vaker dan eenmaal gaat aanspreken. In mijn geval past het spul wat ik frequent gebruikt prima in RAM, zoals ik ook kan aflezen aan de groote van de Most Frequently Used Cache Size met zfs-stats. Ik verwacht dat, qua persoonlijke data, daar mijn studiefiles in zitten, want ik maak van elk studievak een git repo en push/pull die op verschillende PCs, waarbij mijn server de centrale node is. Ik wil iets meer met webhosting gaan doen op de server, voornamelijk mijn broertje wil een website gaan hosten. Dus dan gaat de frequently used wel omhoog.
Mogelijk dat ik dan upgrade van 8GB naar 16GB RAM, maar ik verwacht dat ik het daar nog wel flinke tijd mee ga redden.

[FireDrunk]

Ik heb 24GB RAM en nog 48GB liggen, dus voor L2ARC hoef ik geen SSD te gebruiken, daar heb ik wel RAM voor

[Ultraman]

[Erik1]

Verwijderd schreef op dinsdag 06 maart 2012 @ 23:27:
Als je L2ARC SSD caching gebruikt, betekent dat niet persé dat je geen controle hebt over welke data op de SSD komt. Je kunt met de secondarycache parameter per filesystem of volume (ZVOL) opgeven of hij gebruik mag maken van de L2ARC. Je kunt opgeven: none (niets), metadata (alleen filesystem data zoals directory structuur) en all (metadata+data; standaard setting).

Hetzelfde geldt voor de Level 1 RAM cache, die je met primarycache parameter kunt veranderen met dezelfde opties als hierboven uitgelegd.

Zo heb je dus precies controle welke datasets gebruik maken van je verschillende cache lagen. Je kunt bulk data op 'none' zetten, of op 'metadata' zodat je SSD wel de directory structuren cached. Dat kan handig zijn als je veel bestanden in directories hebt en lekker snel de directories wilt kunnen openen.

Kijk, dat lost het grootste bezwaar van 1 pool al op.

Bedenk dat L2ARC cache je ook RAM geheugen kost; dat kan tot enkele gigabytes oplopen met een 100GB cache. Bij onvoldoende RAM wordt de L2ARC niet volledig gebruikt.

Heb nu 1 80GB ssd (Intel 320) die ik ga inzetten voor L2ARC en misschien ook ZIL, moet alleen nog uitzoeken wat de meest optimale partitie indeling is. Als later blijkt dat een 2e SSD zinvol zou kunnen zijn kan ik er altijd nog 1 bijzetten.

Concluderend denk ik dat je met optie 1 de beste setup hebt. Weet dat je kunt beginnen met enkele disks en daar later pas een mirror van maken. Kan handig zijn als je tijdelijk ruimte nodig hebt om data over te zetten. Dan kun je bijvoorbeeld eerst een RAID0 maken van één Samsung en één Seagate schijf, zodat je twee vdevs hebt. Later kun je aan elke vdev eenzelfde disk van hetzelfde type toevoegen en heb je nog steeds twee vdevs maar dan mirrors.

Deze optie is het dan ook geworden. Ik heb nu ZFSguru geinstalleerd op een VM met 8GB RAM en de LSI kaart als passthrough met 2x2TB Samsung F4EG + 2x3TB Seagate ST3000DM001 disks en de SSD. Het booten van de LSI kaart in een VM is helaas niet mogelijk (vmware esxi beperking denk ik), dus dat moet altijd via een virtuele disk vanuit esxi. Daarna de pool aangemaakt, de performance (sequentieel) is prima te noemen.

code:

[root@zfsguru /bigpool]# dd if=/dev/zero of=/bigpool/zero.000 bs=1m count=8000
8000+0 records in
8000+0 records out
8388608000 bytes transferred in 33.775466 secs (248363946 bytes/sec)
[root@zfsguru /bigpool]# dd if=/bigpool/zero.000 of=/dev/null bs=1m
8000+0 records in
8000+0 records out
8388608000 bytes transferred in 14.577420 secs (575452172 bytes/sec)
[root@zfsguru /bigpool]# rm zer

Wat wel opvalt is dat de schrijfsnelheid niet precies de helft is maar iets minder.

Klopt het dat via de ZFSguru interface geen pool van 2 mirrored vdevs gemaakt kan worden? Ik kon alleen een stripe of 4-way mirror maken.

Heb de pool aangemaakt via de command line, kon de 4K sector gnop methode commands mooi afkijken van het voorbeeld uit de webinterface

[Verwijderd]

Je kunt je SSD in meerdere partities indelen op de Disks pagina (partition map editor). Voor een 80GB SSD denk ik aan:
50GB L2ARC - 4GB SLOG - rest unpartitioned spare space

Maar misschien kun je ook booten van je SSD? Heeft je SSD een 'ada' interface in FreeBSD/ZFSguru? Zo niet, dan heb je geen TRIM support. Dat is een groot nadeel van RDM of virtuele disks; omdat alles via een emulatie-layer loopt heb je niet de originele functionaliteit; zaken als TRIM kun je vergeten. Dat is één van de nadelen van ESXi. Een setup waarbij het ZFS OS directe controle over de hardware heeft en je andere OS via virtualisatie draait (Virtualbox, Xen, BeHyVe) is voor het ZFS-gedeelte stukken beter, maar ook een stuk moeilijker mogelijk als je bijvoorbeeld 3D acceleratie wilt voor guests. Geen idee of ESXi dat ondersteunt? Wat ga je nog meer via ESXi draaien?

Je benchmark is slechts 8GB groot; je moet met 8 keer je RAM testen voor nauwkeurige resultaten; dus je zult net iets lagere maar realistische scores krijgen met 64GB testfile, wat geloof ik ook de default is als je test via de Web-interface (Pools->Benchmark).

Wil je een pool met meerdere vdevs, dan maak je eerst de pool aan met de eerste vdev op de Pools->Create pagina. Daarna voeg je telkens een vdev toe op de Pools->Expand pagina. Dus je begint met een mirror van 2 disks, je expand met een mirror van 2 disks, nog een keer expanden met een mirror van 2 disks, en je hebt een pool met 3 vdevs en 6 disks in totaal (RAID1+0).

[ Voor 14% gewijzigd door Verwijderd op 17-03-2012 16:43 ]

[matty___]

Verwijderd schreef op zaterdag 17 maart 2012 @ 16:41:


Maar misschien kun je ook booten van je SSD? Heeft je SSD een 'ada' interface in FreeBSD/ZFSguru? Zo niet, dan heb je geen TRIM support.

vanaf 9 zit alles in het scsi framework dus zal die wel als ada herkend worden. Trim support kun je achter halen via het camcontrol command; dacht met de inquiry parameter.

[Erik1]

De HBA is via passthrough aan de VM gegeven, waardoor er volledige controle over de hardware is. Wat helaas niet kan is direct booten vanaf een disk die aan de HBA hangt, is denk ik een beperking van de VMware bios. Ik heb dus een virtuele schijf gemaakt om vanaf te booten. Die staat op de VMware datastore op een 2,5" 160GB schijfje aan de onboard sata.

De disks hebben wel een "da" naam ipv "ada". Misschien omdat het een SAS adapter is waar SATA schijven aan hangen? TRIM zal dus helaas niet gebruikt kunnen worden, onderpartitioneren moet dat nadeel opvangen.


Wat ik er verder nog naast ga draaien in ESXi:
- pfSense: Komt in alle vlans te hangen als router/firewall en VPN toegang vanaf internet
- Windows XP of 7: Remote desktop / downloads als mijn desktop PC uit staat.
- Debian: TV server / recorder (er zit een DVB-C kaart in de server)

Verder een testomgeving waar ik snel een paar machientjes kan optuigen zonder met fysieke hardware te hoeven slepen

Zou natuurlijk ook prima met bijv. virtualbox op FreeBSD als host kunnen, maar met vmware heb ik het meeste ervaring.

Verwijderd schreef op zaterdag 17 maart 2012 @ 16:41:
Je benchmark is slechts 8GB groot; je moet met 8 keer je RAM testen voor nauwkeurige resultaten; dus je zult net iets lagere maar realistische scores krijgen met 64GB testfile, wat geloof ik ook de default is als je test via de Web-interface (Pools->Benchmark).

Inderdaad een stuk lager!

code:

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : bigpool (4.53T, 0% full)
Test size       : 64 GiB
Data source     : /dev/zero
Read throughput : 311.1 MB/s = 296.6 MiB/s
Write throughput: 228.4 MB/s = 217.8 MiB/s

Wil je een pool met meerdere vdevs, dan maak je eerst de pool aan met de eerste vdev op de Pools->Create pagina. Daarna voeg je telkens een vdev toe op de Pools->Expand pagina. Dus je begint met een mirror van 2 disks, je expand met een mirror van 2 disks, nog een keer expanden met een mirror van 2 disks, en je hebt een pool met 3 vdevs en 6 disks in totaal (RAID1+0).

Ah, de expansion tab had ik even gemist

[Verwijderd]

Je SSDs kun je beter ook niet op een SAS controller gebruiken maar op je chipset AHCI controller, zodat je wel TRIM support hebt en ook DIPM kunt gebruiken.

Nadeel is wel dat als je je AHCI controller doorgeeft, je daar geen disk op kunt aansluiten voor ESXi, iets wat je denk ik met USB kunt oplossen; ik neem aan dat de systeemdisk van ESXi nauwelijks gebruikt wordt als eenmaal alles draait?

Disks met 'da' zijn SCSI subsystem disks; ad = ATA subsystem; ada = ATA AHCI subsystem. In FreeBSD 10 is er support voor TRIM/UNMAP voor SCSI interfaces; maar of dat zomaar gaat werken met SATA SSDs op een LSI SAS controller is nog maar zeer de vraag.

Verder nog wat gedachtenspindels:
- pfSense heb je dat echt nodig? FreeBSD/ZFSGuru heeft ook 'pf' firewall en kun je dus prima op de host draaien; alleen mis je dan wel een web-interface voor het configureren van de firewall; daar is het je denk ik om te doen?
- winxp/7: heb je denk ik geen passthrough voor nodig?
- debian: daar heb je wel USB passthrough voor nodig?

Punt is, een alternatieve setup zou zijn als je alles via een FreeBSD host systeem doet; dus gewoon FreeBSD/ZFSguru met Virtualbox voor je Windows + Debian VM. Voor heel belangrijke VMs zou ik niet zo snel virtualbox gebruiken maar voor wat extra dingen erbij kan het een prima oplossing zijn. Groot voordeel is da je ZFS host nu directe toegang tot alles heeft en geen emulatie-penalty meer. Ook minder foutgevoelig, bijvoorbeeld de ESXi + FreeBSD9 + LSI controller + vt-d passthrough bug.

[FireDrunk]

Nee dat kan niet, je kan je host AHCI controller niet doorgeven, want de vmx file van de VM die de controller krijgt moet op een VMFS/NFS volume staan en mag niet op USB staan.

[Verwijderd]

Dus je kunt ESXi niet gebruiken zonder de onboard chipset controller in zijn geheel op te offeren aan ESXi (of via RDM maar dan heb je natuurlijk ook geen TRIM) ? Dat is wel een groot nadeel. Ik bedoel met Virtualbox kun je zonder disks booten; kan dat bij ESXi niet?

Als je je mooiste controller (je chipset controller) kwijt bent aan ESXi vind ik dat een groot nadeel. Dan hoop ik toch echt dat Xen straks lekker werkt als host op BSD; lijkt mij stukken beter dan ESXi. Ook BHyVe (bee-hive; ofwel bijenkorf) is interessant; omdat je zonder vt-d support PCI passthrough krijgt. Werkt op dit moment alleen nog voor BSD guests; maar heeft zeker potentie.

Leuk PDFje over BHyVe:
http://wiki.freebsd.org/2...e&do=get&target=BHyVe.pdf

[FireDrunk]

Bij RDM geen TRIM? niet? Waarom niet?

[Verwijderd]

Omdat RDM een SCSI-laag introduceert? Als je via RDM een AHCI disk aan een FreeBSD guest koppelt, krijg je onder FreeBSD een 'da' SCSI/SAS interface te zien; geen 'ada' interface. Correct me if i'm wrong.

Wat theoretisch wel zou kunnen is dat je FreeBSD 10 draait die UNMAP commando's stuurt naar 'da'; het TRIM-equivalent van SCSI, en dat de RDM-emulatielaag van ESXi deze commando's converteert naar TRIM commando's. Het FreeBSD-gedeelte om dit te laten werken is af, maar ik denk niet dat je deze support onder ESXi kunt verwachten, als die er al ooit komt.

[FireDrunk]

Goed punt, ik ga er even van uit dat de VMware Paravirtual controller geen TRIM ondersteund, hoewel ik het zo snel niet kan vinden.

Even terughaken:

omdat je zonder vt-d support PCI passthrough krijgt.

Dat kan nooit snel zijn, want dat moet zonder DMA. Met andere woorden, dat wil je alleen voor easy peasy devices als een geluidskaartje of een extra printerpoortje. Niet voor je hele IO backend.

[ Voor 56% gewijzigd door FireDrunk op 17-03-2012 19:37 ]

[Erik1]

ESXi zelf kan wel op USB, maar er is inderdaad altijd een datastore nodig voordat je een VM kunt aanmaken. Je kunt je onboard controller wel passthrough-en maar dan moet je dus ergens anders je datastore vandaan halen.

Ik heb dat al eens geprobeerd door een goedkoop 2-poort pci-e 1x sata kaartje (Sil3132 chip) bij te prikken, maar deze wordt door esxi niet ondersteund. Het kaartje zelf passthrough-en werkte ook niet goed, hele host loopt vast zodra je er wat data overheen stuurt. Misschien dat er andere kaartjes zijn waarmee dit wel goed werkt. Enterprise spul zal natuurlijk wel werken in esxi, maar de prijs daarvan is natuurlijk niet in verhouding tot het doel.

Datastore via nfs vanaf een routertje met openwrt of via internet (als je toevallig ergens anders een server hebt draaien) kan ook als er toch alleen een .vmx file op staat, maar dat wordt wel een heel foutgevoelige hobby-bob oplossing.

Verwijderd schreef op zaterdag 17 maart 2012 @ 18:08:
Verder nog wat gedachtenspindels:
- pfSense heb je dat echt nodig? FreeBSD/ZFSGuru heeft ook 'pf' firewall en kun je dus prima op de host draaien; alleen mis je dan wel een web-interface voor het configureren van de firewall; daar is het je denk ik om te doen?

Klopt. Ook kun je in esxi heel makkelijk netwerken scheiden, wat met native FreeBSD waarschijnlijk ook prima kan maar meer uitzoek en configwerk kost. Het is ook wel prettig om voor het netwerkgedeelte een aparte VM te hebben aangezien op 1 van de interfaces het internet zit gekoppeld wat niet bepaald als een veilig netwerk bekend staat

Als alternatief zou ik natuurlijk ook een hardware routertje kunnen blijven gebruiken, stroomverbruik is niet hoog.

- winxp/7: heb je denk ik geen passthrough voor nodig?
- debian: daar heb je wel USB passthrough voor nodig?

Is een PCI DVB-C kaart, maar kan ik natuurlijk vervangen door een USB DVB-C als dat beter werkt.

Punt is, een alternatieve setup zou zijn als je alles via een FreeBSD host systeem doet; dus gewoon FreeBSD/ZFSguru met Virtualbox voor je Windows + Debian VM. Voor heel belangrijke VMs zou ik niet zo snel virtualbox gebruiken maar voor wat extra dingen erbij kan het een prima oplossing zijn. Groot voordeel is da je ZFS host nu directe toegang tot alles heeft en geen emulatie-penalty meer. Ook minder foutgevoelig, bijvoorbeeld de ESXi + FreeBSD9 + LSI controller + vt-d passthrough bug.

Ook voor de geheugenverdeling zie ik voordelen, nu heb ik vast 8GB aan de NAS VM gegeven en ook vaste aantallen aan de andere VM's. Met FreeBSD/ZFSguru als host systeem gebruikt Virtualbox wat hij nodig heeft en wordt de rest voor ARC gebruikt. Zie ik dat goed? Zou je dan nog bepaalde memory tuning nodig hebben?

[FabiandJ]

Ik heb nu zfs op mijn linuxbak staan en nu wil ik graag aan RAIDZ2 aanmaken wat zo zou moeten:
zpool create mijnpool raidz2 disk1 disk2 disk3 disk4 disk5 disk6

Alleen ik weet niet precies wat ik met die 6 disken moet, moet ik hier een partitie opzetten en deze formatteren?

Ik heb dit geprobeerd:
zpool create tank raidz2 /dev/sdb/ /dev/sdc/ /dev/sdd/ /dev/sde/ /dev/sdf/ /dev/sdg/

Maar dan krijg ik een error: cannot open '/dev/sdb/': Not a directory

[ Voor 25% gewijzigd door FabiandJ op 17-03-2012 21:47 ]

[CurlyMo]

Dutch3men schreef op zaterdag 17 maart 2012 @ 21:44:
Ik heb nu zfs op mijn linuxbak staan en nu wil ik graag aan RAIDZ2 aanmaken wat zo zou moeten:
zpool create mijnpool raidz2 disk1 disk2 disk3 disk4 disk5 disk6

Alleen ik weet niet precies wat ik met die 6 disken moet, moet ik hier een partitie opzetten en deze formatteren?

Ik heb dit geprobeerd:
zpool create tank raidz2 /dev/sdb/ /dev/sdc/ /dev/sdd/ /dev/sde/ /dev/sdf/ /dev/sdg/

Maar dan krijg ik een error: cannot open '/dev/sdb/': Not a directory

Wanneer je je pool aanmaakt zoals je zelf al beschrijft, dan wordt je mountpoint automatisch /mijnpool dat is ook gelijk de root fs van je pool. Je filesystem wordt dus al gelijk voor je aangemaakt. Wil je child hebben, dan maak je deze aan via "zfs create mijnpool/[naam van je fs]". Deze kunnen zo diep genesteld zijn als je wilt.

[HyperBart]

Goed, paar dingen nu al gelezen, nog eens goed het verschil tussen een ZIL en een L2ARC bekijken, maar een ding steekt me nu wel wat tegen: een vdev (waar je dus het redundantiemechanisme definieert...) kan je niet uitbreiden...

Stel nu dat ik besluit om een NAS te bouwen (het begint weer te kriebelen ) met 4x 3TB en ik maak daar dan een vdev van, pool'tje er op en huppa. En ik besluit om op termijn mijn pool uit te willen breiden met nog eens 2 3TB disks, dan moet ik dus oftewel:

• een nieuwe vdev aanmaken met die twee disks, die onder de pool steken
• al mijn data kopiëren, de oude vdev destroyen, en een nieuwe aanmaken met de 2 nieuwe disks er bij

Besluit ik dan later om er weer een disk bij te hangen, dan neem ik daarmee een groot risico want ik heb op die disk dan geen redundantie...

Als dit allemaal niet eenvoudig op te vangen is, vind ik dat wel een tegenvallertje bij ZFS...

[Erik1]

Dutch3men schreef op zaterdag 17 maart 2012 @ 21:44:

Maar dan krijg ik een error: cannot open '/dev/sdb/': Not a directory

Als je de laatste slash weglaat bij de disks moet het goed gaan.

[FabiandJ]

Erik1 schreef op zaterdag 17 maart 2012 @ 22:33:
[...]

Als je de laatste slash weglaat bij de disks moet het goed gaan.

Ah dat wat het

Nu wil ik alleen zfs-fuse automatisch laten starten bij het opstarten van OpenSuse maar dan krijg ik een error:
/etc/init.d/zfs-fuse start returned 1 (unspecified error):</pre></p>

Iemand een idee?

Oh en is dit nu goed?

code:

bak:/ # zpool status
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0
            sdg     ONLINE       0     0     0

errors: No known data errors

[ Voor 75% gewijzigd door FabiandJ op 17-03-2012 23:04 ]

[matty___]

HyperBart schreef op zaterdag 17 maart 2012 @ 22:30:
Goed, paar dingen nu al gelezen, nog eens goed het verschil tussen een ZIL en een L2ARC bekijken, maar een ding steekt me nu wel wat tegen: een vdev (waar je dus het redundantiemechanisme definieert...) kan je niet uitbreiden...

Stel nu dat ik besluit om een NAS te bouwen (het begint weer te kriebelen ) met 4x 3TB en ik maak daar dan een vdev van, pool'tje er op en huppa. En ik besluit om op termijn mijn pool uit te willen breiden met nog eens 2 3TB disks, dan moet ik dus oftewel:

• een nieuwe vdev aanmaken met die twee disks, die onder de pool steken
• al mijn data kopiëren, de oude vdev destroyen, en een nieuwe aanmaken met de 2 nieuwe disks er bij

Besluit ik dan later om er weer een disk bij te hangen, dan neem ik daarmee een groot risico want ik heb op die disk dan geen redundantie...

Als dit allemaal niet eenvoudig op te vangen is, vind ik dat wel een tegenvallertje bij ZFS...

klopt dat is ook het grootste probleem wat zfs heeft op dit moment.
zou het opsparen en dan nog een raidz van 4x3tb toevoegen.

als je kijkt voor wat voor machines zfs bedacht is was dat niet zo een probleem.

[Ultraman]

Of met mirrors werken, want die kun je prima uitbreiden met 2 disken per keer.
Striped mirrors is voor de thuisgebruiker het meest flexibel. Je kunt ze namelijk ook online uit elkaar trekken zodat je met de vrijgekomen disken een andere opstelling kan bedenken.
Gerelateerd artikel: http://constantin.glez.de...-why-mirroring-still-best
Hij doet voor zichzelf een kosten/baten analyse, maar er zitten punten in waar ik me in kan vinden.

Andere optie voor je: 3-disk raidz vdevs. Daarmee heb je wat minder ruimteverlies door redundantie en je kunt per 3 uitbreiden, dat is ook nog te overzien.

[ Voor 44% gewijzigd door Ultraman op 18-03-2012 12:15 ]

[Verwijderd]

Dat artikel is niet van toepassing op thuisgebruikers:

We'll assume a random read usage pattern.

Als je al random reads hebt, doe je die van L2ARC; dus dat RAID-Z niet zo goed is eigenlijk gewoon onzin. Overigens zou ik altijd wel RAID-Z2 proberen te krijgen; dat is enorm veilig. Een mirror en raid-z vind ik niet veilig genoeg; dan moet je op een andere manier nog voor veiligheid zorgen; bijvoorbeeld door een full-backup ook op ZFS.

Oh en HyperBart, lees deze en volgende posts eens over ZFS expansion:
Verwijderd in "Het grote DIY RAID NAS topic deel 3"

Binnenkort eens mooi in de topicstart integreren.

[Ultraman]

Ieder zijn voorkeur, die van mij gaat uit naar simpliciteit.
Een ander wil zo veel mogelijk opslagruimte voor zo min mogelijk geld.
Weer iemand anders wil zo min mogelijk kans hebben op dataverlies.
En dan heb je nog het aspect performance over.

Ik denk dat ieder daar zijn/haar balans in vind en daaruit kiest voor een vorm van opslag.
Welke kant dat op gaat hangt af van wat je wilt bereiken, hoeveel geld je er voor over hebt en met welke hardware je moet/gaat werken.

[ Voor 16% gewijzigd door Ultraman op 18-03-2012 13:40 ]

[Verwijderd]

Klopt, maar ik ben een beetje allergisch voor links naar sites die een sterke opinie houden over ZFS met veel aannames. Zo is veel ZFS informatie specifiek voor Solaris-platforms en niet algemeen, terwijl het wel zo wordt verteld alsof het voor alle ZFS implementaties van toepassing is.

Daarnaast, de auteur van dat artikel wil RAID-Z gewoon zwartmaken; hij kiest de meest slechte combinatie die mogelijk is, en gaat dan vergelijken:

To summarize: The 20% price advantage that RAID-Z gives us, doesn't buy us very much:

We get slower read performance,
we get less fault-tolerance (read: A higher probability that we lose data), and
we get less flexibility and more clutter.

More disks in a RAID-Z set mean bigger savings, but performance, fault tolerance and flexibility gets worse the bigger the stripes get.

Laat ik bovenstaande eens in mijn bewoordingen overtypen:

Concluderende kunnen we stellen dat RAID-Z op het gebied van opslagcapaciteit enorm efficiënt is. Een 10-disk RAID-Z2 heeft slechts 20% overhead nodig voor een tweevoudige bescherming, iets wat mirroring niet kan garanderen. Een mirror biedt de bescherming van RAID-Z, met een mogelijkheid tot nog een disk failure; maar dat laatste is gokken in het casino. Je wilt zekerheid daarom draai je redundant.

Dus RAID-Z2 is superieur op vlakken als:

• bescherming voor je data (veel beter dan mirroring)
• lage overhead (20% in bovenstaand voorbeeld versus 50% voor mirroring; terwijl je veel betere bescherming hebt)
• sequential write performance (geen mirror overhead)

Des te meer schijven in een RAID-Z1/2/3 vdev, des te groter de winst op opslagcapaciteit. Het grote nadeel van RAID-Z is dat alle schijven meedoen voor elke I/O actie, dus random reads zijn enorm traag vergeleken met ouderwets RAID5, mirroring of single disk (RAID0). Om dat tegen te gaan, sla je enkel grote bestanden op op RAID-Z, en/of kun je L2ARC caching gebruiken om de RAID-Z IOps te boosten, een SLOG kun je gebruiken voor constante random write performance; koop je een goede SSD zoals Intel 320 dan kun je die voor alle taken (systeem, swap, l2arc, slog) gebruiken. Een kleine SSD kan zo een multi-terabyte array versnellen.

Kortom, voor thuisgebruikers is de RAID-Z familie de meest gebruikelijke keuze. Een groot voordeel van ZFS mirrors is wel dat je per 2 disks kunt uitbreiden. Als dat opweegt dat je bijna twee keer zoveel schijven nodig hebt, kun je prima dat gebruiken. Maar uitbreiden van RAID-Z met meerdere disks is natuurlijk veel goedkoper en logischer. Waarom moet je persé uitbreiden met 1 of 2 disks tegelijk? Je bespaart bij ZFS op zoveel kosten dat je bergen geld overhoudt om gewoon meer schijven per keer te kunnen kopen; daar heb je tenminste wat aan dan alle extra poespas wat duizenden euro's gaat kosten.

[Ultraman]

Verwijderd schreef op zondag 18 maart 2012 @ 13:53:
Laat ik bovenstaande eens in mijn bewoordingen overtypen:

Concluderende kunnen we stellen dat RAID-Z op het gebied van opslagcapaciteit enorm efficiënt is.

Dat is het zeker
Je verliest effectief maar de opslagruimte van 1 disk, waardoor het verlies van ruimte relatief aan het aantal disken is. Meer disken -> meer ruimte. Waar je dan wel weer een parabool bewandeld tussen opslagruimte vs kans-op-dataverlies, naarmate hoeveel disken je in één vdev stopt.

Een 10-disk RAID-Z2 heeft slechts 20% overhead nodig voor een tweevoudige bescherming, iets wat mirroring niet kan garanderen.

Wat je zegt klopt, alleen maak je hier ook een aanname: 10 disken in een thuisserver. Ik heb geen 10 disken in mijn thuisserver zitten en HyperBart sprak over op dit moment ook vier, met plannen om uit te breiden naar zes.

Een mirror biedt de bescherming van RAID-Z, met een mogelijkheid tot nog een disk failure; maar dat laatste is gokken in het casino. Je wilt zekerheid daarom draai je redundant.

Klopt, er kunnen meerdere schijven uitvallen, maar dat moet dan wel de "goede" zijn.
Voor zekerheid is RAID-Z2 koning.

Dus RAID-Z2 is superieur op vlakken als:
[list]
• bescherming voor je data (veel beter dan mirroring)

Naarmate het aantal disks toenemen schuift de kans op dataverlies door dubbele uitval naar elkaar toe.
Voor zekerheid zit je bij RAID-Z2 altijd beter. Maar mirroring is zeker niet dramatisch.
Ik maak niet vaak mee dat een disk er ineens *poef* mee ophoud. Het komt voor, maar vaak is er toch wel enige indicatie: een paar sectoren die checksum errors vertonen, SMART waarden die reallocaties laten zien, mindere performance van een disk.
Zolang je zorgt dat de monitoring in orde is en met waarschuwingen daadwerkelijk iets doet zit je redelijk safe.
Als er bij nu een disk fouten begint te vertonen, zal ik vlot een disk bij kopen, deze in een vrije SATA poort prikken en alvast mirroren met de mirror die een slechte schijf lijkt te hebben. Dan draai ik een three-way-mirror zolang die "slechte" disk nog werkt.

• lage overhead (20% in bovenstaand voorbeeld versus 50% voor mirroring; terwijl je veel betere bescherming hebt)

Deze overhead groeit naarmate het aantal disken in de pool toeneemt.
In een thuis server zitten meestal niet zoveel disken. Nu ga ik een aanname doen: "Ik verwacht dat van alle thuisservers het merendeel behoort tot de categorie 'thuisservers t/m zes disks'.
Moederborden van de afgelopen twee jaar tot nu hebben meestal zes SATA poorten aan boord, daar komt die aanname een beetje vandaan.

Bij vier disken is het verschil in overhead tussen mirroring en RAID-Z2 nul.
Bij zes disken is dit verschil maar 1 disk van de zes: 16.6% verschil in capaciteit
En daarboven neemt het toe.

• sequential write performance (geen mirror overhead)[/list]Een enkele mirror heeft inderdaad dezelfde write performance als een single disk. Striped mirrors gaan, zoals jij ook weet, omhoog in write performance met elke mirror die je aan de pool toevoegt.

Maar is sequential write performance een daadwerkelijk issue?
Voor het merendeel van de thuisgebruikers is de sequential write performance van een single disk voldoende. Vrijwel alle disks vandaan doen prima een average sequential write van 90MB/s, in het begin is zelfs 130MB/s haalbaar. 90MB/s over Gigabit is hartstikke prima en merendeel van de thuisgebruikers gebruikt Gigabit Ethernet voor zover mij bekend is.
Wanneer je netwerkapparatuur sneller is dan Gigabit Ethernet is dit een mogelijk weegpunt. Maar voor de meeste thuisgebruikers is hier (nog) geen sprake van.

Des te meer schijven in een RAID-Z1/2/3 vdev, des te groter de winst op opslagcapaciteit. Het grote nadeel van RAID-Z is dat alle schijven meedoen voor elke I/O actie, dus random reads zijn enorm traag vergeleken met ouderwets RAID5, mirroring of single disk (RAID0).

Om dat tegen te gaan, sla je enkel grote bestanden op op RAID-Z, en/of kun je L2ARC caching gebruiken om de RAID-Z IOps te boosten, een SLOG kun je gebruiken voor constante random write performance; koop je een goede SSD zoals Intel 320 dan kun je die voor alle taken (systeem, swap, l2arc, slog) gebruiken. Een kleine SSD kan zo een multi-terabyte array versnellen.

Dat is een prima oplossing om de mindere random I/O performance van RAID-Z(2) op te vangen.

Maar, misschien heb ik je verkeerd begrepen, maar spreek je hier jezelf niet ietwat tegen?
Jouw vorige reactie over het artikel waar ik naar linkte:

Dat artikel is niet van toepassing op thuisgebruikers:
[...]
Als je al random reads hebt, [...]

Hiermee krijg ik de indruk dat je aangeeft dat thuisgebruikers vrijwel geen random I/O doen.
Waar ik het overigens wel mee eens ben, want als de thuisserver als mediatank wordt gebruikt zal er weinig random I/O plaatsvinden.

In een thuisserver met vier disken win je geen capaciteit om voor RAID-Z2 te gaan. Wel verlaag je de kans op dataverlies bij uitval van twee disken naar nul ipv 33%.
Daar wil je dan een SSD bij kopen, wat kost zo'n ding? Intel 320 40GB of Crucial M4 64GB: 80 euro?
Die kan je in de zak houden als je voor mirroring gaat, want dan hoef je geen random I/O performance te boosten.
Dan krijg je echter wel die 33% kans op dataverlies bij dubbele uitval voor je kiezen.
Als dat je toch niet lekker zit kun je ook het volgende doen: Voor 85 euro kun je een 1.5TB harde schijf kopen, zowel intern of extern. Ga voor extern bijvoorbeeld:
Persoonlijke data, foto's + filmpjes van vakantie/festiviteiten/herinneringen, studie/werk files, muziek collectie, eventuele website/hobbyprojecten, die kun je daar mooi naar kopiëren. Dat is vaak geen terabytes aan data, maar tientallen tot een paar honderd GB.
Dan heb je een extra offline backup mocht er iets met de server gebeuren, of zelfs als je per ongeluk een hoop data verwijdert van een ZFS volume waar je geen snapshot van hebt gemaakt. (tip: automatiseren die snapshots)
Bij dubbele uitval van disken, of verwijder actie of meltdown van de server, met uitvallen van de array/pool tot gevolg, ben je (als ik het vanuit mijn gebruikspatroon bekijk) kwijt:
- gedownloadde films en series; meestal materiaal wat je opnieuw kunt downloaden.
En als je er zeldzaam spul tussen hebt zitten kun je die vaak nog wel naar je externe disk kwijt.

Dat zou mijn oplossing zijn, mijn alternatief tov een L2ARC die ik niet nodig heb.

Natuurlijk als je meer data hebt, bijvoorbeeld als je foto/videografisch werk doet, die echt cruciaal voor je is dan zul je meer moeten investeren in een offline backup. Maar voor het merendeel van de gebruikers is dat hier denk ik best mee af te vangen.

Als ik naar mijzelf kijk, mijn thuisserver is juist waar mijn backups zich bevinden. Het enige wat echt alleen op de server staat zijn films en series die ik ooit gedownload heb en leuk vind om te bewaren.
Natuurlijk probeer ik die te bewaren, anders had ik ze wel op single disk gezet.

Kortom, voor thuisgebruikers is de RAID-Z familie de meest gebruikelijke keuze. Een groot voordeel van ZFS mirrors is wel dat je per 2 disks kunt uitbreiden. Als dat opweegt dat je bijna twee keer zoveel schijven nodig hebt, kun je prima dat gebruiken. Maar uitbreiden van RAID-Z met meerdere disks is natuurlijk veel goedkoper en logischer.

Ik kijk hier dus iets anders tegenaan.
De simpliciteit en flexibiliteit welke mirrors mij geven is wat mijn keuze bepaald. Capaciteitsverlies hoef ik met vier disken geen rekening mee te houden, en bij zes disken is het verlies voor mij acceptabel tov de eerder genoemde flexibiliteit die er tegenover staat.
Wanneer je met meer disken werkt, dan vind ik de RAID-Z familie interessant, want dan gaan voor mij de voordelen opwegen tegen de nadelen. Waar dat omslagpunt ligt is voor ieder anders en ieder heeft daar zo zijn eigen kijk op. Dit hangt af van de eisen die je stelt en wat je er voor over hebt.

Waarom moet je persé uitbreiden met 1 of 2 disks tegelijk? Je bespaart bij ZFS op zoveel kosten dat je bergen geld overhoudt om gewoon meer schijven per keer te kunnen kopen; daar heb je tenminste wat aan dan alle extra poespas wat duizenden euro's gaat kosten.

Ik bespaar met ZFS helemaal niet flink op de kosten. Integendeel, het maakt bij mij volgens mij helemaal geen verschil. Een dure RAID-controller heb ik nooit gehad, en heb ik ook nooit gemist.
Mijn vorige server draaide Linux en daarop maakt ik gebruik van mdadm (software RAID) + LVM (volume manager) + ext4 (filesystem).
ZFS bied mij meer voor evenveel geld. Ik ben er niet minder geld aan kwijt, en ik denk dat deze lijn door te trekken is richting meer thuisserver in de categorie "tot zes disken".

Wie meer disken gebruikt zal voorheen waarschijnlijk wel geinvesteerd hebben in een goede RAID controller en mogelijk zelfs mooie behuizing met hot-swap bays acht,twaalf,zestien disken.
Mijn server zit in een tweedehands Chieftec Dragon, welke ik opgeknapt heb en voorzien van een zelfgebouwde drivebay waarin mijn disken in koord-elastiek hangen. Doel #1: Fluisterstil, en dat is gelukt
Zeer weinig kosten aan gemaakt, want dat was doel #2.

[Verwijderd]

Als je ZFS slechts als een "RAID" systeem ziet -- dan heb je het niet helemaal begrepen.

[FireDrunk]

Onderbouw je post dan ook door meteen uit te leggen wat hij niet ziet

[Pixeltje]

Spullen zijn binnen en ik heb mijn NAS inmiddels draaien. Na alle ellende met de webshop nu ook ellende met m'n mooie nieuwe spulletjes (of eigenlijk, vooral met de spullen die ik nog had).



Is dit einde disk, of valt er nog iets te redden?

Zou goed klote zijn, want van deze vier schijven kwam er één aan als DOA, één is twee maanden terug RMA gegaan wegens reallocated sector count die als een idioot bleef stijgen, en nu zou er dus weer een terug moeten. Het gaat om Seagate Baaracuda 5900 rpm schijven, 2TB/stuk. ST32000542AS .

Heb geen geld om 4 nieuwe schijven te kopen, dus deze seagate's moeten het nog even uithouden..

[ Voor 37% gewijzigd door Pixeltje op 18-03-2012 22:20 ]

[matty___]

Pixeltje schreef op zondag 18 maart 2012 @ 22:18:
Spullen zijn binnen en ik heb mijn NAS inmiddels draaien. Na alle ellende met de webshop nu ook ellende met m'n mooie nieuwe spulletjes (of eigenlijk, vooral met de spullen die ik nog had).

[afbeelding]

Is dit einde disk, of valt er nog iets te redden?

Zou goed klote zijn, want van deze vier schijven kwam er één aan als DOA, één is twee maanden terug RMA gegaan wegens reallocated sector count die als een idioot bleef stijgen, en nu zou er dus weer een terug moeten. Het gaat om Seagate Baaracuda 5900 rpm schijven, 2TB/stuk. ST32000542AS .

Heb geen geld om 4 nieuwe schijven te kopen, dus deze seagate's moeten het nog even uithouden..

zijn de kabels goed. zelfde geldt voor voeding.

[Pixeltje]

Zitten allemaal prima. Het is wat proppen in de kast maar juist daarom heb ik alles goed aangedrukt en nagelopen voor ik de kast sloot..

[Verwijderd]

Check je SMART info voor die schijf en kijk naar UDMA CRC Error Count. Is de raw value hiervan niet 0, dan heb je kabelfouten gehad in het verleden. Blijft deze oplopen, dan zijn je kabels nog steeds defect.

[Pixeltje]

Als dat zo zou zijn en ik vervang de kabels, is het probleem dan ook over?

[matty___]

Pixeltje schreef op zondag 18 maart 2012 @ 22:40:
Als dat zo zou zijn en ik vervang de kabels, is het probleem dan ook over?

ja als het echt aan de kabel lag wel

[Verwijderd]

Het kan ook zijn dat je kabel vlakbij een stroomkabel loopt of dat datakabels te dicht tegen elkaar aan zitten. EMI knaagt aan je signaal en uiteindelijk degradeert het tot het punt dat je CRC fouten gaat ontwikkelen.

Gewoon even je SMART checken en een scrub starten ofzo of een read dd op die specifieke disk. Dan kijken of de UDMA CRC Error Count raw value toeneemt. Zo ja, dan moet je echt wat hardwarematigs veranderen.

[HyperBart]

Pixeltje schreef op zondag 18 maart 2012 @ 22:18:
Zou goed klote zijn, want van deze vier schijven kwam er één aan als DOA, één is twee maanden terug RMA gegaan wegens reallocated sector count die als een idioot bleef stijgen, en nu zou er dus weer een terug moeten. Het gaat om Seagate Baaracuda 5900 rpm schijven, 2TB/stuk. ST32000542AS .

AAAAAAAAAAAAAAAH DIE ROTZAKKEN VAN HDD's WEER!

productreview: Seagate Barracuda LP ST32000542AS, 2TB review door HyperBart

Serieus, de reacties op die review van mij ook... Gadver wat een rotserie is/was dat zeg...

[Verwijderd]

Ultraman schreef op zondag 18 maart 2012 @ 15:32:
Wat je zegt klopt, alleen maak je hier ook een aanname: 10 disken in een thuisserver. Ik heb geen 10 disken in mijn thuisserver zitten en HyperBart sprak over op dit moment ook vier, met plannen om uit te breiden naar zes.

Voor kleine builds zijn je opties ietwat beperkt, je kunt:

• In één keer alles kopen (10 disks RAID-Z2 of 6-disk RAID-Z2)
• Twee vdevs doen in in twee stappen kopen; 6-disk RAID-Z2 nu een tweede 6-disk RAID-Z2 later
• Mirrors doen en per twee schijven uitbreiden

Nog steeds best te doen met aardig wat mogelijkheden, alhoewel het niet kunnen uitbreiden van bestaande RAID-Z natuurlijk wel een nadeel is van ZFS voor thuisgebruikers (niet voor enterprise).

In een thuis server zitten meestal niet zoveel disken. Nu ga ik een aanname doen: "Ik verwacht dat van alle thuisservers het merendeel behoort tot de categorie 'thuisservers t/m zes disks'.

Ik wil wel opmerken dat ZFS vooral voor grote builds erg interessant is, omdat je bij klassieke setups dan steeds sneller/vaker tegen problemen als bad sectors aanloopt. Op HardOCP waar ik ZFSguru heb leren kennen bijvoorbeeld, waren ZFS builds met 40 disks vrij normaal. Nu is dat natuurlijk wel een 'elitair' forum voor perverse storage-freaks maar toch, met veel schijven wordt het pas leuk natuurlijk! Zeker als je met 10 gigabit gaat spelen, wat nu steeds betaalbaarder gaat worden (nieuwe Intel adapter laatst nog op de frontpage).

Probleem hierbij is natuurlijk de hoge prijzen van hardeschijven op dit moment. Als je de mooie Samsung F4EG voor 58 euro kon halen per stuk, was het wel leuk om 10 schijfjes in je NAS te pleuren voor 580 euro, best te doen. Home NAS wordt dus pas echt leuk als de prijzen weer flink gaan zakken, wat mogelijk pas eind dit jaar gaat gebeuren.

Voor zekerheid is RAID-Z2 koning.

Daarom: doen! Waarom is die twee-voudige bescherming zo belangrijk? Omdat je niet meer kunt rekenen op twee dode schijven; het scenario nu is: één dode schijf + een schijf met uBER ofwel een onleesbare sector. Met RAID-Z2 kun je dat opvangen, met een mirror soms en met RAID-Z nooit. Dus zo zie ik het dan ook; RAID-Z2 geeft je de zekerheid die je bestanden eigenlijk verdienen.

De populaire 4K-optimale builds met 6-disks of 10-disks in RAID-Z2 geven je 33% of 20% overhead; beide prima te doen en superieur aan mirroring. Sequential write is ook goed, random writes veel beter op de mirror.

Maar mirroring is zeker niet dramatisch.
Ik maak niet vaak mee dat een disk er ineens *poef* mee ophoud. Het komt voor, maar vaak is er toch wel enige indicatie: een paar sectoren die checksum errors vertonen, SMART waarden die reallocaties laten zien, mindere performance van een disk.

Probleem is dat als je iets merkt van een gefaalde schijf en je gaat rebuilden met een nieuwe schijf, je geconfronteerd kunt worden met silent corruption; corruptie die niet is opgemerkt. Je schijf heeft enorm veel sectoren die lang niet altijd regelmatig worden uitgelezen. Zonder regelmatige scrubs kun je dan tegen dit probleem stuiten.

Ik stel dus voor een andere mentaliteit: ga uit van een paar onleesbare sectoren tijdens de rebuild van een failed disk, hoe zit het dàn met je bescherming?

RAID-Z: disk failure kan betekenen dat sommige bestanden corrupt raken; je pool blijft intact; metadata blijft intact (replicated)
RAID-Z2: één disk failure betekent dat je veel schijven met bad sectors kan hebben maar ZFS ze allemaal corrigeert; tenzij je twee schijven hebt met een bad sector op precies hetzelfde stripe block, wat natuurlijk heel zeldzaam is. Voor twee disk failures geldt hetzelfde als voor RAID-Z
Mirror: iene-miene-mutte casino jackpot tussen RAID-Z en RAID-Z2 in

Ik laat al doorschemeren dat ik de 'mogelijkheid' tot dubbele protectie van mirroring niet zo boeiend vind. Voor mij is dat gewoon enkelvoudige bescherming. Ik ga ook van het ergste; dat je tijdens een rebuild van een echte failed disk bij de overige member disks nog bad sectors tegenkomt. Als je kunt zeggen dat je data dan nog steeds veilig is, dan zit het wel goed met de risico's die je met ZFS kan uitsluiten.

Zolang je zorgt dat de monitoring in orde is en met waarschuwingen daadwerkelijk iets doet zit je redelijk safe.

Je zegt het zelf al: redelijk safe. Het leuke is dat je met coole setups zoals hierboven met 33% tot 20% overhead een 'heel erg safe' gehalte bereikt. En dat is toch net even wat leuker, vooral als je geen full backup van je NAS data hebt, zoals best veel mensen.

Maar is sequential write performance een daadwerkelijk issue?

Vaak wel ja, vooral door de transaction groups van ZFS. Bij slecht getunde setups zag je dan een patroon waarbij je redelijk snel kon schijven, maar de snelheid dan een tijd stillag. Met een dd test lokaal op de server haalde je 150MB/s write; maar niet genoeg om gigabit in de praktijk vol te trekken, wat is daar aan de hand?

Maar niet teveel offtopic, in principe ben je met gigabit al heel snel capped, een 3-disk RAID-Z met rappe schijven zou dat prima moeten kunnen. Dus daarin geef ik je gelijk. Ik wil wel opmerken dat 10 gigabit toch lijkt door te breken, maar daar had ik al iets over gezegd.

Maar, misschien heb ik je verkeerd begrepen, maar spreek je hier jezelf niet ietwat tegen?
Hiermee krijg ik de indruk dat je aangeeft dat thuisgebruikers vrijwel geen random I/O doen.

Ja en nee.

Stel een gebruiker heeft 90% van zijn 10TB NAS in gebruik met grote bestanden; daar heb je geen L2ARC voor nodig. Maar daarnaast heeft hij ook een virtual machine die draait, heeft hij games opgeslagen op de NAS die hij draait en misschien nog wat zaken die nut hebben van L2ARC caching.

Het grote voordeel is dat je alles op je HDD pool kunt plaatsen in zijn eigen filesystem, via de secondarycache aangeeft welk filesystem van de L2ARC gebruik mag maken, en je zo zowel comfort als performance hebt. Comfort omdat het cachen automatisch gaat en ZFS dat verder lekker regelt, en automatisch optimaliseert voor jouw gebruikspatroon (data die je regelmatig opnieuw aanspreekt).

Je kunt voor grote bestanden nog steeds L2ARC gebruiken voor metadata, wat je via de secondarycache parameter ook kunt instellen (all - metadata - none). Het voordeel hiervan is dat het openen van directories sneller gaat, iets wat zeker wel traag kan zijn bij RAID-Z-achtigen.

Heb je echt alleen maar grote bestanden dan wegen de kosten niet op tegen de baten en is L2ARC dus niet voor jou. (hiermee bedoel ik niet jou persoonlijk )

Die kan je in de zak houden als je voor mirroring gaat, want dan hoef je geen random I/O performance te boosten.

Factor 4 hogere random IOps betekent niet dat je opeens met SSDs kunt concurreren; L2ARC wil je zeker ook op je mirroring pool. Je wint wel met random writes; die zijn flink sneller.

Ik bespaar met ZFS helemaal niet flink op de kosten.

Ik doel hiermee op een build (in DIY RAID NAS topic dacht ik) waarin iemand een veels te dure config met Windows wilde draaien, waarbij de RAID controller zonder BBU alleen al net iets onder de 1000 aantikte. Dan nog TLER schijven + BBU en mijn god wat een geldverspilling zou dat zijn geweest - gelukkig is hij voor een andere config gegaan.

Het punt is: met ZFS kun je slim investeren. Normale consumentenschijven, normale HBA controllers. Afgezien van de HDD-prijspiek op dit moment zijn deze twee normaliter geen dure investeringen. Ook veel CPU-kracht heb je niet nodig, en RAM is op dit moment spotgoedkoop (8GiB = 35 euro).

Kortom, je houdt (in theorie) heel veel geld over, geld wat je aan zaken die echt nuttig zijn kunt besteden: meer schijven. Zo kun je dus wat meer schijven per keer kopen zoals ik hierboven al schreef. Deze hele gedachtengang is puur een vergelijking van ZFS met een traditionele NAS setup met Hardware RAID, wat als je het volgens het boekje wilt doen enorm kostbaar is en eigenlijk zinloze geldverspilling voor een thuisserver.

Ik wil hiermee natuurlijk niet tegenspreken dat als voor 'jouw' situatie (derde persoon ) het nuttiger is om per 2 schijven uit te breiden, bijvoorbeeld als je nu in deze tijden van hoge HDD prijzen een nieuwe NAS + schijven wilt kopen, ja dan kan ik mij dat prima voorstellen. Maar RAID-Z en met name RAID-Z2 wil ik toch primair aanraden; wat inderdaad een (groot) nadeel heeft dat je qua aanschaf met schijven niet erg veel flexibiliteit hebt.

[ Voor 198% gewijzigd door Verwijderd op 19-03-2012 01:46 ]

[Pixeltje]

Verwijderd schreef op zondag 18 maart 2012 @ 22:53:

Gewoon even je SMART checken en een scrub starten ofzo of een read dd op die specifieke disk. Dan kijken of de UDMA CRC Error Count raw value toeneemt. Zo ja, dan moet je echt wat hardwarematigs veranderen.

Hoe kan ik de smartstatus van één disk opvragen? (of van allemaal voor that matter) in FreeNAS? Er zit een optie in om SMART scans in te plannen, maar ik kan (ook op internet) niet vinden hoe ik nu, eenmalig, de SMART info van een schijf/de schijven kan opvragen, uitgebreider dan 'zpool status'

HyperBart schreef op maandag 19 maart 2012 @ 00:27:
[...]


AAAAAAAAAAAAAAAH DIE ROTZAKKEN VAN HDD's WEER!

productreview: Seagate Barracuda LP ST32000542AS, 2TB review door HyperBart

Serieus, de reacties op die review van mij ook... Gadver wat een rotserie is/was dat zeg...

Ja hou op.. ik heb deze schijven gekocht samen met mijn vorige NAS. Was tweedehands maar zo goed als nieuw(2 maanden oud ofzo?) De DOA was dus niet bij mij, maar de vorige RMA wel. Zit me nu ook af te vragen of ik wel eenzelfde seagate schijf terug wil, als die dingen elk halfjaar dood neervallen blijf ik bezig. Aan de andere kant; om nu één andere schijf in m'n array te hangen is ook niet echt ideaal.

[Erik1]

Pixeltje schreef op maandag 19 maart 2012 @ 09:33:
Hoe kan ik de smartstatus van één disk opvragen? (of van allemaal voor that matter) in FreeNAS? Er zit een optie in om SMART scans in te plannen, maar ik kan (ook op internet) niet vinden hoe ik nu, eenmalig, de SMART info van een schijf/de schijven kan opvragen, uitgebreider dan 'zpool status'

smartctl -a /dev/[jouwschijf]