Het grote ZFS topic

[rednaxela84]

MikeVM schreef op vrijdag 27 december 2013 @ 02:20:
Hey iedereen, ik heb nu al bijna een jaartje mijn zfsguru servertje up and running, maar de disks draaien de hele dag nonstop. ik vind nergens een goede guide hoe ik deze automatisch in sleepmodus laat gaan..

kan iemand me hierbij helpen

camcontroll idle/sleep/standby werkt niet hier.

Dat vraag ik me dus ook af, veel info kan je hier niet over vinden.
Ik heb een pool van 10 disken die 90% van de tijd idle is dus lijkt me zeker nuttig.

[vargo]

Verwijderd schreef op dinsdag 24 december 2013 @ 21:46:
@vargo: niet gaan scrubben met defect RAM; dat is gevaarlijk! Direct je RAM testen en daarna met 100% goed RAM nog een keer scrubben. Heb je dan oncorrigeerbare corruptie dan is de checksum door RAM corruptie verkeerd aangemaakt; dan ben je wel een bestand kwijt.

Memtest vandaag een halve dag laten draaien (6 cycli) en zonder errors.
An sich goed nieuws maar ik vraag me wel af wat dan de oorzaak kan zijn. Wellicht de SASUC8i, maar geen idee hoe ik die kan testen. Iemand suggesties?

[FireDrunk]

Een andere kaart proberen, heb hier nog wel een M1015 liggen, woon je in de buurt van Arnhem?
Je mag hem wel ff gebruiken om te testen (tegen een onderpand ofzo )

]Byte\[ schreef op donderdag 26 december 2013 @ 11:20:
Mijn FC wil nog steeds niet werken...

Wat heb ik gedaan:

in de /boot/loader.conf de volgende regel voor de driver toegevoegd:

code:

ispfw_load="YES"

(ja ik weet het, ik hoef in principe niet alle drivers te laden, maar alleen die van de QLE2300. - maar voor nu even beter mee verlegen dan om verlegen)
in de /boot/devices.hints de volgende regels toegevoegd:

code:

hint.isp.0.fullduplex="1"
hint.isp.0.topology="nport"
hint.isp.0.role="1"

En verder:

code:

[root@zfsguru /usr/src/sys/amd64/conf]# cp GENERIC MYKERNEL

en in MYKERNEL de volgende regel uncommented:

code:

#device          ctl             # CAM Target Layer

Vervolgens:

code:

[root@zfsguru /usr/src]# make buildkernel KERNCONF=MYKERNEL
[root@zfsguru /usr/src]# make installkernel KERNCONF=MYKERNEL

reboot

Kernelbuild lijkt goed te zijn gegaan:

code:

[root@zfsguru ~]# uname -a
FreeBSD zfsguru.bsd 9.2-RELEASE FreeBSD 9.2-RELEASE #0: Wed Dec 25 23:21:04 CET 2013     [e-mail]:/usr/obj/usr/src/sys/MYKERNEL  amd64

Na de reboot een RAMdrive aangemaakt om te testen...

code:

ctladm create -b ramdisk -s 1048576000000 -S ZFSSERIAL001 -d ZFSLUN001
ctladm port -o on
camcontrol devlist -v

En zie daar... de ramdrive:

code:

scbus9 on ctl2cam0 bus 0:
<FREEBSD CTLDISK 0001>             at scbus9 target 1 lun 0 (da14,pass16)
<>                                 at scbus9 target -1 lun -1 ()

In de dmesg:

code:

<knip>
(7:2:0:0): <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
(7:2:0:0):  2048000000 blocks, blocksize 512
da14 at ctl2cam0 bus 0 scbus9 target 1 lun 0
da14: <FREEBSD CTLDISK 0001> Fixed Direct Access SCSI-5 device 
da14: 800.000MB/s transfers WWNN 0x500000020b0dfb00 WWPN 0x500000020b0dfb02 PortID 0x1
da14: Command Queueing enabled
da14: 1000000MB (2048000000 512 byte sectors: 255H 63S/T 127482C)
<knip>

Tot zover lijkt alles nog goed te gaan.

Nu in vSphere onder [Configuration] => [Storage Adapters] een “Rescan All” gedaan...
En toen bleef het akelig STIL!
Op ZFSguru zie ik in de /var/log/messages wel de discovery's van iSCSI naar verder 0,0 meldingen en zeker geen RAMdrive op mijn ESX.

Wat zie ik over het hoofd?

Heb je met ctladm je fc poorten ook al gecontroleerd?

[root@NAS ~]# ctladm port -l
Port Online Type     Name         pp vp WWNN               WWPN
0    NO     IOCTL    CTL ioctl    0  0  0                  0
1    NO     INTERNAL CTL internal 0  0  0                  0
2    YES    ISCSI    iscsi        0  0  0                  0
3    NO     INTERNAL ctl2cam      0  0  0x5000000081ec5b00 0x5000000081ec5b04

[ Voor 89% gewijzigd door FireDrunk op 27-12-2013 18:03 ]

[]Byte[]

FireDrunk schreef op vrijdag 27 december 2013 @ 17:58:
[...]

Heb je met ctladm je fc poorten ook al gecontroleerd?

[root@NAS ~]# ctladm port -l
Port Online Type     Name         pp vp WWNN               WWPN
0    NO     IOCTL    CTL ioctl    0  0  0                  0
1    NO     INTERNAL CTL internal 0  0  0                  0
2    YES    ISCSI    iscsi        0  0  0                  0
3    NO     INTERNAL ctl2cam      0  0  0x5000000081ec5b00 0x5000000081ec5b04

Nee, die had ik nog niet geprobeerd.

[root@zfsguru ~]# ctladm port -l
Port Online Type     Name         pp vp WWNN               WWPN              
0    YES    IOCTL    CTL ioctl    0  0  0                  0                 
1    YES    INTERNAL ctl2cam      0  0  0x500000020b0dfb00 0x500000020b0dfb02
2    YES    INTERNAL CTL internal 0  0  0                  0                 

Hij lijkt wel online te staan.
Zou ik in dit overzicht ook de disk moeten zien staan?

[FireDrunk]

Nee, je controllers...

[]Byte[]

FireDrunk schreef op vrijdag 27 december 2013 @ 22:00:
Nee, je controllers...

Oke. Dat is duidelijk. En de conclusie is nu?

[Durandal]

C0rnelis schreef op woensdag 25 december 2013 @ 19:27:
[...]


Thanks, ik heb 'em nu uitgezet en ga z.s.m. achter nieuwe schijven aan. Voor mijn informatie: het klopt dat ik ook met 4 disks (dus zonder enige vorm van redundantie) "zonder problemen" 2 nieuwe schijven kan aansluiten en mijn pool kan resilveren ?

Ja, maar hou de volgorde aan die ik zei, dus per 1 disk vervangen. Kapotte eerst en slechte nog even laten zitten. Daarna de slechte vervangen; disk bij steken, replace commando geven (gaat resilveren). Als 'ie klaar is kan je de slechte er uit nemen en ben je klaar.

Als je in een keer 2 disks vervangt ben je een tijdje redundantieloos en waarom zou je dat risiko nemen?

FireDrunk schreef op vrijdag 27 december 2013 @ 17:58:
Een andere kaart proberen, heb hier nog wel een M1015 liggen, woon je in de buurt van Arnhem?
Je mag hem wel ff gebruiken om te testen (tegen een onderpand ofzo )

Ik ruik een verkapte verkoop truuk

[ Voor 17% gewijzigd door Durandal op 28-12-2013 02:13 ]

[FireDrunk]

Nah, zo'n M1015 is altijd handig om te hebben liggen

[vargo]

FireDrunk schreef op vrijdag 27 december 2013 @ 17:58:
Een andere kaart proberen, heb hier nog wel een M1015 liggen, woon je in de buurt van Arnhem?
Je mag hem wel ff gebruiken om te testen (tegen een onderpand ofzo )

Ah dank voor het aanbod; ik ben de komende week in het buitenland en kijk daarna even wat handig is. Ik woon in Utrecht dus dat is nog een eindje uit de buurt.

[C0rnelis]

Durandal schreef op zaterdag 28 december 2013 @ 02:05:
[...]

Ja, maar hou de volgorde aan die ik zei, dus per 1 disk vervangen. Kapotte eerst en slechte nog even laten zitten. Daarna de slechte vervangen; disk bij steken, replace commando geven (gaat resilveren). Als 'ie klaar is kan je de slechte er uit nemen en ben je klaar.

Als je in een keer 2 disks vervangt ben je een tijdje redundantieloos en waarom zou je dat risiko nemen?


[...]

Ik ruik een verkapte verkoop truuk

Snapte ik De dode disk gisteravond al vervangen en is inmiddels al geresilvered een uurtje of 12 later.

[Q]

Vraag:

Waarom is een SSD met supercapacitor zo belangrijk als je de server (natuurlijk) aan een UPS hebt hangen?

Of de vraag anders gesteld: is een supercapacitor of wat die Crucial M500 doet nog echt relevant als je een UPS gebruikt?

[Verwijderd]

Ja, omdat de meeste onverwachte stroomonderbrekingen niet het gevolg zijn van een stroomstoring, maar softwarematige issues. Bij sommige gebruikers is dat zelfs bij elke shutdown het geval; dat kan een bug zijn in het OS of de drivers, waardoor er niet gewacht wordt op het sturen van een STANDBY IMMEDIATE commando. Alleen na het sturen van zo'n commando mag de stroom worden onderbroken. Dat kan veel vaker mis gaan dan stroomstoringen.

Stroomstoringen komen in Nederland heel zelden voor (eens per 3 jaar) maar unexpected power-loss kun je in je SMART goed vinden; dat komt veel vaker voor; tussen de 20 en 200 keer per jaar. Power-safe capacitors zijn dus niet optioneel maar eigenlijk een verplicht onderdeel voor elke op NAND-gebaseerde SSD.

[FireDrunk]

Of je moet een UPS achter je SSD zetten

Oh muuuux

[Verwijderd]

Helaas is dat ook geen garantie omdat de firmware geen seintje krijgt dat de stroom eraf gaat. Ding van mux werkt waarschijnlijk prima op een Intel SSD die niet/nauwelijks aan background management doet, maar neem een Samsung die bij idle vanalles doet en je hebt het probleem hooguit een aantal milliseconden uitgesteld.

Het blijft een kwetsbaarheid van NAND geheugen dat er ernstige corruptie voor kan doen bij het onderbreken van actieve writes. En doordat een SSD op de achtergrond - terwijl de host idle is - allemaal I/O kan gaan uitvoeren, kan ook onderbreking bij idle dus ernstige problemen opleveren.

Geen SSDs meer kopen zonder power caps lijkt mij een redelijk advies, in elk geval totdat de opvolger van NAND zijn intrede doet; zoals MRAM of PCM.

[FireDrunk]

Nou ja, de firmware krijgt (in veel gevallen) een seintje dat de data verbinding wegvalt. Dat zou de firmware moeten triggeren om te flushen.

Het is inderdaad geen zekerheid, en advies is zeker om een SSD met Supercaps te kopen.

Aan de andere kant is het voor mensen die al een sloot SSD's hebben (zoals ik ) wel een goedkope uitkomst. Want zomaar even omruilen is ook niet makkelijk

Had je trouwens mijn idee gezien met de PCIe mSATA kaart? Wat vind jij van die Marvell controller?

[ Voor 11% gewijzigd door FireDrunk op 28-12-2013 12:29 ]

[Q]

Ok helder, bedankt, maar de problematiek met een SSD heb je ook gewoon met reguliere schijven, lijkt me. Het is vooral dat background gedrag van SSDs dat vooral een probleem kan zijn en wat je niet hebt met reguliere harde schijven?

Letop: mijn context is een NAS voor thuisgebruik, niet voor een bedrijfsmatige multi-user toepassing.

Mooi artikel: http://nex7.blogspot.nl/2013/04/zfs-intent-log.html

Stelling: NAS bouwers hebben geen SLOG nodig op SSD voor het ZIL. Een SLOG is vooral kritisch als je de ZFS storage gebruikt als onderliggende laag voor VMs en Database servers.

ZFS qua file system is altijd qua integriteit gewaarborgd, maar de DATA niet. Je kunt data verlies hebben, maar je zult geen file system corruptie hebben. Voor mij zou dat prima zijn.

De sleutel hier is SYNC writes. Alleen SYNC writes raken de SLOG. NFS doet volgens mij standaard SYNC writes.

Ik gebruik ZFS alleen om data op te slaan als in een soort van archief. Random I/O boeit mij als NAS gebruiker niet. Ik wil snelle sequentiële doorvoer. Als de stroom er af valt of als een server crashed -> dan kun je dataverlies hebben.

Maakt mij niet uit, dan kopieer ik de data wel opnieuw.

Het SLOG is er alleen om ZIL te versnellen omdat dit snel een bottleneck wordt op de VDEVs zelf die zowel het ZIL als de reguliere data af moeten handelen.

Voor een NAS is een SSD cache eigenlijk ook niet interessant, want harde schijven zijn prima ok voor het in tempo sequentieel doorvoeren van data.

Een separaat SLOG device en SSD Readcache is pas spannend als je veel random I/O doet (multi-user, VM, DB, etc).

Of pies ik heel erg naast de pot?

[Verwijderd]

FireDrunk schreef op zaterdag 28 december 2013 @ 12:28:
Nou ja, de firmware krijgt (in veel gevallen) een seintje dat de data verbinding wegvalt. Dat zou de firmware moeten triggeren om te flushen.

Mee eens, maar in geval van het apparaatje van Mux krijgt de SSD een dergelijk seintje niet, omdat de stroom niet wegvalt. Of heb ik het mis?

Aan de andere kant is het voor mensen die al een sloot SSD's hebben (zoals ik ) wel een goedkope uitkomst. Want zomaar even omruilen is ook niet makkelijk

Het zal zeker helpen ook al krijgt de firmware geen seintje; je zorgt in elk geval dat recente activiteit van de host niet meer van invloed is, hooguit background activiteit. Die mogelijk pas triggered na een periode van activiteit; dat wellicht werkt het in de praktijk goed genoeg om echt waardevol te zijn.

Had je trouwens mijn idee gezien met de PCIe mSATA kaart? Wat vind jij van die Marvell controller?

Ik heb wat gemist denk ik. Heb je een linkje voor me?

---

Q schreef op zaterdag 28 december 2013 @ 14:00:
Ok helder, bedankt, maar de problematiek met een SSD heb je ook gewoon met reguliere schijven, lijkt me.

Absoluut niet! Dat is juist het hele probleem.

Filesystems en applicaties zijn allemaal gebouwd om om te gaan tegen verlies van recente writes; dat is immers het enige wat grofweg mis kan gaan met hardeschijven; verliezen van recente writes. Data die er al een tijdje staat, is veilig en hoeft niet te vrezen van onverwacht stroomverlies.

Bij SSDs is dit totaal anders; daar kan data die al tijden lang niet is aangeraakt, toch gemutileerd worden door onverwacht stroomverlies. Het wegvallen van spanning tijdens het schrijven of erasen van NAND kan gevolgen voor omliggende blokken hebben. Daarnaast kan er zogenaamde 'Retroactive Data Corruption' plaatsvinden, die lastig te detecteren is en voor corruptie kan zorgen.

Maar ook de mapping tables voegen een extra kwetsbaarheid toe. Zonder deze inhoudsopgave ben je nergens, en een corrupte mapping table betekent in principe dat alle data weg is. Een bricked SSD die je alleen nog kunt flashen; Intel SSDs kenmerken zich hierbij door 8MB als opslagcapaciteit weer te geven. Andere SSDs worden simpelweg niet meer herkend totdat ze met HPA Secure Erase (HDDErase.exe) een nieuwe mapping table is gegeven.

Dan geldt bij Sandforce nog dat er naast de mapping tables ook deduptables worden bijgehouden, die ook corrupt kunnen raken. Dan heb je allemaal snippertjes van data waar je niets mee kunt. Kortom, een SSD is vele malen gevoeliger voor onverwacht stroomverlies dan een hardeschijf. Erger nog is dat het gedrag ook heel anders is, waardoor corruptie op SSD-niveau ernstige gevolgen kan hebben voor je filesystem die daar helemaal niet tegen bestand is. Alle rare Windows-foutmeldingen die je bij OCZ SSDs tegenkomt, zijn de gevolgen van corruptie op SSD niveau. Onacceptabel - uiteraard. NAND SSDs hebben capacitor-bescherming simpelweg nodig.

Grappig is dat mensen de noodzaak voor 'capacitors' als onzin af doen, omdat recente writes helemaal niet zo belangrijk zijn; je filesystem kan daar immers prima tegen met journalling en intent log. De grap is dat bijvoorbeeld de Crucial M500 niet genoeg capaciteit heeft om de 6MiB buffercache weg te schrijven, maar alleen beschermt tegen het onderbreken van een lopende write-erase-cycle. De buffercache verdwijnt gewoon, poef. Niet erg, daar kan je filesystem tegen.

Letop: mijn context is een NAS voor thuisgebruik, niet voor een bedrijfsmatige multi-user toepassing.
Mooi artikel: http://nex7.blogspot.nl/2013/04/zfs-intent-log.html
Stelling: NAS bouwers hebben geen SLOG nodig op SSD voor het ZIL. Een SLOG is vooral kritisch als je de ZFS storage gebruikt als onderliggende laag voor VMs en Database servers.

Je kunt gewoon sync=disabled op je filesystems instellen, maar normaliter is dat niet nodig omdat je weinig sync writes te verwerken krijgt.

Maar als je zoals je zegt application consistency nodig hebt, voor je ESXi NFS mounts, voor je iSCSI ZVOLs met foreign filesystem erop, dan wil je sync=standard of sync=always ingesteld hebben. Dan gaat het je wel performance kosten, performance die je kunt verbeteren met een sLOG.

ZFS qua file system is altijd qua integriteit gewaarborgd, maar de DATA niet.

De data ook, enkel de order-of-writes is niet gegarandeerd met sync=disabled. Voor zover ik begrepen heb. Dus gebruik je iSCSI zonder sLOG en met sync=disabled, dan is na een harde crash je ZFS filesystem prima intact maar je Ext4-filesystem op het iSCSI-volume deels corrupt. Of althans in een inconsistente staat waarbij fsck/chkdsk uitgevoerd dient te worden.

Een separaat SLOG device en SSD Readcache is pas spannend als je veel random I/O doet (multi-user, VM, DB, etc).
Of pies ik heel erg naast de pot?

Dat zijn natuurlijk de situaties bij uitstek waarbij cache en sLOG tot zijn recht komt. Maar alleen al het cachen van metadata kan heel erg waardevol zijn, voor zoekacties, voor snel door grote directories kunnen lopen. Verder geldt dat hoe minder je hardeschijven seeks moeten doen voor metadata, des te meer ze zich kunnen concentreren op waar ze goed in zijn: sequential read en write. Als het aandeel random I/O op device-niveau significant genoeg is om de performance van sequential te beïnvloeden, dan heeft een SSD nut voor het doel de sequential I/O te verbeteren.

Zeker een grote array is het erg zonde als er niet tenminste een SSD aanwezig is om de metadata te cachen. Bovendien zijn er vaak toch wel zaken die niet louter sequential worden uitgelezen. En een SSD is leuk voor snelle boots (bij gebruik van Root-on-ZFS) en heb je gelijk een mooie separatie tussen OS en data.

[FireDrunk]

Q schreef op zaterdag 28 december 2013 @ 14:00:
Ok helder, bedankt, maar de problematiek met een SSD heb je ook gewoon met reguliere schijven, lijkt me. Het is vooral dat background gedrag van SSDs dat vooral een probleem kan zijn en wat je niet hebt met reguliere harde schijven?

Letop: mijn context is een NAS voor thuisgebruik, niet voor een bedrijfsmatige multi-user toepassing.

Mooi artikel: http://nex7.blogspot.nl/2013/04/zfs-intent-log.html

Stelling: NAS bouwers hebben geen SLOG nodig op SSD voor het ZIL. Een SLOG is vooral kritisch als je de ZFS storage gebruikt als onderliggende laag voor VMs en Database servers.

Makkelijker gezegd, als je je datastore voor random IO gebruikt... Of het nou sync is of niet, een SLOG helpt altijd wel.

ZFS qua file system is altijd qua integriteit gewaarborgd, maar de DATA niet. Je kunt data verlies hebben, maar je zult geen file system corruptie hebben. Voor mij zou dat prima zijn.

De sleutel hier is SYNC writes. Alleen SYNC writes raken de SLOG. NFS doet volgens mij standaard SYNC writes.

Niet helemaal, ESXi bijvoorbeeld overspoelt je datastore met SYNC writes, maar ook weer niet *alle* writes, maar iig wel veel...
NFS heeft daar niets mee te maken, die kan beide (ASYNC en SYNC).

Ik gebruik ZFS alleen om data op te slaan als in een soort van archief. Random I/O boeit mij als NAS gebruiker niet. Ik wil snelle sequentiële doorvoer. Als de stroom er af valt of als een server crashed -> dan kun je dataverlies hebben.

Maakt mij niet uit, dan kopieer ik de data wel opnieuw.

Het SLOG is er alleen om ZIL te versnellen omdat dit snel een bottleneck wordt op de VDEVs zelf die zowel het ZIL als de reguliere data af moeten handelen.

SLOG is technisch gezien je ZIL, alleen op een ander device (Seperate Log)

Voor een NAS is een SSD cache eigenlijk ook niet interessant, want harde schijven zijn prima ok voor het in tempo sequentieel doorvoeren van data.

Leuke van L2ARC is ook dat je daar je directory structuur in kan laden, en dat je disks pas opspinnen als er data nodig is buiten de L2ARC.

Een separaat SLOG device en SSD Readcache is pas spannend als je veel random I/O doet (multi-user, VM, DB, etc).

Of pies ik heel erg naast de pot?

Ik weet niet, kan je niet goed mikken?

[HyperBart]

Grappig is dat mensen de noodzaak voor 'capacitors' als onzin af doen, omdat recente writes helemaal niet zo belangrijk zijn; je filesystem kan daar immers prima tegen met journalling en intent log. De grap is dat bijvoorbeeld de Crucial M500 niet genoeg capaciteit heeft om de 6MiB buffercache weg te schrijven, maar alleen beschermt tegen het onderbreken van een lopende write-erase-cycle. De buffercache verdwijnt gewoon, poef. Niet erg, daar kan je filesystem tegen.

Eeeeeuh wacht even, rewind.

Dat wil dan toch zeggen dat een M500 gebruiken als ZIL gewoon bad practice is?

[FireDrunk]

idd, als dat echt zo is, kan het namelijk zijn dat bijvoorbeeld mijn ESXi VM's tegelijkertijd allemaal SYNC writes sturen om hun journal te updaten, maar dat dat allemaal mislukt omdat dat in DRAM cache zit?

Tenzij de M500 bij SYNC writes echt het DRAM cache over slaat (wat mij logisch lijkt), dan zou het wel weer goed gaan omdat een ZIL nooit ASYNC beschreven wordt...

[Verwijderd]

Ja en nee, het punt is dat een veilige write-back het FLUSH CACHE-commando eerbiedigt. Hardware RAID controller negeren deze flush-commando's simpelweg, anders kan hun gigabyte-grote write-back nauwelijks gevuld worden. Maar ik heb geen reden te twijfelen dat de M500 wel degelijk sync writes correct uitvoert, dat wil zeggen dat het FLUSH CACHE commando blijft 'hangen' totdat de write-back is weggeschreven.

Als dat klopt, hetgeen ik verwacht, is het allemaal zo erg niet dat de M500 zijn write-back verliest. Maar de Intel 320 of S3500 is om deze reden mogelijk wel een betere / veiligere keuze. 100% zeker weten doe ik het niet namelijk, dus op veilig gaan en voor Intel kiezen is een overweging. Dat gezegd gebruik ik zelf ook M500; veel goedkoper per GB natuurlijk.

[FireDrunk]

Heb je een linkje waar gezegd word dat die M500 zulke 'waardeloze' supercaps heeft?

De Seagate 600 Pro heeft namelijk volgens een aantal review sites wel genoeg power om zijn hele DRAM cache te flushen.

http://www.tweaktown.com/...se-ssd-review/index3.html

[ Voor 56% gewijzigd door FireDrunk op 28-12-2013 17:43 ]

[Verwijderd]

Nee. Maar je zou een aanwijzing kunnen vinden in het feit dat de capacitors maar goed zouden zijn voor iets van 0,01 seconde bij de M500. Zelfs die spec kan ik niet zo gauw terugvinden in de PDF. Als een van jullie beter kan zoeken hoor ik graag de uitkomst.

[FireDrunk]

Ok... *tik* *tik* *tik...

* FireDrunk streept een paar puntjes weg bij de M500...


http://www.tomshardware.c...-m500-1tb-ssd,3551-2.html

Supercapacitors are basically big honkin' batteries, like a mini-UPS on the PCB. They've fallen out of favor over the past few years though, and many drives rely on a series of tantalum caps to keep data flowing when power to the SSD is interrupted. Crucial goes with a slightly different approach on the M500, though. Armed with a series of small caps, the controller flushes most of what's in the cache, while using "NAND tricks" to make up any deficit. At any given time, there's only 1 to 4 MB of user data in the DRAM, so it's not like the hardware is trying to write the Great American Novel in a handful of microseconds.

[ Voor 79% gewijzigd door FireDrunk op 28-12-2013 18:13 ]

[Verwijderd]

De supercaps van die Seagate 600 (evenals bij de Intel 320) zijn ook stukken groter dan de 'mini caps' van de M500. Maargoed, het belangrijkste is dat het NAND nooit onderbroken wordt gedurende write/erase-cycli.

[FireDrunk]

Maar goed, tenzij echt bewezen wordt dat de M500 de SYNC writes / cache flushes honoreert, vind ik het advies om de M500 als ZIL te gebruiken onterecht. Als er meerdere journal writes binnenkomen en de M500 kan ze niet allemaal afmaken, kan je zeker corruptie krijgen in VM's gok ik zo...

[Verwijderd]

Maar dat is de bewijslast omdraaien. Er is geen aanwijzing dat een respectabel product als de M500 zou afwijken van de gangbare conventie om de ATA-standaard te eerbiedigen, en FLUSH CACHE-commando's op juiste manier af te wikkelen. Enige wat je daarover hoort is in combinatie met Hardware RAID; vandaar ook de noodzaak voor een BBU. Een BBU zou niet nodig zijn als de flush-commando's normaal werden uitgevoerd.

Bovendien krijg je filesystem corruptie als flush-commando's niet correct worden geïmplementeerd; dan hadden we meer vage windows-boot problemen hadden moeten zien met een populaire SSD als de M500. Kortom, als ik mag uitgaan van mijn gevoel, dan denk ik dat de M500 inderdaad geen write-back kan flushen bij stroomfalen, maar wel flush-commando's eerbiedigt. Mijn logica zegt mij dat het apparaat dan nog steeds geschikt is voor sLOG; al hoor ik dat graag van een échte expert.

[FireDrunk]

SLOG is inherent altijd single queue synced write, dus zou je er dan vanuit moeten kunnen gaan dat hij geschikt is omdat hij zijn DRAM overslaat.

Ik las op HardForum ook al zoiets. Daar zij iemand ook: Als je SSD een synced write echt goed honoreert heb je helemaal geen powercaps nodig, want de data staat *echt* op NAND (inc gewijzigde mapping tables) voordat de write klaar gemeld word door de SSD.

Maar goed, dat moet getest worden denk ik dan... Hebben we dan niet liever de zekerheid van een 600 Pro of een DC3500 / DC3700?

[ Voor 13% gewijzigd door FireDrunk op 28-12-2013 18:59 ]

[Verwijderd]

Ik las op HardForum ook al zoiets. Daar zij iemand ook: Als je SSD een synced write echt goed honoreert heb je helemaal geen powercaps nodig, want de data staat *echt* op NAND

Als powercaps enkel nodig waren voor het beschermen tegen verlies van de write-back, gaf ik hem gelijk. Echter, de voornaamste (en bij de M500 enige) taak van powercaps is het beschermen tegen retroactive datacorruption; beschadiging en corruptie van de NAND zelf. Dat heeft met name gevolgen voor al bestaande data, en niet recent geschreven data. Daarom is het zo cruciaal dat elke SSD over power-caps beschikt. Net zoals elke desktopcomputer eigenlijk over ECC RAM zou dienen te beschikken. 99% veiligheid is niet genoeg; je stapt ook niet in een vliegtuig wat 99% veilig is.

[FireDrunk]

Maar als de SSD gewoon doet wat hem opgedragen wordt, heb je toch zelfs geen retroactive datacorruptie?

SSD ontvangt data
SSD leest mapping table
SSD schrijft data in lege plek (ik ga even uit van een situatie waarin je SSD niet 100% vol is )
SSD markeert data in mapping table
SSD zegt "OK done!"

Als de stroom uit valt en de SSD kan de write niet afmaken, prima, ZFS ging er toch niet vanuit dat het al weggeschreven was. Valt de stroom uit en is de write gedaan, leest ZFS de ZIL in en ziet, hey, een actie om uit te voeren, ff checken of dat gaat.

Pas als de SSD de data in DRAM zet, en al een OK teruggeeft, kan het fout gaan. Als de SSD *niets* anders doet dan de data wegschrijven, zou ik niet verwachten dat er corruptie optreed...

[ Voor 4% gewijzigd door FireDrunk op 28-12-2013 19:33 ]

[Verwijderd]

Het punt is dat bij het wegvallen van de stroom tijdens een write- of erasecyclus er corruptie kan plaatsvinden in bestaande data die niet recent is beschreven. Ook kan er permanente fysieke beschadiging optreden waardoor een specifieke NAND cell een veel minder hoge retentietijd heeft dan een normale cell. Dit valt voor de controller niet te detecteren. Voor sLOG zal het laatstgenoemde probleem niet zo heel erg zijn aangezien alleen de zeer recent geschreven data relevant is. Maar het eerste probleem is zeker aanwezig. NAND mag niet onderbroken worden tijdens een wis- of schrijfactie, anders kun je problemen verwachten.

Edit: hier heb ik wel een linkje van: PDF

Samsung SSDs zijn nog minder geschikt voor sLOG omdat ze de mapping tables kunnen terugdraaien; een soort journalling voor de mapping tables. Dit maakt deze SSD bijna per definitie ongeschikt als sLOG. Voor doorsnee consumenten desktopsystemen is dit veel minder erg. Maar ook hier geldt dus dat ook minder recent beschreven data ná een flush commando niet geheel veilig is. Is dat wel wat je wilt van een opslagapparaat vraag ik me dan af.... Samsung komt er mee weg, en is zelfs zeer succesvol op de SSD markt. Maar of dat terecht is....

[ Voor 5% gewijzigd door Verwijderd op 28-12-2013 19:44 ]

[mux]

Verwijderd schreef op zaterdag 28 december 2013 @ 19:07:
[...]

Als powercaps enkel nodig waren voor het beschermen tegen verlies van de write-back, gaf ik hem gelijk. Echter, de voornaamste (en bij de M500 enige) taak van powercaps is het beschermen tegen retroactive datacorruption; beschadiging en corruptie van de NAND zelf. Dat heeft met name gevolgen voor al bestaande data, en niet recent geschreven data. Daarom is het zo cruciaal dat elke SSD over power-caps beschikt. Net zoals elke desktopcomputer eigenlijk over ECC RAM zou dienen te beschikken. 99% veiligheid is niet genoeg; je stapt ook niet in een vliegtuig wat 99% veilig is.

Op verzoek van thijs meng ik me toch maar even in de discussie

Hoe bedoel je retroactieve datacorruptie? Je kunt flash niet beschadigen puur door de spanning eraf te halen op een random moment. De enige manier om datacorruptie te veroorzaken is door er een illegale, corrupte of incomplete write in te gooien. En de schade blijft dan beperkt tot die block, spul eromheen blijft zoals hij blijft. Geen enkel onderdeel van een NAND Flash chip is volatiel. Het is niet zo als bij DRAM dat je bij een block refresh een hele column+row powert en dat dan bij problemen al die andere blokken die ook in dezelfde kolom of rij zaten ook problemen krijgen. Flash werkt niet zo. Reeds opgeslagen data wordt niet gedegradeerd zolang het niet beschreven wordt, ook niet bij power failures. Dit failure mechanism is alleen van toepassing bij DRAM en SRAM, en dan specifiek de 2- of 3-transistor varianten.

Maareh... jullie duiken wel érg diep in de details hier. 99% van de betrouwbaarheid van een SSD als SLOG of ZIL hangt niet af van z'n specifieke features, maar van de implementatie ervan. Power failure is een extreem zeldzaam event dat zelfs bij een SLOG, in een goed ontworpen systeem, maar hele kleine repercussies heeft. Vergeet niet dat zelfs in een 'busy' systeem je SSDs nog steeds voornamelijk zitten te idlen. En power failures die niet door een opgeblazen voeding worden veroorzaakt zullen toch als eerste je netwerk eruit flikkeren voordat de fileserver op z'n donder krijgt. En... En... Moet ik het nog over kansberekeningsmodellen hebben?

Zonder harde performance- en security-data kun je hier echt niet (terecht) zulke sterke meningen over hebben. Ik zou bijna een hele stapel SSDs als sponsoring vragen en een grote test draaien ofzo.

[Verwijderd]

Power failure is een extreem zeldzaam event

Vanuit het perspectief van de host misschien wel, vanuit het perspectief van de SSD niet zeldzaam. Denk aan power-knop tijdens BIOS-fase gebruiken, OS crashes of voortijdige shutdowns. Sommige gebruikers hebben vrijwel geen enkele veilige shutdown en alleen maar onveilige shutdowns. OS bugs vermoed ik, maar dat is gissen.

Je kunt het aantal onveilige shutdowns zien in de SMART data van je SSD: Unexpected Power-Loss. Dat getal is vele malen groter dan échte power failures die je al dan niet hebt ervaren.

Wat betreft Retroactive Datacorruption; heb je het PDF-linkje in mijn voorgaande reactie al gelezen? Daarin wordt namelijk het tegenovergestelde beweerd dan wat jij geschreven hebt over NAND flashgeheugen.

[mux]

Yes, ik heb hem nu doorgelezen, en begrijp waar de confusion vandaan komt. Ik heb het namelijk over logical blocks en pages, en in de PDF hebben ze het over eh... een ander soort definitie van pages. Hier is de letterlijke tekst:

For 2-bit MLC chips, cells store data of two different pages.
Manufactures require that pages within a block be programmed in
order, so to differentiate between the two pages in a cell, we refer
to them as “first page” and “second page.”

(...)

The unpredictable effect of power loss during an MLC program
operation demonstrated above makes it clear that SSDs must assume
that data written during an interrupted program is corrupt.
However, the data in Figure 2 also show something more dangerous:
Power failure while programming a second page can corrupt
data that the chip successfully programmed into a first page. We
call this effect retroactive data corruption.

Dit zijn geen logische pages, maar dit is een manier waarop SSDs omgaan met het vertalen van logische pages naar fysieke pages. Het is echter niet zo dat er twee totaal onafhankelijke logische pages worden geschreven naar dezelfde fysieke cellen! Dat zou desastreus zijn, en bovendien altijd voor x2 write amplification zorgen bij een write, wat gewoon nutteloos is.

Deze paper doet niks af aan het feit dat een goede implementatie van power-loss corruption flagging gewoon het hele block moet afkeuren.

Unexpected power loss op de manier die jij zegt is niet zo belangrijk. Op dat moment worden er geen writes naar je SSD gestuurd - en als er al writes naartoe gaan zijn ze niet op userdata. Wat relevant is voor corruptie is power loss tijdens primaire SLOG/ZIL-transacties. En het is m.i. geen zwart-wit verhaal of je dan belt&braces alles altijd moet uitvoeren met de best mogelijke bescherming tegen corruptie.

Dat is hetzelfde als ECC. ECC is leuk en aardig, maar als het je 2x zoveel geld kost om een equivalent ECC-capable systeem neer te zetten dan om een fatsoenlijke (cryptografische) software error correction over je data te gooien en absoluut maximale performance is niet belangrijk, dan is er best een economisch motief om dat te doen.

Even totaal los van deze discussie is de M500 trouwens wel een complete no-brainer in deze discussie. Goedkoper én beter, welk motief is er dan nog om een andere SSD te nemen? Het enige wat de M500 niet goed doet is performance-consistentie, maar dat staat wel héél laag op de prioriteitenlijst.

[FireDrunk]

Nou ja, er zijn alternatieven (Intel DC3500/3700, Seagate 600 Pro)

Als het puur om performance gaat, dan pak ik liever een 840 Pro, performt vele malen beter dan een M500, en verbruikt ook nog eens veel minder stroom (hoewel het in absolute getallen niet zo veel is).

Als we 'teruggaan' naar de performance van een M500 met de reden: geschikt voor ZIL, maar het blijkt dat de M500 niet geschikt is, is het zonde van het inleveren van performance ten opzichte van een 840 Pro...

Het is een beetje: Krijg je de 'zekerheid' die je wil met een M500 of is het schijn, want als het alleen maar schijn is, dan kan je misschien wel beter een andere SSD kiezen...

[Afwezig]

Even een vraag tussen de discussie door. Ik wil een SLOG SSD in mijn ZFS raid gaan hangen. Door beperkingen in het aantal SATA porten is het voor mij niet haalbaar om meerdere losse SSD's te gaan gebruiken voor SLOG / L2ARC en een klein beetje 'losse' SSD ruimte wat ik nodig heb. Mijn idee is nu om 2 80GB Intel DC S3500 SSD's te gaan gebruiken. 2x10 GB Mirror voor SLOG, 2x20 GB L2ARC in stripe (totaal 40GB) en de overige 2x50GB (totaal 100GB) voor wat losse SSD ruimte voor applicaties die veel IOPS vragen.

Ik weet dat het niet optimaal is, maar is het mogelijk?

[Xudonax]

Als je het partitioneerd moet dat geen probleem zijn. Tot vanochtend draaide ik in een vergelijkbare setup, maar dan met slechts 1 SSD. Wel zou ik kijken om wat extra ruimte vrij te laten voor de garbage collector, hoewel ik niet zeker weet hoe nuttig dat nog is voor deze moderne SSDs...

[HyperBart]

Afwezig schreef op zaterdag 28 december 2013 @ 22:14:
Even een vraag tussen de discussie door. Ik wil een SLOG SSD in mijn ZFS raid gaan hangen. Door beperkingen in het aantal SATA porten is het voor mij niet haalbaar om meerdere losse SSD's te gaan gebruiken voor SLOG / L2ARC en een klein beetje 'losse' SSD ruimte wat ik nodig heb. Mijn idee is nu om 2 80GB Intel DC S3500 SSD's te gaan gebruiken. 2x10 GB Mirror voor SLOG, 2x20 GB L2ARC in stripe (totaal 40GB) en de overige 2x50GB (totaal 100GB) voor wat losse SSD ruimte voor applicaties die veel IOPS vragen.

Ik weet dat het niet optimaal is, maar is het mogelijk?

Buiten dat het op 2 ssd is gecombineerd, is dit inderdaad de meest optimale situatie die je kan hebben...

Wel genoeg lege ruimte overhouden.

[Q]

<knip> (hoop geneuzel van mijn kant)

De Crucial M50 240 GB:

pricewatch: Crucial 2.5" M500 240GB

Doet 120 euro inclusief BTW en kan

500 MB/s Lezen
250 MB/s Schrijven

Lijkt mij eigenlijk prima toch als SLOG in RAID1?

240 euro voor een RAID1 boot setup + L2ARC + SLOG vs. 100 euro voor 2 x 320 GB 2.5" 7200 RPM hard diskjes.

Voor wie die 250 MB/s te traag is: dit is alleen voor SYNC writes...

De Samsung 840 Pro heeft fors betere prestaties op papier qua write performance en IOPS.

pricewatch: Samsung 840 series Pro 256GB

Dan zou je ook nog kunnen overwegen als je de slijtage van SSD tegen staat om deze in te zetten:

pricewatch: WD WD2500BHTZ, 250GB

Maar de IOPS en throughput zijn beduidend lager. Of je maakt er een RAID10 van.

Maar als ZFS een sustained data transfer op een array van zeg 8 disks kan leveren van 400+ MB/s dan is dat al lang mooi zat en zie ik weinig noodzaak voor een separaat SLOG. Een SSD als read-cache kan interessant zijn, maar niet voor domme archivering storage.

Voor mijn nieuwe server ga ik even uitzoeken of ik zonder SSDs een eind kom met ZFS. SSDs kunnen altijd later nog gekocht worden. Het gaat niet om heel veel geld, maar het hoeft ook niet nodeloos te worden uitgegeven.

[ Voor 102% gewijzigd door Q op 29-12-2013 04:09 ]

[FireDrunk]

De specs van een SSD zijn voor SLOG compleet nutteloos. 99% van de benches focussed op reads en queued writes (Q4-32) laat SLOG nou net alleen uit synced writes bestaan... Dat is dus nog lager dan de resultaten van Q=1 resultaten in benches... Je slog gaat nevernooit meer dan 60-80MB/s kunnen schrijven.

[Q]

Interessant: Ik vraag me dan eigenlijk af of een setje Western Digital Velociraptors met 10K RPM geshort-stroked niet interessant is als boot + SLOG.... Heb je niet het probleem dat je je SSDs periodiek dood-schrijft.

Is het schrijf-gedrag richting SLOG random of sequentieel I/O depth=1 ?

[ Voor 14% gewijzigd door Q op 29-12-2013 11:49 ]

[FireDrunk]

Een short stroked WD Velociraptor is nog steeds orde van groottes langzamer dan een SSD in synced writes. Waar een SSD misschien iets van 2-3000 IOPS doet, doet een WD Velociraptor er misschien 100.

SLOG / ZIL is sequentieel single queue synced writes.

[mux]

Ik weet niet of Q geïnteresseerd is in een efficiënte setup - vanuit welk perspectief dan ook

[Q]

Hoe bedoel je dat?

[mux]

Ik sta er gewoon versteld van dat je niet alleen een RAID1 voor een boot+slog+zil wil gebruiken (waarom RAID1? wat gaat je dat opleveren?) maak je er hypothetisch zelfs een RAID10 opstelling van! Met lawaaiige, trage, hete harde schijven!

(context: neem mij niet te serieus, ik vind zelfs één HDD te lawaaiig, alles moet altijd minder verbruiken en RAID moet dood)

edit: lees deze post niet, dadona heeft het een stuk beter verwoord

[ Voor 9% gewijzigd door mux op 29-12-2013 12:36 ]

[Dadona]

Omdat, ietwat gechargeerd, jouw opstelling een beetje overeen komt met die van Clarkson:

[Xudonax]

Ik begin echt een hekel te krijgen aan ZFS on Linux... Eerst krijg ik het voor elkaar om de hele pool vol te gooien met data (1,8T volgens df -h) zonder een melding te krijgen, en dan is het ook nog eens onmogelijk om data te verwijderen. Herstart ik, is de beschikbare (en in gebruik zijnde) ruimte ineens 1,4T (komt dichter in de buurt van de 1,31T die refered is volgens zfs list)...

Maar... Ik heb er 6 1TB schijven in liggen in RAID-Z2. Zeg even dat er 900GiB beschikbare ruimte over is, dan zou er toch ~4x900GiB = ~3600GiB (ofwel ~3,6TiB) beschikbare ruimte moeten zijn? Ik mis waarschijnlijk ergens iets...

Het leukste is nog dat als ik nu data verwijder, er geen beschikbare ruimte bij komt. Ik begin heel veel zin te krijgen om VMWare ESXi op die bak te gooien, en dan de M1015 vrolijk via VT-d door te geven aan een BSD variant *zucht*

[FireDrunk]

Heb je een snapshot?

BTW: dat verschil heb ik ook, ik heb volgens df -h 9.3TB in use, en volgens ZFS maar 8.02

[root@NAS /datapool/data]# zfs list -t all datapool
NAME       USED  AVAIL  REFER  MOUNTPOINT
datapool  8.02T  2.36T   302K  /datapool
[root@NAS /datapool/data]# df -h | grep datapool
datapool/data                9.3T    6.9T    2.4T    75%    /datapool/data

Verschil zit hem er in dat child filesystems meegerekend worden volgens mij door df, en niet door zfs zelf (alleen door zpool)

[ Voor 92% gewijzigd door FireDrunk op 29-12-2013 12:54 ]

[Xudonax]

Nee, daar doe ik helemaal niets mee. Ik was bezig om een aantal volumes naar één volume te mergen met behulp van mv. Maar schijnbaar heeft ZoL een bug (die pas in 0.6.6 gefixt word volgens de bugtracker) voor het verwijderen van bestanden die niet in een subvolume zitten...

Unmounten/mounten en de beschikbare ruimte neemt weer iets af. Precies genoeg om een volgend volume te mv'em naar waar ik 'em wil hebben. Gezellig zo

[FireDrunk]

Ouch, dat klinkt wel als een vieze bug... Had je geen child filesystem gemaakt?

[Xudonax]

Jawel, maar dit waren een aantal mappen uit het begin van het volume, toen was ik nog niet zo bezig met child filesystems. Dat is ook één van de redenen dat ik nu alles samenvoeg, dan kan ik straks alles weer keurig een eigen volumen geven.

Dat, en Deluge doet kut. Dus die moest ik ook even herinstalleren

EDIT: Maar dan blijft de vraag, waarom kan ik maar ~1,5TiB opslaan op een volume dat ~3.5TiB aan ruimte heeft? Dat vind ik namelijk wel erg vreemd... Alsof slechts de helft van de beschikbare ruimte daadwerkelijk bruikbaar is.

Ik heb op verschillende filesystems verschillende compressie settings staan, maar dat zou IMO juist méér ruimte moeten opleveren, in plaats van minder. Deduplicatie staat op deze pool overal uit, en copies staat ook overal gewoon op 1.

Ofwel, waarom staat USED op 3,49T terwijl REFER slechts 1,31T is (ok, dat kan ik begrijpen/verklaren met compressie), en er zou maar ~75G AVAIL zijn?

code:

$ sudo zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
tank                     3,49T  74,3G  1,31T  /tank
tank/Documents           51,3G  74,3G  51,3G  /tank/Documents
tank/Downloads           1,51M  74,3G  1,51M  /tank/Downloads
tank/Music                170G  74,3G   170G  /tank/Music
tank/Torrents            1,86T  74,3G  1,86T  /tank/Torrents
tank/Torrents/Completed   272K  74,3G   272K  /tank/Torrents/Completed
tank/tm                  40,7G  74,3G  40,7G  /tank/tm
tank/vm_images           73,9G  74,3G  73,9G  /tank/vm_images
tank/websites            1,25G  74,3G  1,25G  /tank/websites

[ Voor 67% gewijzigd door Xudonax op 29-12-2013 13:42 ]

[Q]

mux schreef op zondag 29 december 2013 @ 12:34:
Ik sta er gewoon versteld van dat je niet alleen een RAID1 voor een boot+slog+zil wil gebruiken (waarom RAID1? wat gaat je dat opleveren?) maak je er hypothetisch zelfs een RAID10 opstelling van! Met lawaaiige, trage, hete harde schijven!

(context: neem mij niet te serieus, ik vind zelfs één HDD te lawaaiig, alles moet altijd minder verbruiken en RAID moet dood)

edit: lees deze post niet, dadona heeft het een stuk beter verwoord

Ik snap de reply van Dadona niet 'more power'.

Lawaai van harde schijven en het stroom verbruik er van maakt mij niets uit. Mijn NAS staat in een aparte ruimte en staat ook uit als ik 'm niet gebruik.

Ik zat even hardop te denken om van die SSD-wear&tear af te komen die je met een SLOG krijgt. Maar die gedachte werd snel en terecht de kop in gedrukt.

RAID1 of mirror of hoe je het ook noemt in ZFS-speak voor SLOG wordt overal aangeraden?
Ik bedoel geen MDADM RAID1? Trigger je op taalgebruik -> gezien je opmerking RAID must die?

Als boot device zie ik Linux MDADM RAID1 als een prima optie (2x 2.5" schijf of SSD). De data zou op ZFS komen. Als ik de SSDs wat groter koop kan ik wat partities inzetten als L2ARC en 2 mirroren als SLOG. Dan zou het me alleen wat extra geld kosten voor meer SSD space. Voor het OS heb je maar weinig storage nodig en zou een kleine goedkope SSD in mirror volstaan.

Mijn doel is echter alleen lekkere sequentiële doorvoer te hebben en dat de status van de integriteit van data-in-rust helder is. Ik denk dat dit true is voor veel mensen.

Zoals ik het nu lees: Geen SLOG nodig en geen L2ARC nodig. En dat geldt voor de meeste NAS bouwers hierzo.

In het begin denk je dat je met ZFS alleen kunt overleven met een L2ARC en SLOG op SSD maar dat is zoals ik het begrijp helemaal niet nodig voor een thuis NAS, ongeacht de grootte van de opslag.

[ Voor 25% gewijzigd door Q op 29-12-2013 13:50 ]

[HyperBart]

Dat klopt, het is vooral vanaf het moment dat je met meerdere clients en met VM's die op ZFS draaien je beter af bent met een SLOG + L2ARC.

[FireDrunk]

En zelfs dan kan je als je geen SLOG / L2ARC wil, nog vaak prima performance halen door sync uit te zetten. Risico op dataverlies is iets hoger, maar als je fatsoenlijke backups maakt ook weer geen probleem.

Met sync=disabled op je filesystem negeert ZFS gewoon keihard de flush commando's en houdt het zich aan de transaction group timeouts (default 5 seconden). Dan kan je dus in principe nooit meer dan 5 seconden data verliezen.

Let op: sync uit, is niet hetzelfde als ZIL uit mocht je dat denken

[Q]

Wat ook nog zou kunnen (zil uit) (Q wordt nagejaagd door woedende ZFS gurus)

Ik test nog eens wat met DD op een vdev van 6 disks in RAIDZ1 en steady 350 MB/s dd write dus ik heb er wel vertrouwen in.

[FireDrunk]

Nee, ZIL uit wil je niet... Dat is een beetje de achillespees van ZFS doorsnijden (vergelijkbaar met op Hardware RAID draaien )

[HyperBart]

Q schreef op zondag 29 december 2013 @ 14:44:
Wat ook nog zou kunnen (zil uit) (Q wordt nagejaagd door woedende ZFS gurus)

[]Byte[]

Brrrrrrrrr....
Krijg er wat van om FC aan de praat te krijgen op ZFSguru.
Krijg de LUN's met geen mogelijkheid zichtbaar op mijn ESX-bak.

Alles lijkt goed te staan, maar daar heb je het ook wel mee gehad.
Heeft er iemand een werkende ervaring met Qlogic-kaarten?
* ]Byte[ gaat maar eens alvast uitkijken naar een paar IB-kaartjes

[Q]

@Hyperbart: ik hoor in gedachten een paar mensen even hun adem in houden terwijl ze mijn troll lezen.

Jammer van de perikelen met FC. Ik hoop dat IB betere ervaringen geeft.

Ik heb zojuist wel het voor elkaar gekregen om NFS over Linux Bonding (quad-port NICS) met 350 MB/s te laten transferen. Helaas alleen via een MDADM 6-disk RAID0,

Dit over een reguliere switch, zonder etherchannel of trunking of wat dan ook. Dus je hebt alleen veel poorten nodig op je switch, 4 voor iedere host die je aan wilt sluiten.

Dat maakt IB en FC ook zo schoon tov bonding: geen kabel clutter en theoretisch veel meer bandbreedte.
Daarom hoop ik dat IB of FC wel gaat lukken --> toekomstige upgrade.

Om het on-topic te houden en ZFS er bij te betrekken:

ZFS geeft super brakke performance met NFS. Maar groot risico dat dit aan mij ligt. Heb nog helemaal niet geëxperimenteerd om dit te corrigeren.

[ Voor 6% gewijzigd door Q op 29-12-2013 17:48 ]

[]Byte[]

Q schreef op zondag 29 december 2013 @ 17:48:
Jammer van de perikelen met FC. Ik hoop dat IB betere ervaringen geeft.

Als er nu maar 1 iemand was die FC in target-mode wel werkend heeft, zou ik er waarschijnlijk wel uitkomen.
Ik heb het gevoel dat ik er kort op zit... Alleen hoe....?

Geef mij HP MSA's, D2D's, EVA's, EMC VMAX, NetApp, DataDomain...
Ik kan er "mee lezen en schrijven"... Dat dit dan niet wil lukken is ietswat frustrerend.
(dan druk ik mij nog politiek correct uit )

[FireDrunk]

@Q,
Heb je de mount SYNC of ASYNC gemount? Maakt nogal verschil. Heb je jumbo frames aan? Hoe staan je transaction groups? Hoeveel RAM heb je nu? Hoe staat het met je vdev cache?

(met andere woorden, genoeg te tunen )

@Byte, heb je die CTLADM port -l al goed?

[ Voor 33% gewijzigd door FireDrunk op 29-12-2013 18:03 ]

[]Byte[]

FireDrunk schreef op zondag 29 december 2013 @ 18:02:
@Byte, heb je die CTLADM port -l al goed?

code:

[root@zfsguru ~]# ctladm port -l
Port Online Type     Name         pp vp WWNN               WWPN              
0    YES    IOCTL    CTL ioctl    0  0  0                  0                 
1    YES    INTERNAL ctl2cam      0  0  0x500000020b0dfb00 0x500000020b0dfb02
2    YES    INTERNAL CTL internal 0  0  0                  0                 
[root@zfsguru ~]#

Wat is hier "mis" aan?

[FireDrunk]

Je moet daar de QLogic poorten zien. Staan ze al wel in target mode?

> /boot/loader.conf:
>
> isp_2300_load="YES"
>
>
> /boot/device.hints:
>
> hint.isp.0.role="target" (should this be "target" or "1"?)
> hint.isp.0.iid="0"

Of zo:

>> kernel config:
>>
>> device          scbus           # SCSI bus (required for SCSI)
>> device          pass            # Passthrough device (direct SCSI access)
>> device          isp             # Qlogic family
>> device          targ            #SCSI Target Mode Code
>> device          targbh          #SCSI Target Mode Blackhole Device
>> options         VFS_AIO
>> options         ISP_TARGET_MODE=1
>> options         ISP_DEFAULT_ROLES=1

[ Voor 106% gewijzigd door FireDrunk op 29-12-2013 18:11 ]

[Q]

]Byte\[ schreef op zondag 29 december 2013 @ 18:01:
[...]

Als er nu maar 1 iemand was die FC in target-mode wel werkend heeft, zou ik er waarschijnlijk wel uitkomen.
Ik heb het gevoel dat ik er kort op zit... Alleen hoe....?

Geef mij HP MSA's, D2D's, EVA's, EMC VMAX, NetApp, DataDomain...
Ik kan er "mee lezen en schrijven"... Dat dit dan niet wil lukken is ietswat frustrerend.
(dan druk ik mij nog politiek correct uit )

Ach, die HP MSAs beginnen al met 6K exclusief schijven, dus tja, maak het jezelf makkelijk (helaas geen ssd support )

Krijg je gratis data corruptie bij op je vdevs! Had je maar die kritische patch update van augustus 2013 moeten installeren. Tja. Maar ik dwaal af.

Storage is gewoon kut.

FireDrunk schreef op zondag 29 december 2013 @ 18:02:
@Q,
Heb je de mount SYNC of ASYNC gemount? Maakt nogal verschil. Heb je jumbo frames aan? Hoe staan je transaction groups? Hoeveel RAM heb je nu? Hoe staat het met je vdev cache?
(met andere woorden, genoeg te tunen )

Ja had ik mee gespeeld, maar alleen client-side en dat is niet genoeg denk ik. Genoeg uit te zoeken zeker, ik geef het niet zomaar op. De ruwe vdef performance is er wel, dus dat is het probleem niet.

[ Voor 30% gewijzigd door Q op 29-12-2013 18:45 ]

[]Byte[]

FireDrunk schreef op zondag 29 december 2013 @ 18:09:
Je moet daar de QLogic poorten zien. Staan ze al wel in target mode?

> /boot/loader.conf:
[...]
> hint.isp.0.iid="0"

Die ken ik nog niet... Heb 'm er ff bijgezet.

Of zo:

>> kernel config:
>>
>> device          scbus           # SCSI bus (required for SCSI) [b]- JA[/b]
>> device          pass            # Passthrough device (direct SCSI access) [b]- JA[/b]
>> device          isp             # Qlogic family [b]- JA[/b]
>> device          targ            #SCSI Target Mode Code [b]- NEE - staat er niet eens in...[/b]
>> device          targbh          #SCSI Target Mode Blackhole Device [b]- NEE - staat er niet eens in...[/b]
>> options         VFS_AIO [b]- NEE - staat er niet eens in...[/b]
>> options         ISP_TARGET_MODE=1 [b]- JA[/b]
>> options         ISP_DEFAULT_ROLES=1 [b]- JA[/b]

Is dit een "of-of" of een "en-en"?

Wel:

code:

device          ctl             # CAM Target Layer

(en die mis ik in jou overzicht )

Alles wat er nog niet in stond heb ik er ff bijgezet. Hij staat nu de kernel opnieuw te compileren.
To be continued... Ik hou jullie op de hoogte.

[]Byte[]

Q schreef op zondag 29 december 2013 @ 18:18:
[...]
Ach, die HP MSAs beginnen al met 6K exclusief schijven, dus tja, maak het jezelf makkelijk (helaas geen ssd support )

Krijg je gratis data corruptie bij op je vdevs! Had je maar die kritische patch update van augustus 2013 moeten installeren. Tja. Maar ik dwaal af.

Storage is gewoon kut.
[...]

Tja, je moet toch wat met dergelijke prijs/kg

Die corruptie kunnen we weer opvangen met ZFS-head er tussen
Storage is fun! Alleen heeft het zo af en toe zijn beperkingen en nukken...

[Xudonax]

Kan iemand dit misschien nog verklaren?

Waarom kan ik maar ~1,5TiB opslaan (REFER) op een volume dat ~3.5TiB (6 schijven van 1TB, dus ~900GiB beschikbaar) aan ruimte heeft? Dat vind ik namelijk wel erg vreemd... Alsof slechts de helft van de beschikbare ruimte daadwerkelijk bruikbaar is.

Ik heb op verschillende filesystems verschillende compressie settings staan, maar dat zou IMO juist méér ruimte moeten opleveren, in plaats van minder. Deduplicatie staat op deze pool overal uit, en copies staat ook overal gewoon op 1.

Ofwel, waarom staat USED op 3,49T terwijl REFER slechts 1,31T is (ok, dat kan ik begrijpen/verklaren met compressie), en er zou maar ~75G AVAIL zijn?

code:

$ sudo zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
tank                     3,49T  74,3G  1,31T  /tank
tank/Documents           51,3G  74,3G  51,3G  /tank/Documents
tank/Downloads           1,51M  74,3G  1,51M  /tank/Downloads
tank/Music                170G  74,3G   170G  /tank/Music
tank/Torrents            1,86T  74,3G  1,86T  /tank/Torrents
tank/Torrents/Completed   272K  74,3G   272K  /tank/Torrents/Completed
tank/tm                  40,7G  74,3G  40,7G  /tank/tm
tank/vm_images           73,9G  74,3G  73,9G  /tank/vm_images
tank/websites            1,25G  74,3G  1,25G  /tank/websites

[mux]

Omdat tank USED de som is van alles in tank? Als je alle REFER groottes bij elkaar optelt krijg je netjes 3,5TiB.

[Xudonax]

Dat klinkt logisch ja... Dan is de "nood" om meer storage te regelen hoger dan ik dacht. Tijd om eens serieus te gaan kijken naar nogmaals ~3,5TiB aan schijfjes

[]Byte[]

FireDrunk schreef op zondag 29 december 2013 @ 18:09:
Je moet daar de QLogic poorten zien. Staan ze al wel in target mode?

> /boot/loader.conf:
>
> isp_2300_load="YES"
>
>
> /boot/device.hints:
>
> hint.isp.0.role="target" (should this be "target" or "1"?)
> hint.isp.0.iid="0"

Of zo:

>> kernel config:
>>
>> device          scbus           # SCSI bus (required for SCSI)
>> device          pass            # Passthrough device (direct SCSI access)
>> device          isp             # Qlogic family
>> device          targ            #SCSI Target Mode Code
>> device          targbh          #SCSI Target Mode Blackhole Device
>> options         VFS_AIO
>> options         ISP_TARGET_MODE=1
>> options         ISP_DEFAULT_ROLES=1

Alle settings gelijk getrokken met wat jij aangaf...
Helaas! nog steeds hetzelfde resultaat.
Is er nog een manier om te controleren of de kaart werkelijk in target-mode staat dan alleen met "ctladm port -l"?
Als er nog een manier is waarbij ik de andere kant van de glasvezelkabel niet hoeft te zien, kan dat het gebied voor onderzoek verkleinen.
Simpel gezegd:
Als blijkt dat de kaart bevestigd in target-mode staat, zou het ook nog de kabel of de andere controller kunnen zijn. (de TX van de kabel werkt in ieder geval (hij gaf licht aan de andere kant ))

Voor het geval er vragen opduiken over de aansluiting:
De kabels zitten gekruist aangesloten en de HBA's hebben een 4Gb link.

TX --------   ------- TX
           \ /
           / \
RX --------   ------- RX

[FireDrunk]

Niet dat ik weet. Volgens mij is ctladm het belangrijkst...

[Durandal]

Xudonax schreef op zondag 29 december 2013 @ 20:03:

code:

$ sudo zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
..
tank/Torrents            1,86T  74,3G  1,86T  /tank/Torrents
tank/Torrents/Completed   272K  74,3G   272K  /tank/Torrents/Completed
..

Zeg, volkomen off topic, maar ik ben wel nieuwsgierig. Maak jij wel eens een torrent af?

[latka]

Durandal schreef op zondag 29 december 2013 @ 22:51:
[...]

Zeg, volkomen off topic, maar ik ben wel nieuwsgierig. Maak jij wel eens een torrent af?

Lol. Volgens mij gewoon een leecher en completed files niet seeden

[Megalith]

]Byte\[ schreef op zondag 29 december 2013 @ 18:01:
[...]

Als er nu maar 1 iemand was die FC in target-mode wel werkend heeft, zou ik er waarschijnlijk wel uitkomen.
Ik heb het gevoel dat ik er kort op zit... Alleen hoe....?

Geef mij HP MSA's, D2D's, EVA's, EMC VMAX, NetApp, DataDomain...
Ik kan er "mee lezen en schrijven"... Dat dit dan niet wil lukken is ietswat frustrerend.
(dan druk ik mij nog politiek correct uit )

Het is een jaar of anderhalf geleden dat ik mijn ZFS SAN heb ingericht, maar destijds had ik voor OpenIndiana gekozen omdat je met FreeBSD geen FibreChannel target aan kon bieden. Men was geloof ik wel bezig deze support in te bouwen maar dat was nog best wel experimenteel en ondersteunde alleen QLogic hba's. Zo te horen werkt het op BSD helaas nog niet zo fijn als op Solaris

[ Voor 4% gewijzigd door Megalith op 29-12-2013 23:24 ]

[Xudonax]

latka schreef op zondag 29 december 2013 @ 23:05:
[...]

Lol. Volgens mij gewoon een leecher en completed files niet seeden

Jawel hoor Maar Deluge doet kut (99% van de torrents staan op Queued zonder dat ik een queue heb gedefinieerd en starten nooit meer), en de Deluge forums zwijgen ook in alle talen . Nu dus alles naar Downloading verplaatsen, dan Deluge opnieuw instellen, torrents toevoegen, local data checken en gaan met die banaan

Er is AFAIK maar één torrent in die hele serie die niet voltooid is, en dat is een heel klein dingetje... Maarja, geen seeders meer

[ Voor 4% gewijzigd door Xudonax op 30-12-2013 00:07 ]

[Q]

Ik maakte net een grapje over het uitschakelen van het ZIL, maar als je sync=disable oid doet, dan is dat in feite wat je aan het doen bent. Async writes treffen het ZIL niet, het zil wordt alleen gebruikt by sync writes. De grote vraag is dus hoeveel writes je sync hebt of wilt hebben. Voor een DB / VM is dat anders dan een isotje lijkt me.

[]Byte[]

fcg123 schreef op zondag 29 december 2013 @ 23:16:
[...]

Het is een jaar of anderhalf geleden dat ik mijn ZFS SAN heb ingericht, maar destijds had ik voor OpenIndiana gekozen omdat je met FreeBSD geen FibreChannel target aan kon bieden. Men was geloof ik wel bezig deze support in te bouwen maar dat was nog best wel experimenteel en ondersteunde alleen QLogic hba's. Zo te horen werkt het op BSD helaas nog niet zo fijn als op Solaris

Ik heb de screenshots er van gezien en zag er goed uit.
Misschien moet ik er toch maar eens serieus naar kijken.

[FireDrunk]

Ik heb FC target hier prima werkend gehad met Nexenta en Emulex kaartjes. Ik ga er van uit dat Qlogic ook zou moeten werken.

De developer van CAM CTL verzekerde mij dat QLogic onder BSD zou moeten werken...

Heb je al alle driver variabelen uitgelezen?

Sysctl -a | grep qla
Of
Sysctl -a | grep isp

[ Voor 4% gewijzigd door FireDrunk op 30-12-2013 09:55 ]

[]Byte[]

Hmmmm....
Ziet er volgens mij goed uit.

code:

isp_2300: registered firmware <isp_2300>
isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0xa000-0xa0ff mem 0xf7740000-0xf7743fff irq 16 at device 0.0 on pci3
isp0: setting role to 0x1
isp0: Polled Mailbox Command (0x8) Timeout (100000us) (started @ isp_reset:1046)
isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT)
device_attach: isp0 attach returned 6
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7000000-0xf73fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
net.isr.dispatch: direct
dev.vgapci.0.%desc: VGA-compatible display

/me ]Byte[ krijgt het gevoel van: Het is allemaal niet zo moeilijk. Het is net als fietsen.... Je moet alleen even weten hoe.

[FireDrunk]

Dat lijkt dmesg?

[efan]

zojuist in vmware zfsguru geinstalleerd om eens te bekijken. ik wil nu bij Filesystems "testpool/share" delen naar m'n Mac. Ik kies dan een naam voor de NFS share (ZFS), klik op create en execute,en dat gaat allemaal goed, maar hoe kan ik nu vanaf OSX verbinden met deze NFS share? Als ik via verbind server nfs://x.x.x.x/ZFS invul dan krijg ik steeds een melding over dat ik geen permissies heb.
Wat moet ik aanpassen zodat ik de ZFS share kan benaderen?

[]Byte[]

FireDrunk schreef op maandag 30 december 2013 @ 11:21:
Dat lijkt dmesg?

Nee, maar er was wel iets fout gegaan bij de copy-paste...
Hier is ie volledig:

code:

[root@zfsguru ~]# sysctl -a | grep -i isp
options ISP_DEFAULT_ROLES=1
options ISP_TARGET_MODE=1
device  isp
isp_2300: registered firmware <isp_2300>
isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0xa000-0xa0ff mem 0xf7740000-0xf7743fff irq 16 at device 0.0 on pci3
isp0: setting role to 0x1
isp0: Polled Mailbox Command (0x8) Timeout (100000us) (started @ isp_reset:1046)
isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT)
device_attach: isp0 attach returned 6
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7000000-0xf73fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
isp_2300: registered firmware <isp_2300>
isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0xa000-0xa0ff mem 0xf7740000-0xf7743fff irq 16 at device 0.0 on pci3
isp0: setting role to 0x1
isp0: Polled Mailbox Command (0x8) Timeout (100000us) (started @ isp_reset:1046)
isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT)
device_attach: isp0 attach returned 6
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7000000-0xf73fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
isp_2300: registered firmware <isp_2300>
isp0: <Qlogic ISP 2432 PCI FC-AL Adapter> port 0xa000-0xa0ff mem 0xf7740000-0xf7743fff irq 16 at device 0.0 on pci3
isp0: setting role to 0x1
isp0: Polled Mailbox Command (0x8) Timeout (100000us) (started @ isp_reset:1046)
isp0: Mailbox Command 'ABOUT FIRMWARE' failed (TIMEOUT)
device_attach: isp0 attach returned 6
vgapci0: <VGA-compatible display> port 0xf000-0xf03f mem 0xf7000000-0xf73fffff,0xe0000000-0xefffffff irq 16 at device 2.0 on pci0
net.isr.dispatch: direct
dev.vgapci.0.%desc: VGA-compatible display
[root@zfsguru ~]#

[Megalith]

Hoe ziet je /boot/loader.conf eruit?

Ik kwam onderstaande regels via google tegen, misschien eens proberen deze er in te zetten. Zag hierboven dat je de ispfw_load nog niet had.

code:

ispfw_load="YES"
isp_load="YES"

[]Byte[]

ik heb alleen de

code:

isp_2300_load="YES"

er in zitten.
Voor zover ik begrepen heb is de ispfw_load voor alle isp-drivers, en heb ik alleen de 2300 nodig.

[Megalith]

Oke. Ik lees onder andere hier dat de timeout die jij ook hebt verholpen wordt door de firmware van je kaart in te laden. Dat schijnt met ispfw_load="YES" te moeten. Misschien toch het proberen waard? Niet geschoten is altijd mis

[]Byte[]

code:

[root@zfsguru ~]# ctladm port -l
Port Online Type     Name         pp vp WWNN               WWPN              
0    YES    IOCTL    CTL ioctl    0  0  0                  0                 
1    YES    INTERNAL ctl2cam      0  0  0x5000000897af6300 0x5000000897af6302
2    YES    INTERNAL CTL internal 0  0  0                  0                 
3    YES    FC       isp0         0  0  0x500110a0001725ff 0x500110a0001725fe
[root@zfsguru ~]#

Telkens als ik zat te switchen tussen de 2300 en de ipsfw-driver had ik daarmee ook de isp_load="YES" weggehaald! (vraag mij nu even niet waarom...)
Heb 'm er nu eens in laten staan, en jahoor.... Daar zie ik de HBA van mijn ESX.

Een ramdisk aangemaakt, en ik zie 'm gelijk in ESX na een rescan!

[Megalith]

Tof! Gelijk de fabric even benchmarken, komen bij ramdisks zalige snelheden uit voor :-)

[]Byte[]

Ik durf het bijna niet te laten zien...

code:

[root@esx1 ~]# dd if=/dev/sdh of=/dev/null
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 72.042 seconds, 146 MB/s
[root@esx1 ~]#

Dit had ik even niet verwacht. Had toch echt 300+ getallen verwacht te zien.
Ik ga nog wel even verder spitten.
Als iemand een idee heeft... Ik sta overal voor open.

[Verwijderd]

bs=1M

[]Byte[]

Dat dacht ik ook.
Maar dan kom ik ook niet verder dan gemiddelde van 152 MB/s
en bij een bs=10M zie ik met een ctlstat alleen het aantal tps drastisch omlaag gaan, maar gemiddeld blijft ie steken op 140 MB/s.
Zonder bs liep de tps op naar zo'n 4600-5100
bs=4k geeft 140 MB/s

Hmmm....

code:

[root@esx1 ~]# dd if=/dev/zero of=/dev/sdh1 bs=1M
dd: writing `/dev/sdh1': No space left on device
10000+0 records in
9999+0 records out
10485743616 bytes (10 GB) copied, 43.8635 seconds, 239 MB/s
[root@esx1 ~]#

Schrijven gaat sneller dan lezen...

[ Voor 38% gewijzigd door ]Byte[ op 30-12-2013 21:10 ]

[Q]

ido schreef op maandag 30 december 2013 @ 17:36:
zojuist in vmware zfsguru geinstalleerd om eens te bekijken. ik wil nu bij Filesystems "testpool/share" delen naar m'n Mac. Ik kies dan een naam voor de NFS share (ZFS), klik op create en execute,en dat gaat allemaal goed, maar hoe kan ik nu vanaf OSX verbinden met deze NFS share? Als ik via verbind server nfs://x.x.x.x/ZFS invul dan krijg ik steeds een melding over dat ik geen permissies heb.
Wat moet ik aanpassen zodat ik de ZFS share kan benaderen?

Het kan zijn dat je user-id (tik in op terminal 'id') qua getal moet overeen komen met de user id op je ZFS machine. Dan zul je mogelijk /etc/passwd moeten editen (be carefull). Of het is misschien een extra nfs parameter voor zfs.

Ku nje op je zfs machine eens 'showmount -e ' doen?
Of op je mac: 'showmount -e <ipadress zfs server>'

[Q]

]Byte\[ schreef op maandag 30 december 2013 @ 20:16:
Ik durf het bijna niet te laten zien...

Je bent in ieder geval een stap verder: hij werkt en dat is een pre!

Misschien eens checken of je ook echt een 4Gbit link hebt en geen 2Gbit link?
Geeft de interface stats over eventuele dropped packets of misschien kernel messages in syslog?
Is er een manier om de snelheid van de FC interface real-time te monitoren: is die 150 MB/s of 240 MB/s het resultaat van een continue strakke snelheid of zie je gigantische fluctuaties? Volgens mij moet je dat met esxtop of iets als vmscsistat oid (ik verzin het ter plekke) kunnen zien?

[ Voor 26% gewijzigd door Q op 31-12-2013 00:27 ]

[]Byte[]

Uitgezonderd af en toe een dipje lijkt het redelijk stabiel.
Op mijn ESX een write gestart:

code:

[root@esx1 ~]# dd if=/dev/zero of=/dev/sdh1 bs=1M count=10000
dd: writing `/dev/sdh1': No space left on device
10000+0 records in
9999+0 records out
10485743616 bytes (10 GB) copied, 43.5301 seconds, 241 MB/s
[root@esx1 ~]#

Geeft op de LUN het volgende:

code:

[root@zfsguru ~]# ctlstat
  CPU              lun0             lun1 
          ms  KB/t tps  MB/s    ms  KB/t tps  MB/s 
  0.9%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  0.8%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  0.5%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  0.8%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  1.4%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  0.6%  0.00  0.00   0  0.00  0.00  0.00   0  0.00 
  3.1%  0.00  0.00   0  0.00  2.28 509.65 216 107.61 
  2.9%  0.00  0.00   0  0.00  1.93 512.00 440 220.21 
  1.9%  0.00  0.00   0  0.00  1.81 512.00 490 245.24 
  2.3%  0.00  0.00   0  0.00  1.80 512.00 491 245.74 
  2.5%  0.00  0.00   0  0.00  1.91 512.00 463 231.74 
  2.3%  0.00  0.00   0  0.00  1.95 512.00 443 221.71 
  4.2%  0.00  0.00   0  0.00  2.28 512.00 355 177.68 
  3.0%  0.00  0.00   0  0.00  1.93 512.00 464 232.24 
  2.4%  0.00  0.00   0  0.00  1.86 512.00 472 236.23 
  2.4%  0.00  0.00   0  0.00  1.86 512.00 479 239.75 
  3.1%  0.00  0.00   0  0.00  1.93 512.00 445 222.71 
  2.0%  0.00  0.00   0  0.00  1.83 512.00 486 243.25 
  2.4%  0.00  0.00   0  0.00  1.77 512.00 494 246.76 
  2.4%  0.00  0.00   0  0.00  1.95 512.00 433 216.71 
  CPU              lun0             lun1 
          ms  KB/t tps  MB/s    ms  KB/t tps  MB/s 
  3.7%  0.00  0.00   0  0.00  2.00 512.00 435 217.72 
  2.2%  0.00  0.00   0  0.00  1.83 512.00 481 240.26 
  2.9%  0.00  0.00   0  0.00  1.86 512.00 477 238.72 
  2.9%  0.00  0.00   0  0.00  1.86 512.00 468 234.24 
  1.9%  0.00  0.00   0  0.00  1.80 512.00 490 245.24 
  2.2%  0.00  0.00   0  0.00  1.88 512.00 469 234.74 
  3.5%  0.00  0.00   0  0.00  1.93 512.00 444 222.22 
  1.4%  0.00  0.00   0  0.00  1.84 512.00 474 237.22 
  2.3%  0.00  0.00   0  0.00  1.86 512.00 469 234.75 
  1.6%  0.00  0.00   0  0.00  1.80 512.00 489 244.74 
  2.2%  0.00  0.00   0  0.00  1.83 512.00 471 235.74 
  3.0%  0.00  0.00   0  0.00  1.93 512.00 446 223.22 
  2.0%  0.00  0.00   0  0.00  1.80 512.00 485 242.74 
  2.8%  0.00  0.00   0  0.00  1.87 512.00 470 235.22 
  3.8%  0.00  0.00   0  0.00  1.91 512.00 450 225.23 
  1.3%  0.00  0.00   0  0.00  1.88 512.00 469 234.73 
  2.0%  0.00  0.00   0  0.00  1.81 512.00 483 241.74 
  1.8%  0.00  0.00   0  0.00  1.87 512.00 468 234.23 
  2.3%  0.00  0.00   0  0.00  1.78 512.00 489 244.25 
  3.2%  0.00  0.00   0  0.00  1.86 512.00 475 237.74 
  CPU              lun0             lun1 
          ms  KB/t tps  MB/s    ms  KB/t tps  MB/s 
  2.1%  0.00  0.00   0  0.00  1.85 512.00 472 236.23 
  2.0%  0.00  0.00   0  0.00  1.78 512.00 498 248.99 
  3.3%  0.00  0.00   0  0.00  2.23 512.00 367 183.38 
  2.9%  0.00  0.00   0  0.00  2.00 512.00 434 217.20 
  2.4%  0.00  0.00   0  0.00  1.95 512.00 440 220.23 
  2.4%  0.00  0.00   0  0.00  1.90 512.00 465 232.73 
  2.5%  0.00  0.00   0  0.00  1.85 512.00 477 238.74 
  2.9%  0.00  0.00   0  0.00  1.95 512.00 444 222.21 
  2.2%  0.00  0.00   0  0.00  1.85 512.00 457 228.73 
  2.9%  0.00  0.00   0  0.00  1.86 511.95 383 191.37 
  0.7%  0.00  0.00   0  0.00  0.00  0.00   0  0.00

De errors lijken ook geen probleem (iig vanuit ESX gezien):
(Link speed: zie regel 21)

code:

[root@esx1 ~]# cat /proc/scsi/qla2xxx/7 
QLogic PCI to Fibre Channel Host Adapter for HPAE311A:
        FC Firmware version 5.02.00 (496), Driver version 831.k1.28.1-1vmw

Host Device Name vmhba1

BIOS version 1.09
FCODE version 1.12
EFI version 1.05
Flash FW version 4.00.70
ISP: ISP2432
Request Queue = 0x41814000, Response Queue = 0x41895000
Request Queue count = 4096, Response Queue count = 512
Total number of interrupts = 1200022
    Device queue depth = 0x20
Number of free request entries = 2342
Number of mailbox timeouts = 0
Number of ISP aborts = 0
Number of loop resyncs = 11
Host adapter:Loop State = <READY>, flags = 0x945a93
Link speed = <4 Gbps>

Dpc flags = 0x10800
Link down Timeout =   008
Port down retry =   005
Login retry count =   008
Execution throttle = 2048
ZIO mode = 0x6, ZIO timer = 1
Commands retried with dropped frame(s) = 0
Product ID = 0000 0000 0000 0000


NPIV Supported : Yes 
Max Virtual Ports = 127

SCSI Device Information:
scsi-qla0-adapter-node=500110a0001725fd:0000ef:0;
scsi-qla0-adapter-port=500110a0001725fc:0000ef:0;

FC Target-Port List:
scsi-qla0-target-0=500110a0001725fe:0000e8:0:Online;

[root@esx1 ~]#

(Op FreeBSD heb ik geen /proc/scsi/... en weet zo niet waar ik de cijfers daar kan zien)

[FREAKJAM]

Weer eens een leuk artikeltje gevonden op het net. Misschien iets om op te nemen in de startpost.

[ Voor 108% gewijzigd door FREAKJAM op 31-12-2013 08:20 ]

[Dadona]

Schitterend, briljant artikel! Goed gevonden.

spoiler:

Check de sig van Q.... ; )

[Q]

Ik zie niets vreemds. Dat de bandbreedte constant is zou misschien kunnen wijzen op een andere bottleneck? Ik verzin maar iets. 240 MB/s = ~ 2Gbit-ish.

Toch eens met disks testen ipv ram? Klinkt waardeloos maar ach?

Kun je een andere disk even gebruiken als boot om daar Loenux op te zetten en daar de FC kaart als HBA target te testen? Is nogal rigoureus, maar dan weet je ten minste of het een OS implementatie issue is. Als Lunox ook de zelfde speed geeft is het OS vaak niet een issue.

[FREAKJAM]

Haha, doh! Ik deed alleen maar een search op ZFS, SLOG etc bij Google gefilterd op afgelopen week en dat artikel kwam vrij snel als eerste link naar voren. Nou kudos voor Q dan maar

Afgelopen weken weinig in dit topic geloerd omdat ik nog steeds mijn ZFS-systeem niet heb kunnen bouwen omdat ik al 6 weken zonder een moederbord zit. Wou mijn geheugen even opfrissen

[ Voor 35% gewijzigd door FREAKJAM op 31-12-2013 01:12 ]

[Q]

Dadona schreef op dinsdag 31 december 2013 @ 01:06:
Schitterend, briljant artikel! Goed gevonden.

spoiler:

Check de sig van Q.... ; )

Heb even een schandalige tik fout uit de titel gehaald.

[ Voor 9% gewijzigd door Q op 31-12-2013 01:11 ]

[FREAKJAM]

Heeft mijn geweldige vondst toch nog nut gehad

[ Voor 7% gewijzigd door FREAKJAM op 31-12-2013 01:20 ]

[FireDrunk]

Uh ]Byte[, je moet NOOIT via de commandline van esxi testen. Dat is alleen maar een vage geknepen shell die waardeloos performt. Je moet echt even via een VM testen.