Het grote ZFS topic

[Verwijderd]

Ligt eraan welk attribuut. Oudere schijven gaven al failures aan als de schijf 55 graden werd. Dat op zichzelf is natuurlijk niet een reden dat de schijf gelijk in duizend stukjes uiteenvalt. Dus je zult toch zelf de SMART moeten proberen te interpreteren.

En verder: dit is het ZFS topic; je kunt vragen over SMART stellen in het Check je SMART topic.

[ Voor 19% gewijzigd door Verwijderd op 01-07-2014 21:42 ]

[ikkeenjij36]

Verwijderd schreef op dinsdag 01 juli 2014 @ 21:36:
Ligt eraan welk attribuut. Oudere schijven gaven al failures aan als de schijf 55 graden werd. Dat op zichzelf is natuurlijk niet een reden dat de schijf gelijk in duizend stukjes uiteenvalt. Dus je zult toch zelf de SMART moeten proberen te interpreteren.

En verder: dit is het ZFS topic; je kunt vragen over SMART stellen in het Check je SMART topic.

Ok ga ik m daar ook ff stellen.
Vraag blijft echter welke weg te gaan met zfs om een(de) schijf te vervangen door een grotere.
Die heb ik nu nog liggen nml maar durf niet te zeggen uit mn hoofd of ik nog een sata aansluiting over heb.
Mm vt weekend eens even kijken.

[Verwijderd]

Als je RAID-Z2 hebt kun je nog steeds redundant rebuilden. Dus dan is het niet erg dat er één schijf mist. Met twee schijven draai je dan zonder redundantie.

[Beninho]

Schone install gedaan met Ubuntu

Krijg mijn zpool niet geimporteerd, krijg ook geen foutmelding.

Las een stukje terug al

Als de zpool niet netjes ge-exporteerd is, zul je waarschijnlijk "zpool import -f <naam>" moeten gebruiken.

Ook dat geprobeerd, maar het scherm blijft leeg, lang wachten, +/- 1 uur, nog niks. Na reboot, nog niks.
Als ik enkel zpool import - invoer zie ik mijn pool staan, gewoon netjes staan.

code:

   pool: pool
     id: 15758535370166747320
  state: ONLINE
 action: The pool can be imported using its name or numeric identifier.
 config:

    pool                                          ONLINE
      raidz2-0                                    ONLINE
        ata-WDC_WD20EARX-00PASB0_WD-WCAZAA032642  ONLINE
        ata-ST2000DL003-9VT166_5YD9Z9QQ           ONLINE
        ata-WDC_WD20EFRX-68EUZN0_WD-WMC4M3237416  ONLINE
        ata-WDC_WD20EARX-00PASB0_WD-WMAZA5862730  ONLINE
        ata-WDC_WD20EFRX-68AX9N0_WD-WCC300359484  ONLINE
        ata-WDC_WD20EFRX-68AX9N0_WD-WCC300374991  ONLINE

zpool import -f pool --> levert niks op.

Welke stap kan ik nog meer nemen om de zpool te kunnen importeren?

[ Voor 39% gewijzigd door Beninho op 02-07-2014 22:09 ]

[mkroes]

Dit ook al geprobeerd?

code:

zpool import -f 15758535370166747320

Importeren niet met de pool-naam, maar met de pool-id.

[Beninho]

Klopt, ook daar gebeurde niks. --> althans -->

Nu, na een nacht wachten, is de pool toch geimporteerd. Misschien, doordat er een brakke-schijf in de pool, dat het zo lang duurde, want uiteindelijk heb ik er minstens 4 uur op gewacht eer die pool geimporteerd was..

[FireDrunk]

Dedup toevallig aan staan?

[Beninho]

hmm weet het niet zeker.

code:

NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  10.9T  6.82T  4.05T    62%  1.00x  ONLINE  -

Staat op 1X -- weet niet of dit nu standaard of of dat het betekent dat het aan staat. Misschien dwaal ik af, maar wel zeker dat ik compressie aan heb staan.

De hele pool is super traag, de geplande wekelijkse scrub gaat momenteel met 9MB/s

[Kortfragje]

Vreemd, neem aan dat je de kabels en voeding al gecontroleerd / aangedrukt hebt?

Zou het kunnen dat dit veroorzaakt wordt door eerst gebruik van ZFS 0.6.2 en nu 0.6.3? Heeft er al iemand een upgrade gedaan onder ubuntu van 0.6.2 naar 0.6.3?

(kwam deze thread tegen nml http://bernaerts.dyndns.o...ezy-zfsonlinux-zpool-lost)

[ Voor 19% gewijzigd door Kortfragje op 03-07-2014 10:41 ]

[Beninho]

Heb de kabels nog niet gecheckt, goede tip, want daar heb ik nog niet aangedacht. Kan natuurlijk niet zomaar losschieten, maar beter even checken dan..

Heb wel een update gedaan met ZFS, maar dat is al weer een paar weken geleden, dit "gedrag" is echt sinds de laatste dagen.
-edit- dat zeg ik wel, maar misschien is het me pas in de afgelopen dagen opgevallen.. normaal check ik die scrubresultaten niet wekelijks.. Ik ben er naar gaan kijken sinds ik haperingen bij verschillende videobestanden opmerkte..

[ Voor 30% gewijzigd door Beninho op 03-07-2014 10:40 ]

[FireDrunk]

Beninho schreef op donderdag 03 juli 2014 @ 10:32:
hmm weet het niet zeker.

code:

NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
pool  10.9T  6.82T  4.05T    62%  1.00x  ONLINE  -

Staat op 1X -- weet niet of dit nu standaard of of dat het betekent dat het aan staat. Misschien dwaal ik af, maar wel zeker dat ik compressie aan heb staan.

De hele pool is super traag, de geplande wekelijkse scrub gaat momenteel met 9MB/s

1.00x is standaard inderdaad. Dan zal Dedup uit staan. Waarom ik het vraag: Als je een pool importeert met dedup aan, gaat ZFS de complete dedup table (DDT ofzo) in het geheugen laden (van disk). Als die table niet in je RAM past, moet die op swap komen. Als je swap op ZFS ligt.... Problem...

Maar dat zal hier niet het geval zijn. Het zal eerder een bokkende schijf zijn.

BTW: Scrubs lopen de eerste minuten (tot het eerste uur ofzo) altijd langzamer. Dat loopt vanzelf op (als het goed is )

[ Voor 6% gewijzigd door FireDrunk op 03-07-2014 11:47 ]

[Beninho]

Deze scrub liep/loopt vooral op het einde ineens heel langzaam.

Net even de kabel gecheckt, dat zit/zit allemaal oke. Tijdens de boot gaf de bios een smart rror bij stata2, smart=bad. Nu even geboot met smart-check disabled. Nu komt het grote-welke schijf is dan stuk-vraagstuk.

zpool scurb geeft nu reparing aan bij ^{ata-WDC_WD20EARX-00PASB0_WD-WMAZA5862730} --> hoe kan ik checken dat die schijf is die een smart-fout in de bios geeft?

code:

ls -l /dev/disk/by-id/

[ Voor 6% gewijzigd door Beninho op 03-07-2014 14:41 ]

[ikkeenjij36]

*knip: dit hoort in het Check je SMART-topic; niet in het ZFS topic. Maar ik help je graag als je het op de juiste plaats post.

[ Voor 88% gewijzigd door Verwijderd op 06-07-2014 19:43 ]

[ikkeenjij36]

ikkeenjij36 schreef op zondag 06 juli 2014 @ 19:38:
[mbr]*knip: dit hoort in het Check je SMART-topic; niet in het ZFS topic. Maar ik help je graag als je het op de juiste plaats post. :)[/]

Oeps sorry in het juiste topic gezet.

[Habana]

Tip gezocht, ik probeer met mijn WDtv mediaplayer in te loggen op mijn ZFSguru nas hetgeen maar niet wil lukken, ik krijg telkens de melding "Ongeldige gebruikersnaam of wachtwoord"

De shared files zijn wel zichtbaar en bereikbaar op een W7 machine dus geen probleem aldaar, en de WDtv werkt perfect met mijn Synology nas.

Op de ZGFguru nas staat bij Files->Permisions Owner en Group beiden op share,
Er is een user en paswoord aangemaakt bij Acces->users met lees en schrijf rechten,
Bij Files->file systems staat de shared map (SSD/Test) shared met Samba.
Wat zie ik over het hoofd? waarom dit niet wil lukken….

@CiPHER onder , Allemaal al gedaan, guest acces staat uit, In Windows lukt het wel, die heeft geen probleem met user en wachtwoord enkel dat ik wel altijd onthouden moet aanvinken, vreemd dat vond ik ook temeer daar het eerder wel eens gelukt is…

[ Voor 17% gewijzigd door Habana op 11-07-2014 19:25 ]

[Verwijderd]

Heb je de share ook geconfigureerd voor die user? Access->Shares en klik op je share. Daar moet je de gebruiker die je hebt aangemaakt slepen naar 'Full Access'. Daarna Samba herstarten. Mogelijk ook je WDtv herstarten.

Je hebt geprobeerd dezelfde share met dezelfde user/password te benaderen via Windows 7? Weet je zeker dat je niet via guest access inlogt?

Wel vreemd dat het dan bij Windows wel zou lukken en met WDtv niet. Je kunt de log level verhogen en in de Samba logs kijken (/var/log/samba) of je daar wat ziet verschijnen zodra je probeert te connecten met WDtv.

[Verwijderd]

Omdat er ineens vanalles mis gaat met editten, maak ik post maar even opnieuw.

Probleemschets: ik haal met dd /dev/random maar 65MB/s, en met dd/zero 750MB/s. Eerstgenoemde is natuurlijk een standaard scenario qua sequential writes, en is wel erg weinig. firedunk kaart aan dat het CPU based is, maar vreemd genoeg is de load op de CPU nagenoeg 0%. Met 750MB/s is de load zo'n 15%.

Hardware/software:
Freenas 9.2.1.6 baremetal
e5-2620
10x4TB, 10x2TB, 2xRaidZ2
48GB ram

Wellicht dat het te maken heeft met het feit dat ashift=12 op de ene vdev staat, en ashift=9 op de andere. (Niet op gelet met configureren dat ashift per vdev werkte. (?))

[ Voor 255% gewijzigd door Verwijderd op 12-07-2014 15:33 ]

[FireDrunk]

Het zou inderdaad niet uit moeten maken tenzij je zo slim bent om /dev/random te gebruiken.
Dat is CPU limited, en het is niet zo gek dat je daar maar 65MB/s haalt.

65MB/s voor /dev/random is btw helemaal niet slecht, dat haal ik hier echt niet

[Verwijderd]

Hehe, dat verklaart wel het een en ander. Ziet ernaar uit dat ik dan de performance bottleneck ergens anders moet gaan zoeken.

[Verwijderd]

/dev/random is bedoeld voor security; het is beperkt door de beperkte entropy. Dat heeft niets met ZFS te maken, kijk maar:

dd if=/dev/random of=/dev/null bs=1m count=1000
(lees van /dev/random en schrijf naar /dev/null dus nergens naartoe; blijft een laag getal)

/dev/zero is prima en geeft niet andere scores dan dat je wel /dev/random tegen RAM-snelheid zou kunnen lezen. Tenzij je compressie ingeschakeld hebt, of deduplicatie. Zonder deze technieken kun je /dev/zero prima gebruiken.

[Compizfox]

Je moet ook /dev/urandom gebruiken, die is in tegenstelling tot /dev/random non-blocking.

Edit: geldt alleen voor Linux. Op FreeBSD is ie sowieso non-blocking en is /dev/random dus symgelinkt naar /dev/urandom. Op FreeBSD zou hij dus niet moeten blocken en is hij dus even snel als /dev/null.

[ Voor 53% gewijzigd door Compizfox op 12-07-2014 17:25 ]

[FireDrunk]

thijs@NAS:~$ dd if=/dev/urandom of=/dev/null bs=1M count=100000
175+1 records in
175+0 records out
183500800 bytes (184 MB) copied, 13.1805 s, 13.9 MB/s

Nope, die is net zo hard CPU bound...

[dcm360]

Dan nog is /dev/urandom niet echt een snelheidswonder:

linux-wlpy:~ # dd if=/dev/zero of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 0.816552 s, 1.3 GB/s
linux-wlpy:~ # dd if=/dev/urandom of=/dev/null bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 96.3468 s, 10.9 MB/s

[FireDrunk]

Lol... Mijn /dev/zero is wel wat sneller dan die van jou lijkt het

thijs@NAS:~$ dd if=/dev/zero of=/dev/null bs=1M count=100000
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 7.0834 s, 14.8 GB/s

[dcm360]

Ik had toevallig een SSH-sessie open naar de bak die ik in de winter gebruik als mining-rig, dus allemaal lekker oud traag (en zuinig) spul met een (relatief) lompe videokaart. De CPU is een Athlon 64 X2 4600+.
Momenteel ben ik op die pc een beetje aan het spelen met ZFS, voor mn nieuwe server heb ik vooralsnog alleen 2 van de 3 HDD's binnen en die heb ik maar even in die pc gestopt.

[ Voor 5% gewijzigd door dcm360 op 12-07-2014 17:29 ]

[Verwijderd]

code:

# dd if=/dev/zero of=/dev/null bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 0.296783 secs (35331407273 bytes/sec)

(35.3GB/s)

Draaien jullie allemaal Linux ofzo?

[FireDrunk]

Ja, op een Celeron G1610

[Verwijderd]

Dat maakt wel uit; hier een Core i5 3570. Uit mijn hoofd haalde ik op de J1900 trouwens rond de 10GB/s - nog zeker niet slecht.

[FireDrunk]

Heeft volgens mij vooral te maken met single core performance in combinatie met je geheugensnelheid.
En die is bij jou zeer waarschijnlijk 1600Mhz @ 9-9-9 en is hier 1333Mhz 10-10-10

[Verwijderd]

J1900 doet maar 1333MHz max en in het SuperMicro bordje kan ik dat niet veranderen. 3570 draait 1600MHz op CL9.

[dcm360]

Ja hee, 1600 en 1333MHz? In die testbak van mij zitten wat random DDR2-modules

Werkbak haalt overigens ~15GB/s, en zou in theorie 1600MHz op 9-9-9 moeten zijn, al weet ik niet zeker of ik dat na de laatste BIOS-update nagegaan was.

[ Voor 49% gewijzigd door dcm360 op 12-07-2014 17:50 ]

[Verwijderd]

Zo onderscheiden de mannen zich van de jongens.

Overigens: ik wil nog een keer wat tests doen met ZFS om te kijken hoeveel invloed geheugenperformance heeft op ZFS performance. Ik speculeerde al langer dat ZFS bovengemiddeld voordeel haalt uit sneller geheugen omdat het vooral geheugen-intensief is. Maar dat heb ik nooit met benchmarks aannemelijk gemaakt. Misschien een leuk project, na mijn huidige avontuur.

[ Voor 82% gewijzigd door Verwijderd op 12-07-2014 18:00 ]

[]Byte[]

FireDrunk schreef op zaterdag 12 juli 2014 @ 17:32:
Ja, op een Celeron G1610

Ben je aan een upgrade begonnen?

[FireDrunk]

Uh, nee

gallery: FireDrunk

[FireDrunk]

Voor de mensen die goedkoop op zoek zijn naar een ZIL/SLOG voor hun pool:

http://www.ibood.com/extra-nl/nl/

[]Byte[]

Voor diegene die ibood nog niet kennen... het is een DAG-aanbieding.

[Keiichi]

Ik heb het volgende idee waarvan ik niet weet of het zo werkt als het bedacht heb:

Ik heb 4 schijven van 2TB.
Ik heb 4 schijven van 1TB.

Kan ik hiermee, van 1TB schijven eerst 2x een stripe maken en hierna een raid-z2 van de 4x2TB schijven + 2x2TB stripe maken?

Ik heb nog niets zelf kunnen proberen, omdat de server met die schijvenconfig pas over een paar dagen in m'n handen is

[Pixeltje]

Ik zou het niet doen, want als één van die 1TB schijven onderuit gaat, ben je in volgens mij zijn striped collega ook kwijt, op die manier wordt de kans op degration of zelfs dataverlies groter.

Als het zou werken zoals je voorstelt heb je van de 12TB bruto 8 TB netto over (want raidz 2). Als je twee verschillende pools maakt met raidz2 (een van je 2TB schijven en een van je 1TB schijven) hou je minder bruto opslagruimte over (6TB) maar ben je wel beter beschermd tegen diskfailure.

[ Voor 43% gewijzigd door Pixeltje op 17-07-2014 14:42 ]

[FireDrunk]

Waarom niet gewoon 2 * RAIDZ1 en backup de allerbelangrijkste dingen tussen de twee pools?

Dat is effectief denk ik de beste oplossing. Je gaat mij niet vertellen dat je *echt* kritieke data > 8TB is

[dcm360]

FireDrunk schreef op donderdag 17 juli 2014 @ 11:04:
Voor de mensen die goedkoop op zoek zijn naar een ZIL/SLOG voor hun pool:

http://www.ibood.com/extra-nl/nl/

Wat een korting, niets eens 4 euro goedkoper dan in de pricewatch...

[FireDrunk]

is toch > 10%

[Berkeley]

FireDrunk schreef op donderdag 17 juli 2014 @ 11:04:
Voor de mensen die goedkoop op zoek zijn naar een ZIL/SLOG voor hun pool:

http://www.ibood.com/extra-nl/nl/

Klinkt mooi om 2van die dingen te gebruiken als bootdisk in FreeBSD met ZFS on root.

[Keiichi]

Mijn ZFS idee zou voor alleen maar zijn voor, 'kan het?' eigenlijk wil ik nog 2x 2TB schijven erbij kopen ter vervanging van de 1TB's. Het idee is dat ik beetje kan testen hoe de server minimaal performed met FreeBSD 10 en istgt en Linux met ietd.

[zzattack]

Ik vind het steeds irritanter om met steeds kortere tussenpozen snapshots te moeten verwijderen omdat m'n freebsd zroot vol is, zodoende een grotere ssd aangeschaft. Deze moet de oude vervangen. Klopt mijn stappenplan of vergeet ik nog iets belangrijks?
1. nieuwe schijf zelfde gpt indeling geven als oude, op het 'data' gedeelte na?
2. data partitie van nieuwe schijf attachen aan de zroot pool
3. wachten op resilveren
4. oude schijf detachen
5. evt bootcode in orde maken

[FireDrunk]

Volgens mij klopt dat inderdaad. Let wel goed op dat je attach doet ipv add

[Ultra]

Verwijderd schreef op zaterdag 31 mei 2014 @ 16:44:
5 disks in RAID-Z is optimaal
6 disks in RAID-Z2 is optimaal

Staat ook in de startpost.

Volgens Matt Ahrens geldt dat sowieso niet als je compressie toepast:

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

Trying to optimize your RAID-Z stripe width based on exact numbers is irrelevant in nearly all cases
[...]
Due to compression, the physical (allocated) block sizes are not powers of two, they are odd sizes like 3.5KB or 6KB. This means that we can not rely on any exact fit of (compressed) block size to the RAID-Z group width.

[FireDrunk]

Hmm interresant, Er staat wel dat het helpt in de space effeciency hoor.

Use RAID-Z. Not too wide. Enable compression. IF AND ONLY IF you are using RAID-Z with 512-byte sector devices with recordsize=4K or 8K and compression=off (but you probably want compression=lz4): use at least 5 disks with RAIDZ1; use at least 6 disks with RAIDZ2; and use at least 11 disks with RAIDZ3.

Meer is dus niet erg voor space effeciency, er is (voor zover ik het artikel goed begrijp) alleen een noodzaak aan een minimaal aantal schijven.

Let wel: de context van dit artikel is 4k/8k recordsize, voor 128k gelden weer andere regels volgens mij...

Using 512-byte aligned writes on a native-4K sector drive typically results in very poor write performance.

The default record size (128K) does minimize space overhead — don’t change it for general-purpose uses. The only reason to change the recordsize is if your application does smaller random writes to large files (e.g. databases or disk images).

In orde van belangrijkheid:

1) Maak je pool aan met ashift=12 voor zowel 512b schijven, als 4k schijven.
2) kies eerst voor 128k recordsize(default) en zet compressie aan(lz4, niet default)
3) kies een minimaal aantal schijven in je vdev.
4) kies een aantal schijven in een mzoals CiPHER aan geeft.

Dat laatste is dus blijkbaar niet verplicht lees ik...

[ Voor 36% gewijzigd door FireDrunk op 18-07-2014 09:39 ]

[Ultra]

FireDrunk schreef op vrijdag 18 juli 2014 @ 09:36:
Hmm interresant, Er staat wel dat het helpt in de space effeciency hoor.

[...]


Meer is dus niet erg voor space effeciency, er is (voor zover ik het artikel goed begrijp) alleen een noodzaak aan een minimaal aantal schijven.

Let wel: de context van dit artikel is 4k/8k recordsize, voor 128k gelden weer andere regels volgens mij...

Nee, de uitzondering die je quote geldt alleen bij een record size van 4k/8k, zonder compressie. In het artikel wordt zelfs aangegeven dat de default van 128k bijna nooit veranderd hoeft te worden.

[FireDrunk]

Dat bedoelde ik

https://docs.google.com/s...qTA0w_ZY/edit?pli=1#gid=0

Het 3e tabje van zijn spreadsheet is dus wel weer interessant

Met mijn 4 schijven in RAIDZ1 met een 128k recordsize heb ik dus 'maar' een verlies van 1%, waar iedereen altijd roept dat het slecht is

[ Voor 27% gewijzigd door FireDrunk op 18-07-2014 09:44 ]

[Ultra]

FireDrunk schreef op vrijdag 18 juli 2014 @ 09:42:
[..]
Met mijn 4 schijven in RAIDZ1 met een 128k recordsize heb ik dus 'maar' een verlies van 1%, waar iedereen altijd roept dat het slecht is

In de tabel staat 'block size in sectors', dus of 3% bij 4k sectoren of 0% bij 512b sectoren lijkt me? En nogmaals, alleen als er geen compressie wordt toegepast (dat is de aanname bij alle data in die sheet).

[FireDrunk]

Mja, zo las ik het niet, maar de term Block size in Sectors is raar, want bij een true-4K schijf is 1 sector toch gewoon 4K... Als de schijf 512b sectors emuleert is het inderdaad 3% ja.

(Nog steeds verwaarloosbaar in mijn ogen )

[Keiichi]

Ultra schreef op vrijdag 18 juli 2014 @ 09:25:
[...]


Volgens Matt Ahrens geldt dat sowieso niet als je compressie toepast:

[...]

Is de conclusie nu dat het aantal schijven in totaal niet zo gek veel uitmaakt als je compressie gebruikt?

[FireDrunk]

Volgens mij wel ja.

[Ultra]

Inderdaad.

[]Byte[]

Keiichi schreef op vrijdag 18 juli 2014 @ 11:27:
[...]
Is de conclusie nu dat het aantal schijven in totaal niet zo gek veel uitmaakt als je compressie gebruikt?

Je hebt twee onderdelen...
Aantal schijven per RAIDZ1/2/3 sets, en de opgeslagen informatie binnen die set.
Dat zijn (volgens mij) totaal twee verschillende zaken.

De hoeveelheid aantal disken per Z1/2/3-set is al helemaal uitgekauwd en hoeft volgens mij niet 'opnieuw te worden uitgevonden'.
Dit staat helemaal LOS van wat je er op zet!

Compressie wordt toegepast op de data die je op de set wilt wegschrijven...
Het zijn nog steeds hele brokken data die op disk terecht blijven komen.

Hoeveel sectoren je er exact mee vol schrijft is net zo boeiend als zonder compressie...
Je zal altijd wel een deel overhead blijven houden omdat je gewoonweg vanwege de size (bijna) nooit exact tot de laatste bit in een sector vult.

Tav dedup zou ik mij voor kunnen stellen dat hier de overhead wel groter is omdat er daar alleen pointers worden weggeschreven, maar doordat de opgeslagen informatie een veelvoud lager is, heeft dit nog altijd een extreem hoog rendement.
Maar ook dat hangt er weer vanaf HOE die pointers worden weggeschreven.
zijn het allemaal individuele bestandjes, of zitten ze in een database?

Daarom adviseert men voor databases ook een veel kleinere recordsize in je pool dan de standard 128 kB.

For PostgreSQL and MysSQL users recomment using a different recordsize than default 128k.

PostgreSQL: 8k
MySQL MyISAM storage: 8k
MySQL InnoDB storage: 16k

Alles staat en valt met type data.
Nu kan je voor ieder type data een aparte pool aanmaken, maar dan heb je weer veel meer overhead per pool en schiet je je doel ook weer voorbij.
Ik heb zelf nu 3 pools draaien.
- Reguliere data
- Databases
- Backup (met dedup)

[FireDrunk]

Je kan de recordsize per filesystem instellen... Dus dat probleem is al getackeld.

[Ultra]

]Byte\[ schreef op vrijdag 18 juli 2014 @ 11:57:
[...]
De hoeveelheid aantal disken per Z1/2/3-set is al helemaal uitgekauwd en hoeft volgens mij niet 'opnieuw te worden uitgevonden'.
[...]

Dan zou ik het nog eens lezen:

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

I’d like to take the opportunity to address one piece of misinformed advice about how many disks to put in each RAID-Z group

[FireDrunk]

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.

[Paul]

Maar wat de auteur ook herhaaldelijk aangeeft: Dit gaat puur om de parity-overhead. Parity-overhead is maar één van de variabelen, zo zijn er ook mensen die hebben getest wat de performance doet met diverse aantallen schijven, en daar lijkt (2^N)+P weer wel op te gaan...

[FireDrunk]

Dat is dus alleen maar interresant voor sequentiele performance. Voor random IOPS maakt het toch niet uit, want je IOPS zijn gelimiteerd aan (ongeveer) de snelheid van 1 disk.

[Paul]

Volgens mij zijn de meeste mensen hier thuisgebruiker. Wat doen die? Films wegschrijven en zeuren dat ze geen 110 MB/sec halen

[FireDrunk]

Oh, zeker waar

Als we eerlijk zijn, zou voor 99% van de mensen hier, 60MB/s ook nog genoeg zijn

[Xudonax]

Voor wie het niet zo erg bijhoud, ZFS on Linux v0.6.3 is uit. Eindelijk support voor kernels >3,11
Ik ga vanavond eens kijken hoe dit gaat met de nieuwste Fedora 19, om daarna een upgrade naar Fedora 20 te doen. Hoop dat het allemaal blijft werken.

[FireDrunk]

DXaroth in "Het grote ZFS topic"

Je loopt achter

[Paul]

FireDrunk schreef op vrijdag 18 juli 2014 @ 12:34:
Oh, zeker waar

Als we eerlijk zijn, zou voor 99% van de mensen hier, 60MB/s ook nog genoeg zijn

...wat ook ongeveer is wat ik haal met mijn 5400-RPM schijfje in mijn laptop -> cheap switch 1 -> cheap switch 2 -> VMware -> VM

60 MB/s is ook snel genoeg, Tweakers (myself included...) geilen natuurlijk op de getalletjes, zelfs dingen als LACP en port channels komen regelmatig voorbij, maar onder de streep staat het geheel 95% van de tijd niks te doen

[ikkeenjij36]

Ff een vraagje,ik wil in mijn pool 2 schijven vervangen.
Er zijn 9 hdd's in depool waarvan 1 failing en 1 onderweg,zfsguru heeft er een z1 pool van gemaakt.
Klopt wel zijn zelfde leeftijd en hebben bijna net zolang gedraaid.
Probleem nu is heb geen sata aansluitingen meer over.
Hoe het beste dit te doen zonder data verlies of moet ik opnieuw beginnen met de pool nieuw aanmaken en dan gelijk een z2 pool ervan maken?
Os staat op aparte ssd.
Graag advies.

[Paul]

Het veiligst nu is ergens een SATA-poort vandaan halen (mogelijk werkt USB -> SATA, anders ergens een PCI-kaartje lenen?) en zorgen dat de failing disk en de nieuwe disk beiden zijn aangesloten, zo loop je het minste risico.

Als dat niet lukt dan de failing disk vervangen door de nieuwe. Het hele idee achter Z1/2/3 is juist dat er een schijf uit kan vallen en je toch geen dataverlies hebt, alleen bij optie 1 kan ZFS voor 99% van de blokken putten uit de gegvens

Pool weggooien en er een Z2 van maken gaat niet zonder dataverlies. Z2 beschermt tegen meer uitval dan Z1, en een pool van 9 schijven is groter dan wat ik persoonlijk zou maken op Z1, maar het is maar net waar jij je prettig bij voelt en hoe belangrijk de data is

[FireDrunk]

Geen USB naar SATA gebruiken!!! Ik heb dat ooit eens getest met ZFS, en dat werkte niet stabiel!

Pak liever eSATA of een echte sata poort via een extra PCIe kaartje.

[Paul]

Hmm ok. Ik doe hier regelmatig van alles via USB -> SATA (externe HDD, dock, externe behuizing waar ik zelf een SATA-schijf in het gezet etc etc) en dat werkt perfect met NTFS. Doet ZFS dan iets speciaals wat NTFS niet doet (behalve dan het berekenen en wegschrijven van parity / CRC, maar dat lijkt me niets te maken te hebben met de aansturing van de schijf)?

En, 'niet stabiel', wat houdt dat in? Ik zou nooit USB gebruiken voor een pool in productie, maar werkt het ook niet wanneer je daar de 'kapotte' schijf aan hangt tijdens het rebuilden naar een verse schijf?

[ikkeenjij36]

Ok dus 1 schijf tegelijk vervangen moet lukken met z1?
Moet er dan nog resilveren of gewoon in de disk pagina een replace geven?

[FireDrunk]

Ik heb problemen gehad met een chip van JMicron (USB3 -> SATA2), onder FreeBSD. Ik had een pool gemaakt en na een tijdje kreeg ik rare command timeouts en checksum errors. Nog wat langer de pool ging offline.

Natuurlijk is mijn ervaring maar met 1 chip, en maar 1 uit vele, maar ik doe het iig niet meer...

[nero355]

Paul schreef op vrijdag 18 juli 2014 @ 13:06:
60 MB/s is ook snel genoeg, Tweakers (myself included...) geilen natuurlijk op de getalletjes, zelfs dingen als LACP en port channels komen regelmatig voorbij, maar onder de streep staat het geheel 95% van de tijd niks te doen

Daar ben ik het dus echt helemaal niet mee eens : Mijn USB 3.0 card reader zit ook meer te niksen dan dat die wel wat doet, maar als ik hem dan ineens wel nodig heb is het wel zo fijn dat alles naar mijn PC gaat met 75 MB/s (max. van de CF kaartjes) in plaats van 24-28 MB/s van de USB 2.0 versie

Kortom : Alles moet gewoon zo snel mogelijk werken als het kan op het moment dat je het nodig hebt, want het scheelt gewoon een heleboel tijd!

[ikkeenjij36]

Hallo schijven zijn vervangen en dat is allemaal goed gegaan.
Nu wil ik mijn pool upgraden naar v5000 maar als ik dat doe gaan alle feature flags werken en daar zijn volgens mij mijn schijven niet voor geshikt.
Hoe krijg ik de pool geupgrade zonder dat alle feature flags geactiveerd worden?

[ Voor 9% gewijzigd door ikkeenjij36 op 19-07-2014 13:19 ]

[Verwijderd]

Schijven niet geschikt voor feature flags?

Als je geen feature flags wilt, gebruikt je ZFS v28. Maar het gebruik ervan heeft niets met je schijven te maken hoor.

[ikkeenjij36]

Ok ik dacht juist van wel want als je van de pool wil booten lukt dat niet omdat er bepaalde flags ervoor zorgen dat dat niet lukt.
Nu boot ik van aparte ssd dus u geen last van.

[Verwijderd]

Als dat al zo zou zijn, heeft dat toch niets te maken met het feit dat het een mechanische hardeschijf is? Voor je systeem is dat gewoon een block-level storage device. Hoe snel het is en hoe het intern werkt verandert niets aan de werking ervan. Feature flags zouden op een SSD hetzelfde werken als op een HDD.

Verder is het wel nodig dat je bootcode up-to-date is. Je boot pool gewoon op v28 laten kan ook; maar ik heb geen problemen met v5000 met LZ4-compressie enabled. Wellicht dat je wel problemen krijgt als je 11.x hebt gebruikt; omdat die nieuwere features heeft. Als je dan naar 10.x terug gaat kan dat problemen geven omdat je pool nog wel de feature flags van 11.x ingeschakeld heeft, terwijl 10.x dit niet ondersteunt.

[ikkeenjij36]

Nee niet van 11 naar 10 gegaan.
Gewoon pool opnieuw gemaakt eerst op v28 daarna geupgrade naar v5000.
Ik zal de bootcode nog ff nakijken of die up to date is.

Edit:Alles up to date echter zie ik bij de opslag pool alle flags actief en bij mijn os pool alleen de eerste 3 maar toch allebei v5000?
Ik heb geen idee waarom maar zolang niet alles actief is op mijn os is dan start alles gewoon op.

[ Voor 42% gewijzigd door ikkeenjij36 op 19-07-2014 19:41 ]

[Verwijderd]

Het verschil tussen Actief en Enabled heeft te maken met compatibiliteit. Zo kan LZ4-compressie enabled zijn, maar nog niet actief omdat het nog niet 'actief' gebruikt wordt.

Maar als je niet kunt booten met v5000 pool, wat is dan de exacte foutmelding die je krijgt? Je kunt wel gewoon booten vanaf je SSD die ook gewoon v5000 is?

[ikkeenjij36]

Ja idd ssd v5000 met :Enabled async_destroy

Active empty_bpobj
Active lz4_compress
de rest inactive
pool opslag:

Status Feature Description
Enabled async_destroy Destroy filesystems asynchronously.
Active empty_bpobj Snapshots use less space.
Enabled lz4_compress LZ4 compression algorithm support.
Enabled multi_vdev_crash_dump Crash dumps to multiple vdev pools.
Active spacemap_histogram Spacemaps maintain space histograms.
Active enabled_txg
Active hole_birth
Enabled extensible_dataset Enhanced dataset functionality, used by other features.
Enabled bookmarks

Als ik bv van de opslag pool zou willen booten zegt ie ..........hole birth .......
Weet het niet precies meer omdat ik al een tijd gewoon van een aparte pool(mijn ssd dus) boot

[Keiichi]

Ik heb een test-server in deze situatie gekregen:

code:

[root@fstest /test1]# zpool status
  pool: test1
 state: DEGRADED
status: One or more devices has been taken offline by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a
        degraded state.
action: Online the device using 'zpool online' or replace the device with
        'zpool replace'.
  scan: resilvered 8.62G in 0h2m with 0 errors on Sun Jul 20 18:06:22 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        test1                       DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            mfid5p1.nop             ONLINE       0     0     0
            spare-1                 OFFLINE      0     0     0
              16359712086492402797  OFFLINE      0     0     0  was /dev/mfid6p1.nop
              mfid2p1.nop           ONLINE       0     0     0
            mfid7p1.nop             ONLINE       0     0     0
            mfid0p1.nop             ONLINE       0     0     0
            mfid1p1.nop             ONLINE       0     0     0
        spares
          17755701212529100355      INUSE     was /dev/mfid2p1.nop

errors: No known data errors

Ik ben eerlijk gezegd nu even de weg kwijt hoe ik dit kan herstellen. De offline drive mag helemaal weg en er is nu ook geen hot-spare meer.

[CurlyMo]

@ikkeenjij36, opnieuw is zoeken een kunst. Mijn laatste reacties gaan allemaal over v5000 ervaringen.

[Paul]

nero355 schreef op zaterdag 19 juli 2014 @ 02:22:
Kortom : Alles moet gewoon zo snel mogelijk werken als het kan op het moment dat je het nodig hebt, want het scheelt gewoon een heleboel tijd!

Tja, en daarvan zeg ik juist als thuisgebruiker (en al helemaal PC <--> NAS) dat het juist niet boeit. Als ik 2 TB over moet zetten op 100 MB/s dan duurt dat al 6 uur, op 60 MB/s duurt het er 10/ Oftewel, fire and forget, ik ga ondertussen wat anders doen...

Want, hoe vaak komt dat voor? Want die ene film van 11 GB (en dan heb je al een hele flinke) doet er bij 100 MB/s 2 minuten over, en bij 60 MB/s zijn dat er 3. Bij een normalere film van 4 GB is het 41 seconde of 68 seconde. Oftewel, lekker boeiend

Kijk, als het sneller kan, graag. Echter, vaak vind ik het al teveel moeite om de UTP-kabel te pakken en doe ik het gewoon via wireless Het is dus een kosten/baten-analyse...

[blauwe eend]

Heb laatst een freenas gebouwd en ziet er leuk uit, draait nu freenas vanaf usb en er zitten 6 3TB seagate 7200.14 schijven in. Deze schijven wil ik graag in RAIDZ2 zetten, maar ik krijg dan een error . Namelijk het volgende:
Error: Unable to GPT format the disk "ada2" ( Het zelfde is dus ook bij ada3/4/5 )
Nu hebben deze vier schijven hiervoor in een raid config gezeten en ik denk dus dat dit het probleem is. Heb al wat gezocht op internet en wat geprobeerd, maar kom er nog niet uit. Schijven al in windows omgeving leeg gemaakt en met en zonder partitie geprobeerd, maar niks lijkt te werken.
Ook als ik een van deze disks in FreeNas omgeving probeer te 'wipe(n)' dan krijg ik ook weer een error . :Error: Failed to wipe ada4: dd: /dev/ada4: Operation not permitted
En het zelfde dus weer bij alle vier de schijven...

Weet iemand hiervoor een oplossing? Want zelf weet ik het even niet meer

[zzattack]

da's opmerkelijk, misschien even overhangen naar een andere pc en daar je gpt in orde maken of wat je zegt, het begin van de schijf wipen

[_-= Erikje =-_]

Gparted destroy?

[Verwijderd]

Komt door de RAID metadata en geom_raid. Je kunt mij een DM sturen met 'glabel status' en 'graid status' en ik hoop je er van te kunnen verlossen. FreeBSD ondersteunt namelijk FakeRAID metadata en kan zo de RAID metadata van andere vendors gebruiken om zijn eigen software RAID implementatie aan te wenden. Om die reden kun je FakeRAID zoals Intel/AMD gebruiken onder BSD - voor Linux geldt hetzelfde.

[nero355]

Paul schreef op maandag 21 juli 2014 @ 10:01:
Want, hoe vaak komt dat voor?

Het gaat erom dat het voorkomt! En dan moet het zo min mogelijk tijd kosten

Kijk, als het sneller kan, graag. Echter, vaak vind ik het al teveel moeite om de UTP-kabel te pakken en doe ik het gewoon via wireless Het is dus een kosten/baten-analyse...

Daarom heb ik 1 Gbps door het hele huis lopen waar PC/laptop achtige apparatuur zich bevindt : WLAN is alleen voor wat internetten en telefoons en zo... voor de rest ben ik het liever kwijt dan rijk, maar het moet tegenwoordig wel met al die smartphone addicts

[dcm360]

Paul schreef op maandag 21 juli 2014 @ 10:01:
[...]
Tja, en daarvan zeg ik juist als thuisgebruiker (en al helemaal PC <--> NAS) dat het juist niet boeit. Als ik 2 TB over moet zetten op 100 MB/s dan duurt dat al 6 uur, op 60 MB/s duurt het er 10/ Oftewel, fire and forget, ik ga ondertussen wat anders doen...

Want, hoe vaak komt dat voor? Want die ene film van 11 GB (en dan heb je al een hele flinke) doet er bij 100 MB/s 2 minuten over, en bij 60 MB/s zijn dat er 3. Bij een normalere film van 4 GB is het 41 seconde of 68 seconde. Oftewel, lekker boeiend

Kijk, als het sneller kan, graag. Echter, vaak vind ik het al teveel moeite om de UTP-kabel te pakken en doe ik het gewoon via wireless Het is dus een kosten/baten-analyse...

Het hangt er net een beetje vanaf hoe je de NAS gebruikt. Ik maak back-ups van mijn pc's naar mijn thuisserver, en ik ben er toch wel blij mee dat mijn werkbak of laptop daar 15 minuten over doet, en niet 5 uur. Ook met het overzetten van een disk-image van een VM is sneller beter, want dan kan ik weer sneller aan de slag (sowieso kan ik dan nog wel tijdens het kopiëren een bak koffie halen). Wat betreft films maakt de snelheid echter totaal niet meer uit: zelfs de wireless is snel zat om films te streamen, dus kopiëren doe ik niet.

[-Moondust-]

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 15% gewijzigd door -Moondust- op 22-07-2014 03:28 ]

[Verwijderd]

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.

[-Moondust-]

Wat zie je op de server zelf?

Opstarten kan ik via KVM/IPMI geheel volgen en loopt voor zover ik dat kan beoordelen normaal behalve aan het einde bij dhclient.

code:

igb0: no link ......igb0: link state changed to UP
 got link
DHCPDISCOVER on igb0 to 255.255.255.255 port 67 interval 6
DHCPOFFER from 192.168.178.1
DHCPREQUEST on igb0 to 255.255.255.255 port 67
DHCPACK from 192.168.178.1
bound to 192.168.178.17 -- renewal inb 43200 seconds.
Starting dhclient.
igb1: no link .............. giving up
/etc/rc.d/dhclient: WARNING failed to start dhclient

Er komt nog eea achteraan maar dat gaat deels te snel om te capturen en wat er aan het einde staat ziet er goed uit, dwz geen foutmeldingen.

Kun je de server pingen?

Ja, dat lukt.

Op welk opslagapparaat heb je ZFSguru geïnstalleerd?

Intel 320 40GB SSD.

Kan het zijn dat dit opslagapparaat vol is geraakt?

Zou kunnen, maar hoe kan ik dat checken?

[Verwijderd]

'df -h' kun je de free disk space mee checken. zfs list zou ook kunnen.

PS. Soms worden dit soort help-chats erg lang. Daarom kan het beter zijn via DM te doen.

[-Moondust-]

Ok, DM verstuurd.

[DXaroth]

#	Product	Prijs	Subtotaal
1	ASRock E3C224D4I-14S	€ 245,27	€ 245,27
1	Crucial M500 2,5" 240GB	€ 91,92	€ 91,92
1	Intel Xeon E3-1230 V3 Boxed	€ 213,50	€ 213,50
2	Kingston ValueRAM KVR16E11/8EF	€ 79,42	€ 158,84
1	Seasonic SS-250SU	€ 37,-	€ 37,-
1	Silverstone DS380	€ 149,42	€ 149,42
2	WD Red SATA 6 Gb/s WD40EFRX, 4TB	€ 143,90	€ 287,80
Bekijk collectie Importeer producten		Totaal	€ 1.183,75

Eindelijk (en FireDrunk zal het hier vast mee eens zijn) na veel te lange tijd de knoop maar doorgehakt, en besteld.

Is wel irritant; geheugen is super slecht beschikbaar; deze 2 waren op voorraad bij leverancier, anders had dit ook meer dan een week op zich moeten laten wachten... je zou verwachten dat zulk niet-al-te-duur spul vaak ergens wel op voorraad is...

[Verwijderd]

Hi all,

Ik ben bezig met het ontwerp van mijn nieuwe fileserver.

Op dit moment zijn het 2 zfs raidz1 arrays van 8x4TB en 8x2TB.
Dit zijn niet ideale ZFS nummers en de allignment van de 4TB ZFS pool klopt niet (512k op 4k disks)
Vandaar dat het anders moet.

Er is plek voor 16x 4TB en ik ga gebruik maken van een Intel 320 40GB SSD als ZIL en een Samsung 840 Evo of Crucial M500 als 120GB cache. Dat alles heeft mij tot 2 mogelijk scenario's heeft gebracht;


Scenario 1:
3x 5disk Raidz1 pool
60TB Bruto
48TB Netto

Voordeel:
Mogelijkheid tot hot-spare
Cache SSD actief op complete storage
Hoogste performance
Enkele 48TB pool
Vlottere resilvering (inschatting 3 dagen voor 1 vdev)

Nadeel:
Verlies van 3 disks/12TB tbv parity
2de disk vdev dood = alles verloren

------------------------------

Scenario 2:
1x 10disk Raidz2
1x 6disk Raidz2
64TB Bruto
48TB Netto

Voordeel:
Veilig ivm 2 parity disks
Cache en ZIL SSD actief op max 1 array

Nadeel:
Verlies van 4 disks/16TB ivm parity
1 32TB en 1 16TB mountpoint
Trage resilvering (inschatting 1 week)


Ik ben er nog niet helemaal uit. Suggesties?

[blauwe eend]

Verwijderd schreef op dinsdag 22 juli 2014 @ 09:21:
Hi all,

Ik ben bezig met het ontwerp van mijn nieuwe fileserver.

Op dit moment zijn het 2 zfs raidz1 arrays van 8x4TB en 8x2TB.
Dit zijn niet ideale ZFS nummers en de allignment van de 4TB ZFS pool klopt niet (512k op 4k disks)
Vandaar dat het anders moet.

.....

...

Ik ben er nog niet helemaal uit. Suggesties?

Als je veel disks hebt is het volgens mij beter om voor de Raidz2 te gaan. Stel je kiest voor Raidz1 en er gaat een disk kapot, als er bij het opbouwen dan een onherstelbare fout optreed zit je in de put, als je dan gekozen hebt voor Raidz2 dan draait ie gewoon verder.
Maar ik zit nog in de beginners schoenen dus ik kan je nog geen gebruikservaring geven

[ Voor 97% gewijzigd door blauwe eend op 22-07-2014 09:40 ]

[Paul]

2 mountpoints hoeft helemaal niet, in optie 1 stop je ook 3 vdevs in een pool, waarom in optie 2 niet?

Het hangt vooral af van de grootte van je disks, omdat het samenhangt met de Error Rate, die bij veel van de hier gebruikte schijven op 1 op 12 TB ligt: http://subnetmask255x4.wo...nd-how-that-impacts-raid/ Hoe groter een vdev ten opzichte va de parity, hoe kleiner de kans dat je een rebuild / resilver correct uit kunt voeren.

Ook qua performance maakt het uit: worst case scenario (en ik ben even kwijt welk type IO dat ook alweer was) is je pool niet sneller dan (vdevs) * (IOPs van 1 schijf). Meer vdevs maken je pool dus sneller.

Met 16 schijven kun je RAID Z1's maken van 3+1 (4 vdevs) of 4+1 (3 vdevs en 1 schijf over), of twee RAID Z2's van 6+2 maken voor 48 TB. 3x een 4+1 aligned het mooist, vraag is of je het aan 'durft' met een capaciteit die boven je URE ligt. Persoonlijk heb ik dat wel gedaan (want de belangrijkste data staat ook nog ergens anders) maar dat i een afweging die ieder voor zich moet maken

[FireDrunk]

Ik zou niet designen rond de URE spec, dat is gokken op een gemiddelde failure rate...
Het is *gemiddeld* misschien 1 op 12TB, maar 1 fout in de eerste byte, en daarna 12TB geen fouten, is ook 1 op 12TB...

In dat verhaaltje wat laatst ook geplaatst is staat ook, je kan prima een grote VDEV nemen, dat is helemaal niet erg. Zolang je geen Random IO nodig hebt...

12 schijven in 1 VDEV is dus niets om je voor te schamen... (12 disk RAIDZ2 met een RAID10 er naast voor extra backups).

[Paul]

FireDrunk schreef op dinsdag 22 juli 2014 @ 10:13:
Ik zou niet designen rond de URE spec, dat is gokken op een gemiddelde failure rate...
Het is *gemiddeld* misschien 1 op 12TB, maar 1 fout in de eerste byte, en daarna 12TB geen fouten, is ook 1 op 12TB...

Uiteraard zijn het gemiddeldes, maar als die URE niet boeiend is, waarom is er dan zoveel over te doen? Of, om de vraag anders te stellen, hoe bepaal je dan hoeveel schijven je maximaal in een VDEV stopt?

[Verwijderd]

Paul schreef op dinsdag 22 juli 2014 @ 10:02:
2 mountpoints hoeft helemaal niet, in optie 1 stop je ook 3 vdevs in een pool, waarom in optie 2 niet?

Het hangt vooral af van de grootte van je disks, omdat het samenhangt met de Error Rate, die bij veel van de hier gebruikte schijven op 1 op 12 TB ligt: http://subnetmask255x4.wo...nd-how-that-impacts-raid/ Hoe groter een vdev ten opzichte va de parity, hoe kleiner de kans dat je een rebuild / resilver correct uit kunt voeren.

Ook qua performance maakt het uit: worst case scenario (en ik ben even kwijt welk type IO dat ook alweer was) is je pool niet sneller dan (vdevs) * (IOPs van 1 schijf). Meer vdevs maken je pool dus sneller.

Met 16 schijven kun je RAID Z1's maken van 3+1 (4 vdevs) of 4+1 (3 vdevs en 1 schijf over), of twee RAID Z2's van 6+2 maken voor 48 TB. 3x een 4+1 aligned het mooist, vraag is of je het aan 'durft' met een capaciteit die boven je URE ligt. Persoonlijk heb ik dat wel gedaan (want de belangrijkste data staat ook nog ergens anders) maar dat i een afweging die ieder voor zich moet maken

een 4x4disk raidz1 zou inderdaad een hele mooie bezetting zijn, geeft qua udevs de meeste performance en qua capaciteit zit je precies op de URE.
Je hebt echter geen goede uitlijning i.v.m. 4k sectors. Het zijn Seagate 4000dm000 schijven, ik weet niet hoe vlot die zijn met sector emulatie.
Misschien moet ik dat maar voor lief nemen.


Scenario 1:
3x 5disk Raidz1
60TB Bruto
48TB Netto

Voordeel:
Mogelijkheid tot hot-spare
Cache/ZIL SSD actief op complete pool
Medium performance
Enkele 48TB mountpoint
Vlottere rebuild

Nadeel:
Verlies 3 disks/12TB
2de disk in vdev dood = alles verloren

------------------------------

Scenario 2:
1x 10disk Raidz2
1x 6disk Raidz2
64TB Bruto
48TB Netto

Voordeel:
Veilig ivm 2 parity disks
Cache/ZIL SSD actief op max 1 pool

Nadeel:
Verlies van 4 disks/16TB
1 32TB en 1 16TB mountpoint
Trage rebuild
Lage performance


------------------------------

Scenario 3:
4x 4disk Raidz1
64TB Bruto
48TB Netto

Voordeel:
Enkele 48TB mountpoint
Snelle rebuild
Cache/ZIL SSD actief op complete pool
Snelle performance

Nadeel:
Verlies van 4 disks/16TB
Geen perfecte allignment (4k disks)