Het grote ZFS topic

[FireDrunk]

http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/

TL;DR: Choose a RAID-Z stripe width based on your IOPS needs and the amount of space you are willing to devote to parity information. If you need more IOPS, use fewer disks per stripe. If you need more usable space, use more disks per stripe. Trying to optimize your RAID-Z stripe width based on exact numbers is irrelevant in nearly all cases.

For best reliability, use more parity (e.g. RAIDZ3 instead of RAIDZ1), and architect your groups to match your storage hardware. E.g, if you have 10 shelves of 24 disks each, you could use 24 RAIDZ3 groups, each with 10 disks – one from each shelf. This can tolerate any 3 whole shelves dying (or any 1 whole shelf dying plus any 2 other disks dying).

For best space efficiency, use a large number of disks in each RAID-Z group. Wider stripes never hurts space efficiency. (In certain exceptional cases, use at least 5, 6, or 11 disks (for RAIDZ-1, 2, or 3 respectively) – see below for more details.) When trading off between these concerns, it is useful to know how much it helps to vary the parameters.

[Paul]

Verwijderd schreef op dinsdag 22 juli 2014 @ 10:41:
Je hebt echter geen goede uitlijning i.v.m. 4k sectors.

Waar heb je het over? ashift=12 is al een tijdje standaard? Je hebt geen n^2 aan dataschijven, maar dat boeit (op een paar hele specifieke use cases na) niet zo heel veel.

Cache/ZIL SSD actief op complete pool
Enkele 48TB mountpoint
------------------------------
Cache/ZIL SSD actief op max 1 pool
1 32TB en 1 16TB mountpoint
------------------------------
Enkele 48TB mountpoint
Cache/ZIL SSD actief op complete pool

Wat zie jij als mountpoint? Waarom zou je in optie 2 meerdere pool aanmaken? Je kunt zoveel en zo verschillende vdevs aan één pool hangen als je zelf wilt In optie 1 en optie 3 zijn dat toevallig allemaal dezelfde vdevs, en je moet opletten wat je bij elkaar voegt omdat de hele pool de bescherming van de 'zwakste' vdev heeft, maar er is niks op tegen om twee RAID Z2's van verschillende grootte bij elkaar te plaatsen

[Verwijderd]

Paul schreef op dinsdag 22 juli 2014 @ 11:25:
[...]
Waar heb je het over? ashift=12 is al een tijdje standaard? Je hebt geen n^2 aan dataschijven, maar dat boeit (op een paar hele specifieke use cases na) niet zo heel veel.
[...]
Wat zie jij als mountpoint? Waarom zou je in optie 2 meerdere pool aanmaken? Je kunt zoveel en zo verschillende vdevs aan één pool hangen als je zelf wilt In optie 1 en optie 3 zijn dat toevallig allemaal dezelfde vdevs, en je moet opletten wat je bij elkaar voegt omdat de hele pool de bescherming van de 'zwakste' vdev heeft, maar er is niks op tegen om twee RAID Z2's van verschillende grootte bij elkaar te plaatsen

ashift instellen is geen probleem inderdaad. Maar je zit nog wel met recordsize verdeling. de n^2 zoals je zegt.

Mountpoint bedoel ik eigelijk Zpool mee. Het is geen best-practice om vdevs van verschillende groottes in 1 pool te stoppen.

Natuurlijk is het allemaal mogelijk. Maar ik blijft het liefste zo dicht mogelijk bij de best practices.

Ik neig nog altijd het meeste naar scenario 1.

[FireDrunk]

Als je compressie aan zet is recordsize matchen op je disk stripe size (recordsize / aantal data disks) helemaal niet meer zo belangrijk.

En LZ4 is een haast verwaarloosbare belasting voor je systeem.

[Verwijderd]

Daar heb ik even ingelezen en kom het volgende tegen;

ZFS uses variable-sized blocks of up to 1024 kilobytes. If data compression (LZJB or LZ4) is enabled, variable block sizes are used

Another particular thing to note is that LZ4's performance on incompressible data is very high. It achieves this by incorporating an "early abort" mechanism which will trigger if LZ4 can't meet the expected minimum compression ratio (12.5% on ZFS). This feature is particularly useful to storage administrators who would like to use compression as an "enable and forget about it" feature. Enabling LZ4 across the board only uses compression where appropriate, while making sure that the algorithm won't work hard on incompressible data (e.g. multimedia) and reads don't incur a latency penalty due to transparent decompression.

Betekend dat wanneer mijn data de 12.5% compressie niet haalt, compressie niets doen en recordsize matchen wel uitmaakt?

[FireDrunk]

Lastig te zeggen... Als ik het verhaal goed begrijp denk ik dat je wel gelijk hebt, maar of dat zo kort door de bocht te zeggen is weet ik niet.

Het ligt er ook maar aan of er naast je data ook nog opgeslagen word, dat het daadwerkelijk niet compressbaar was bijvoorbeeld... Dat scheelt ook weer een paar bytes...

Allemaal dingen die in de berekening misschien wel meegenomen moeten worden.

[-Moondust-]

-Moondust- schreef op dinsdag 22 juli 2014 @ 03:22:
Al bijna 3 maanden draait mijn server op ZFSguru redelijk probleemloos, maar vanavond begon ie te haperen. Een aantal torrents stopten met de melding dat de netwerknaam niet meer beschikbaar was. Paar bestande op de server benaderd, krijg zelfde foutmelding in Windows, maar even later weer niet. Toen ik een serie wilde gaan kijken waren de episodes die ik al gezien had gewoon op te starten, maar degene die ik nog niet had gezien gaven een File not found melding in MPC-HC. In Windows waren de bestanden wel zichtbaar. Toen de router herstart. Geen effect. Server herstart. Na enige tijd bliept de server netjes 4 keer ten teken dat alles operationeel is. Netwerkverbinding is echter niet meer actief en de web interface werkt ook niet meer (voor de herstart nog wel). Het IP-adres is wel goed, heb ik gecheckt op de router. Device name = zfsguru, maar mijn twee Windows machines in het netwerk zien helemaal niets. Het enige wat ik kan bereiken op de server is de web interface van het Supermicro moederbord (via KVM). Via remote control zie ik het gebruikelijke blauwe scherm van ZFSguru, maar ik kan dus op geen enkele andere wijze contact krijgen met de server, laat staan dat ik bij mijn bestanden kan.

Iemand enig idee wat hier aan de hand kan zijn?

Voor wie bovenstaand probleem ooit tegenkomt...

Mijn systeempartitie van 4GB was vol. Ik dacht dat 4GB voor systeembestanden van 900MB plus services wel genoeg was, maar dat blijkt dus een vergissing. Ik heb ZFSguru opnieuw geinstalleerd met 16GB voor de systeempartitie en nu geen problemen meer. Eerder ervaren problemen mbt het installeren van services is ook verdwenen. Gnome werkt nu alsmede ook qBittorrent. De problemen daarmee werden dus ook veroorzaakt door gebrek aan ruimte.

[blauwe eend]

Verwijderd schreef op dinsdag 22 juli 2014 @ 03:42:
Wat zie je op de server zelf? Heb je een monitor erop of kun je met IPMI zien wat de monitor weergeeft? Kun je de server pingen?

Je kunt niet bij de web-interface heb ik begrepen; dat is natuurlijk niet goed. Op welk opslagapparaat heb je ZFSguru geïnstalleerd? Kan het zijn dat dit opslagapparaat vol is geraakt? In dat geval kunnen er zich vreemde dingen voordoen.

Je kunt me ook via DM dingen sturen, zoals logs, screenshots e.d. Samen komen we er hopelijk wel uit.

Heb DM gestuurd

[Streamert]

Kan iemand mij misschien uitleggen waarom ik de acl's vanuit mijn Windows client van mijn door Samba gesharede ZFS filesystem niet kan wijzigen, maar op dezelfde server, met tevens een Samba gesharede EXT4 partitie wel?

Debian 7.6 server, geïnstalleerd op een een EXT4 / partitie.
ZFS Pool/share

*Situatie 1 ZFS
Samba/Winbind/etc en alle praat prima via Domain Controllert. De rechten zijn vanuit de shell (chgrp "domain admin /pool/share) probleemloos te wijzigen. Maar dus niet vanuit een Windows client die de share benadert.In de properties van de folder of file zie ik tevens alle juiste acl's.

*Situatie 2 EXT4
Samba/Winbind/etc en alle praat prima via Domain Controllert. De rechten zijn vanuit de shell (chgrp "domain admin /testshare) probleemloos te wijzigen. En dus wel vanuit een Windows client die de share benadert.In de properties van de folder of file zie ik tevens alle juiste acl's.

Moet de ZFS pool nog specifieke opties meekrijgen, hetzij in een zfs set commando, /etc/default/zfs, of in /etc/samba/smb.conf?

[Xudonax]

Welke ZFS on Linux draai je? AFAIK zaten ACLs er pas vanaf v0.6.3 in.

[Streamert]

Even zoeken.

[ Voor 77% gewijzigd door Streamert op 23-07-2014 08:21 ]

[Streamert]

Ik heb de gangbare handleiding (http://zfsonlinux.org/debian.html) gebruikt en weet niet wat de uiteindelijke versie is van ZOL. Is daar achter te komen?

[FireDrunk]

Dpkg -l | grep zfs

Volgens mij Oh wauw, ik had het nog in 1 keer goed ook

root@NAS:~# dpkg -l | grep zfs
ii  dkms                                2.2.0.3-1.1ubuntu5+zfs9~trusty all          Dynamic Kernel Module Support Framework
rc  libzfs1                             0.6.2-2~trusty                 amd64        Native ZFS filesystem library for Linux
ii  libzfs2                             0.6.3-2~trusty                 amd64        Native ZFS filesystem library for Linux
ii  mountall                            2.53-zfs1                      amd64        filesystem mounting tool
ii  ubuntu-zfs                          8~trusty                       amd64        Native ZFS filesystem metapackage for Ubuntu.
ii  zfs-dkms                            0.6.3-2~trusty                 amd64        Native ZFS filesystem kernel modules for Linux
ii  zfsutils                            0.6.3-2~trusty                 amd64        Native ZFS management utilities for Linux

[ Voor 126% gewijzigd door FireDrunk op 23-07-2014 09:31 ]

[Streamert]

Bedankt. Versie 0.6.3.1

Nog even voor de duidelijkheid, ACL werkt wel, maar ik kan deze met een Windows Explorer niet aanpassen, wat daarentegen op een EXT4 partitie op diezelfde server vanaf diezelfde Windows Explorer wel lukt.

Het is mijn laatste hobbel voor een perfecte ZoL oplossing.

[FireDrunk]

Dat ligt meer aan Samba den ik (dat je het niet kan aanpassen). Staat default volgens mij uit.

Voorbeeldje (random van inet):

[share1]
   path = /samba/share1
   nt acl support = yes
   writeable = yes

[ Voor 40% gewijzigd door FireDrunk op 23-07-2014 09:33 ]

[Streamert]

In dat geval had het vanaf de EXT4 partitie, geshared vanaf dezelfde server met dezelfde Samba config ook niet moeten lukken. Toch?

[Streamert]

FireDrunk schreef op woensdag 23 juli 2014 @ 09:33:
Dat ligt meer aan Samba den ik (dat je het niet kan aanpassen). Staat default volgens mij uit.

Voorbeeldje (random van inet):

[share1]
   path = /samba/share1
   nt acl support = yes
   writeable = yes

Precies die settings gebruik ik voor zowel de share op het ZFS FS, als op de EXT4 partitie.

[FireDrunk]

http://fearedbliss.wordpr...ls-on-zfs-on-linux-0-6-3/

Google is je vriend.

[ Voor 13% gewijzigd door FireDrunk op 23-07-2014 09:39 ]

[Streamert]

Ga ik checken. Vinden is ook een kunst.;-)

[Streamert]

Dit lijkt helaas geen oplossing voor deze puzzel. Ik ben echt reuze benieuwd wat hier het probleem is. Het lijkt duidelijk een ZFS issue. Temeer omdat in extact dezelfde configuratie op deze server het simpelweg met een EXT4 partitie gewoonweg wel werkt.
En het gekke is ook dat ik in de Security tab van Windows Explorer bij het opvragen van share op EXT4 er CREATOR OWNER en CREATOR GROUP erbij krijg, hetgeen op de share op ZFS niet zichtbaar is.

[FireDrunk]

Server rebooten?

[Streamert]

FireDrunk schreef op woensdag 23 juli 2014 @ 10:22:
Server rebooten?

Hoe veel keer?

[FireDrunk]

Ik denk 120x ofzo...

[blauwe eend]

Ik zit nog steeds met een GPT format probleem en zou graag geholpen worden. Ben nog maar een paar dagen thuis...

probleem:
Error: Unable to GPT format the disk "ada2" (bij alle vier de hdd's die hiervoor in raid5 op een raidkaart hebben gezeten.)

[zzattack]

code:

dd if=/dev/zero of=/dev/ada2 bs=1M count=1

Al geprobeerd? Daarna gewoon gpart create gebruiken.

[Paul]

"dd if=/dev/zero of=/dev/ada2 bs=1M count=1" al geprobeerd?

Edit: GMTA

[ Voor 12% gewijzigd door Paul op 23-07-2014 10:50 ]

[blauwe eend]

zzattack schreef op woensdag 23 juli 2014 @ 10:49:

code:

dd if=/dev/zero of=/dev/ada2 bs=1M count=1

Al geprobeerd? Daarna gewoon gpart create gebruiken.

Ja al geprobeerd, er komt dan te staan: opperation not permitted

[Paul]

En als je als root inlogt of het via sudo probeert?

[FireDrunk]

su -?

[zzattack]

Hrm, lijkt erop dat FreeBSD om mij ombekende reden je niet met de schijf wil laten kloten. Kun je de schijven niet even overhangen, of een livecd van ubuntu ofzo starten en het daarmee wissen?

[Bigs]

Ik ben momenteel 4TB schijven aan het uitzoeken voor een nieuwe ZFS setup. Ik kan daarbij kiezen tussen twee formaten; 512b emulatie en 4Kb native. Uiteraard ga ik het liefst voor de laatste, maar werkt dit in alle gevallen goed in de laatste FreeBSD versies op een recent en dit moederbord? Ik ga niet booten van de pool.

Het zou wel fijn zijn om me daar geen zorgen meer over te hoeven maken namelijk

[edit]
Nevermind, ik zie nu dat ik de tool op de Seagate site niet goed interpreteerde. Alleen de 6TB schijf is in 4k format te krijgen namelijk. Desondanks ben ik wel benieuwd of iemand al ervaring heeft met dit soort schijven.

[ Voor 26% gewijzigd door Bigs op 23-07-2014 11:38 ]

[FireDrunk]

Zijn er al schijven die echt 4K sectoren publiceren dan? Ik dacht dat vooralsnog alle schijven dat emuleerden?

[Bigs]

FireDrunk schreef op woensdag 23 juli 2014 @ 11:39:
Zijn er al schijven die echt 4K sectoren publiceren dan? Ik dacht dat vooralsnog alle schijven dat emuleerden?

Als ik die link hierboven bekijk dan kun je bij de 6TB enterprise schijven van Seagate kiezen tussen '4KN' en '512E' formaat. Ik ga er vanuit dat die eerste dus 4K sectoren publiceert.

Het valt me nu op dat de 4TB schijven uit diezelfde serie nog gewon 512 native zijn. Ik heb die schijven nu in een ZFS pool zitten en daar helemaal met gnop etc behandeld als 4k schijven

[zzattack]

FireDrunk schreef op woensdag 23 juli 2014 @ 11:39:
Zijn er al schijven die echt 4K sectoren publiceren dan? Ik dacht dat vooralsnog alle schijven dat emuleerden?

Andersom toch meer? Veel 2TB schijven (Hitachi uitgezonderd) emuleerden 512b sectors terwijl ze fysiek 4k sectors hadden, voor compatibility.
Edit: nevermind dat, we zeggen hetzelfde.

Inmiddels doen de meeste schijven deze emulatie standaard niet meer, vziw.

[ Voor 7% gewijzigd door zzattack op 23-07-2014 11:54 ]

[blauwe eend]

Paul schreef op woensdag 23 juli 2014 @ 11:14:
En als je als root inlogt of het via sudo probeert?

Ik snap niet helemaal wat je bedoelt, ik typ dit in op de pc zelf en dan onder het kopje 'shell' in freenas. Ik kan het ook via de browser doen (in shell) op een andere pc, maar dan typ ik het commando, druk op enter en dan gebeurt er niks. Lijkt wel of hij het commando dan niet aan kan ofzo .

Maar ik heb dus even ubuntu gedownload en kijk of ik ze via daar dan even kan wissen ofzo. Het maakt me niet uit of ik ze er uit moet halen of iets dergelijks, maar gewoon dat ze maar werken

Edit: euhh noob vraag, maar moet ik een of andere plugin downloaden in ubuntu om de hdd's te kunnen zien en te wissen??? (ubuntu 12.04 64b)

[ Voor 10% gewijzigd door blauwe eend op 23-07-2014 17:42 ]

[Ultraman]

Dat dd geen output geeft is normaal en vrij standaard UNIX gedrag, output krijg je pas zodra het commando is uitgevoerd en klaar is of tegen een probleem aan loopt. Het commando wordt dus weldegelijk uitgevoerd, gewoon laten lopen. Kijk maar eens naar je HD led op zo'n moment. ;-)
Je kunt wel om output vragen. Dat kan onder linux volgens door het commando en USR1 of HUP commando te sturen. Onder FreeBSD kan het ook met een toetsaanslag. Ben even vergeten welke dan is. Deze staat van beschreven in de manpage van dd: man dd. Sluiten door op q te drukken.

[ Voor 16% gewijzigd door Ultraman op 23-07-2014 17:45 ]

[Paul]

Alleen schrijft het één blok van 1 MB weg, dat is zo gedaan. Ik zou dus verwachten dat je die statistieken te zien krijgt (want daar sluit dd afaik mee af als het klaar is) in plaats van helemaal niets...

[Ultraman]

True dat. Op mijn telefoon even niet die count vlag gespot.

[blauwe eend]

Het lukt nog niet echt met dat ubuntu... Iemand nog een ander idee?

[FireDrunk]

Wat probeer je precies onder Ubuntu? Want als het daar niet lukt, zijn je schijven simpelweg kapot (maar dat verwacht ik niet )

[blauwe eend]

FireDrunk schreef op woensdag 23 juli 2014 @ 18:19:
Wat probeer je precies onder Ubuntu? Want als het daar niet lukt, zijn je schijven simpelweg kapot (maar dat verwacht ik niet )

Ik kan niet vinden waar de schijven staan onder ubuntu _{(ik voel me nu best wel een noob)}

[FireDrunk]

Als er geen filesystem op de schijven aanwezig is, krijgen de schijven /dev/sd[letter]

En op volgorde van detectie, /dev/sda is niet altijd je bootschijf (zoals C: wel altijd je bootschijf is bij Windows).

[blauwe eend]

FireDrunk schreef op woensdag 23 juli 2014 @ 18:25:
Als er geen filesystem op de schijven aanwezig is, krijgen de schijven /dev/sd[letter]

En op volgorde van detectie, /dev/sda is niet altijd je bootschijf (zoals C: wel altijd je bootschijf is bij Windows).

Dacht dat het eindelijk zou lukken met Gpart... in ubuntu, maar als ik er een partitie van wil maken geeft hij een error en ik kan dus ook in ubuntu geen partitie maken op een van de hdd's

[FireDrunk]

Type eens letterlijk over wat je doet en wat je resultaten zijn, want voor ons is dit ook koffiedik kijken...

[blauwe eend]

FireDrunk schreef op woensdag 23 juli 2014 @ 19:05:
Type eens letterlijk over wat je doet en wat je resultaten zijn, want voor ons is dit ook koffiedik kijken...

Ik zal het even zo duidelijk mogelijk proberen op te sommen. Laten we beginnen met het proberen van een raid array te maken op de freenas webinterface:
Tabje: storage >> ZFS volume manager >> naam= test, available disks =4x3TB (de andere 2 heb ik even losgekoppeld want die deden het). >> Selecteer de 4 disks, en maak (bv.) een mirror aan. >> ik druk op add volume.
Heel even komt er een laad balkje en daarna is er niks gebeurt. Geen nieuwe dingen niks niet. Wel komt er bovenaan deze error te staan: Error: Unable to GPT format the disk "ada0"

Dus nu het probleem oplossen...

Dan probeer ik het volgende in de webinterface onder het tabje: "shell" >> Eerst kwam er na 30 sec nog niks na het onderstaande command te hebben ingevoerd, maar nu werkt het blijkbaar wel . Misschien heeft ubuntu geholpen>zie uitleg later.

[root@freenas ~]# dd if=/dev/zero of=/dev/ada0 bs=1m count=1
dd: /dev/ada0: Operation not permitted
[root@freenas ~]# sysctl kern.geom.debugflags=0x10
kern.geom.debugflags: 0 -> 16
[root@freenas ~]# dd if=/dev/zero of=/dev/ada0 bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.004229 secs (247958872 bytes/sec)
[root@freenas ~]# dd if=/dev/zero of=/dev/ada1 bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.004266 secs (245810782 bytes/sec)
[root@freenas ~]#

Nu probeer ik een stripe volume te maken met ada0 en ada1:

ZFS volume manager >> naam: test, select ada0 en ada1, stripe. >> add volume... Er kwam een laad balkje welke best wel even bleef staan wat een stuk normaler is...
en wonder boven wonder werkt het!!! Hoe dan, ik heb dit al eerder gedaan, alleen dan via de pc zelf....

Nou ik dus even verder proberen... ... ...

[root@freenas ~]# dd if=/dev/zero of=/dev/ada2 bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.011112 secs (94364506 bytes/sec)
[root@freenas ~]# dd if=/dev/zero of=/dev/ada3 bs=1m count=1
1+0 records in
1+0 records out
1048576 bytes transferred in 0.003949 secs (265534415 bytes/sec)
[root@freenas ~]#


En ja hoor, het werkt!!! Heb nu stripe van alle vier de disks . Misschien heeft dat ubuntu toch nog wat gedaan, want eerst werkte dit gewoon niet. Bij ubuntu gebruikte ik "Gparted Partition Editor". Bij de vier disks, /dev/sda(tot en met 'd') stond er een uitroepteken achter 'unallocated' bij het kolommetje Partition. Dit heb ik weg gekregen door 'create partition table' te gebruiken onder het kopje 'Device'. Hierdoor verdween het uitroepteken.

Waarschijnlijk heeft dit dus geholpen denk ik . Nu nog even mn andere twee hdd's aansluiten, maar ik ga er al vanuit dat het zal werken.

Bedankt voor de hulp, heb er zeker wat aan gehad.

[FireDrunk]

Mooi zo! Goed om te horen dat het nu werkt.

Ik zou overigens niet een RAID0 array maken... Lijkt me onverstandig

[Streamert]

FireDrunk schreef op woensdag 23 juli 2014 @ 09:39:
http://fearedbliss.wordpr...ls-on-zfs-on-linux-0-6-3/

Google is je vriend.

Streamert schreef op woensdag 23 juli 2014 @ 01:13:
Kan iemand mij misschien uitleggen waarom ik de acl's vanuit mijn Windows client van mijn door Samba gesharede ZFS filesystem niet kan wijzigen, maar op dezelfde server, met tevens een Samba gesharede EXT4 partitie wel?

Debian 7.6 server, geïnstalleerd op een een EXT4 / partitie.
ZFS Pool/share

*Situatie 1 ZFS
Samba/Winbind/etc en alle praat prima via Domain Controllert. De rechten zijn vanuit de shell (chgrp "domain admin /pool/share) probleemloos te wijzigen. Maar dus niet vanuit een Windows client die de share benadert.In de properties van de folder of file zie ik tevens alle juiste acl's.

*Situatie 2 EXT4
Samba/Winbind/etc en alle praat prima via Domain Controllert. De rechten zijn vanuit de shell (chgrp "domain admin /testshare) probleemloos te wijzigen. En dus wel vanuit een Windows client die de share benadert.In de properties van de folder of file zie ik tevens alle juiste acl's.

Moet de ZFS pool nog specifieke opties meekrijgen, hetzij in een zfs set commando, /etc/default/zfs, of in /etc/samba/smb.conf?

Yes Yes Yes!!! Het probleem is opgelost Bedankt voor de tip FireDrunk

Korte beschrijving van de oplossing.

ZFS ZoL vanaf v0.6.3
Zet op het betreffende file system:

zfs set acltype=posixacl pool/fs

en unmount/mount je fs

zfs unmount pool/fs
zfs mount pool/fs

Samba (in dit geval Debian 7.6 met Samba 3.6.6)
In het bestand /etc/samba/smb.conf

[Share naam]
vfs objects = acl_xatt

Herstart Samba

service samba restart

Pas de rechten aan op het betreffende fs.

chown -R "ADuser:ADgroup" /pool/fs

Hopelijk heeft iemand hier iets aan. Het heeft mij in ieder geval aardig wat tijd gekost om tot de bovenstaande conclusie te komen.

[ Voor 1% gewijzigd door Streamert op 24-07-2014 12:28 . Reden: Opmaak ]

[FireDrunk]

Mooi, kan ik het direct toepassen binnenkort
Thanks voor het terugkoppelen!

[]Byte[]

... modus

FireDrunk schreef op donderdag 24 juli 2014 @ 12:15:
Mooi, kan ik het direct toepassen binnenkort

lol

[ Voor 3% gewijzigd door ]Byte[ op 24-07-2014 12:49 ]

[FireDrunk]

Direct als in, zonder nog wijzigingen door te voren

Betere term was 1-op-1 overnemen

[iMick]

Excuus, als dit niet de juiste plek is voor problemen met ZFS, maar dit leek me de beste plek omdat hier de mensen met de meeste kennis zitten. Een bevriend software ontwikkelaar (uit Zuid Korea) heeft namelijk vrij grote problemen met zijn ZFS configuratie, waardoor hij data van ongeveer 5 jaar kan kwijtraken. En dat zou zeer zonde zijn, ook aangezien hij hier zijn open source projecten op heeft staan. (http://myhack.sojugarden.com)

Het begon dat zijn beide schijven van de server kapot gingen. De backup stond op zijn werkstation, waarvandaan hij de data dus weer terug wilde kopiëren. Alleen na een reboot kwam er een ZFS error (kernel panic), waarbij hij een hard shutdown moest doen. Sindsdien wilt hij niet meer booten en krijgt hij elke keer een kernel panic in OS X, waardoor hij niet de status van de schijven kan zien. Als er 1 schijf wordt verwijderd, dan krijgt hij de optie 'destroy and rebuild', maar dat leek hem niet de juiste optie..

Dit is zijn configuratie, zoals hij hem beschreef:
4x 1TB drives in raidz1 on osx
openzfs version is osx.zfs-signed-20140627

Hij zit er vooral mee dat hij niet kan zien of het een OS fout is, of dat er iets goed mis is met de ZFS pool. Zou het een idee zijn om de schijven in een computer met een (speciaal?) Linux OS te hangen, om toch de data terug te halen?

Waarschijnlijk is er nog veel meer informatie nodig om een goed antwoord te geven, maar dan hoor ik dat graag. Ik moet eerlijk bekennen dat ik vrij weinig weet over ZFS.

[Verwijderd]

OSX is niet stabiel; dus 'WTF' gaat hij niet naar een stabiele ZFS implementatie op basis van het BSD platform? Gelijk een BSD platform booten, bijvoorbeeld ZFSguru, en daarin met ZFS verder werken. Hij heeft zijn data ernstig in gevaar gebracht door een OSX implementatie te gebruiken, zeker in problemen.

Als in BSD tot op de dag van vandaag (vorige week nog) ZFS dataloss bugs worden gepatched, kun je nagaan hoe andere platforms eraan toe zijn die véél minder review hebben gekregen, veel minder users hebben, en vooral in zeldzame situaties heel obscure bugs kunnen hebben.

Dus een flinke pets voor de billen en ZSM zijn schijven veilig stellen onder een betrouwbaar OS voor ZFS. In mijn optiek is dat eigenlijk alleen BSD.

Bovendien... als je in een noodsituatie met belangrijke data gaat prutsen, maak je eerst een ruwe 1:1 kopie en ga je niet met live disks zitten klooien. 'DUH' zou ik bijna zeggen!

[iMick]

Bedankt CIPHER! Ik zie dat hij zijn data toch heeft kunnen veiligstellen, door het aan een schone OS X installatie te hangen. Heb je advies in ieder geval doorgegeven. Gelukkig beseft hij nu wel dat dit niet stabiel genoeg is en dat een aparte backup eigenlijk ook wel handig is...

Ik vond het ook vreemd dat hij voor ZFS koos in combinatie met OS X ... Lijkt mij vragen om problemen. Wist niet eens dat het ondersteund werd.

[Verwijderd]

Apple had ZFS versie 9 in OSX, maar heeft het eruit gesloopt nadat Oracle zijn klauwen in Sun heeft gestoken. OpenZFS voor OSX ken ik niet goed, maar zeker bij problemen moet je onmiddelijk naar een andere implementatie.

Weet wel dat HFS - het 'normale' filesystem voor OSX - niets meer is dan NTFS en andere legacy meuk; dus geen enkele bescherming. Geen correctie en geen detectie.

Dus ik kan zeker begrijpen dat hij ZFS gebruikt; je wilt in elk geval WETEN als er corruptie is. Maar backups maken zeker als je een minder veilige implementatie gebruikt is toch zeker wel verplicht. Zeker als hij zijn open source projecten erop opslaat; je zal maar de hele toko kwijt zijn zeg! Maanden zo niet jaren werk naar de knoppen dat moet je niet willen....

[blauwe eend]

FireDrunk schreef op donderdag 24 juli 2014 @ 08:25:
Mooi zo! Goed om te horen dat het nu werkt.

Ik zou overigens niet een RAID0 array maken... Lijkt me onverstandig

haha nee nee, ik ga voor de RaidZ2

[]Byte[]

Ik heb even een vraagje:

Ik haal veel hogere snelheden zonder zil/slog dan met...

Met:
nas: ~ # dd if=/dev/zero of=/hdd_pool1/test.dd bs=4M count=10000
10000+0 records in
10000+0 records out
41943040000 bytes transferred in 61.928955 secs (677276730 bytes/sec)


Zonder:
nas: ~ # dd if=/dev/zero of=/hdd_pool1/test.dd bs=4M count=10000
10000+0 records in
10000+0 records out
41943040000 bytes transferred in 55.162146 secs (760359104 bytes/sec)

Ik zou verwachten dat dit juist gelijk zou 'moeten' zijn, maar hier hebben we het over een verschil van bijna 100 MB/s.
Iemand een idee waarom/waardoor dit komt?

[GioStyle]

Ik neem aan dat je zil/slog nog leeg is? Misschien dat het daardoor komt?

[Bigs]

dd gebruikt geen O_SYNC, dus de ZIL wordt volgens mij niet gebruikt (check met zpool iostat) dus als je systeem verder idle is zou dat geen verschil moeten maken. Zijn dit je enige twee samples? Want het verschil kan ook ergens anders door zijn veroorzaakt.

[Compizfox]

GioStyle schreef op vrijdag 25 juli 2014 @ 17:05:
Ik neem aan dat je zil/slog nog leeg is? Misschien dat het daardoor komt?

Hoe bedoel je leeg? Verwar je het nu niet met L2ARC?

[]Byte[]

Bigs schreef op vrijdag 25 juli 2014 @ 21:12:
dd gebruikt geen O_SYNC, dus de ZIL wordt volgens mij niet gebruikt (check met zpool iostat) dus als je systeem verder idle is zou dat geen verschil moeten maken. Zijn dit je enige twee samples? Want het verschil kan ook ergens anders door zijn veroorzaakt.

Ik heb de testen diverse malen herhaald en dit zijn de gemiddelden.
M'n hdd-pool had soms uitschieters naar even boven de 1 GB/s, maar nogmaals: de sample die ik gegeven heb is een gemiddelde van alle metingen (ca. 10-12 stuks)
Verder draait er niets op het systeem. (ook geen iSCSI/NFS/...)

[GioStyle]

Compizfox schreef op zaterdag 26 juli 2014 @ 10:45:
[...]

Hoe bedoel je leeg? Verwar je het nu niet met L2ARC?

Ja, daar ben ik mee in de war. Voor de rest zou ik echt niet weten waar het aan zou kunnen liggen.

[Q]

Ik zou zelf gewoon het ZIL/SLOG uitzetten voor thuis gebruik. Nergens voor nodig als je geen productie draait. Tenzij het een proeftuin is voor productie.

[ Voor 16% gewijzigd door Q op 27-07-2014 10:25 ]

[Q]

Gaaf

http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/

2^N+P (P = aantal parity disks) lijkt niet te gelden voor storage capaciteitsverlies als je grote files weg schrijft.
Dat was iets wat ik niet goed had begrepen.

Dat zou betekenen dat een grote 24 disk RAIDZ3 voor mij ideaal zou zijn.

[Verwijderd]

Q schreef op zondag 27 juli 2014 @ 10:24:
Ik zou zelf gewoon het ZIL/SLOG uitzetten voor thuis gebruik. Nergens voor nodig als je geen productie draait. Tenzij het een proeftuin is voor productie.

Mja.. dat is wel kort door de bocht. Sync writes gebeuren niet alleen door applicaties; ook door ZFS zelf.

Overigens is er zojuist wel een belangrijke commit in BSD op dit vlak:

MFC r268420:
Remove IO_SYNC flag when writing extended file attributes on ZFS.

While it is possible to create and write file, modify its permissions, etc.
without ever doing sync, it looks odd that it is required for setting
extended file attributes on ZFS. UFS does not do sync there too.

Samba uses those extended attributes to store some its data, and doing it
synchronously by many times reduces file creation performance for systems
without SLOG device.

[Q]

Verwijderd schreef op zondag 27 juli 2014 @ 21:59:
[...]

Mja.. dat is wel kort door de bocht. Sync writes gebeuren niet alleen door applicaties; ook door ZFS zelf.

Wat maakt dat voor thuis gebruik uit? Voor thuis is die BSD update helemaal mooi.

[ Voor 7% gewijzigd door Q op 27-07-2014 22:18 ]

[Verwijderd]

Dat thuisgebruikers graag hoge getallen zien (waarom anders geilen ze zo op SSD benchmarks?!). Technisch gezien maakt het inderdaad niet veel uit in de meeste gevallen. Maar bij veel HDDs in RAID-Z-families kan het gebrek aan sLOG in bepaalde situaties wel een bottleneck vormen. Voor een simpele 6-disk RAID-Z2 met gigabit is dat inderdaad hoogst uitzonderlijk.

Ik heb ook geen exacte benchmarks, maar wel situaties van triple RAID-Z2 vdev pools waarbij het uitschakelen van sync writes wel degelijk voor performanceverbetering zorgt. Het zou best fijn zijn als daar wat benchmarks/tests voor gedaan kunnen worden; maar je krijgt dan al snel dat de uitkomst daarvan als universele waarheid wordt gebruikt, terwijl ik juist heb geleerd dat situaties per geval sterk kunnen verschillen.

[Q]

Raar, maar het is allemaal soms best complex en niet altijd voorspelbaar / intuïtief.


http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/

A misunderstanding of this overhead, has caused some people to recommend using “(2^n)+p” disks, where p is the number of parity “disks” (i.e. 2 for RAIDZ-2), and n is an integer. These people would claim that for example, a 9-wide (2^3+1) RAIDZ1 is better than 8-wide or 10-wide. This is not generally true. The primary flaw with this recommendation is that it assumes that you are using small blocks whose size is a power of 2. While some workloads (e.g. databases) do use 4KB or 8KB logical block sizes (i.e. recordsize=4K or 8K), these workloads benefit greatly from compression.

[ Voor 80% gewijzigd door Q op 27-07-2014 22:49 ]

[Verwijderd]

Ik begrijp het ook niet helemaal, er zijn ook heel veel factoren. Niet alleen de setup zelf maar dus ook welke ZFS versie, welk OS en welke patches er gebruikt worden. Zoals nu dus de commit van BSD naar 10-STABLE, die in 10.1 terecht zal komen.

Beste advies is denk ik per situatie testen en als je ontevreden bent over performance proberen dingen uit te sluiten. Zoals sync writes en flush buffer requests negeren; maakt dat veel verschil qua performance dan is dat reden genoeg om hier verder in te duiken. Maakt het niets/nihil verschil dan kun je verder zoeken naar de oorzaak.

Dat gezegd, ik ben niet ontevreden over ZFS performance. Maar zodra ik sneller dan gigabit ethernet heb, zal de discussie over ZFS performance denk ik weer actueel worden. Zelf kijk ik uit naar Thunderbolt 10Gbps ethernet; wat goedkoop en goed beschikbaar zou moeten worden; alleen wel host-to-host en niet switched. Maar prima voor thuis zou ik zeggen.

En over je verhaal over stripe width: interessant! Echter, ik denk dat dit wel betekent dat je bij gebruik van ZVOLs de blocksize veel hoger moet instellen dan 8KiB - de default. Misschien een idee om hier wat testjes voor te doen - niet alleen performance maar ook wat betreft diskspace - en daarna de startpost aan te passen.

[ Voor 14% gewijzigd door Verwijderd op 27-07-2014 22:52 ]

[Q]

ZFS sequentiele performance is meer dan uitstekend. Ik haal nu 2.3 GB/s reads en 1.5 GB/s writes op een 24 disk RAIDZ3. Thunderbolt of 10Gbit ethernet zou niet genoeg zijn

[Verwijderd]

Nouja als je meerdere Thunderbolts gaat trunken kan het Tweakers-hartje toch aardig sneller gaan kloppen. :~9

De link die je gaf over stripe width lijkt mijn verhaal over ZVOL blocksize te bevestigen. Eigenlijk zegt hij: gebruik LZ4-compressie. Maar ook dan doet hij de aanname dat je geen ashift=12 gebruikt; althans die indruk krijg ik ik moet zijn verhaal nog verder doorlezen. Want als door de ashift=12 alsnog alles op 4KiB-boundaries wordt afgerond dan zit je volgens mij met exact het probleem van space efficiency waar zo vaak over gesproken wordt.

[]Byte[]

Verwijderd schreef op zondag 27 juli 2014 @ 22:49:
Beste advies is denk ik per situatie testen en als je ontevreden bent over performance proberen dingen uit te sluiten.
[...]

"Ontevreden" is een groot woord.
Maar het verwijderen van de zil/slog van de hdd_pool en vervolgens een 100 MB/s meer writes halen doet bij mij de wenkbrauwen fronsen...
Juist omdat het dezelfde install is op dezelfde hardware met dezelfde Z2-config (10 disks)
De 24-disk config van Q zit er voor mij nog even niet in.

@Q
Je kan 40 Gb IB overwegen...

[Verwijderd]

Dat lijkt me bijna onmogelijk ]Byte[ - waarschijnlijk heb je dan sync=always ingesteld, of je hebt appliation workloads waar 100% van de writes sync writes zijn, zoals bij ESXi. Dan is het logisch dat een enkele SSD de datarate niet kan bijhouden.

[]Byte[]

Workloads zijn 0,0 draait verder niets op die doos.
Mijn iSCSI draait nog op mijn QNAP's tbv ESX.
Maar ik zal eens ff kijken naar de sync=always.
Tnx voor de tip.

[Verwijderd]

sync=always is juist wat je niet wilt hebben. sync=standard is normaal. sync=disabled betekent dat er helemaal geen application sync writes meer als sync worden behandeld.

Gebruik je nou iSCSI en/of ESXi op de server waar je zónder sLOG meer performance haalde dan zonder? Dat is me nog niet duidelijk.

[Q]

Zie hier de impact van ashift=9 vs ashift=12 op 4K drives qua storage gebruik met een RAIDZ3.

code:

root@nano:/# zpool create storage -o ashift=9 raidz3 /dev/sd[abcdefghijklmnopqrstuvwx]
storage                                                  74T  128K   74T   1% /storage
root@nano:/# zpool create storage -o ashift=12 raidz3 /dev/sd[abcdefghijklmnopqrstuvwx]
storage                                                  69T  512K   69T   1% /storage

Kost GVD gewoon 5TB, dus meer dan een hele drive?

Performance is nog steeds 1GB/s schrijven, 2,2 GB/s lezen. Dus dat zit wel snor.

[Verwijderd]

De vraag is of dat ook echt zo is als je voornamelijk grote bestanden opslaat. Een mogelijkheid is namelijk dat ZFS de free space 'conservatief' berekent, alsof je allemaal kleine files zou opslaan. Zou je je pool helemaal volschrijven met één groot bestand, dan zou het kunnen zijn dat je vrijwel geen ruimte verliest. Pure speculatie, overigens.

[Q]

Kan mogelijk ook iets met alignment zijn, RAIDZ2 shift 9 vs 12 geeft maar 1 TB verschil.

Ik had even ZFS geformatteerd op een MDADM raid array, maar dat geeft 2 TB minder capaciteit als BTRFS of als XFS, op papier dan.

[ Voor 43% gewijzigd door Q op 28-07-2014 03:15 ]

[]Byte[]

Verwijderd schreef op zondag 27 juli 2014 @ 23:46:
sync=always is juist wat je niet wilt hebben. sync=standard is normaal. sync=disabled betekent dat er helemaal geen application sync writes meer als sync worden behandeld.

Gebruik je nou iSCSI en/of ESXi op de server waar je zónder sLOG meer performance haalde dan zonder? Dat is me nog niet duidelijk.

sync=standard is de setting.
De test die ik heb gedaan was op 'bare-metal' van de ZFS-doos zelf zonder dat er verdere load is op de machine of shares die in gebruik zijn.
Zonder de slog haalde ik dus zo'n 100 MB/s meer aan writes dan met slog op mijn hdd-pool (10 * 4 TB met Z2).

[CurlyMo]

Afgelopen dagen een beetje lopen klooien met een Raspberry Pi met als doel om als offsite backup te fungeren.

Snelheden zijn best ok.

code:

root@xbian:~# rsync --progress /mnt/curlymo/ZFS/xbian-source-imx6.tar.gz /offsite/xbian-source-imx6.tar.gz
xbian-source-imx6.tar.gz
   368534820 100%    1.79MB/s    0:03:16 (xfer#1, to-check=0/1)

sent 368579893 bytes  received 31 bytes  1856825.81 bytes/sec
total size is 368534820  speedup is 1.00
root@xbian:~# rsync --progress /offsite/xbian-source-imx6.tar.gz /root/xbian-source-imx6.tar.gz
xbian-source-imx6.tar.gz
   368534820 100%    5.31MB/s    0:01:06 (xfer#1, to-check=0/1)

sent 368579893 bytes  received 31 bytes  4947381.53 bytes/sec
total size is 368534820  speedup is 1.00
root@xbian:~# rsync --progress /root/xbian-source-imx6.tar.gz /offsite/xbian-source-imx6.tar.gz
xbian-source-imx6.tar.gz
   368534820 100%  912.30kB/s    0:06:34 (xfer#1, to-check=0/1)

sent 368579893 bytes  received 31 bytes  931934.07 bytes/sec
total size is 368534820  speedup is 1.00
root@xbian:~# rsync --progress /mnt/curlymo/ZFS/xbian-source-imx6.tar.gz /root/xbian-source-imx6.tar.gz
xbian-source-imx6.tar.gz
   368534820 100%    2.06MB/s    0:02:50 (xfer#1, to-check=0/1)

sent 368579893 bytes  received 31 bytes  2100170.51 bytes/sec
total size is 368534820  speedup is 1.00

De root is hier een BTRFS partitie

Tuning:

code:

vmalloc=256M

Toevoegen aan de cmdline.txt

code:

gpu_mem_512=32

In de config.txt zetten.

In /etc/modprobe.d/zfs.conf:

code:

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

Ik denk dat ik hem zelf bij de buurman neerleg zodat ik via WIFI een redelijke offsite backup heb. Mijn upload is jammer genoeg niet meer dan 100kb.

Root is een class 10 SD kaart. Offsite is een Sandisk Cruzer Fit SD kaart. mnt is een samba share.

[ Voor 3% gewijzigd door CurlyMo op 30-07-2014 17:43 ]

[FireDrunk]

Geen NFS aan de andere kant? Is vaak iets sneller.

[CurlyMo]

Niet op deze hele oude leenlaptop.

[]Byte[]

En daarbij is de NFS op de Pi wat gevoelig voor compatibiliteitsproblemen tussen NFS v3 en v4.
Standaard zou v2 in de kernel van Wheezy gebakken zitten.
Je moet wel het nodige sleutelwerk doen wil je v.3 of 4 kunnen gebruiken.
Ik heb het in ieder geval nooit aan de gang kunnen krijgen met mijn Pi's naar mijn QNAP's.

[ Voor 26% gewijzigd door ]Byte[ op 31-07-2014 09:37 ]

[TMon]

Even het spindown verhaal nog eens aanhalen.
Ik las ergens in dit topict dat ZFSguru tegenwoordig de optie al heft ingebouwd in de rf.config. Deze heb ik aangezet op 900sec, voor alle schijven behalve m'n OS ssd. 7 schijven zitten om 'n moederboard en 3 op m'n M1015. Deze zijn aangegevens als ADA en DA.
Ik heb beide typen toegevoegd aan de regel, maar mag dit wel?

Mocht dit niet kunnen, dien ik dan de spindown te installeren die FIredrunk eerder in dit topic heft uitgelegd voor de M1015?

En als laatste, hoe veilig gaat 't dan worden om 1 pool via 2 verschillende command spindown te laten uitvoeren?

[Verwijderd]

Het werkt niet altijd op 'da' disks afhankelijk van de controller. 'ada' disks wel, dat zijn AHCI disks en ondersteunen alles wat je wilt. 'da' = SCSI/SAS ook als het SATA disks op een SAS controller zijn. Dat ligt iets ingewikkelder. Daarvoor kun je 'spindown' gebruiken. Volgens mij zit dat standaard ook in ZFSguru systeemversies tegenwoordig.

[Phyt_]

Ik gebruik dit voor ZFSguru en mijn disk op de IBM 1015, it mode, in spindown te krijgen.
Wel moet ik dit iedere keer ingeven na een reboot, geen idee hoe ik dit in de startup kan zetten.

spindown -b -i 300 -t 600 -d da1 -t 600 -d da2 -t 600 -d da3 -t 600 -d da4 -t 600 -d da5

[FireDrunk]

FireDrunk in "Het grote ZFS topic"

[TMon]

Firedrunk, precies. Daar had ik 't over. Lijkt me logisch en ga ik ook zeker instellen.

Dan rest 't laatste deel van mijn vraag nog; Is het veilig om ingebouwde ADA spindown te gebruiken samen met de "firedrunk" DA spindown? Beide natuurlijk op gelijke tijd.

Als die niet "samenwerken" valt je pool dus half uit. Een van mijn pools van 5 schijven zit 3 stuks op ADA en 2 stuks op DA. Iemand hier ervaring mee?

[Scooper]

Ik heb een Raid-z array draaien van 5 schijven icm ZFSGuru. Maandelijks wordt daarop een scrub gedraaid. Een tijd geleden resulteerde dit in het vinden van meerdere actieve bad sectors.

Zoals verwacht repareerde ZFS de schade en verdwenen de actieve bad sectors op één na (ook terug te zien in de SMART als Offline_Uncorrectable)! Ook na nogmaals een scrub te hebben gedraaid bleef er wel reparatie noodzakelijk. De maanden erna bleef ik één actieve bad sector houden.

Nadat ZFS onlangs volledig vast sloeg tijdens het bekijken van een film, heb ik een reset gedaan en wederom een dubbele scrub gedraaid. En weer moest er beide keren data gerepareerd worden. De maat was vol en dus heb ik een nieuwe schijf besteld en de kapotte schijf vervangen.

Nu heb ik de 'defecte' schijf geanalyseerd:
HDTune gaf een aantal damaged blocks en in de smart was de Current_Pending_Sector opgelopen tot 10.
DataLifeGuard Tools van WD gaf bij een korte test direct een 007 melding (Read Element Failure). Toen de extended test gedaan. Die resulteerde in een 223. Dat betekent dat er bad sectors zijn gevonden, maar dat ze gerepareerd zijn. De disk was weer volledig operabel volgens DLG Tools.

Vervolgens weer HDTune gedraaid en die vind nu alles weer prima. Ik had gehoopt deze schijf te kunnen RMA'en, maar dat lijkt er nu niet in te zitten. Ik dacht dat ZFS juist goed met die bad sectors om kon gaan. Aangezien er vaak bij scrubs gerepareerd moest worden en er nu dus zelfs een crash van ZFS had plaatsgevonden, had ik het idee dat de schijf écht naar zo'n schrootje was, dat blijkt dus niet het geval te zijn!? Hoe had ik dit beter kunnen aanpakken?

[FireDrunk]

TMon schreef op dinsdag 05 augustus 2014 @ 07:06:
Firedrunk, precies. Daar had ik 't over. Lijkt me logisch en ga ik ook zeker instellen.

Dan rest 't laatste deel van mijn vraag nog; Is het veilig om ingebouwde ADA spindown te gebruiken samen met de "firedrunk" DA spindown? Beide natuurlijk op gelijke tijd.

Als die niet "samenwerken" valt je pool dus half uit. Een van mijn pools van 5 schijven zit 3 stuks op ADA en 2 stuks op DA. Iemand hier ervaring mee?

Zolang je beide tools eigen schijven geeft is dat prima ja. Timer gelijk houden is wel zo fijn

[Verwijderd]

Scooper schreef op dinsdag 05 augustus 2014 @ 16:24:
Ik heb een Raid-z array draaien van 5 schijven icm ZFSGuru. Maandelijks wordt daarop een scrub gedraaid. Een tijd geleden resulteerde dit in het vinden van meerdere actieve bad sectors.

Zoals verwacht repareerde ZFS de schade en verdwenen de actieve bad sectors op één na.
[..]
Ik dacht dat ZFS juist goed met die bad sectors om kon gaan. Aangezien er vaak bij scrubs gerepareerd moest worden en er nu dus zelfs een crash van ZFS had plaatsgevonden, had ik het idee dat de schijf écht naar zo'n schrootje was, dat blijkt dus niet het geval te zijn!? Hoe had ik dit beter kunnen aanpakken?

Door het te negeren; actieve bad sectors in niet-actieve data is geen enkel probleem. Wat wel een probleem is, is dat je schijf actieve bad sectors heeft in actieve data. Dat is wellicht de reden dat je film blokkeerde. Door de hoge timeouts kan het lang duren voordat je server weer normaal doet. Dat kan irritant zijn. Je kunt de timeout verlagen zodat het minder lang duurt voordat ZFS het probleem oplost.

Afhankelijk van welke systeemversie je gebruikt, zou dit al actief kunnen zijn. Check je /boot/loader.conf door via SSH in te loggen en het bestand te editen via:

ee /boot/loader.conf

Je hoort ergens te zien:

# mimic TLER behavior
# note: error recovery is useful in cases where you lost your redundancy!
kern.cam.ada.default_timeout="7"
kern.cam.da.default_timeout="7"

Als er geen # voor staat, is die regel actief. Het gaat dan om die kern.blabla regel met getal 7. Dit betekent een timeout van 7 seconden. Er wordt nog wel een tweetal pogingen gedaan om te retryen. Bij SAS/SCSI is dit zelfs meerdere keren.

Als je schijf continu nieuwe bad sectors aanmaakt, is het reden deze te vervangen. Maar een enkele bad sectors in niet-actieve data is geen enkel probleem. Dat kun je uitsluiten door een scrub te draaien. Heb je nog actieve bad sectors ná een scrub, dan zijn die bad sectors geen enkel probleem. Zodra ZFS ze in gebruik gaat nemen, verdwijnen de bad sectors.

Anders is het met actieve data als daar bad sectors in komen. Bij normaal RAID5 was je array allang uit elkaar gevallen; bij ZFS blijft al je data keurig intact en is het hooguit dat je server hickups krijgt en je film niet vloeiend afspeelt of een foutmelding geeft. Toch een groot verschil.

[Scooper]

Dat is verhelderend, bedankt. Het volume stond nagenoeg vol, dus het kan heel goed zijn dat er actieve bad sectors in actieve data stonden. Bij de hick-ups was zowel ZFSGuru als het volume niet benaderbaar, wellicht was dit dus een kwestie van wachten geweest. Die tijd heb ik niet genomen

Ik snap alleen nog niet zo dat het in totaal maar om 10 sectoren gaat, de scrubs hebben wel eens meerdere MB's aan data gerepareerd. Dat sluit dan niet helemaal aan bij het aantal kapotte sectoren.

De default timeouts staan niet in mijn loader.conf. Ik vermoed dat dit komt door mijn oude versie (0.2.0-beta7 op ZFS v28).

Ik was van plan om mijn volume volledig te gaan backuppen en de huidige vdev opnieuw aan te gaan maken met wat extra schijven (nieuwe vdev ernaast was me te prijzig voor nu). Is het aan te raden om deze schijf gewoon weer daarin mee te nemen?

De SMART zag er niet overweldigend uit voordat ik de schijf verving:


Raw Read errors, Multi-Zone errors, uncorrectable erros

[FireDrunk]

Ik heb momenteel ook op 2 schijven Active Bad Sectors... Op zich niet leuk, maar ze werken nog wel... Ik heb al meerdere scrubs gedaan, en mijn pool volgeschreven, en daarna opnieuw gecheckt... Ze verdwijnen niet..

Beetje dezelfde situatie als jij hebt... Lastige is, is dat de Seagate tool de schijven nog gewoon in orde vind, en ik denk dus dat een RMA er niet in zit

[Murrays]

Ik had al een tijdje FreeNas 9.1 draaien met 2 TB schijven in stripe ZFS setup. Dit werkte naar alle tevredenheid maar toch was ik wat huiverig dat een schijf het zou begeven. Nu heb ik 2x 2TB schijven erbij gehaald met de veronderstelling om dit in RAID-Z te gaan draaien. Tijdens de config in FreeNas geeft ie aan dat RAID-Z niet de optimale instellingen zijn voor een 4 schijven opstelling.. RAID-Z2 wordt geadviseerd, maar zelf vind ik dat voor een thuis opstelling overbodig. Is dit gewoon te draaien in RAID-Z of ga je hier tegen problemen/performance issues aanlopen? Ik heb dit gepoogd op te zoeken via google maar krijg niet echt het duidelijke antwoord hierop.

[FireDrunk]

Het kan wel, het is niet super efficient in termen van performance en ruimte efficientie (je verliest een paar procent).

Als je compressie aan zet, word dit effect nog eens sterk verkleint, dus dat zou je kunnen doen.

Ik heb het hier zelf thuis ook (4*4TB in RAIDZ1)

[Murrays]

Bedankt voor de snelle reactie Je bedoeld de compressie aanzetten in FreeNas zelf? Is dat een optie ergens? Ja ik merkte dat de grootte al iets kleiner was dan verwacht.

Wat haal je met die 4*4TB qua snelheden ? (ik werk zelf met 1 gbit lan kaart dus weet niet wat je hebt draaien dat zal vast wel meer zijn).

[FireDrunk]

Het is een ZFS Filesystem optie.

Snelheden variëren, hoe voller je pool, hoe langzamer het word uiteraard. Mijn pool zit op 87% volgens mij nu.

thijs@NAS:/datapool/data/Linux$ dd if=livedvd-amd64-multilib-20121221.iso of=/dev/null bs=1M
4004+0 records in
4004+0 records out
4198498304 bytes (4.2 GB) copied, 15.2965 s, 274 MB/s

[Bigs]

Gek dingetje.. ik heb een nieuwe ZFS pool in gebruik genomen op een FreeBSD 10 server. Hiervoor gebruik ik zoals altijd netjes GPT partities. Echter zie ik na het importeren van de pool dat in 5 van de 6 gevallen niet mijn gpt label gebruikt wordt, maar een andere naam:

root@nelson:~ # zpool status
  pool: backup
 state: ONLINE
  scan: none requested
config:

	NAME                                            STATE     READ WRITE CKSUM
	backup                                          ONLINE       0     0     0
	  raidz2-0                                      ONLINE       0     0     0
	    gptid/92d0fd60-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gpt/backup1-Z4E02KQG                        ONLINE       0     0     0
	    gptid/9c7d0bab-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/9fe78f14-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/a3a41ef8-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/a70a4448-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0

Hoe kan ik er voor zorgen dat overal netjes mijn gpt labels gebruikt worden? Dat is wel zo handig voor het terugvinden van falende schijven (aangezien de disk fail ledjes op mijn supermicro chassis volgens mij niet uit zichzelf werken).

[matty___]

Bigs schreef op woensdag 06 augustus 2014 @ 15:37:
Gek dingetje.. ik heb een nieuwe ZFS pool in gebruik genomen op een FreeBSD 10 server. Hiervoor gebruik ik zoals altijd netjes GPT partities. Echter zie ik na het importeren van de pool dat in 5 van de 6 gevallen niet mijn gpt label gebruikt wordt, maar een andere naam:

root@nelson:~ # zpool status
  pool: backup
 state: ONLINE
  scan: none requested
config:

	NAME                                            STATE     READ WRITE CKSUM
	backup                                          ONLINE       0     0     0
	  raidz2-0                                      ONLINE       0     0     0
	    gptid/92d0fd60-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gpt/backup1-Z4E02KQG                        ONLINE       0     0     0
	    gptid/9c7d0bab-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/9fe78f14-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/a3a41ef8-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0
	    gptid/a70a4448-1d6c-11e4-8476-0025907ff1db  ONLINE       0     0     0

Hoe kan ik er voor zorgen dat overal netjes mijn gpt labels gebruikt worden? Dat is wel zo handig voor het terugvinden van falende schijven (aangezien de disk fail ledjes op mijn supermicro chassis volgens mij niet uit zichzelf werken).

Al een keer een reimport van je pool probeert?

[Bigs]

matty___ schreef op woensdag 06 augustus 2014 @ 15:58:
[...]

Al een keer een reimport van je pool probeert?

Yep, maar dat heeft geen effect. Waarschijnlijk staan de disks op die manier in de cache. Kennelijk kan ik het 'oplossen' door de pool te importeren met zpool import -d /dev/gpt, maar dat kan ik nu even niet proberen aangezien er op dit moment backups op die pool worden gemaakt.

Wel lekker trouwens, 6*5TB in RAIDZ2. Veel opslag in een relatief klein doosje (SC743T-665B).

[ Voor 5% gewijzigd door Bigs op 06-08-2014 16:28 ]

[Verwijderd]

@Bigs: je gebruikt geen ZFSguru; andere platforms hebben het niet zo op GPT labels kennelijk. Je kunt wellicht wel dit proberen:

code:

# disable id labels
kern.geom.label.gptid.enable="0"
kern.geom.label.ufsid.enable="0"
# disable legacy device mappings (ada->ad)
kern.cam.ada.legacy_aliases="0"

Stop dit in je /boot/loader.conf. Alleen de gptid regel is eigenlijk nodig, maar dit heeft ZFSguru om het probleem van disk labels aan te pakken.

Vervelend is wel dat het niet altijd werkt als ZFS eenmaal gptid's gaat gebruiken. Dan kan het zijn dat het daarna /dev/ada0p2 gaat gebruiken; de device node. Althans dat probleem had ik voordat ZFSguru het bovenstaande stukje in de loader configuratie had.