Het grote ZFS topic

[Quindor]

Moikvin schreef op zaterdag 16 november 2013 @ 00:37:
[...]


Is natuurlijk moeilijk met support-contracten en het doe-het-zelven dat erbij komt kijken.

Bedankt voor de uitleg over evt. SLOG bij een ssd-zpool.


Iemand trouwens ervaring met VDI-omgevingen op ZFS?
Ik zit een beetje te puzzelen met wat nou eigenlijk het beste is voor zo'n omgeving.

Op dit moment zit er een bottleneck in de samsung evo 120gb als SLOG. De disks er achter redden het nog wel(stripe over 3 mirror pairs). Zo'n DDRdrive is nogal duur helaas.

Door linked-clone techniek kan er heel efficient gebruik gemaakt worden van ARC/L2ARC en diskspace maar toch zonde dat er een bottleneck aan de write kant zit.

Ik weet niet of een 840EVO nou echt de beste ZIL/SLOG SSD is. Ik weet dat ze een innovatieve structuur gebruiken en het opzich dus gezien kan worden als een 3GB SLC SSD met daarachter een 120GB TLC SSD (ZEER slecht in writes, gruwelijke latency en doorvoer en sloopt je SSD performance compleet als er zware writes op gebeuren).

Kan het zijn dat je wellicht door die 3GB heen schrijft of dat het mechanisme minder ideaal werkt dan verwacht als je erop blijft hameren?

Zoals ik het begrijp word er op de SSD nooit met meer dan queue depth 1 geschreven wat betekend dat de random single stream 4K performance belangrijk is. Welke daar het beste uitkomt weet ik zo niet, maar bijvoorbeeld de eerder genoemde Seagate 600 Pro of een SanDisk Extreme II en dergelijke zijn waarschijnlijk een beter keuze.

Zeker als je de SSD bijvoorbeeld gepartitioneerd zou hebben en ook als L2ARC in zet. Dat kan heel goed verklaren waarom de SSD spontaan kan instorten.

[ Voor 3% gewijzigd door Quindor op 16-11-2013 00:48 ]

[tvwes]

@Quindor
Ik weet dat er nieuwe producten aankomen die de DDRdrive vermoedelijk overbodig maken. Niet verder vragen, NDA's etc.

De definitie van enterprise is lastig. De linker hand van de enterprise heeft vaak geen idee wat de rechter doet. Je zal vaak meerdere storage systemen aantreffen van verschillende leveranciers. Ik tref vaak ZFS aan bij een (research) project niet zo snel bij de boekhouding. Universiteiten en onderzoeks instituten zijn ook grote gebruikers.
Ik verwacht niet een grotere markt penetratie. Klanten zijn dermate bang, en fear sells, en hebben ook voldoende geld dat de EMC's HDS's NetApp's en vrienden voorlopig de markt in hun greep houden. Op wat kruimels na. ZFS heeft unieke features maar het ijzer van bijv EMC of HDS is allemaal top spul.

[Moikvin]

Quindor schreef op zaterdag 16 november 2013 @ 00:44:
[...]

Ik weet niet of een 840EVO nou echt de beste ZIL/SLOG SSD is. Ik weet dat ze een innovatieve structuur gebruiken en het opzich dus gezien kan worden als een 3GB SLC SSD met daarachter een 120GB TLC SSD (ZEER slecht in writes, gruwelijke latency en doorvoer en sloopt je SSD performance compleet als er zware writes op gebeuren).

Kan het zijn dat je wellicht door die 3GB heen schrijft of dat het mechanisme minder ideaal werkt dan verwacht als je erop blijft hameren?

Zoals ik het begrijp word er op de SSD nooit met meer dan queue depth 1 geschreven wat betekend dat de random single stream 4K performance belangrijk is. Welke daar het beste uitkomt weet ik zo niet, maar bijvoorbeeld de eerder genoemde Seagate 600 Pro of een SanDisk Extreme II en dergelijke zijn waarschijnlijk een beter keuze.

Zeker als je de SSD bijvoorbeeld gepartitioneerd zou hebben en ook als L2ARC in zet. Dat kan heel goed verklaren waarom de SSD spontaan kan instorten.

Ik had al een vermoeden dat hij niet ideaal is. Krijg nu de volgende resultaten.


Draaien nu op zich al aardig wat VM's op maar zag tijdens deze test via gstat geen bottleneck qua %busy.

[Quindor]

Moikvin schreef op zaterdag 16 november 2013 @ 01:15:
[...]


Ik had al een vermoeden dat hij niet ideaal is. Krijg nu de volgende resultaten.
[afbeelding]

Draaien nu op zich al aardig wat VM's op maar zag tijdens deze test via gstat geen bottleneck qua %busy.

Dit is over iSCSI of NFS of wat?

Verder lijkt het best redelijk behalve dat je 4K 32Thread write echt gruwelijk laag is, dat betekend wellicht dat de SSD inderdaad door zijn write 'SLC' cache heen is, maar dat is lastig te verifiëren.

[FireDrunk]

tvwes schreef op vrijdag 15 november 2013 @ 18:49:
@Firedrunk,

ik zie niets wat overduidelijk fout configureerd is aan de zpool's noch de datasets. atime=off compression=on logbias=latency. Laat je datapool aub nog even op version=28 staan, dat geeft je meer mogelijkheden. Als je de async snapshot destroy niet nodig hebt wacht dan nog even met upgraden. Ook de lz4 compressie kan wel even wachten.

De reden van geen windows is dat daar veel minder tools voor zijn om een goede diagnose te stellen.

Later post je een prachtige ATTO score die overeenkomt met een volle gbit lijn??? Hoe kan dat nu?

Dat vroeg ik mij ook af, blijkbaar is er dus niets mis.

Dan doe je drie testjes met verwarrende begrippen en niet beschreven procedure/applicatie en onbekende target. Ik denk dat ik snap wat je hebt gedaan en het ziet er wel plausibel uit maar wat nadere uitleg zou welkom zijn.

Er zijn drie relevante begrippen
-de ZIL
-een SLOG
-de optie sync van een ZFS dataset

-de ZIL ZFS Intent Log is een transactie log waarin uit te voeren writes met de SYNC vlag komen te staan. Zodra de write is opgeslagen in de ZIL beantwoord ZFS de opdracht met afgehandeld. Maar dat is niet alles. Tegelijk verzamelt ZFS deze writes in reguliere asynchrone TXG's. Deze worden periodiek als grote stream weggeschreven. Heel veel random writes worden plots een efficiente stream. De ZIL is er altijd en kan niet worden disabled, wel kan je er geen gebruik van maken.
-de SLOG, Separate Intent Log is een block device/drive/lun waarop de ZIL kan worden geschreven. Door een SLOG toe tevoegen aan je zpool voorkom je dat de ZIL je data vdevs belast. Zonder SLOG wordt per write eerst een entry voor de ZIL gemaakt en daarna als de async buffer vol zit of tijd om te flushen wordt de async buffer weggeschreven. Netto schrijf je dan twee keer de data, een keer met per write een flush en nog een keer als grote stream als de TXG's worden weggeschreven. Dat zorgt ervoor dat je writes op een NFS datastore zo slecht zijn. Daar bovenop komt dat raidz heel slecht is in random i/o. Tel uit je verlies.
-de optie sync van een ZFS dataset. Door hier sync=disabled in te stellen bypass je de ZIL voor alle write naar deze dataset. Veel NFS servers doen dit ook, die liegen als ze een sync write binnen krijgen, en geven onmiddelijk ok terug. De data staat dan nog in ram of diverse caches. Bij een reset/powerloss ben je de data kwijt. De sync=disabled in te stellen voor een dataset kan je standaard 5 seconden aan writes verliezen.

Samenvattend:
-een SLOG kan je toevoegen aan je zpool. (je kan geen ZIL toevoegen, die is er altijd)
-de ZIL kan je bypassen via sync=disabled. (je kan de ZIL niet uitschakelen)

Dan nog even voor het testen. Maak altijd een extra vmdk aan als test target. Nooit op je boot disk, achtergrond i/o verstoord de test. Je kan je test vmdk dan ook op een andere datastore zetten, bijv met een andere compressie instelling.

Hier is een oneliner om je zpool te testen:
> dd if=/dev/zero of=./1GB.tmp oflag=sync bs=4K count=256K
Dit is het maximale wat je van je zpool kan verwachten.
Dit zijn de relevante varianten die je zou moeten testen om de extremen op te zoeken:
ZET EERST COMPRESSIE UIT VOOR JE DATASET of test of /dev/random voldoende snel data kan leveren
-zpool zonder SLOG en dataset met sync=enabled en dd zonder de sync flag -> de maximale sequentiele snelheid van je zpool met 4K writes (de hooste snelheid)
-zpool zonder SLOG en dataset met sync=enabled en dd MET de sync flag -> de maximale sequentiele snelheid van je zpool met sync 4K writes (de laagste snelheid)
-zpool zonder SLOG en dataset met sync=DISABLED en dd MET de sync flag -> zou gelijk moeten zijn aan de eerste test.
-zpool met SLOG en dataset met sync=ENABLED en dd MET de sync flag -> ligt er tussenin. performance hangt af van de SLOG. Meerdere SLOGS stripen helpt. Een ramdisk is een slecht plan. Beter om te kiezen voor sync=disabled.

Begrijp ik allemaal, ik heb nergens ZIL uitgezet, maar een SLOG gebruikt, ik heb de termen door de war gehaald. De eerste 2 screenshots zijn testjes met IOmeter met de settings die ik iets later post. (4K read, 16K read, 4K write, 16K write,32 outstanding IO's)

Ook je DD oneliner gebruik ik al jaren, het leuke is dat je wel -oflag=sync kan doen, maar ESXi heeft toch zijn eigen wil. ALLE writes in ESXi zijn namelijk synced, dus dat is helemaal niet nodig.

Deze testen lokaal uitgevoerd leveren de maximaal te verwachten prestaties op. Random i/o doet het slechter net als kleinere blocksizes. Dit is een redelijke test om de maxima te bepalen. Rommelen met de blocksize van dd zal hogere scores opleveren maar als dat niet overeen komt met de writes van ESXi en dan hou je jezelf voor de gek. 4K tot max 64K is wat je kan verwachten, verwacht eerder 4K dan 64K. Daarnaast doet ESXi nog een heleboel kleine writes. DTrace is your friend...

Als je nu ook dd uitvoerd in een vm weet je hoeveel je verliest door de hele keten van guest, esxi, nfs netwerk switch etc. Boven de 120MB/sec kom je niet met GE en 8MB/sec vond ik heel goed voor een RAIDZ1 pool zonder SLOG.

8MB/s was sequentieel, niet 4k random writes. En dus erg laag. 8MB/s aan random IO was inderdaad leuk geweest.

Succes, ik hoop dat je de testen hierboven wilt uitvoeren en posten. Ik ben benieuwd!

Ik heb zo goed als alle tests al laten zien, welke wil je nog expliciet zien?

[tvwes]

@Firedrunk

Goedemorgen,

de grote post is ook als algemeen naslag werkje bedoeld.

Laten we eerst kijken naar de mogelijkheden van je zpool voordat we verder gaan kijken.

Ook je DD oneliner gebruik ik al jaren, het leuke is dat je wel -oflag=sync kan doen, maar ESXi heeft toch zijn eigen wil. ALLE writes in ESXi zijn namelijk synced, dus dat is helemaal niet nodig.

ESXi heeft geen eigen wil en doet niks onvoorspelbaars. Alle writes op een NFS datastore worden sync uitgevoerd. (De reden is om data verlies tegen te gaan. In alle gevallen. En is daarom niet instelbaar. VMware wil simpelweg geen gezeur en dwingt jouw een goede NAS te kopen)
Dus alle ESXi datastore NFS writes worden met de sync vlag uitgevoerd. De ZIL wordt daardoor ALTIJD gebruikt. (Tenzij je op die dataset de optie sync=disabled hebt staan) Mijn dd oneliner met de oflag=sync optie is de enige correcte manier om ESXi NFS writes te simuleren. Tuurlijk er zijn andere programma's en instellingen mogelijk, prima zolang iedere write maar sync is. Nu het belang van mijn vier voorgestelde testjes. Met deze vier krijg je inzicht in wat je maximaal kan verwachten. Alle verstorende factoren als netwerk, ESXi en guest zijn weg. Dat heet een baseline verkrijgen. Pas als je dat weet kan je bepalen hoe ver je waarden in je guest afwijken.

Ook je DD oneliner gebruik ik al jaren, het leuke is dat je wel -oflag=sync kan doen, maar ESXi heeft toch zijn eigen wil. ALLE writes in ESXi zijn namelijk synced, dus dat is helemaal niet nodig.

Ik hoop dat ik voldoende heb uitgelegd dat dd met oflag=sync WEL nodig is.

Die 8MB/seq sequentieel lijkt me helemaal niet onredelijk op een RAIDZ1 pool zonder SLOG voor sync writes.

Ik heb zo goed als alle tests al laten zien, welke wil je nog expliciet zien?

Ik ben veel langer bezig geweest dit allemaal uit te zoeken, op te schrijven en wat tests voor je te bedenken dan jij bezig bent om die 4 testjes die ik vroeg even uit te voeren. Ik zou het erg op prijs stellen als je die vier even doet en post. Zie het ook als algemene info. (Vergeet niet je compressie even uit te zetten of het in een andere dataset zonder compressie te doen) Een printje van je commando's en output (zal zo'n 20 regels bij elkaar) zou ook goed zijn. Dan kunnen anderen het overnemen.

Voor de testen zal een SLOG moeten toevoegen en verwijderen. Dat is niet gevaarlijk, de ZIL zal alleen verplaatst worden.
#zpool add mpool log [SLOG device]
#zpool remove mpool [SLOG device]

LET OP dat je niet het woord log vergeet bij de add!

[ Voor 5% gewijzigd door tvwes op 16-11-2013 09:56 ]

[FireDrunk]

Ik heb een Linux VM, op NFS staan *in* ESXi, als ik daar op de lokale root test, heb je dus geen oflag=sync nodig, want dan gaat het door ESXi heen, en wordt het automatisch sync, dat was wat ik bedoelde.

Maar test loopt. Eerste test op lokale datastore loopt nu met iets van 2MB-3MB/s (4GB test size, dus dat duurt wel even...)

[FireDrunk]

Linux VM op ESXi via datastore (VMDK)
Sync aan, geen SLOG

root@LLAHDL01:/root# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
29675+0 records in
29675+0 records out
121548800 bytes (122 MB) copied, 1443.88 s, 84.2KB/s

Ik heb deze maar afgebroken, ging zo langzaam... Rare is dat ik tijdens deze test continue 2-3MB/s in zpool iostat -v 1 zie.

Sync uit, geen SLOG

root@LLAHDL01:/root# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 190.551 s, 2.1 MB/s

Hier zie ik duidelijk breathing op ZFS (12MB/s...0...0...0...0... 12MB/s...0....0....0...0)

Sync standard, SLOG (256GB 840Pro, niet underprovisioned)

root@LLAHDL01:/root# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 897.043 s, 457 kB/s

Hier zie ik continue 4MB/s op de ZIL, maar OS vind dat het allemaal heel wat trager gaat...

Linux VM op ESXi via NFS Mount in de VM zelf.
Sync aan, geen SLOG

root@LLAHDL01:/mnt/data# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 1511.06 s, 271 kB/s

Sync uit, geen SLOG

root@LLAHDL01:/mnt/data# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 55.789 s, 7.3 MB/s

sync standard, SLOG (256GB 840Pro, niet underprovisioned)

root@LLAHDL01:/mnt/data# dd oflag=sync if=/dev/zero of=test.000 bs=4k count=100000
100000+0 records in
100000+0 records out
409600000 bytes (410 MB) copied, 253.906 s, 1.6 MB/s

[idef1x]

Iemand die weet wat ze nu precies bedoelen bij zpool export :

For pools to be portable, you must give the zpool command whole
disks, not just slices, so that ZFS can label the disks with porta-
ble EFI labels. Otherwise, disk drivers on platforms of different
endianness will not recognize the disks.

Het gaat mij om het "whole disk command". Hoe ziet dat commando eruit?
Ik ben net met zfs begonnen dus zal we een domme vraag zijn wellicht, maar toch...

De reden van de vraag is dat ik net een dump van mijn "oude" software RAID5 gebaseerde (Ubuntu) op een externe USB disk heb gezet, waarop ik een zfs pool heb gezet (gehele externe disk als /dev/disk/by-id). Voor het afsluiten heb ik de pool gexporteed d.m.v. "zpool export <poolnaam>. De "oude" RAID5 heb ik nu veranderd in een RAIDZ1 pool en wil dus nu de backup terugzetten. Nu dacht ik slim te zijn en die externe disk uit zijn behuizing te slopen en rechtstreeks aan een vrije SATA poort te hangen want dat schiet dan tenminste op met terugzetten dacht ik. Maar hij kan de pool nu niet meer vinden. Ook niet met een zpool import -d /dev/sdf . Waarschijnlijk omdat het disk/by-id nu niet meer gelijk is?
Misschien dat het met dat "whole commando" nog vindbaar is te maken? Anders moet ik nog maar een dagje wachten tot de restore via usb klaar is

[FireDrunk]

Heb je al geprobeerd om de disk weer terug te plaatsen in de USB case? Er zijn namelijk een aantal USB kastjes die niet netjes de disk 100% doorgeven, maar een paar sectoren voor zichzelf houden. De grootte van de disk is dus anders buiten het kastje en misschien krijgt hij daardoor wel een ander ID.

[idef1x]

VIa USB krijgt ie id: usb-HGST_Touro_Desk_3.0_31001303180002400105-0:0

en rechtstreeks via sata iets van ata-<nogiets> (kan ik nu even niet zien want hij zit nu via usb te restoren.

Ik had eigenlijk wel verwacht dat ie met een zpool import wel iets zou moeten zien.

[tvwes]

@Firedrunk,

Goedemiddag, dank voor de testen. Je bent precies aan de verkeerde kant gaan testen, namelijk in de VM. De waardes zijn absurd laag. Dus zal er nog wel wat aan de hand zijn. Deze meting is op zich niet waardeloos alleen weet je nu nog niks. Is dit een probleem van de VM? Van ESXi? Van je netwerk? Van je NAS? Van ZFS?
Wat ik bedoelde was de 4 testen direct op de je ZFS filesysteem te doen. Als het even kan zou ik je ook willen vragen om je ESXi. machines even uit te zetten of los te nemen van het netwerk. Zodat er geen (NFS) verkeer de NAS beinvloed. Ja ik weet dat je uiteindelijk graag snelle io in je vm wilt. Maar zolang we niet weten wat de prestaties van je NAS zijn kan je niks zinnigs zeggen over de metingen die je vanochtend hebt gedaan. Ik zag dat je de testen met 4K hebt gedaan, eigenlijk had ik om 8K gevraagd omdat dat wat realistischer is maar doe nu de andere ook maar op 4K.

Succes en ik ben benieuwd.

[FireDrunk]

oflag=sync bestaat niet op BSD, daarom kan ik die tests niet eens doen Daarom dacht ik dat je bedoelde in de vm

[tvwes]

@Firedrunk

mmm ok. Kan je de package benchmarks/xdd toevoegen als je xdd nog niet op je systeem hebt staan?

Dan zoek ik even de syntax voor xdd bij elkaar.

[tvwes]

Ik moet even een slag om de arm houden want ik heb geen xdd bij de hand. Laat aub ook even weten van de versie is.

Dit zouden ze moeten zijn:
# xdd -op write –targets 1 /mnt/zpool/esxdatastore/xddtest.tmp -blocksize 512 –reqsize 8 -mbytes 1024 –verbose –passes 1

# xdd -op syncwrite –targets 1 /mnt/zpool/esxdatastore/xddtest.tmp -blocksize 512 –reqsize 8 -mbytes 1024 –verbose –passes 1

[FireDrunk]

[root@NAS /datapool/lagelanden]# zfs set sync=standard datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1023 -verbose -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 19:32:21 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 21741) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 21741
                Thread ID, 21741
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 512
                Request size, 8, blocks, 4096, bytes
                Number of Requests, 261888
                Start offset, 0
                Number of MegaBytes, 1023
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, disabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096
TARGET   Average     0  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096
         Combined    1  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096
Ending time for this run, Sat Nov 16 19:32:27 2013

[root@NAS /datapool/lagelanden]# zfs set sync=disabled datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1023 -verbose -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 19:33:00 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 21756) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 21756
                Thread ID, 21756
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 512
                Request size, 8, blocks, 4096, bytes
                Number of Requests, 261888
                Start offset, 0
                Number of MegaBytes, 1023
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, disabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
TARGET   Average     0  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
         Combined    1  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
Ending time for this run, Sat Nov 16 19:33:05 2013

[root@NAS /datapool/lagelanden]# zfs set sync=standard datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1024 -verbose -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 19:36:57 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 21771) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 21771
                Thread ID, 21771
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 512
                Request size, 8, blocks, 4096, bytes
                Number of Requests, 262144
                Start offset, 0
                Number of MegaBytes, 1024
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, disabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
TARGET   Average     0  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
         Combined    1  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
Ending time for this run, Sat Nov 16 19:37:08 2013

[root@NAS /datapool/lagelanden]# zfs set sync=disabled datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1024 -verbose -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 19:38:03 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 21773) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 21773
                Thread ID, 21773
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 512
                Request size, 8, blocks, 4096, bytes
                Number of Requests, 262144
                Start offset, 0
                Number of MegaBytes, 1024
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, disabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
TARGET   Average     0  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
         Combined    1  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
Ending time for this run, Sat Nov 16 19:38:09 2013

Het gaat allemaal zo snel, dat ik niet de moeite heb genomen om met een ZIL te testen, als je dat graag wil, kan ik dat wel even doen, maar het voegt weinig toe volgens mij.

[tvwes]

@Firedrunk

yes! Ik weet niet waar die fout vandaan komt. Maar heb je via zpool iostat of iostat of geluid kunnen vaststellen dat er wat is weggeschreven?

Welke tag gebruik je voor de output?

Dit is mijn interpretatie van de resultaten van boven naar beneden:

[root@NAS /datapool/lagelanden]# zfs set sync=standard datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1023 -verbose -passes 1
                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096
TARGET   Average     0  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096
         Combined    1  1    1072693248   261888     5.601   191.513     46756.15    0.0000    93.03   write        4096

Je schrijft 1GB in 4K blocken met 191MB/sec weg. Dit is voor een raidz1 pool best redelijk alleen zie ik al dat de test te kort duurt. Je moet minimaal 30 sec runnen. Wil je deze test aub nogmaals runnen maar met 8GB ipv 1GB Hier onder mijn output ter vergelijking

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
mpool                       964G  2.68T      0  1.98K      0   250M
  mirror                    482G  1.34T      0    991      0   122M
    c1t50024E9204294EE5d0      -      -      0    991      0   122M
    c1t50024E900499258Fd0      -      -      0  1.06K      0   133M
  mirror                    482G  1.34T      0  1.01K      0   128M
    c1t50024E9004992426d0      -      -      0  1.12K      0   141M
    c1t50024E9004992406d0      -      -      0  1.01K      0   128M
logs                           -      -      -      -      -      -
  c3t3d0                   1.40M  1007M      0      0      0      0
-------------------------  -----  -----  -----  -----  -----  -----
                     T  Q       Bytes        Ops      Time      Rate       IOPS   Latency     %CPU
TARGET   PASS0001    0  1    8412725248   2053888    35.720   235.517     57499.18    0.0000    99.80                                                               
TARGET   Average     0  1    8412725248   2053888    35.720   235.517     57499.18    0.0000    99.80                                                               
         Combined    1  1    8412725248   2053888    35.720   235.517     57499.18    0.0000    99.80                                                               
Ending time     for     this run, Sat Nov 16 20:00:41 2013

Het eerste stuk is een blokje uit zpool iostat -v mpool 2.
Je ziet dat ik 2 mirrors hier heb en een SLOG
Iedere disk schrijft 125MB/sec weg maar het totaal is geen 500MB/sec maar 250MB/s! Dat komt door de mirrors net schrijf je per mirror zo snel als de langzaamste drive.
Daarna het resultaat van xdd met 8GB de uiteindelijke snelheid is 235MB/sec. (Ik had net een piek sample gepakt uit iostat) Maar het resultaat bij mij ligt helemaal in lijn met de verwachting.

Volgende:

[root@NAS /datapool/lagelanden]# zfs set sync=disabled datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1023 -verbose -passes 1

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
TARGET   Average     0  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
         Combined    1  1    1072693248   261888     5.177   207.211     50588.53    0.0000    96.74   write        4096
Ending time for this run, Sat Nov 16 19:33:05 2013

Op een meetfout na door de te korte test. Deze zou ook over gedaan moeten worden met 8GB. Ligt het resultaat in de buurt van de eerste. Dat zou ook moeten want of sync=enabled of sync=disabled maakt niet uit voor async writes (wat je weer deed als bij de eerste test)

De derde:

[root@NAS /datapool/lagelanden]# zfs set sync=standard datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1024 -verbose -passes 1
                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
TARGET   Average     0  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
         Combined    1  1    1073741824   262144    10.875    98.733     24104.80    0.0000    59.55   write        4096
Ending time for this run, Sat Nov 16 19:37:08 2013

Ziet er weer niet onredelijk uit. De test zou iets langer mogen duren. Maar deze 100MB/sec is het max wat je kan verwachten als je vanuit een vm gaat schrijven (bij een stream van 4K writes) Kan je aub bevestigen via zpool iostat -v dat je ziet dat er wordt geschreven naar je SLOG (vergeet niet de size omhoog te zetten naar bijv 2GB)

Hier mijn output

$ dd if=/dev/zero of=4GB.tmp oflag=sync bs=4096 count=1000000
1000000+0 records in
1000000+0 records out
4096000000 bytes (4.1 GB) copied, 180.902 s, 22.6 MB/s

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
mpool                       970G  2.68T      0  5.55K      0  44.4M
  mirror                    485G  1.34T      0      0      0      0
    c1t50024E9204294EE5d0      -      -      0      0      0      0
    c1t50024E900499258Fd0      -      -      0      0      0      0
  mirror                    485G  1.34T      0      0      0      0
    c1t50024E9004992426d0      -      -      0      0      0      0
    c1t50024E9004992406d0      -      -      0      0      0      0
logs                           -      -      -      -      -      -
  c3t3d0                    383M   625M      0  5.55K      0  44.4M
-------------------------  -----  -----  -----  -----  -----  -----

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
mpool                       970G  2.68T      0  5.81K      0  75.6M
  mirror                    485G  1.34T      0    206      0  15.8M
    c1t50024E9204294EE5d0      -      -      0    158      0  15.8M
    c1t50024E900499258Fd0      -      -      0    157      0  15.8M
  mirror                    485G  1.34T      0    228      0  16.7M
    c1t50024E9004992426d0      -      -      0    160      0  16.7M
    c1t50024E9004992406d0      -      -      0    162      0  16.7M
logs                           -      -      -      -      -      -
  c3t3d0                    383M   625M      0  5.38K      0  43.1M
-------------------------  -----  -----  -----  -----  -----  -----

22MB/sec met 4K writes (dit zijn de ESXi NFS writes) Als ik de write size omhoog breng is het minder dramatisch maar dit is het beste wat je kan verwachten. Als ik een SLOG bijzet gaat de perfomance natuurlijk omhoog. Ik klaag hier niet over. Ik heb nog even de output van 32K writes geplakt:

$ dd if=/dev/zero of=4GB.tmp oflag=sync bs=32K count=125000
125000+0 records in
125000+0 records out
4096000000 bytes (4.1 GB) copied, 51.8208 s, 79.0 MB/s

                              capacity     operations    bandwidth
pool                       alloc   free   read  write   read  write
-------------------------  -----  -----  -----  -----  -----  -----
mpool                       970G  2.68T      0  3.21K      0   176M
  mirror                    485G  1.34T      0    454      0  47.3M
    c1t50024E9204294EE5d0      -      -      0    412      0  47.8M
    c1t50024E900499258Fd0      -      -      0    407      0  47.3M
  mirror                    485G  1.34T      0    527      0  47.5M
    c1t50024E9004992426d0      -      -      0    429      0  47.5M
    c1t50024E9004992406d0      -      -      0    428      0  47.5M
logs                           -      -      -      -      -      -
  c3t3d0                    145M   863M      0  2.25K      0  81.1M
-------------------------  -----  -----  -----  -----  -----  -----

Ook al schrijf ik nu 8 keer zoveel data weg de throughput gaat maar van 20 naar 80 MB/sec Slechts 4x ipv de verwachte 8x. Dat heeft te maken met het flushen na iedere write.

Laatste test van jouw:

[root@NAS /datapool/lagelanden]# zfs set sync=disabled datapool/lagelanden
[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -targets 1 test.000 -blocksize 512 -reqsize 8 -mbytes 1024 -verbose -passes 1

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
TARGET   PASS0001    0  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
TARGET   Average     0  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
         Combined    1  1    1073741824   262144     5.138   208.968     51017.58    0.0000    99.59   write        4096
Ending time for this run, Sat Nov 16 19:38:09 2013

Nu bypass je de ZIL met je sync writes en schrijf je op de async snelheid uit de eerste twee testen. Doordat de test te kort duurt klopt het antwoord niet. Ook hier zou de test zo'n 30 sec of langer moeten duren. Als je tijdens de test stroom zou verliezen ben je max 5 sec aan data kwijt. Dat is het risico van deze setting. Voor readonly systemen als mediaserver in een vm. Maakt dat weinig uit. Voor een database of mailstore heel veel. Daarnaast het je het gezeur dat je je guest OS's moet gaaan fsck'en etc.

Maar ai wat lees ik nu al deze testen waren zonder SLOG? Weet je dat zeker?
Het andere is dat xdd onder solaris erg funky doet met syncwrite ik moest terug naar dd voor betrouwbare metingen. Daar moet ik in duiken

[FireDrunk]

Goddomme, moet je natuurlijk wel ff dubbel controleren of je compressie uit staat domme ukkel...

Ik moest me toch even verdiepen in de tool.
Het goede commando is:

Zonder SLOG

[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -dio -targets 1 test.000 -blocksize 4096 -mbytes 16384 -reqsize 1 -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 21:17:40 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 24941) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 24941
                Thread ID, 24941
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 4096
                Request size, 1, blocks, 4096, bytes
                Number of Requests, 4194304
                Start offset, 0
                Number of MegaBytes, 16384
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, enabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
         Combined    1  1   17179869184   4194304   105.026   163.578     39935.92    0.0000    84.04   write        4096
Ending time for this run, Sat Nov 16 21:19:26 2013

Met SLOG.

[root@NAS /datapool/lagelanden]# zpool add datapool log gpt/256GB-A
[root@NAS /datapool/lagelanden]# xdd -op write -syncwrite -dio -targets 1 test.000 -blocksize 4096 -mbytes 16384 -reqsize 1 -passes 1

IOIOIOIOIOIOIOIOIOIOI XDD version 6.5.013007.0001 IOIOIOIOIOIOIOIOIOIOIOI
xdd - I/O Performance Inc. Copyright 1992-2007
Starting time for this run, Sat Nov 16 21:20:08 2013

ID for this run, 'No ID Specified'
Maximum Process Priority, disabled
Passes, 1
Pass Delay in seconds, 0
Maximum Error Threshold, 0
Target Offset, 0
I/O Synchronization, 0
Total run-time limit in seconds, 0
Output file name, stdout
CSV output file name,
Error output file name, stderr
Pass seek randomization, disabled
File write synchronization, disabled
Pass synchronization barriers, enabled
Number of Targets, 1
Number of I/O Threads, 1

Seconds before starting, 0
(PID 25090) xdd: Could not lock 4096 bytes of memory for RW BUFFER
Reason: Resource temporarily unavailable
        Target[0] Q[0], test.000
                Target directory, "./"
                Process ID, 25090
                Thread ID, 25090
                Processor, all/any
                Read/write ratio,  0.00, 100.00
                Throttle in MB/sec,   0.00
                Per-pass time limit in seconds, 0
                Blocksize in bytes, 4096
                Request size, 1, blocks, 4096, bytes
                Number of Requests, 4194304
                Start offset, 0
                Number of MegaBytes, 16384
                Pass Offset in blocks, 0
                I/O memory buffer is a normal memory buffer
                I/O memory buffer alignment in bytes, 4096
                Data pattern in buffer, '0x00'
                Data buffer verification is disabled.
                Direct I/O, enabled
                Seek pattern, sequential
                Seek range, 1048576
                Preallocation, 0
                Queue Depth, 1
                Timestamping, disabled
                Delete file, disabled

                     T  Q       Bytes      Ops    Time      Rate      IOPS   Latency     %CPU  OP_Type    ReqSize
         Combined    1  1   17179869184   4194304    86.112   199.506     48707.49    0.0000    94.79   write        4096
Ending time for this run, Sat Nov 16 21:21:35 2013

Geen idee wat ik er van moet vinden, ik zie overigens wel wat traffic op de SLOG, maar niet zoals jij dat ziet.

[tvwes]

@Firedrunk
het enige wat ik er nu al van kan zeggen is dat zonder compressie met of zonder SLOG deze resultaten nooit via NFS gehaald kunnen worden. Ik haal op een snellere pool dan jij, Ik heb immers 2 vdevs en jij maar 1 in async met 4K 235MB/sec en maar 22MB/sec naar mijn DRAM SLOG met sync writes. Jij haalde nu 160 MB/sec zonder slog en 200 MB/sec met SLOG. Je zou via zpool iostat dan ook minstens 200MB/sec op je SLOG moeten zien. Ik betwijfel of je dat ziet. Ik vermoed dat xdd de boosdoener is. Je hebt bijv nu de -dio flag toegevoegd die ik ook niet had. Ik zal me eerst daarin moeten verdiepen. Ik zal de ESXi writes dtracen en dan kijken hoe ik xdd moet aansturen om hetzelfde te bereiken.
Het spijt me dat ik je nog niet verder heb kunnen helpen. Die eerste twee testen kloppen redelijk maar duurden te kort. Alles testen met sync zijn op dit moment wat mij betreft onbetrouwbaar. Ooit poste je 8MB/sec vanuit je vm. Ik doe lokaal met een DRAM SLOG met 4K writes 22MB/sec. Dan vind ik die 8MB/sec zelfs nog heel goed als dat zonder SLOG was.
Ik hoop dat het je duidelijk is wat ik probeer vast te stellen. Bij mij kan ik lokaal max 22MB/sec schrijven vanuit een vm doe ik iets van 19MB/sec. Het verschil is overhead van de guest, ESXi en netwerk. Omdat ik weet dat 22MB/sec het maximale is ga ik niet verder zoeken als ik 19MB/sec meet in de guest. Als ik in de guest nu 10MB/sec zou meten weet ik dat er ergens een botleneck is. Dit probeer ik voor je uit te zoeken. Alsmede een plan van aanpak voor een ieder die wil weten wat je kan verwachten in je ESXi guest.

To be continued, ik moet eerst dat xdd uitzoeken.

Oh en hoe maak jij die monospaced witte blokken in je posts?

[FireDrunk]

[ pre ] [/pre] gebruiken. En spijt hoef je niet te hebben hoor Dat is wel het laatste waar we hier op zitten te wachten

Ik ben al lang blij dat je input levert!

[ Voor 73% gewijzigd door FireDrunk op 16-11-2013 23:21 ]

[tvwes]

Weer wat geleerd.

Ik baal een beetje van xdd of dd zonder oflag=sync en dat ik niet zelf achter je toetsenbord zit.

Ik moet even wat tijd steken in het vinden van een tool die op freebsd betrouwbaar de ESXi NFS writes kan simuleren.

Welke FreeBSD gebruik je ook alweer?

[FireDrunk]

10.0-BETA3.

Vandaag echt mijn cluster in gebruik genomen en een heel aantal VM's weer eens opgestart, en ik moet zeggen, de snelheid is ook echt niet hoog... Zelfs met sync=disabled stotteren de VM's toch nogal eens. Als ik de statistieken van ESXi mag geloven zit er een flinke latency op de datastore.



Misschien toch maar een setje SSD's als datastore gaan gebruiken, met een async snapshot backup naar de grote pool.

[ Voor 106% gewijzigd door FireDrunk op 17-11-2013 11:36 ]

[tvwes]

Ik ben bezig maar het is allemaal een beetje zozo.
xdd heeft een bug, ik kan alleen de source van versie 6.2 downloaden en jij hebt 6.5 waar ik geen source van kan vinden.
ik heb een gnu compatible dd, jij niet
er is geen gemeenschappelijke tool die de juiste io's kan generen, misshien op sysbench na maar dat is weer veel te lomp qua dependencies.

ik zal FreeBSD 10 installeren en een werkende tool daarin voor je compileren.
pas als ik weet je lokale zpool te bieden heeft kunnen we verder.

Je zou mij kunnen helpen met het vinden een werkende link naar de tarball van xdd zoals freebsd die gebruikt. De site van de auteur heeft het niet staan en sourceforge heeft een andere versie.

[FireDrunk]

ftp://ftp.debian.nl/pub/f...istfiles/xdd65.013007.tgz

Is Bonnie++ niet een optie?

[ Voor 19% gewijzigd door FireDrunk op 17-11-2013 12:14 ]

[tvwes]

Op zich goed idee maar ik vind dat een zeer matige tool.
Zie ook de lovende recensie hier:
https://blogs.oracle.com/roch/entry/decoding_bonnie

Dank je voor de xdd link. Die vesie heeft precies hetzelfde gebruik als mijn 6.2 Het is geen bug maar een feature. De sync wordt alleen uitgevoerd op het einde van de pass.

Ik ben daar nu een patch te maken die in principe portable zou moeten en een nieuwe optie bied om permanent sync te schrijven next als ESXi.
Ik heb me nooit gerealiseerd dat dd in FreeBSD al die features mist. xdd gebruik ik niet maar zag er leuk uit. Er zijn alleen en aantal issues mee. Die probeer ik nu te fixen.

[FireDrunk]

Mooi!

@tvwes, zou jij het aanraden om op een pool van alleen SSD's Deduplicatie aan te zetten? Ik heb vandaag 2 840 Pro's 128GB vrijgespeeld door wat te schuiven met hardware, hier zou ik al mijn VM's op kunnen zetten, maar ik weet niet of alles gaat passen. Zou het veel helpen? (90% van de VM's is Windows 2012R2)

[ Voor 95% gewijzigd door FireDrunk op 17-11-2013 21:22 ]

[tvwes]

@Firedrunk
Op zich denk ik dat best gaat. Dedup kan je aanzetten per dataset, dus als je het beperkt tot een parr honderd GB moet dat wel gaan. Doe het niet met minder dan 16GB ram.
Je weet dat ik een groot voorstander ben van vm's op ssd's gecombineerd met een zpool van harddisks. Je kan probleemloos twee datastores aanmaken in ESXi en bijv je vm boot vmdk's op de ssdstore plaatsen en je D-schijf op roeststore plaatsen. Ja, je hebt niet je gehele vm in een enkele directory staan maar er is wel veel voor te zeggen. Al je windows vm's delen files/blocken dus zal dedup het goed doen. Je user data vaak veel minder, alles van multimedia en/of gecomprimeerd zal een dedup ratio van 0 halen. Dedup zal hoogstens wat helpen als duizend medewerk de nieuwe CAO als pdf in hun home dir opslaan.

Je hebt heel wat teweeg gebracht met je performance vraag. Ik heb diverse interessante zaken gevonden. (Mischien zelfs wel een echte bug) Het patchen van xdd is klaar. Echter xdd gaat op een gegeven moment ook lezen??? DD doet raar als ik de oflag=sync meegeef maar de zfs dataset sync=disabled zet.
Dan was/is er de vraag in welke vfs opdrachten de nfs commando's van de ESXi NFS client worden omgezet. Dit is echt diep in de code duiken.
NFS ops != vfs ops
Ik heb nu een minimale test app gemaakt. Ik zal daar wat commandline arguments aan toevoegen en dan in FreeBSD 10 compileren.

[Kompaan]

@FireDrunk:
Een paar honderd gig deduppen gaat prima, kost je misschien een gig aan ram ofzo?
Ik zou het proberen als er meerdere kopieën van Windows/programma's op staan.

Als je genoeg ram/tjid hebt kan je een keer op een rusting moment "zdb -S poolnaam" draaien om te kijken watvoor ratio je zou krijgen.

[FireDrunk]

Ik heb 64GB RAM dus RAM genoeg om dedup aan te zetten, ik ben meer een beetje bang voor performance. Omdat ZFS natuurlijk de checksums moet vergelijken heb je een lichte vertraging in je write latency (meen ik ergens gelezen te hebben). Voor VM's is dat natuurlijk erg merkbaar, waar dat bij een home directory veel minder is. Daarom mijn vraag.

[Mystic Spirit]

Het heeft even geduurd, maar ik heb mijn nieuwe hardware binnen om mijn ZFS storage in mijn server met ESXi te gaan bouwen.

Gezien de discussie van de laatste paar weken in dit topic over wel of geen TLER, toch maar eieren voor m'n geld gekozen en gegaan voor WD RED's. In samenwerkig met mijn geflashte IBM HBA, moet dat goed gaan komen. Ondanks dat het niet optimaal is, ben ik voor 7 stuks gegaan en gaan die in RAID Z2 draaien (dus met 4k blokken zal ik mogelijk wat verlies hebben)

Nu ik de Hardware op orde heb, is de vraag alleen nog welk OS ik zal gaan draaien. Ik heb geëxperimenteerd met ZFSguru en die bevalt me goed. Ondanks dat ZFSguru minder volwassen is, een minder actieve /grote community lijkt te hebben, denk ik toch dat ik voor ZFSguru moet kiezen. Toch twijfel ik omdat het wel om mijn primaire opslag gaat en ik het erg vervelend zou vinden als er wat mis gaat. Ook staat het me tegen dat ik de MSI aanpassing moet doen om ZFSguru te kunnen booten met mijn geflashte IBM HBA. Of is dat misschien gefixed in de laatste realese?

Iemand nog een laatste opmerking voor ik mij in het diepe stort met ZFSguru?

[FireDrunk]

Nope, het werkt prima. Let wel op met guides op internet om dingen voor elkaar te krijgen. Sommige acties kan je niet zomaar doen op ZFSguru (portstree gebruiken enzo). PKG updates doen.

Verder is het een prima OS.

Die MSI bug is niet van ZFSguru, maar van FreeBSD zelf. (En de mening van de FreeBSD dev's is dat het aan ESXi ligt, dus ze lossen het ook niet op.... dodo's...)

[ Voor 16% gewijzigd door FireDrunk op 18-11-2013 22:05 ]

[Mystic Spirit]

Thnx. Dus wel de MSI aanpassing doen.... Andere guides zal ik niet veel gebruiken. De installatie zal behoorlijk "vanilla" blijven. Alle andere services los van storage draai ik al in andere VM's. De enige package die ik installeer is de VMware Guest package, maar eigenlijk ben ik de grafische interface niet nodig.

[ Voor 8% gewijzigd door Mystic Spirit op 18-11-2013 22:32 ]

[fluppie007]

Mijn nieuwe (ESXi 5.0 U3) server met o.a. ZFSguru werkt :-).

Hardware:

Virtualized under VMware Workstation!
64-bit dual core Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz - Running at MHz ( scales from 424 MHz to 3392 MHz ) / Er zijn 2 vCores toegewezen
16 GiB physical memory, 15.3 GiB usable / het RAM geheugen krijgt de VM direct toegekend
6 normal harddrives
1 USB sticks (dit is de virtuele harde schijf)
Gigabit networking

Harde schijven (6x 3TB in RAID-Z2) worden via VT-D doorgelust langs een IBM M1015 controller.

Benchmarkje draaien:

code:

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool            : storagepool (16.2T, 67% full)
Test size       : 64 GiB
normal read : 568 MB/s
normal write    : 411 MB/s
I/O bandwidth   : 32 GB/s

Ook heb ik een W7 VM draaien met een Ati Radeon HD7770 via VT-D doorgelust. Draai dualscreen zonder problemen. Kan op elk scherm een 1080p film kijken zonder haperingen. Volgens mij moet je hier zelfs op kunnen gamen!

[FireDrunk]

Die is volgens mij al een hele tijd stuk, en om de laatste versie te installeren heb je het compat9x-AMD64 package nodig, en die moet je uit de ports tree halen, en die is weer kapot als service...

Dus dat kan nog een uitdaging worden

@Fluppie, keurige snelheden en zelfs een werkende GPU passthrough, netjes!

[ Voor 13% gewijzigd door FireDrunk op 18-11-2013 22:43 ]

[fluppie007]

Mystic Spirit schreef op maandag 18 november 2013 @ 22:31:
Thnx. Dus wel de MSI aanpassing doen.... Andere guides zal ik niet veel gebruiken. De installatie zal behoorlijk "vanilla" blijven. Alle andere services los van storage draai ik al in andere VM's. De enige package die ik installeer is de VMware Guest package, maar eigenlijk ben ik de grafische interface niet nodig.

Ik draai daarom ESXi 5.0 U3 en niet de 5.1 (Passthrough was daar slecht of werkte soms geheel niet!) en 5.5 vind ik nog te nieuw om naar over te stappen.

[FireDrunk]

Persoonlijk heb ik nooit problemen gehad met passthrough in 5.0/5.1 of 5.5... Werkte altijd...

[HyperBart]

Hmmm, der was ergens een versie die wat klote deed, daar staat me iets van bij hoor.

[]Byte[]

Ik heb zelf alleen nog het probleem dat ESXi 5.5 de SSD's bij mij niet via RDM wil doorzetten.
In ESX zie ik wel alle HDD's en SSD's, maar zodra ik ze wil doorzetten via RDM laat ie alleen de HDD's zien...

[FireDrunk]

Al via de commandline geprobeerd?

[]Byte[]

FireDrunk schreef op dinsdag 19 november 2013 @ 08:07:
Al via de commandline geprobeerd?

Ik begrijp je reactie en was ook mijn eerste idee.
Ik ben diverse van deze workarounds tegen gekomen via CLI, maar ik ben eigenlijk vooral benieuwd naar de 'waarom' dat ie de SSD's niet wil/kan zien voor RDM en wel de HDD's.
Juist ook omdat een deel van de SSD's op dezelfde controller zitten als de HDD's.
Ik kan het gewoon niet plaatsen waarom hij specifiek alle SSD's, ongeacht merk/type/controller, allemaal op RDM Capable op false heeft.

t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______
   Display Name: Local ATA Disk (t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______)
   Has Settable Display Name: true
   Size: 122104
   Device Type: Direct-Access 
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______
   Vendor: ATA     
   Model: SAMSUNG SSD 830 
   Revision: CXM0
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   [b]Is RDM Capable: false[/b]
   Is Local: true
   Is Removable: false
   Is SSD: true
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: yes
   Attached Filters: 
   VAAI Status: unknown
   Other UIDs: vml.0100000000533058594e45414336343536363220202020202053414d53554e
   Is Local SAS Device: false
   Is Boot USB Device: false
   No of outstanding IOs with competing worlds: 32

[Mystic Spirit]

fluppie007 schreef op maandag 18 november 2013 @ 22:43:
[...]


Ik draai daarom ESXi 5.0 U3 en niet de 5.1 (Passthrough was daar slecht of werkte soms geheel niet!) en 5.5 vind ik nog te nieuw om naar over te stappen.

Het doorgeven is volgens mij niet het probleem. Het functioneerd gewoon prima. ik moet alleen die twee MSI settings op disabled zetten. Vraag me sowieso af wat die settings toevoegen....

[FireDrunk]

Snelheid... MSI/MSI-X is de opvolger van standaard (enkelvoudige) interrupts.

Wikipedia: Message Signaled Interrupts

Overigens hoef je alleen MSI-X uit te zetten, gewoon MSI kan je aan laten.

De bug zit hem er in, dat FreeBSD het maximaal aantal Interrupts opvraagt voor een device (dat is volgens mij 2048 bij MSI-X), maar VT-d heeft een limiet dat lager is (waarschijnlijk om de CPU te sparen in het aantal interrupts...) ESXi limiteert dus het aantal interrupts wat er aangezet kan worden voor een bepaald device. Windows en Linux vinden dat prima, maar FreeBSD begint te stuiteren dat ze dat toch willen...

@tvwes, is IOzone een alternatief?

[matty___]

FireDrunk schreef op dinsdag 19 november 2013 @ 09:35:
Snelheid... MSI/MSI-X is de opvolger van standaard (enkelvoudige) interrupts.

Wikipedia: Message Signaled Interrupts

Overigens hoef je alleen MSI-X uit te zetten, gewoon MSI kan je aan laten.

De bug zit hem er in, dat FreeBSD het maximaal aantal Interrupts opvraagt voor een device (dat is volgens mij 2048 bij MSI-X), maar VT-d heeft een limiet dat lager is (waarschijnlijk om de CPU te sparen in het aantal interrupts...) ESXi limiteert dus het aantal interrupts wat er aangezet kan worden voor een bepaald device. Windows en Linux vinden dat prima, maar FreeBSD begint te stuiteren dat ze dat toch willen...

@tvwes, is IOzone een alternatief?

Zijn de MSI-X waardes niet per device in de /boot/loader.conf te regelen?

[tvwes]

@Firedrunk,

Goedemorgen,

IOzone kan maar is redelijk complex. Gezien de beperkte skills van de meeste tweakers hier, het liefste wil iedereen "clickerdeclick" ipv "typerdetype", lijkt me IOzone net als Bonnie veel te ingewikkeld. Een extreem simpele benchmark die portable is lijkt mij toch wel handig. Mijn benchmark, wat in feite een gestripte versie van DD is, geeft in een paar minuten een beeld van de maximale throughput van je zpool voor een enkele thread. Het aantal tweakers hier die echt concurrency en grotere queue dieptes zal erg beperkt zijn. De waarden die hier uitrollen zijn de boven grenzen van wat je kan verwachten met je ESXi client. Als je in je guest vervolgens de helft aan throughput meet, weet je dat er een bottleneck is. De tool is echt een fire and forget test, IOzone en andere zijn dat echt niet.
Ik zal het later vandaag aan je geven. Ik moet alleen nog werken aan een wrapper script wat de ZFS dataset manipuleert voor de test.

[FireDrunk]

Wat wil je er precies aan manipuleren? Want ik weet niet of iedereen dat zo leuk vindt

@matty__, ik ben even de sourcecode van de LSI driver aan het downloaden of ik iets kan vinden, maar ik denk niet dat daar opties voor zijn.

]Byte\[ schreef op dinsdag 19 november 2013 @ 08:42:
[...]

Ik begrijp je reactie en was ook mijn eerste idee.
Ik ben diverse van deze workarounds tegen gekomen via CLI, maar ik ben eigenlijk vooral benieuwd naar de 'waarom' dat ie de SSD's niet wil/kan zien voor RDM en wel de HDD's.
Juist ook omdat een deel van de SSD's op dezelfde controller zitten als de HDD's.
Ik kan het gewoon niet plaatsen waarom hij specifiek alle SSD's, ongeacht merk/type/controller, allemaal op RDM Capable op false heeft.

t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______
   Display Name: Local ATA Disk (t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______)
   Has Settable Display Name: true
   Size: 122104
   Device Type: Direct-Access 
   Multipath Plugin: NMP
   Devfs Path: /vmfs/devices/disks/t10.ATA_____SAMSUNG_SSD_830_Series__________________S0XYNEAC645662______
   Vendor: ATA     
   Model: SAMSUNG SSD 830 
   Revision: CXM0
   SCSI Level: 5
   Is Pseudo: false
   Status: on
   [b]Is RDM Capable: false[/b]
   Is Local: true
   Is Removable: false
   Is SSD: true
   Is Offline: false
   Is Perennially Reserved: false
   Queue Full Sample Size: 0
   Queue Full Threshold: 0
   Thin Provisioning Status: yes
   Attached Filters: 
   VAAI Status: unknown
   Other UIDs: vml.0100000000533058594e45414336343536363220202020202053414d53554e
   Is Local SAS Device: false
   Is Boot USB Device: false
   No of outstanding IOs with competing worlds: 32

Volgens mij staat RDM capable voor alle lokale schijven uit, je moet het gewoon keihard forceren dacht ik.
Het is dan ook bedoeld voor FC/iSCSI LUN's, en niet voor lokale disken.

Gister nog gedaan met ESXi 5.5 met 2 lokale SSD's, dus het moet werken.

[ Voor 124% gewijzigd door FireDrunk op 19-11-2013 10:51 ]

[FireDrunk]

@matty__, net in de sourcecode gekeken, enige wat ik kan vinden is dat MSI/MSI-X automatisch uitgezet word bij een FreeBSD versie ouder dan 7 (ik gok vanaf die versie pas MSI/MSI-x geintroduceerd is).

Verder wordt er gewoon maximaal ingezet zonder enige harde limieten of variabelen voor zover ik de sourcecode begrijp.

[matty___]

FireDrunk schreef op dinsdag 19 november 2013 @ 10:48:
Wat wil je er precies aan manipuleren? Want ik weet niet of iedereen dat zo leuk vindt

@matty__, ik ben even de sourcecode van de LSI driver aan het downloaden of ik iets kan vinden, maar ik denk niet dat daar opties voor zijn.

van de mps(4)

code:

 To disable MSI interrupts for all mps driver instances, set the following
     tunable value in loader.conf(5):

       hw.mps.disable_msi=1

     To disable MSI interrupts for a specific mps driver instance, set the
     following tunable value in loader.conf(5):

       dev.mps.X.disable_msi=1

     where X is the adapter number.

     To disable MSI-X interrupts for all mps driver instances, set the follow-
     ing tunable value in loader.conf(5):

       hw.mps.disable_msix=1

     To disable MSI-X interrupts for a specific mps driver instance, set the
     following tunable value in loader.conf(5):

       dev.mps.X.disable_msix=1

     To set the maximum number of DMA chains allocated for all adapters, set
     the following variable in loader.conf(5):

       hw.mps.max_chains=NNNN

     To set the maximum number of DMA chains allocated for a specific adapter,
     set the following variable in loader.conf(5):

       dev.mps.X.max_chains=NNNN

     This variable may also be viewed via sysctl(8) to see the maximum set for
     a given adapter.

     The current number of free chain frames may be seen via the
     dev.mps.X.chain_free sysctl(8) variable.

     The lowest number of free chain frames may be seen via the
     dev.mps.X.chain_free_lowwater sysctl(8) variable.

     The current number of active I/O commands is shown in the
     dev.mps.X.io_cmds_active sysctl(8) variable.

     The maximum number of active I/O command seen since boot is shown in the
     dev.mps.X.io_cmds_highwater sysctl(8) variable.

Maar idd weinig aan te tunen

[]Byte[]

FireDrunk schreef op dinsdag 19 november 2013 @ 10:48:
[...]
Volgens mij staat RDM capable voor alle lokale schijven uit, je moet het gewoon keihard forceren dacht ik.
Het is dan ook bedoeld voor FC/iSCSI LUN's, en niet voor lokale disken.

Die theorie zou ik graag willen volgen als ik ook mijn lokale HDD's niet zou zien.
En die zie ik juist wel!
Lijkt dan een selectief iets op alleen lokale SSD's te zijn.

Weet jij overigens de 'goede' cli?
Ik heb nu alleen de workaround om de SSD's te linken aan VMDK's en die aan een VM erbij te koppelen.
Of is dat juist de goede optie?

[Panzy]

Ik heb een tijd geleden een topic aangemaakt waarin een discusse onstond over moderne HDD's, TLER, etc. Ik ben nu inmiddels bezig mijn server weer online te krijgen, en bij het uitzoeken van een OS heb ik dit topic en het DIY NAS topic nog eens doorgelezen.

Ik ben hier een aantal zaken tegengekomen waar ik toch mijn twijfels bij heb of dit waar is, en zou dit als het iemand wat interresseert tenminste onder de aandacht willen brengen.

In de beginpost staat het volgende als voordeel van ZFS t.o.v. hardware RAID:

'•Geen dure TLER-schijven nodig, zoals de WD RE series, die stukken duurder zijn alleen voor meer garantie en firmware die TLER mogelijk maakt. Door goedkope schijven te gebruiken kun je er meer van kopen dus meer storage en meer performance. (Wikipedia: Time-Limited Error Recovery) '

Ik durf te beweren dat dit niet juist is. Ik heb de spec sheets erbij gepakt van WD en als je bijvoorbeeld de desktop schijven (green, red, black) vergelijkt met bijvoorbeeld de RAID Edition schijven dan zie je duidelijk dat (volgens de specificaties) de RAID Edition schijven gewoon simpelweg beter zijn. Bijvoorbeeld alleen al de (Non-recoverable read errors per bits read) specificatie die bij de goedkope schijven hangt op (<1 in 10^14) en bij de RE schijven op (<10 in 10^16) duid dus precies het veelal omschreven probleem aan van de 'soft bad sectors' wat dus inderdaad voorkomt bij de goedkope schijven maar niet bij de duurdere RE schijven.

Ik zelf heb hier trouwens een indicatie van dat dit klopt, ik heb meerdere Green schijven (1Tb) die in de SMART data onder 'Read Error Rate' allemaal een waarde van 20-50 aangeven, en ik heb een RAID Edition schijf (500Gb) die na bijna dezelfde 'Power-On Hours' een Read Error Rate heeft van 0.

In de tweede post staat het volgende:

'Moraal van het verhaal?
Ouderwetse opslagtechnieken zoals legacy RAID engines en legacy filesystems (FAT, NTFS, Ext2, Ext3, Ext4, UFS, XFS, JFS, ReiserFS) bieden totaal geen bescherming tegen bad sectors. Dat is onacceptabel zeker omdat het probleem van bad sectors steeds groter wordt. Dit heeft te maken met dat de hoeveelheid bitfouten - uitgedrukt in de uBER-specificatie - gelijk blijft terwijl de datadichtheid blijft toenemen. Relatief gezien komen bad sectors daarom steeds vaker voor. Ik gelijk nu gemiddeld één bad sector per 3 tot 5 keer de schijf van A tot Z uitlezen. Dit soort specificaties gaat enkel op als je zeer grote hoeveelheden schijven gaat testen. Met een enkel exemplaar kun je alle kanten uit.'

Is dat zo? Een RAID Edition schijf geeft normaal gesproken (volgens mij) dus nooit bitfouten. Als het toch wel een keer gebeurt dan kicked de TLER in en hij stuurt hij een read error naar de controller, waarna hij dus FAILED en uit de array wordt gekicked. Dit lijkt me zeer terecht en heeft naar mijn mening niks te maken met een slechte RAID controller maar juist met een slechte en kapotte HDD, want een goede HDD hoort geen fouten te geven. Deze schijf moet meteen RMA gestuurd worden.

Wat ik denk dat er gebeurt is, en wat je dus als reden zou kunnen noemen dat ZFS nodig is, is dat consumenten harde schijven slechter zijn geworden. Je kan er gewoon veel minder op vertrouwen als vroeger en als je ze toch wil gebruiken voor belangrijke dingen dan heb je dus eigenlijk gewoon ZFS nodig. Dit is mijn conclusie tenminste.

Dit komt uiteraard omdat bedrijven uitproberen wat ze kunnen flikken, gemiddelde consumenten geven blijkbaar geen moer om data integriteit en daarom is het mogelijk dat de gemiddelde kwaliteit van producten omlaag kan, wat een hoop winst oplevert. Dit is denk ik ook precies de reden waarom ze jaren geleden met RAID Edition kwamen, dat was de eerste stap in het plan. Het opsplitsen van de HDD markt. Vroeger had je maar 1 type schijf, namelijk degene die werkte. Fabrikanten gingen inzien dat er meerdere groepen consumenten zijn, namelijk thuisgebruikers en enterprise. Als je dan opeens slechtere schijven kan gaan produceren (het is natuurlijk ook steeds moeilijker om foutloze schijven te maken met de toenemende capaciteit) en deze voor bijna dezelfde prijs kan verkopen, en je maakt gewoon nog goede schijven die opeens het label 'Enterprise Storage' opgeplakt krijgen en voor het dubbele over de toonbank gaan, dan maak je in totaal meer winst inderdaad.

Ik weet dat dit allemaal niet bewezen is maar ik weet het gewoon zeker, ik hoop meer bewijs te krijgen
nadat mijn RE array lange tijd draait en de Green schijven ernaast. Mischien kunnen meerderen SMART data of ander bewijs aanleveren? Ik ben ook wel benieuwd naar andere fabrikanten.

Ik weet in elk geval dat ik nooit meer een inferieure consumentenschijf koop, liever genaaid worden en veel te veel betalen voor een goede schijf dan genaaid worden en weinig betalen voor een die in potentie gewoon leesfouten kan geven. Het is jammer dat het zo is maar het is de marktwerking. People don't give a fuck, they just buy.

Wat we kunnen proberen is elke schijf waarbij we een unreadable sector tegen komen gewoon meteen terugsturen naar de fabrikant, zo van 'hij doet vreemd' en dan een nieuwe eisen. Mischien dat ze na een tijdje er zat van worden haha.

Mischien wordt het tijd dat dit aan het licht gebracht wordt en er naast een SSD topic ook weer een HDD topic komt, zodat mensen niet meer klakkeloos HDD's kopen maar de verschillen weten en een juiste afweging kunnen maken.

Ben benieuwd wat jullie ervan denken, waarschijnlijk wordt ik voor gek verklaard of was dit al lang bekend maar het is hoe ik erover denk in elk geval.

[FireDrunk]

matty___ schreef op dinsdag 19 november 2013 @ 11:02:
[...]

van de mps(4)

code:

 To disable MSI interrupts for all mps driver instances, set the following
     tunable value in loader.conf(5):

       hw.mps.disable_msi=1

     To disable MSI interrupts for a specific mps driver instance, set the
     following tunable value in loader.conf(5):

       dev.mps.X.disable_msi=1

     where X is the adapter number.

     To disable MSI-X interrupts for all mps driver instances, set the follow-
     ing tunable value in loader.conf(5):

       hw.mps.disable_msix=1

     To disable MSI-X interrupts for a specific mps driver instance, set the
     following tunable value in loader.conf(5):

       dev.mps.X.disable_msix=1

     To set the maximum number of DMA chains allocated for all adapters, set
     the following variable in loader.conf(5):

       hw.mps.max_chains=NNNN

     To set the maximum number of DMA chains allocated for a specific adapter,
     set the following variable in loader.conf(5):

       dev.mps.X.max_chains=NNNN

     This variable may also be viewed via sysctl(8) to see the maximum set for
     a given adapter.

     The current number of free chain frames may be seen via the
     dev.mps.X.chain_free sysctl(8) variable.

     The lowest number of free chain frames may be seen via the
     dev.mps.X.chain_free_lowwater sysctl(8) variable.

     The current number of active I/O commands is shown in the
     dev.mps.X.io_cmds_active sysctl(8) variable.

     The maximum number of active I/O command seen since boot is shown in the
     dev.mps.X.io_cmds_highwater sysctl(8) variable.

Maar idd weinig aan te tunen

Dat ziet er eigenlijk heel goed uit, de normale opties waren altijd om heel MSI/MSI-X voor alle devices uit te zetten, nu kan dat alleen voor de LSI driver, een stuk beter al dus (want VMXNET3 gebruikt bijvoorbeeld ook MSI/MSI-X).

]Byte\[ schreef op dinsdag 19 november 2013 @ 11:14:
[...]

Die theorie zou ik graag willen volgen als ik ook mijn lokale HDD's niet zou zien.
En die zie ik juist wel!
Lijkt dan een selectief iets op alleen lokale SSD's te zijn.

Weet jij overigens de 'goede' cli?
Ik heb nu alleen de workaround om de SSD's te linken aan VMDK's en die aan een VM erbij te koppelen.
Of is dat juist de goede optie?

cd /vmfs/volumes/[datastore_om_rdm's_in_te_zetten]
vmkfstools -z /vmfs/devices/disks/t10.ATA_____SAMSUNG_SSD_830_Series__________________S0WK
NYAC302978______ SSD1.vmdk

En dan via de GUI die vmdk (SSD1.vmdk) aan een VM geven.

Panzy schreef op dinsdag 19 november 2013 @ 12:15:
Ik heb een tijd geleden een topic aangemaakt waarin een discusse onstond over moderne HDD's, TLER, etc. Ik ben nu inmiddels bezig mijn server weer online te krijgen, en bij het uitzoeken van een OS heb ik dit topic en het DIY NAS topic nog eens doorgelezen.

Ik ben hier een aantal zaken tegengekomen waar ik toch mijn twijfels bij heb of dit waar is, en zou dit als het iemand wat interresseert tenminste onder de aandacht willen brengen.

In de beginpost staat het volgende als voordeel van ZFS t.o.v. hardware RAID:

'•Geen dure TLER-schijven nodig, zoals de WD RE series, die stukken duurder zijn alleen voor meer garantie en firmware die TLER mogelijk maakt. Door goedkope schijven te gebruiken kun je er meer van kopen dus meer storage en meer performance. (Wikipedia: Time-Limited Error Recovery) '

Ik durf te beweren dat dit niet juist is. Ik heb de spec sheets erbij gepakt van WD en als je bijvoorbeeld de desktop schijven (green, red, black) vergelijkt met bijvoorbeeld de RAID Edition schijven dan zie je duidelijk dat (volgens de specificaties) de RAID Edition schijven gewoon simpelweg beter zijn. Bijvoorbeeld alleen al de (Non-recoverable read errors per bits read) specificatie die bij de goedkope schijven hangt op (<1 in 10^14) en bij de RE schijven op (<10 in 10^16) duid dus precies het veelal omschreven probleem aan van de 'soft bad sectors' wat dus inderdaad voorkomt bij de goedkope schijven maar niet bij de duurdere RE schijven.

Ik zelf heb hier trouwens een indicatie van dat dit klopt, ik heb meerdere Green schijven (1Tb) die in de SMART data onder 'Read Error Rate' allemaal een waarde van 20-50 aangeven, en ik heb een RAID Edition schijf (500Gb) die na bijna dezelfde 'Power-On Hours' een Read Error Rate heeft van 0.

De discussie over het wel of niet nodig hebben van TLER schijven ligt ook wat genuanceerder dan dat. Een paar pagina's terug heeft tvwes een keurige korte samenvatting gegeven wanneer je het wel en niet nodig hebt.

In de tweede post staat het volgende:

'Moraal van het verhaal?
Ouderwetse opslagtechnieken zoals legacy RAID engines en legacy filesystems (FAT, NTFS, Ext2, Ext3, Ext4, UFS, XFS, JFS, ReiserFS) bieden totaal geen bescherming tegen bad sectors. Dat is onacceptabel zeker omdat het probleem van bad sectors steeds groter wordt. Dit heeft te maken met dat de hoeveelheid bitfouten - uitgedrukt in de uBER-specificatie - gelijk blijft terwijl de datadichtheid blijft toenemen. Relatief gezien komen bad sectors daarom steeds vaker voor. Ik gelijk nu gemiddeld één bad sector per 3 tot 5 keer de schijf van A tot Z uitlezen. Dit soort specificaties gaat enkel op als je zeer grote hoeveelheden schijven gaat testen. Met een enkel exemplaar kun je alle kanten uit.'

Is dat zo? Een RAID Edition schijf geeft normaal gesproken (volgens mij) dus nooit bitfouten.

Nooit kan natuurlijk niet.

Als het toch wel een keer gebeurt dan kicked de TLER in en hij stuurt hij een read error naar de controller, waarna hij dus FAILED en uit de array wordt gekicked. Dit lijkt me zeer terecht en heeft naar mijn mening niks te maken met een slechte RAID controller maar juist met een slechte en kapotte HDD, want een goede HDD hoort geen fouten te geven. Deze schijf moet meteen RMA gestuurd worden.

Niet helemaal waar. Bij een read error kan het komen omdat je een schop tegen de kast aan hebt gegeven. ZFS is zo ontworpen dat als 1 disk een sector niet kan lezen, hij gaat kijken of hij de data ergens anders kan halen (copies=2 kopie, mirror kopie, of via parity reconstructie). Als *elke* disk er uit gekicked zou worden bij 1 read error, zou dat vrij zonde zijn... Een disk kan best wel eens een fout maken *zonder dat deze daadwerkelijk permanent kapot is* dat is nou juist het flauwe aan een disk. Jij roept meteen dat hij RMA moet, maar dat hoeft dus helemaal niet zo te zijn.

Wat ik denk dat er gebeurt is, en wat je dus als reden zou kunnen noemen dat ZFS nodig is, is dat consumenten harde schijven slechter zijn geworden. Je kan er gewoon veel minder op vertrouwen als vroeger en als je ze toch wil gebruiken voor belangrijke dingen dan heb je dus eigenlijk gewoon ZFS nodig. Dit is mijn conclusie tenminste.

Nou ja, niet zozeer slechter alswel, de kwaliteit is gelijk gebleven, maar de grootte is exponentieel gestegen. Waar voorheen een disk 6 keer zichzelf kon lezen voor hij een fout maakte (250/500GB disks) kan hij dat nu maar 1 keer (2TB schijf). De kwaliteit is dus niet direct gedaald, maar niet lineair meegestegen met de grootte... Het uiteindelijke resultaat is inderdaad in verhouding slechter dan vroeger.

Dit komt uiteraard omdat bedrijven uitproberen wat ze kunnen flikken, gemiddelde consumenten geven blijkbaar geen moer om data integriteit en daarom is het mogelijk dat de gemiddelde kwaliteit van producten omlaag kan, wat een hoop winst oplevert.

Dat gebeurt overal, niet alleen in HD land.

Dit is denk ik ook precies de reden waarom ze jaren geleden met RAID Edition kwamen, dat was de eerste stap in het plan. Het opsplitsen van de HDD markt. Vroeger had je maar 1 type schijf, namelijk degene die werkte.

RAID Edition / SAS / SCSI schijven bestaan echt al heeeeeeeel lang... Die markt is al decennia opgesplitst tussen Consumer Grade en Enterprise Grade.

Fabrikanten gingen inzien dat er meerdere groepen consumenten zijn, namelijk thuisgebruikers en enterprise. Als je dan opeens slechtere schijven kan gaan produceren (het is natuurlijk ook steeds moeilijker om foutloze schijven te maken met de toenemende capaciteit) en deze voor bijna dezelfde prijs kan verkopen, en je maakt gewoon nog goede schijven die opeens het label 'Enterprise Storage' opgeplakt krijgen en voor het dubbele over de toonbank gaan, dan maak je in totaal meer winst inderdaad.

Het is niet alleen kwaliteit van de schijf zelf als het gaat om leesfouten, het is veel meer. (Firmware, tests, garantie, vibraties) maar dat is niet echt een discussie voor hier.

Ik weet dat dit allemaal niet bewezen is maar ik weet het gewoon zeker, ik hoop meer bewijs te krijgen
nadat mijn RE array lange tijd draait en de Green schijven ernaast. Mischien kunnen meerderen SMART data of ander bewijs aanleveren? Ik ben ook wel benieuwd naar andere fabrikanten.

Zelfs al zou je 100 mensen zo gek krijgen is het nog niet genoeg doorsnede van de markt om goed beeld te vormen. Het is en blijft gewoon een feit dat hardeschijf fabrikanten niet inzichtelijk maken hoe schijven kapot gaan, en wat ze er aan doen om het te voorkomen. Dat is aan de ene kant klote, maar aan de andere kant wel logisch, want je gaat al je geheime technieken zo aan de concurrent vertellen. Als we allemaal wisten hoe sterrenkoks koken, kon iedereen lekker koken.. Het is juist het geheim van de smid wat geld oplevert...

Ik weet in elk geval dat ik nooit meer een inferieure consumentenschijf koop, liever genaaid worden en veel te veel betalen voor een goede schijf dan genaaid worden en weinig betalen voor een die in potentie gewoon leesfouten kan geven. Het is jammer dat het zo is maar het is de marktwerking. People don't give a fuck, they just buy.

Dan is ZFS toch juist een mooie tussenoplossing? Je kan met consumer schijven gewoon betrouwbare storage maken. Maak een 7-disk RAIDZ3 array met copies=2 en je hebt een idioot robuust storage systeem.

Wat we kunnen proberen is elke schijf waarbij we een unreadable sector tegen komen gewoon meteen terugsturen naar de fabrikant, zo van 'hij doet vreemd' en dan een nieuwe eisen. Mischien dat ze na een tijdje er zat van worden haha.

Nee hoor, die worden gewoon weer gewist, SMART word gereset, en die worden teruggegeven aan mensen die hun *echt* kapotte schijf terugsturen... Helpt niets...

Mischien wordt het tijd dat dit aan het licht gebracht wordt en er naast een SSD topic ook weer een HDD topic komt, zodat mensen niet meer klakkeloos HDD's kopen maar de verschillen weten en een juiste afweging kunnen maken.

Ben benieuwd wat jullie ervan denken, waarschijnlijk wordt ik voor gek verklaard of was dit al lang bekend maar het is hoe ik erover denk in elk geval.

Op zich weten veel mensen het al, maar het is net als met biologisch vlees... We weten allemaal dat biologisch vlees (meestal) beter is, maar we kiezen toch 99/100 keer voor de portemonnee. En dat terwijl we het allemaal weten.

We zijn nou eenmaal Nederlanders...

[ Voor 76% gewijzigd door FireDrunk op 19-11-2013 12:52 ]

[]Byte[]

FireDrunk schreef op dinsdag 19 november 2013 @ 10:48:
[...]
Volgens mij staat RDM capable voor alle lokale schijven uit, [...]

Yup... gevonden!
Dat ie bij mij de HDD's wel laat zien is gewoon puur mazzel...

tnx!
Het is dus idd de VMDK-methode.
Ga ik vanavond even regelen.

[ Voor 8% gewijzigd door ]Byte[ op 19-11-2013 12:42 ]

[Bigs]

Grappig.. ik heb een Dell R310 met H200 RAID adapter en daarvan gebruik ik 1 LUN als datastore en 1 voor RDM. Is op zich een vrij eenvoudige SAS RAID adapter (LSI OEM), maar kennelijk ondersteunt die het dus wel (iig voor RAID arrays, misschien niet voor passthrough disks). Ik moest trouwens wel de RdmFilter.HbaIsShared instelling aanpassen om hem te zien te krijgen, heb je daar misschien iets aan?

[ Voor 4% gewijzigd door Bigs op 19-11-2013 12:45 ]

[FireDrunk]

Bigs schreef op dinsdag 19 november 2013 @ 12:45:
Grappig.. ik heb een Dell R310 met H200 RAID adapter en daarvan gebruik ik 1 LUN als datastore en 1 voor RDM. Is op zich een vrij eenvoudige SAS RAID adapter (LSI OEM), maar kennelijk ondersteunt die het dus wel (iig voor RAID arrays, misschien niet voor passthrough disks). Ik moest trouwens wel de RdmFilter.HbaIsShared instelling aanpassen om hem te zien te krijgen, heb je daar misschien iets aan?

Dat is een beetje een smerig truukje om het vaak toch zichtbaar te krijgen, maar het is nog steeds niet "supported"

Beste manier is toch via de CLI in mijn optiek.

[Bigs]

FireDrunk schreef op dinsdag 19 november 2013 @ 12:53:
[...]

Dat is een beetje een smerig truukje om het vaak toch zichtbaar te krijgen, maar het is nog steeds niet "supported"

Beste manier is toch via de CLI in mijn optiek.

Ik weet niet wat er 'smerig' is aan een toggle die gewoon via de vSphere client beschikbaar wordt gemaakt. Maargoed het raakt een beetje off-topic nu in het ZFS topic

[ Voor 14% gewijzigd door Bigs op 19-11-2013 13:13 . Reden: Correctie; SSH staat standaard niet uit.. CLI natuurlijk niet. ]

[Panzy]

We zijn nou eenmaal Nederlanders...

Goedkoop blijft duurkoop.

Wat ik ga doen is een ZFS array bouwen van de 4 WD Green schijven die ik heb, en daarnaast de hardware array met de RE schijven. Dan gaan we kijken wat het langste in leven blijft en het minste problemen opleverd, ik ben benieuwd.

ZFS klinkt heel mooi maar ik wil eerst zien dan geloven. Een hardware array is gewoon plug & play, of het werkt of het werkt niet. Het is afhankelijk van een perfect storage medium, en dat vind ik juist mooi want een storage medium hoort perfect te zijn.

[Mystic Spirit]

FireDrunk schreef op dinsdag 19 november 2013 @ 12:39:
[...]


Dat ziet er eigenlijk heel goed uit, de normale opties waren altijd om heel MSI/MSI-X voor alle devices uit te zetten, nu kan dat alleen voor de LSI driver, een stuk beter al dus (want VMXNET3 gebruikt bijvoorbeeld ook MSI/MSI-X).


[...]
-KNIP-

Even voor mijn begrip. Kan ik nu hiermee vanavond mijn voordeel doen als ik de storage server aan ga maken? Welke settings moet ik dan hebben om alleen MSIX interrupts uit te zetten voor mijn IBM (LSI) HBA uit te zetten?

[FREAKJAM]

Met betrekking tot het backuppen/snapshotten van mijn VM's, wat is hier best practice in? Ik ga een SSD gebruiken als datastore van 240GB groot. Het lijkt me niet slim om de snapshots op te slaan op de SSD.

Je kunt de snapshots opslaan in een andere directory mbv deze instructies. Bij wat voor soort shares (NFS of CIFS of whatsoever?) zou bovenstaande werken? Ik ben er nog niet helemaal uit wat voor shares ik het beste kan maken op mijn ZFS pool aangezien ik geen ZIL/L2ARC heb in mijn setup.

Het liefst wil ik mijn snapshots/backups opslaan in mijn zfspool in een share en periodiek naar een andere computer kopieren.

[FireDrunk]

In /boot/loader.conf

hw.mps.disable_msix=1

Zou je interrupt drive hook melding op moeten lossen.

[Bigs]

FREAKJAM schreef op dinsdag 19 november 2013 @ 14:40:
Met betrekking tot het backuppen/snapshotten van mijn VM's, wat is hier best practice in? Ik ga een SSD gebruiken als datastore van 240GB groot. Het lijkt me niet slim om de snapshots op te slaan op de SSD.

Je kunt de snapshots opslaan in een andere directory mbv deze instructies. Bij wat voor soort shares (NFS of CIFS of whatsoever?) zou bovenstaande werken? Ik ben er nog niet helemaal uit wat voor shares ik het beste kan maken op mijn ZFS pool aangezien ik geen ZIL/L2ARC heb in mijn setup.

Het liefst wil ik mijn snapshots/backups opslaan in mijn zfspool in een share en periodiek naar een andere computer kopieren.

Je maakt een snapshot op je SSD pool, dat snapshot kun je vervolgens met zfs send naar een andere pool sturen (d.m.v. zfs send/recv, kan ook in incrments) of opslaan in een bestand. Daarna kun je het snapshot weer uit je SSD pool verwijderen.

[Ultraman]

Panzy schreef op dinsdag 19 november 2013 @ 14:31:
Wat ik ga doen is een ZFS array bouwen van de 4 WD Green schijven die ik heb, en daarnaast de hardware array met de RE schijven. Dan gaan we kijken wat het langste in leven blijft en het minste problemen opleverd, ik ben benieuwd.

Benieuwd naar je bevindingen natuurlijk.
Maar houd wel rekening met het flinke verschil in schijven daar. De WD RE serie schijven zijn een stuk robuuster ontworpen, omdat ze voor een enterprise omgeving bedoeld zijn met hogere eisen (en standaarden) rond MTTF en zoals je in een eerdere post al aangaf: veel lagere UBER. Waar ook weer een hoger prijskaartje aan hangt.
Terwijl WD Green disken als speerpunt hebben om zoveel mogelijk GB/€ te bieden en dus goedkoop te zijn, met een lagere MTTF en UBER tot gevolg.

Ik verwacht dat je met de WD RE's minder problemen zult hebben omdat het simpelweg veel robuustere schijven zijn. Of je nou hardware of software RAID gebruikt dat maakt in dit geval weinig uit.
Pas als je tegen een unrecoverable read error aanloopt wordt het interessant, maar gezien de veel betere UBER waarde van de RE's zul je daar ook minder snel tegenaan lopen.

Daarintegen zal de array met WD Greens denk ik prima de tand des tijds kunnen weerstaan, en als voordeel hebben dat je ook 100% zeker kunt zijn of data intact is of niet. Terwijl je daar bij de hardware RAID met WD RE's niet zo zeker van kan zijn.
Er zal vast eerder een WD Green stuk gaan dan zo'n WD RE, dus je zult vast een keer een disk moeten vervangen en resilveren. Als je dat netjes op tijd doet, zal het prima door draaien.
Wat er aan SMART data verzameld wordt vind ik enkel interessant voor monitoring, dan heb ik enige indicatie buiten ZFS om wanneer een disk mogelijk aan vervanging toe is. Hoeveel leesfouten ze verder maken zou ik buiten beschouwing laten. Ten eerste weet je niet zeker of je de SMART values goed leest, daar is immers geen harde specificatie/documentatie van en verschilt per fabrikant. Ten tweede boeit het niet voor de data als een eventuele leesfout prima kan worden opgevangen, maar kan het wel een indicatie zijn dat een schijf mogelijk aan vervanging toe is.
Optioneel leesvoer over eigen ervaring: Ik draai nu bijna twee jaar met striped mirrors en heb al twee keer een disk vervangen. Een disk begon veel leesfouten te verzamelen, zonder dat het problemen opleverde en SMART status was nog Pass, maar het aantal begon steeds sneller op te lopen, dus RMA. De tweede vertoonde eenzelfde gedrag, maar daar gaf SMART status wel fail, ook RMA gegaan.
De data is verder nog geheel intact en ik heb zelfs nog nooit een checksum error gezien... Veel van de leesfouten moeten dus hebben plaatsgevonden op ongebruikte delen van de disk, want ZFS heeft nooit geklaagd. Toch ook nog nooit een corrupte file gehad, dus tot dusver werkt het allemaal goed, want daar is het mij om te doen: data integriteit.
En qua schijven is het een ratjetoe. 2x320GB mirror als root pool en incoming scratch dir, dit zijn oude schijven (7jr & 4jr). En de tank pool bestaat uit 3x1.5TB + 1x2TB(1.5T usable) als striped mirrors, de oudste hiervan is net over de 3 jaar en de jongste is net over een jaar (refurb van RMA). Draaien nog steeds als een zonnetje. In mijn geval dus goede ervaring, geen data loss en problemen op een disk vervangen na heb ik niet gehad.
Dit draait onder FreeBSD 9.1 (begonnen als 9.0) met ZFS v28. Upgrade naar 9.2 stel ik nog even uit want 9.1 is toch een extended support release en ZFS v5000 mag van mij nog wat meer rijpen, al vind ik de LZ4 compressie interessant.

is dat consumenten harde schijven slechter zijn geworden.

Ben ik het niet mee eens. Het is in mijn ogen eerder: "consumenten harde schijven zijn niet beter geworden."
De UBER is gelijk gebleven, terwijl het aantal bytes extreem veel gegroeid is. De kans op een leesfout is dus enorm gegroeid.

[ Voor 4% gewijzigd door Ultraman op 19-11-2013 15:19 ]

[matty___]

Panzy schreef op dinsdag 19 november 2013 @ 14:31:
[...]


Goedkoop blijft duurkoop.

Wat ik ga doen is een ZFS array bouwen van de 4 WD Green schijven die ik heb, en daarnaast de hardware array met de RE schijven. Dan gaan we kijken wat het langste in leven blijft en het minste problemen opleverd, ik ben benieuwd.

ZFS klinkt heel mooi maar ik wil eerst zien dan geloven. Een hardware array is gewoon plug & play, of het werkt of het werkt niet. Het is afhankelijk van een perfect storage medium, en dat vind ik juist mooi want een storage medium hoort perfect te zijn.

ZFS heeft al jaren trouwe dienst achter de rug en perfectie bestaat niet.

[tvwes]

@Firedrunk,

source is inbegrepen. En een beetje vertrouwen, in mijn kunnen, mag ook wel. Ik geloof dat ik inmiddels wel heb aangetoond dat ik van deze materie wel wat afweet. Probeer eens te bedenken wat ik dan zou moeten manipuleren? zpool destroy?

[FireDrunk]

Oh, het was ook meer sarcastisch, ik vertrouw je wel, maar anderen misschien niet.

[ilovebrewski]

Hoe vaak is het het verstandig om een scrub en dedup te draaien onder ZFSguru? Zo ja, zetten jullie dit in een script of doen jullie dit handmatig?

[Verwijderd]

ee /etc/periodic.conf

# scrub ZFS pools periodically
daily_scrub_zfs_enable="YES"
daily_scrub_zfs_pools="tank bootpool" # empty string selects all pools
daily_scrub_zfs_default_threshold="30" # days between scrubs

[ilovebrewski]

ok scrub is duidelijk! Advies is dus om de 30 dagen.

Maar is het onder zfsguru ook nodig dedup te draaien of is dit al geïntegreerd?

[FireDrunk]

Dedup draaien? Het staat aan of uit. En het is beter om het uit te laten in de meeste gevallen... Alleen in heel zeldzame gevallen is het nuttig.

[FREAKJAM]

Zocht op "ZFS" op twitter en stuitte hierop:

Reenable vfs.zfs.zio.use_uma for amd64, disabled at r209261.

On machines with seveal CPUs and enough RAM this can easily twice improve
ZFS performance or twice reduce CPU usage. It was disabled three years
ago due to memory and KVA exhaustion reports, but our VM subsystem got
improved a lot since that time, hopefully enough to make another try.

Iemand die dit kan testen?

[ Voor 4% gewijzigd door FREAKJAM op 19-11-2013 20:03 ]

[FireDrunk]

Ik merk geen verschil

[syl765]

@freakjam.

Dit is alleen beschikbaar in FreeBSD 11, ofwel head.

Gr
Johan

[matty___]

syl765 schreef op dinsdag 19 november 2013 @ 23:04:
@freakjam.

Dit is alleen beschikbaar in FreeBSD 11, ofwel head.

Gr
Johan

Niet waar. Zit er nu ook al in. Wat in de commit zat was een if-statement dat het automatisch wordt ingeschakeld als het een AMD64 systeem betreft.

code:

     if defined(__amd64__)
       static int zio_use_uma = 1;
    else
      static int zio_use_uma = 0;
     endif

[ Voor 15% gewijzigd door matty___ op 19-11-2013 23:07 ]

[syl765]

Inderdaad, maar er is geen mfc gepland.
Dus of het ook effect heeft in de stable branch weet ik niet.

Gr
Johan

[ Voor 34% gewijzigd door syl765 op 19-11-2013 23:21 ]

[matty___]

syl765 schreef op dinsdag 19 november 2013 @ 23:19:
Inderdaad, maar er is geen mfc gepland.
Dus of het ook effect heeft in de stable branch weet ik niet.

Gr
Johan

kwestie van

code:

 vfs.zio.use.uma = "1"

toe te voegen aan /boot/loader.conf

[FireDrunk]

Ik heb 10.0-BETA3 en daar zit het gewoon in, stond wel uit. Aangezet, merk niet zoveel verschil.

[syl765]

Ik snap hoe je het aanzet, maar heeft het nut op 10.0, is er meer code verantwoordelijk voor een goede uitvoeing van deze setting?
Ik ben zo en zo benieuwd naar FreeBSD 11 aangezien daar het nieuwe camlock subsysteem van mav@ is toegevoegd.
Als ik het zo lees geeft dit heel wat verbeteringen.

Helaas op het moment geen tijd voor testen enz.

gr
Johan

[FireDrunk]

Deze bedoel je:

http://people.freebsd.org/~mav/camlock.pdf

[matty___]

syl765 schreef op woensdag 20 november 2013 @ 08:52:
Ik snap hoe je het aanzet, maar heeft het nut op 10.0, is er meer code verantwoordelijk voor een goede uitvoeing van deze setting?
Ik ben zo en zo benieuwd naar FreeBSD 11 aangezien daar het nieuwe camlock subsysteem van mav@ is toegevoegd.
Als ik het zo lees geeft dit heel wat verbeteringen.

Er staat dat het 3 jaar geleden is uitgezet de default instelling is veranderd. De uitvoerende code zat er altijd al in alleen je moest het handmatig aanzetten en nu willen ze het weer standaard aanzetten. Dat is de hele commit.

Het is nu in current maar zodra FreeBSD 10.0 release uit is worden de meeste wijzigingen waaronder deze (camlock en nog meer aanpassingen die veel goeds beloven voor storage) naar 10-STABLE verwerkt. Dus je hoeft echt geen jaar te wachten voordat je het kunt uitproberen. Sowieso wordt alle ZFS code vrij vlot naar STABLE (ook 9) verwerkt.

Dus voordat 10.1 uit is zit het al lang in 10-STABLE of te wel ergens in January/Februari

[FireDrunk]

[Mystic Spirit]

Mijn storage VM op basis van ZFSGuru 0.2.0 Beta 8 (9.1) draait en heb toch besloten dat ik voor ik de storage in productie neem. Ik nog even wat testen wil doen m.b.t. de 4k block size.

Ik heb 1 pool gemaakt van 7 WD RED's van 3TiB in RAIDZ2. Direct bij het aanmaken van de pool was de complete pool size volgens ZFSguru 19TB. Ik neem aan dat ZFSguru de data van alle disks rekend en niet alleen de data disks, want dan zou het een vreemd getal zijn.

Kortom bij het aanmaken van de pool ben ik direct 1,5 terrabyte aan schijfruimte kwijt geraakt, wat de laatste disk iets minder dan 50% effectief maakt.

Nu is de vraag raak ik als ik nu files ga plaatsen ook nog ruimte kwijt en daar ben ik de draad een beetje kwijt. Ik plaatste gisteren een testset van circa 300GB aan files op de pool en in de interface van ZFSguru werd gerapporteerd dat er circa 500GB aan ruimte was gebruikt. Dat komt op mij weer als een rare verhouding over. Ik zou een verhouding van 1GB = 1,4GB overhouden omdat je een 7/5 verhouding hebt, maar het komt dus neer op een verhouding van ongeveer 5/3 en dat is 1GB = 1,66GB.

Als die 1,66 representatief is voor mijn complete set dan wordt die 19TB effectief ongeveer 11,5TB. Dat zou wel een heel ernstig verlies betekenen. Zie ik iets over het hoof is het daadwerkelijk zo inefficient?

Om te kijken welke verhouding er overblijft als ik al mijn data naar de pool zet, loopt vandaag een kopie van mijn oude storage (ongeveer 7TB) naar naar de zfs pool. Ik ben benieuwd wat ik dan voor verhoudingen zie.

[Ultraman]

Volgens mij gaat daar wat mis in de rekensom. Dergelijk verlies merk ik niet, al is mijn array niet zo groot.
Sowieso zijn de schijven waarschijnlijk niet 3 TiB, maar 3TB.
Qua effectieve ruimte zou je, in theorie, met 7 * 3TB in raidz2 overhouden: 5 * 3TB = 15TB
Waarom er 19TB wordt aangegeven vind ik ook vreemd.

Controler je bevindingen ook eens vanaf de console gebruikmakend van de zpool list en zfs list commando's, die zullen namelijk accuraat zijn. En kijk dan voor de grap wat df -h aangeeft, want die zal vast afwijken.

[FireDrunk]

Mijn zpool list geeft de grootte van alle schijven (inc parity schijven) (14.5TiB = 4*4.000.000.000.000 bytes). Daar zou je dus op moeten kunnen vertrouwen.

[ Voor 7% gewijzigd door FireDrunk op 20-11-2013 09:38 ]

[]Byte[]

Hmmmm...
Heb nu ZFSguru in een VM draaien. (disken via RDM doorgezet naar de VM)
Maar de (write) benchmark is om te huilen. Die ligt opeens factor 11 lager

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool : pool1 (36.2T, 0% full)
Test size : 128 GiB
normal read : 582 MB/s
normal write : 60 MB/s
I/O bandwidth : 35 GB/s

Dit staat wel enigszins in scrip contrast van de eerdere benchmarks op exact dezelfde hardware:

ZFSguru 0.2.0-beta8 (9.2-001) pool benchmark
Pool : pool1 (36.2T, 0% full)
Test size : 128 GiB
normal read : 537 MB/s
normal write : 699 MB/s
lzjb read : 5 GB/s
lzjb write : 3 GB/s
gzip read : 5 GB/s
gzip write : 3 GB/s
I/O bandwidth : 37 GB/s

Iemand een idee / tips?

[Mystic Spirit]

Excuus... Ik heb in mijn berekening de begrippen TB en TiB omgedraaid. Nu vraag ik mij wel af of ZFSguru de TB en TiB wel goed gebruikt, want dan worden de verhoudingen nog ernstiger. Dan zou ik namelijk van de laatste schijf 2TB zijn kwijt geraakt met de verhouding 1,66 erbij maakt dat de laatste schijf geen ruimte oplevert, maar ruimte kost. Dat zou wel heel raar zijn.

De berekening zou dan zijn:
7x3TB=21TB (ruwe ruimte)
Ruimte is 19TB van de totale pool inclusief parity disks. Is een verlies van 2TB
Gebruikelijk verhouding naar effectieve ruimte op de data disks zou dan 19/1,4=13,6TB aan daadwerkelijk opslag ruimte.
De test data set laat een evrhouding van 1,66 zien wat effectief 19/1,66 = 11,4TB aan daadwerkelijk storage oplevert.
In een normale RAID opstelling zou je effectief 5x3=15TB aan storage overhouden. In de theorie 1,4TB verlies en bij de test data set 3,6TB verlies.

Er moet dus iets mis gaan, maar wat?

@]Byte[: Hoe zit het met je CPU load? Wie weet vergt RDM wat veel van je machine? Er moeten toch voor zo'n grote pool redelijk wat berekeningen gedaan worden voor RDM.
Ik wil als ik mijn huidige data test heb afgerond in mijn VM wel even proberen wat ik voor waardes haal. Ik gebruik geen RDM, maar geef het geheel door via VT-D.

[ Voor 16% gewijzigd door Mystic Spirit op 20-11-2013 10:34 ]

[FireDrunk]

@]Byte[, welke controller gebruik je om de RDM's door te geven? Standaard kiest ESXi voor de LSI Logic Parallel voor een FreeBSD VM, en die controller is nog ouder dan ZFS...

[]Byte[]

LSI Logic Parallel of SAS maakt geen verschil. Beide zijn dramatisch.
Bij de Buslogic en Paravirtual geeft ie aan 'not recommended for this guest OS'

[FireDrunk]

Klopt, open top even tijdens een write en kijk of de load extreem stijgt.

[]Byte[]

Ik kijk vanavond wel even. Kom er nu remote niet meer bij.
Na een reboot van de VM ben ik zelfs mijn ESXi kwijt.
Heb helaas geen remote power-switch

[FireDrunk]

Gaar, klinkt niet goed

[]Byte[]

Niet gaar.... Wel mogelijk stommiteit van mij.
Ik denk dat mijn VM niet van de CD maar vanaf de HD geboot is.
En in die oude config had ZFSguru dezelfde IP als nu ESXi... (had ik nog niet aangepast)

[update]
hmmmm.... Had het ipadres al wel aangepast.
ESXi stond in een PSOD
Ik had de M1015's in passthru naar de VM gezet om zo van het geklier van de disken af te zijn.
Het lijkt er op dat ESXi dit niet helemaal leuk vindt. Zodra de VM wordt gestart gaat heel ESXi hangen.

[ Voor 41% gewijzigd door ]Byte[ op 20-11-2013 15:34 ]

[FireDrunk]

Iemand hier die een ZFS Pool heeft met alleen SSD's, en zo ja, heb je er nog iets aan getuned?

Want ik haal hier lokaal belabberde resultaten (600 iops sync always, 1500 iops sync standard, 43000 sync uit).

En dat is met 2 840Pro's die toch wel erg laag... Sync uit is nog wel te doen, maar de rest is om te janken...

In deze bench:
http://www.storagereview....c_s3500_enterprise_review

Haalt de 840 Pro als vergelijkingsmateriaal toch dik 8000 IOPS bij 4k writes...

[]Byte[]

FireDrunk schreef op woensdag 20 november 2013 @ 15:33:
Iemand hier die een ZFS Pool heeft met alleen SSD's, en zo ja, heb je er nog iets aan getuned?

Ja, pool2 bestaat bij mij uit 4 * Samsung 840 EVO's van 250 GB.
Heb er nog niet mee kunnen testen.
Eerst maar eens zien dat ik 'm draaiend krijg in een VM met alle disken.

[FireDrunk]

Oe, dat klinkt ook wel alsof het snel zou moeten zijn

[]Byte[]

Als het niet snel genoeg is kunnen we altijd nog overstappen op FusionIO-cards
Dan heb je bij random write 4k 'maar' 490k IOPS. (MLC)
(SLC gaat tot 535k IOPS)
Ik weet alleen nog niet wat ze kosten.

[darth.75]

Weet niet of ik hier moet zijn of in het DIY RAID NAS topic, dus als ik verkeerd zit, graag verplaatsen

Ik heb de afgelopen 2 weken het hele topic van voor tot achter doorgelezen, maar heb nog wat vragen:

Ik heb nu een WHS met 4 schijven:

• 320 GB (512B sectors)
• 640 GB (512B sectors)
• 1,5 TB en (512B sectors)
• 2 TB (4kB sectors)

Zitten in een grote pool van zo'n 4 TB, waarvan ik (inclusief folder duplication) zo'n 2,5 TB gebruik (vooral films, muziek enzo, maar ook wat kostbaarder bestanden als foto's en homevids). Ik wil overstappen naar een ZFS systeem (waarschijnlijk FreeNAS) en daarbij zo min mogelijk investeren, maar wel maximale veiligheid en een interessant upgrade pad. Ik denk nu aan het volgende:

Pool 1 = 8 GB USB stick met OS
Pool 2 = Datatank met 640 en 1,5 TB in mirror (640 GB effectief) + 2x 3TB disk + 1x 2 TB disk in Z1 (4 TB effectief)
Pool 3 = Downloadpool met 320 GB in stripe

Ik wil daarmee het volgende bereiken:

• Op termijn de 2 TB in de Z1 pool vervangen door een ander 3 TB exemplaar. De 2 TB kan dan naar de mirror en de 640 kan dan de downloadschijf worden.
• Een aparte downloadpool, zodat de grote datatank kan downspinnen als ik 's nachts download.
• Een aparte downloadpool, zodat als de schijf crasht de rest van mijn data niet geraakt wordt.
• Installatie van Sabnzbd, CouchPotato e.d op de USB stick.

Ik vraag mij af of mijn denkrichting een beetje klopt. Zo ja, dan wil ik op een oude laptop iets vergelijkbaar in elkaar knutselen (maar dan met partities), zodat ik wat kan testen. Bevalt alles dan is de volgende stap het kopen van hardware. Zie ik nog iets over het hoofd?

[jadjong]

FireDrunk schreef op woensdag 20 november 2013 @ 15:33:
Iemand hier die een ZFS Pool heeft met alleen SSD's, en zo ja, heb je er nog iets aan getuned?

Want ik haal hier lokaal belabberde resultaten (600 iops sync always, 1500 iops sync standard, 43000 sync uit).

En dat is met 2 840Pro's die toch wel erg laag... Sync uit is nog wel te doen, maar de rest is om te janken...

In deze bench:
http://www.storagereview....c_s3500_enterprise_review

Haalt de 840 Pro als vergelijkingsmateriaal toch dik 8000 IOPS bij 4k writes...

4xSamsung 830 in raidZ0/basic vdev. Net geen 2GB/s sequential read doordat de controller op PCIeX4 zat. Getest met Bonnie/DD.

[FireDrunk]

Al eens getest via ESXi over gigabit (4k writes)?

[HyperBart]

]Byte\[ schreef op woensdag 20 november 2013 @ 15:51:
Als het niet snel genoeg is kunnen we altijd nog overstappen op FusionIO-cards
Dan heb je bij random write 4k 'maar' 490k IOPS. (MLC)
(SLC gaat tot 535k IOPS)
Ik weet alleen nog niet wat ze kosten.

Veel absoluut gezien, weinig relatief als je ziet wat dat ding uitpoept aan IOPS, en ze zijn een bitch om te managen en of werkend te krijgen onder ESXi (nou ja, een bitch, het zijn gewoon specifieke stukjes hardware en HP maakt ze ook branded, daar zat vooral het issue samen met het feit dat je een hele zut aan verschillende drivers hebt, ook voor ESXi, allemaal een andere naam en toch lijken ze allemaal hetzelfde). Een tijdje geleden heb ik bij mijn klant een upgrade mogen doen van de VMware View omgeving naar Horizon View (5 naar 5.2) en voorafgaand gingen we ook even de hardware nalopen.

Als je er dan achter komt na een uur à anderhalf zoeken dat een FusionIO kaart zich niet "klaar" presenteert zolang je een attach commando geeft op de DCUI, ja dan is dat klote op een zaterdagavond wanneer je al lang gedacht had om thuis te zitten.

Over IOPS: staan uit hun neus te vreten, het is dat de hosts zo overbelast zijn qua CPU... Maar qua IOPS: boooooom. Heb er al wel eens aan gedacht om zoiets als ZIL te willen hebben. Nou ja, als ze afgeschreven zijn misschien

[ Voor 23% gewijzigd door HyperBart op 20-11-2013 19:01 ]

[Mystic Spirit]

Mijn backup job van mijn bestaande server naar de ZFS VM is gefailed op 1082,7GB aan data. Hij was dus ongeveer op 1/7e toen hij eruit is geklapt. Synolgy had een error, dus was niet een probleem aan de ZFSguru kant.

Op zich wel een mooi punt om af te breken want de dataset die ik nu heb is redelijk representatief. de 1082,7GB aan data vertaald zich in de interface van ZFSguru naar 1,59TB en bij de door Ultraman gegeven commando's is dit de output:

zfspool list:

code:

NAME    SIZE    ALLOC   FREE    CAP DEDUB   HEALTH  ALTROOT
ZFS_RZ2 19T 1.59T   17.4T   8%  1.00x   ONLINE  -
zfsboot 7.94G   1.36G   6.58G   17% 1.00x   ONLINE  -

zfs list:

code:

NAME        USED    AVAIL   REFER   MOUNTPOINT
ZFS_RZ2     1.06T   11.4T   304K    /ZFS_RZ2
ZFS_RZ2/share   1.06T   11.4T   304K    /ZFS_RZ2/share

hier komt ook nog een rijtje zfsboot gegevens achteraan maar die is voor nu niet relevant want dat is een HDD van de VM en niet van de pool

df -h:

code:

Filesystem  Size    Used    Avail   Capacity    Mounted on
ZFS_RZ2     11T 304K    11T 0%      /ZFS_RZ2
ZFS_RZ2     12T 1.1T    11T 9%      /ZFS_RZ2/share

Volgens mij is dit nog steeds erg ongunstig. Of interpreteer ik de gegevens verkeerd? Staat T hier voor TB of voor TiB?

[ Voor 5% gewijzigd door Mystic Spirit op 20-11-2013 19:42 ]

[Verwijderd]

T = TiB.

[Mystic Spirit]

Dankjewel Cipher. Dat blijft dus betekenen dat de laatste 3TB schijf maar voor ongeveer 300GB effectief is en waarschijnlijk treed er nog meer verlies op bij het plaatsen van files, waardoor die laatste schijf dus nog steeds waarschijnlijk meer ruimte kost dan hij oplevert.