Het grote ZFS topic

[CurlyMo]

Bolk schreef op donderdag 02 februari 2012 @ 14:45:
Thanks voor de uitleg heren,

Ik wil graag FreeBSD gaan gebruiken als O/S. Als ik op een Intel 320 SSD (met supercap) van 120 GB ongeveer 40 GB gebruik voor het O/S, 5 GB voor SLOG en 15 GB voor L2ARC. Rest unpartitioned. Kom ik dan weg met 2 SSD's in RAID 1, of is het verstandiger O/S en SLOG/L2ARC te splitsen? Ik praat dan alleen over uptime, niet specifiek performance.

Ik zou gewoon bij 1 SSD blijven. Als je een betrouwbare SSD neemt dan zal deze er ook niet zomaar mee op houden. Voor je SLOG en L2ARC zal een kapotte SSD niet uitmaken (ZFS > v19). Alleen moet je even je OS opnieuw installeren, maar als je daar goede backups van maakt is dat een klus van 10min.

[Bolk]

CurlyMo schreef op donderdag 02 februari 2012 @ 21:28:
[...]

Ik zou gewoon bij 1 SSD blijven. Als je een betrouwbare SSD neemt dan zal deze er ook niet zomaar mee op houden. Voor je SLOG en L2ARC zal een kapotte SSD niet uitmaken (ZFS > v19). Alleen moet je even je OS opnieuw installeren, maar als je daar goede backups van maakt is dat een klus van 10min.

Maar als m'n O/S en SLOG crashen op dezelfde SSD, betekent dat data-loss... Correct?

[nielsdc]

Bolk schreef op donderdag 02 februari 2012 @ 22:16:
Maar als m'n O/S en SLOG crashen op dezelfde SSD, betekent dat data-loss... Correct?

Normaal gesproken zal je kernel de laatste data nog wel wegschrijven zal je O/S disk verdwijnt, maar zelfs als je OS zelf hard crasht ben je nog steeds maar maximaal de laatste 5 seconden data kwijt. Dus wel data-loss, maar niet heel veel . Overgens wordt de SLOG alleen gebruikt voor synchrone schrijfacties, en dat zijn er niet zoveel.

[Verwijderd]

Bolk schreef op donderdag 02 februari 2012 @ 02:46:
Een SSD als SLOG klinkt als een goede optie, maar uptime is ook belangrijk. Ik wil dus rekening houden met zoveel mogelijk variabelen.

Als uptime belangrijk is, wil je redundantie, zodat als iets uitvalt de zaak blijft draaien en je rustig kan kijken hoe je je degraded state kunt verhelpen, zonder dat je systeem gelijk offline is.

Dus ik zou juist wél pleiten voor meerdere SSDs, waarbij je zowel de SLOG als het OS in een mirror configuratie draait. Denk aan vier SSDs, met een partitie-indeling zoals:
SSD1: 20GB OS | 20GB L2ARC | 4GB SLOG
SSD2: 20GB OS | 20GB L2ARC | 4GB SLOG
SSD3: SWAP | 20GB L2ARC | 4GB SLOG
SSD4: SWAP | 20GB L2ARC | 4GB SLOG

Zo'n setup heeft bepaalde voordelen:

• je gebruikt L2ARC in RAID0 dus maximale performance scaling; Crucial M4 64GB doet 250MB/s+ aan 4K random read performance; dus theoretisch tegen de 1GB/s aan random read aan voor je L2ARC in redelijke extreme omstandigheden. Lijkt mij erg gaaf voor relatief weinig geld (4 SSDs)
• je kunt je SLOG mirroren. ik weet even niet of je nou ook RAID0+1 voor je SLOG kunt doen. Je kunt stripen of mirroren, maar misschien ook allebei. Zo niet dan gebruik je gewoon 2 SSDs voor SLOG, of 3 als je extra zekerheid wilt. Bedenk wel dat SLOG 100% writes zijn; reads komen alleen voor bij recovery na een stroomstoring e.d.
• Je hebt een mirror voor je OS, je kunt SSD3 ook nog mirror laten zijn dan heb je een 3-way mirror wat natuurlijk helemaal gaaf is. Je dedicated SWAP is handig voor het geval dat, maar normaliter gebruik je dat vrijwel niet.
• meerdere SSDs met redundantie betekent dat elke SSD uit kan vallen zonder problemen te veroorzaken. De swap uitgezonderd - wat misschien een reden is om de SWAP ook te mirroren of gewoon op de systeempool te laten draaien wat heel makkelijk kan.

Ik raad je wel aan om de SSDs op je chipet controller aan te sluiten, dan kun je ze TRIMen wanneer dat nodig is. FreeBSD ondersteunt TRIM op 'ada' AHCI disks.

Wat voor SSDs? Nou die Intel 320 is een goede voor de SLOG. Dus misschien twee Intels 320 van 80GB en twee crucial m4 voor de extra l2arc snelheid. Doe zoveel mogelijk aan overprovisioning dan blijft alles lekker draaien.

Wat gebeurt er als m'n SSD met SLOG crashed?

Je bedoelt "wat gebeurt er met mijn POOL", correct? Je krijgt dan een FAULTED pool die je niet kunt importeren. Indien de pool v19+ is en je FreeBSD 9 of 8-STABLE met ZFS v28 draait, dan kun je met 'zpool import -F' de pool alsnog importeren. Dit commando zal de huidige (en misschien vorige) transaction group vernietigen en terugdraaien naar een vorige transaction group. Je verliest dan één of twee txg's waard aan data, wat in het meest extreme geval neerkomt op 1 minuut.

Voor een server wil je dit voorkomen, omdat je geen data wilt verliezen. Mits je flush commando's goed geregeld zijn, zullen je applicaties in een consistente state bevinden. Databases zullen dus een oudere versie van hun bestanden te zien krijgen, maar een die wel 'consistent' is. Daar heb je immers je ZFS Intent Log (ZIL) voor.

Is het uberhaupt verstandig om ZFS te gebruiken in een productieomgeving?

Geen enkel systeem wat je zoveel bescherming én performance features biedt als L2ARC en SLOG. En de ARC cache werkt ook erg goed, door niet alleen recent data maar ook frequently requested data gescheiden te cachen.

Is het verstandig om SLOG uit te besteden aan een dedicated SSD of kan dat in combinatie met het o/s op dezelfde SSD?

Je kunt prima een SSD voor meerdere taken gebruiken, mits je een SSD hebt die NCQ ondersteunt; alleen flut SSDs doen dat niet, dus ben je klaar. Belangrijker is dat je voldoende redundantie hebt.

[Bolk]

Helder verhaal CiPHER, wederom bedankt iedereen.

Het verhaal wordt me steeds duidelijker. Het is de bedoeling dat de machine als NFS share gaat werken achter ESXi frontend servers. Centralized storage dus voor VM's. Die sync writes naar de SLOG, komen die alsnog van de vmdk's dan? Oftewel van het O/S dat gevirtualiseerd wordt? Of komt dat van ESXi? Iemand ervaring daarmee?

[Verwijderd]

Je hebt als het goed is een CPU die vt-d (niet vt-x maar vt-d) ondersteunt en daardoor een gehele controller aan je VM kunt geven. Dat betekent dat ESXi zelf en ook andere VMs er geen gebruik van kunnen maken! Dus ik weet niet wat je voor ESXi zelf in gedachte had. Je kan natuurlijk ook via USB ESXi aansturen (doet dat enige I/O van betekenis?) zodat je de onboard AHCI en PCI-express controllers kunt doorgeven aan je ZFS OS.

[fluppie007]

Verwijderd schreef op woensdag 01 februari 2012 @ 21:40:
De beta versies kunnen je SSD mooi partitioneren met meerdere partities.


[...]

Ik mis je geheugen? Dat is cruciaal voor ZFS performance. Die Areca controller raad ik af:
1) het is een RAID controller dus problemen met bad sectors en wegvallende schijven.
2) de 'ix' versie heeft een port multiplier/expander als ik het goed heb, wat voor ZFS RAID-Z niet zo gunstig is, meer dan andere RAID-oplossingen.

Verder moet je weten dat voor 4K sector schijven zoals jij hebt genomen (WD20EARX) je RAID-Z in optimale configuraties hebt:
RAID-Z: 3, 5 of 9 schijven
RAID-Z2: 4, 6 of 10 schijven
RAID-Z3: 5, 7 of 11 schijven

Een RAID-Z van 3 of 5 of een RAID-Z2 van 6 of 10 disks zijn de meest voorkomende builds. Maar als de data toch niet belangrijk is, kun je ook RAID0 draaien toch?

Is er ergens een website waar ik kan bekijken wat het performanceverschil is wanneer ik toch de 8 schijven aansluit.
Ik wil een idee hebben over welke verschillen we spreken . Mijn kast ondersteunt maximaal 8 schijven en een eventuele SSD kan in een 5.25" naar 2.5" adapter.

[Verwijderd]

ZFSguru heeft een ingebouwde geavanceerde benchmark die allerlei combinaties test en een grafiek toont. Zo kun je zien hoe sommige combinaties presteren. Die kun je vinden onder Disks->Benchmark, maar overschrijft de schijven dus die mogen geen pools bevatten.

Wat betreft het performanceverschil; dat variëert maar random I/O wordt zo ook langzaam. Je kunt wel de sectorsize override gebruiken zodat de ZFS pool een ashift waarde van 12 meekrijgt, wat inhoudt dat deze geschikt is voor 4K sector disks. Dan is de performance beter met name bij combinaties die niet optimaal zijn, zoals hierboven besproken. Het nadeel is wel dat je dan minder bruikbare opslagruimte hebt doordat af en toe een blok data onbruikbaar wordt voor ZFS. Dat is met name een probleem als je veel kleine bestanden opslaat.

Persoonlijk zou ik altijd voor een optimale config gaan. Als je kast 8 schijven ondersteunt zou ik eerder zeggen 6 disks in RAID-Z2 en wat SSDs erbij. Als je nog wat met je kast kunt fixen zou een 10-disk RAID-Z2 ook heel goed zijn, omdat je dan maar 20% kwijt bent aan parity terwijl je wel 2-voudige bescherming hebt. Je kunt dat allemaal testen met de benchmark van ZFSguru zodra je je hardware hebt.

[Bolk]

Verwijderd schreef op vrijdag 03 februari 2012 @ 00:15:
Je hebt als het goed is een CPU die vt-d (niet vt-x maar vt-d) ondersteunt en daardoor een gehele controller aan je VM kunt geven. Dat betekent dat ESXi zelf en ook andere VMs er geen gebruik van kunnen maken! Dus ik weet niet wat je voor ESXi zelf in gedachte had. Je kan natuurlijk ook via USB ESXi aansturen (doet dat enige I/O van betekenis?) zodat je de onboard AHCI en PCI-express controllers kunt doorgeven aan je ZFS OS.

Ik heb nu 3 frontend servers die ESXi booten van een USB stick, de virtual machines die op die servers draaien moeten hun data van de storage server halen via NFS of iSCSI. Schijnbaar doet ESXi Sync writes via NFS, waardoor de performance inkakt. iSCSI schijnt het weer niet te hebben. Ga me er toch eens wat meer in verdiepen, heb gezien dat ESXi 5 alweer uit is...

In dit artikel lees ik het volgende:

ESX uses a NFSv3 client, and when it connects to the server, it always asks for a sync connection. It doesn't matter what you set your server to, it will be forced by the O_SYNC command from ESX to sync all writes.

By itself, this isn't a bad thing, but when you add ZFS to the equation,we now have an unnecessary NFS sync due to ZFS's ZIL. It's best to leave ZFS alone, and let it write to disk when it's ready, instead of instructing it to flush the ZIL all the time. Once ZFS has it, you can forget about it (assuming you haven't turned off the ZIL).

[Verwijderd]

Dat gaat over dat ESXi NFS mounted filesystems heeft voor zichzelf (?) die van een VM afkomen die ZFS draait, correct? In dat scenario kun je de ZFS 'sync' property op 'off' zetten zodat je NFS writes als a-sync behandelt. Dat zou je performance een stuk verbeteren.

Maar ik snap eigenlijk niet zo snel waarom ESXI NFS mounts nodig heeft? Ik gebruik het zelf niet, dus misschien zeg ik iets stoms.

[Bolk]

Nee, wat ik wil bereiken is dat de storage van m'n VM's gecentraliseerd staan op de storage server (dan kan ik ook met High Availability aan de gang). Alleen de frontend servers virtualizeren het o/s, terwijl zij via een NFS (of iSCSI) mount hun data halen van de storage server. De storage server wordt RAIDZ2 met 6 2TB disks. Om het kort te zeggen: de virtuele harddrives van de VM's staan op de storage server.



Alleen schijnbaar door de sync writes van NFS-clients van de frontend ESXi servers, is dat nogal een aanslag op de performance. iSCSI heeft dit probleem schijnbaar niet. Reden om NFS te gaan gebruiken is de schaalbaarheid.

Ik zal het moeten gaan testen (met/zonder SSD als SLOG), maar vroeg me af of iemand ervaring heeft met een ZFS storage solution voor ESXi.

[syl765]

Maar ik snap eigenlijk niet zo snel waarom ESXI NFS mounts nodig heeft? Ik gebruik het zelf niet, dus misschien zeg ik iets stoms.

Wij gebruiken ook NFS voor onze ESXi server, exact zoals het plaatje hierboven.
Onze ESXi servers zijn Proliant DL380 servers met een SD kaartje voor het OS (ESXi5.0.0)
Dat is wel mooi van de huidige Proliant servers dat deze een sd slot op het moederboard hebben.
Onze SAN/NAS is een Supermicro 3u of 4u rackserver met FreeBSD 9.0

Wij gebruikenv ook NFS in plaats van ISCSI.
De reden is dat we veel veel meer controle hebben over de data.
Gebruik je ISCSI, dan kun je alleen vanaf de ESXi hosts je ding doen, je ISCSI target is tenslotte een VMFS geworden waar je met FreeBSD niks mee kunt!

Gebruik je NFS, dan kun je gewoon je datastore browsen vanaf je FreeBSD OS.
Dit maakt het gezien vanaf de SAN een stuk gemakkelijker.

Denk aan virtuele machines kopieren of verplaatsen backups maken snapshots terug zetten enz.
Iets wat je anders alleen via de ESXi host kan doen en daarin ben je dan best beperkt.

Echter je ZFS dataset met NFS serveren aan een ESXi host, is belachelijk traag, volgens mij trek je niet eens een 100mbit verbing dicht.
Zet je op de ZFS dataset de sync optie op disabled, dan krijg je gewoon goede tot zeer goede resultaten.

Ik heb een ESXi host die ook een lokale store heeft, twee 146 GB 15k sas schijfjes.
Ik heb een kopieer slag gemaakt en tijdens de kopieer slag het commando zfs set sync-disabled sanstore/ESXishare gegeven.
Op 20:26 of 20:27 starte ik de kopieer slag, rond 20:37 gaf ik het commando

http://doub.home.xs4all.nl/bench/sync.png

Je ziet het verschil, en dit is niet een beetje, nee bijna belachelijk dat ESXi niet in staat is normaal met een NFS share te communiceren.

Wij gebruiken geen SSD's in onze ZFS server, en deze performt gewoon goed.
Ik heb een IBM SAN oplossing bij een klant staan, en de performance doet totaal niet onder voor de IBM san.
En dan gebruiken wij in de test opstelling SATA schijven waar de IBM SAN 15k SAS schijven heeft.
En dan hebben we het maar even niet over de prijs van dat geheel.

Gr
Johan

[ Voor 6% gewijzigd door syl765 op 03-02-2012 10:28 ]

[robertobadjo]

@johan: zou je eens de specs kunnen posten van die zfs bak dan? als ik je grafiek aflees is dat zeer intresant.

welke controler gebruik jij ervoor?

mijn ogen zijn een beetje gericht op de ibm 1015 en dan flashen met de LSI firmware. ben dan benieuwd welke performance ik ga halen ermee

[FireDrunk]

Beetje vreemd dat NFS zo moeilijk doet, ik ga er vanuit dat onze NFS stores ook gewoon met sync werken, maar die halen toch echt meer dan 300MB/s (10Gbit). Aan de combinatie ESX -> NFS kan het dus niet liggen in mijn optiek. Wij gebruiken zelfs ESX 4.1, en nog geen 5.

Heb je al eens geprobeerd om een andere NFS store te maken op een test linux bakje ofzo?

[syl765]

@robertobadjo

De test server is deze.
http://www.supermicro.com...3U/836/SC836E16-R1200.cfm
met dit moederboard.
http://www.supermicro.com...eon/C202_C204/X9SCM-F.cfm

In productie gebruiken we het zelfde moederboard, maar dit chassis
http://www.supermicro.com...4U/846/SC846E16-R1200.cfm

Als controller gebruiken we de LSI 9211-8i in IT mode.

Niks bijzonders eigenlijk.

De schijven in die bak zijn een vergaartje van oude sata schijven van 80, 160, 250, 500 en 750 GB en deze zijn allemaal een mirror, dus twee 80 GB schijfjes gemirrored twee 750 GB enz.
De meeste schijven komen helaas niet meer door de SMART test en er zijn er al twee FAULTED in de pool.

Wat wel vervelend is, is dat je de LSI controller niet kunt flashen vanaf dat moederboard.
Je krijgt dan de Error Failed to initialize PAL.
Schijnt iets te maken te hebben met de intel chipset.
LSI KB nummer is 15807, dus flashen doen we in een HP Proliant ML110.

Het switchje wat we gebruikten was een simpele HP 8 port Gigabit switch.

Gr
Johan

[FireDrunk]

Zoveel dus, vreemd dat jij er toch problemen mee hebt.

[ItsValium]

Ik kan de ervaring van syl765 met de sync optie van ZFS op een NFS-share voor ESXi alleen maar bevestigen.

Opzet hier is : ESXi5 nodes met NFS shares op een Nexenta ZFS HA omgeving.

Screenshot hieronder:
Links Sync Enabled Rechts Sync Disabled op dezelfde VM net na elkaar gedraaid. De Writes hebben grote verschillen tussen beide.

[syl765]

@FireDrunk

Wij hebben helaas geen spare machines, dus even testen met Linux gaat niet lukken.
Het schijnt dus een combinatie ZFS EXSi en NFS te zijn waardoor dit optreed.
Er zijn meerdere topics over te vinden op internet
http://christopher-techni...s-nfs-on-zfs-for-esx.html.

Gr
Johan

[matty___]

ItsValium schreef op vrijdag 03 februari 2012 @ 12:11:
Ik kan de ervaring van syl765 met de sync optie van ZFS op een NFS-share voor ESXi alleen maar bevestigen.

Opzet hier is : ESXi5 nodes met NFS shares op een Nexenta ZFS HA omgeving.

Screenshot hieronder:
Links Sync Enabled Rechts Sync Disabled op dezelfde VM net na elkaar gedraaid. De Writes hebben grote verschillen tussen beide.

[afbeelding]

ook met ssd slog? dacht dat het met een ssd opgelost was / beter werd

[Bolk]

matty___ schreef op vrijdag 03 februari 2012 @ 12:15:
[...]

ook met ssd slog? dacht dat het met een ssd opgelost was / beter werd

Dat zal theoretisch wel een boost opleveren. Maar om hoeveel writes gaat het dan en wat wordt de belasting van de SSD dan? Is iemand in staat dat te meten?

[robertobadjo]

syl765 schreef op vrijdag 03 februari 2012 @ 11:17:
@robertobadjo

De test server is deze.
http://www.supermicro.com...3U/836/SC836E16-R1200.cfm
met dit moederboard.
http://www.supermicro.com...eon/C202_C204/X9SCM-F.cfm

In productie gebruiken we het zelfde moederboard, maar dit chassis
http://www.supermicro.com...4U/846/SC846E16-R1200.cfm

Als controller gebruiken we de LSI 9211-8i in IT mode.

Niks bijzonders eigenlijk.

De schijven in die bak zijn een vergaartje van oude sata schijven van 80, 160, 250, 500 en 750 GB en deze zijn allemaal een mirror, dus twee 80 GB schijfjes gemirrored twee 750 GB enz.
De meeste schijven komen helaas niet meer door de SMART test en er zijn er al twee FAULTED in de pool.

Wat wel vervelend is, is dat je de LSI controller niet kunt flashen vanaf dat moederboard.
Je krijgt dan de Error Failed to initialize PAL.
Schijnt iets te maken te hebben met de intel chipset.
LSI KB nummer is 15807, dus flashen doen we in een HP Proliant ML110.

Het switchje wat we gebruikten was een simpele HP 8 port Gigabit switch.

Gr
Johan

die LSI controler is dus bijna identiek aan de ibm m1015 zie ik. waarom die LSI dan zoveel duurder is snap ik niet. ok de kabels zitten erbij en niet bij de ibm

de LSI firmware word ook veel gebruikt op de ibm kaart. dus dezelfde performance word aardig gehaald.

ik neig dus ook naar zo'n oplossing met 7 earx 2tb schijven en 1 ssd voor cache. ben dan wel benieuwd naar de performance als ik er 2 esxi host aanknoop en met NFS/iscsi ga klooien. uiteindelijk moet de NAS ingezet gaan worden voor extra VM backup met veeam

[ItsValium]

Ik gebruik wel SSD's voor SLOG, maar ik heb de indruk dat die niet performen zoals je zou verwachten. Ben er momenteel voor in gesprek met Nexenta Support en hoop hier later meer info over te krijgen.

[FireDrunk]

Is er geen optie in ESX(i) om NFS_SYNC uit te zetten? Je kan niet bij advanced dat specifiek uitzetten?

[Femme]

robertobadjo schreef op vrijdag 03 februari 2012 @ 12:19:
[...]


die LSI controler is dus bijna identiek aan de ibm m1015 zie ik. waarom die LSI dan zoveel duurder is snap ik niet. ok de kabels zitten erbij en niet bij de ibm

de LSI firmware word ook veel gebruikt op de ibm kaart. dus dezelfde performance word aardig gehaald.

De IBM ServeRaid M1015 wordt gemaakt door LSI. Het is een oem-versie van de LSI MegaRaid SAS 9220-8i. Het belangrijkste is dat er een LSI SAS2008-controller op zit. De firmware op LSI sas-controllers is nogal uitwisselbaar. Je kunt firmware van een LSI SAS9211-8i of een ander type achtpoorts kaart op een ServeRaid M1015 alias MegaRaid SAS 9220-8i zetten, maar dezelfde firmware kon ik ook flashen naar de onboard LSI SAS2008-controller op mijn Tyan-moederbord. Hooguit moet je wat trucjes uithalen om de flash eerst helemaal leeg te maken omdat de flash tool anders geen flash van een MegaRaid naar kale Initiator-Target-firmware toestaat.

[robertobadjo]

Femme schreef op vrijdag 03 februari 2012 @ 12:44:
[...]


De IBM ServeRaid M1015 wordt gemaakt door LSI. Het is een oem-versie van de LSI MegaRaid SAS 9220-8i. Het belangrijkste is dat er een LSI SAS2008-controller op zit. De firmware op LSI sas-controllers is nogal uitwisselbaar. Je kunt firmware van een LSI SAS9211-8i of een ander type achtpoorts kaart op een ServeRaid M1015 alias MegaRaid SAS 9220-8i zetten, maar dezelfde firmware kon ik ook flashen naar de onboard LSI SAS2008-controller op mijn Tyan-moederbord. Hooguit moet je wat trucjes uithalen om de flash eerst helemaal leeg te maken omdat de flash tool anders geen flash van een MegaRaid naar kale Initiator-Target-firmware toestaat.

daar lees ik idd veel over dat dat onderling goed uiwisselbaar is.

wat ik me dan wel afvraag waarom mensen voor een 9220 of 9240 gaan ipv de ibm m1015 die stukken goedkoper is maar op papier toch nagenoeg dezelfde performance geven

[FireDrunk]

Omdat de support LSI uitgebreider is dan die van IBM. IBM garandeerd namelijk dat hij werkt in IBM servers, en niet in bijvoorbeeld Dell machines. LSI levert support voor _veel_ meer servers en moederborden.

[ Voor 3% gewijzigd door FireDrunk op 03-02-2012 12:56 ]

[robertobadjo]

FireDrunk schreef op vrijdag 03 februari 2012 @ 12:54:
Omdat de support LSI uitgebreider is dan die van IBM. IBM garandeerd namelijk dat hij werkt in IBM servers, en niet in bijvoorbeeld Dell machines. LSI levert support voor _veel_ meer servers en moederborden.

betaald voornamelijk voor support dus.

[AlexanderOnline]

Ik ben een beetje aan het spelen gegaan met ZFSguru op een pc die ik als NAS wil inzetten.
Ik heb de volgende disks: 4x250GB (SATA/PATA) en 1x500GB. Ik wil hiermee een raidZ (raid5) array maken. Nu dacht ik dat het wellicht het beste is om 2x250 + 2x250 + 1x500 te combineren en hiermee een effectieve 1TB te krijgen waarbij single disk failure mogelijk is.
Omdat ik niet exact wist hoe dit gedaan moest worden, iig in de ZFSguru interface niet, heb ik ze allemaaltegelijk eens in de pool gegooid.
Ik heb nu een effectieve opslagcapaciteit van 1.13TB. Hoe kan dat? Dan kan die 500GB schijf toch nooit uitvallen zonder dataverlies?
Ik heb eea lopen googlen maar een duidelijk antwoord in hoe zfs omgaat met schijven van verschillende grootte is me niet duidelijk.

code:

[root@zfsguru /home/ssh]# zpool status
  pool: tank
 state: ONLINE
 scan: resilvered 4.50K in 0h0m with 0 errors on Thu Feb  2 22:44:05 2012
config:

        NAME           STATE     READ WRITE CKSUM
        tank           ONLINE       0     0     0
          raidz1-0     ONLINE       0     0     0
            gpt/disk1  ONLINE       0     0     0
            gpt/disk2  ONLINE       0     0     0
            gpt/disk3  ONLINE       0     0     0
            gpt/disk4  ONLINE       0     0     0
            gpt/disk5  ONLINE       0     0     0

errors: No known data errors

[FDMK]

Ik draai momenteel 0.2 beta4 en zit momenteel tegen erg selecte random writes aan te kijken ongeacht raidtype. Vermoedelijk doe ik ergens wat in de basis niet goed maar ik kom er niet achter.

Read throughput : 8.2 GB/s = 7.6 GiB/s
Write throughput: 71 MB/s = 67.7 MiB/s

'Mooie' is wel dat mn writes constant blijven naar gelang de testgrootte hoger wordt maar nog steeds bedroevend in mijn ogen omdat het nog steeds maar 55% is van een 1 sata-disk(moet imo mogelijk zijn). Zelfs wanneer ik een memory disk aanmaak tbv een SLOG blijft de performance hetzelfde. Tuning staat op performance tuning+ prefetch.
Zoals al eerder aangegeven in dit topic draai ik ZFSguru op ESXi met een LSI1068E passedthrough(vt-d). Deze vm draait momenteel in zijn eentje op mijn esxi bak. CPU load komt ook niet verder dan 30%. Op het ZFS forum lees ik dat de random writes zijn gecapped aan de hand van je cpu maar dat lijkt mij hier niet aan de hand aangezien de VM niet eens in de buurt komt van de 100%.

VM

4vcpu @Xeon 1260L 2.4GHz
14GB
4x WDC WD20EARX-00P
br10i

CPU grafiekje van mn benches

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/zero
Read throughput : 263.7 MB/s = 251.5 MiB/s
Write throughput: 262.6 MB/s = 250.4 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/random
Read throughput : 265.1 MB/s = 252.8 MiB/s
Write throughput: 71.2 MB/s = 67.9 MiB/s*

[ Voor 18% gewijzigd door FDMK op 03-02-2012 19:35 . Reden: Benches+grafiek ]

[Verwijderd]

AlexanderOnline schreef op vrijdag 03 februari 2012 @ 18:53:
Ik ben een beetje aan het spelen gegaan met ZFSguru op een pc die ik als NAS wil inzetten.
Ik heb de volgende disks: 4x250GB (SATA/PATA) en 1x500GB. Ik wil hiermee een raidZ (raid5) array maken. Nu dacht ik dat het wellicht het beste is om 2x250 + 2x250 + 1x500 te combineren en hiermee een effectieve 1TB te krijgen waarbij single disk failure mogelijk is.
Omdat ik niet exact wist hoe dit gedaan moest worden, iig in de ZFSguru interface niet, heb ik ze allemaaltegelijk eens in de pool gegooid.
Ik heb nu een effectieve opslagcapaciteit van 1.13TB. Hoe kan dat? Dan kan die 500GB schijf toch nooit uitvallen zonder dataverlies?

Je hebt dus in feite 5 x 250GB. Dat komt neer op 1250GB en dat zal wel ongeveer die 1.13TiB zijn.

De capaciteiten van de ZFS pool worden ruw weergegeven. Een mirror van twee schijven van 500GB zal dus 1TB als ruwe capaciteit opgeven.

De capaciteiten op de ZFS filesystems worden anders weergegeven; namelijk bruikbare ruimte. Op een 500GB mirror systeem zoals hierboven beschreven zie je dan 500GB opslagruimte ipv 1TB.

Zo ook op de ZFSguru pagina's. De capaciteiten op de Pools pagina zijn 'ruw' terwijl op de Files pagina alleen de bruikbare capaciteit wordt weergegeven, in lijn met hoe ZFS de data rapporteert. Zie ook de waarschuwing hierover op de Pools pagina:

Please note capacities on this page include redundancy, and thus show different numbers than the Files page.

Overigens, je kunt van die 250GB disks inderdaad 500GB disks maken. Daarvoor moet je gstripe gebruiken, of gconcat maar gstripe krijg je nog winst uit. ZFSguru gebruikt de GEOM raid providers niet echt, dus je zult dan e.e.a. via command line moeten doen, in elk geval om de pool aan te maken. Maar het kan wel. Als je dat echt wilt hoor ik het wel, dan geef ik je wat instructies.

Rooke schreef op vrijdag 03 februari 2012 @ 19:01:
Ik draai momenteel 0.2 beta4 en zit momenteel tegen erg selecte random writes aan te kijken ongeacht raidtype.

Dat zijn geen 'random writes' maar sequential writes met /dev/random als bron. Dus niet-comprimeerbare data ipv nulletjes. Dat heeft alleen nut op filesystems waarbij compressie is ingeschakeld. De write score zal vaak CPU-bottlenecked zijn omdat je CPU maar beperkt RNG (random number generator) data kan genereren.

Dus selecteer gewoon /dev/zero en schakel compressie uit op je pool filesystem (hoofd filesystem). Dan krijg je wel normale write scores. Dat staat in beta4 ook nog iets duidelijker aangegeven:

random (write score will be bottlenecked by CPU)

Maar kennelijk nog niet duidelijk genoeg?

[ Voor 17% gewijzigd door Verwijderd op 03-02-2012 19:32 ]

[FDMK]

Ik vatte het anders op Ik had verwacht dat de score zou schalen naar mate je meer resources zou toe kennen. Daarom heb ik ook een grafiekje en benches in mn vorige post neergezet.

[Verwijderd]

Ah dat is zo irritant van die gele 'nieuw bericht' links; je ziet geen edits van berichten.

Maar oke nu zie ik je scores. Met wat voor pool/schijf combinatie ook alweer?

Je CPU verbruik op de host hoeft niet gelijk te zijn aan CPU verbruik op de guest. Je CPU heeft denk ik ook hyperthreading? Bij die /dev/random test gaat je data maar tegen ~70MB/s dus heeft ZFS zelf minder CPU-cycles nodig. Maar de RNG trekt wel de CPU leeg. Althans; ik kan me voorstellen dat RNG wel CPU-capped is maar de CPU maar beperkte delen gebruikt om die info te leveren; ik weet niet hoe die RNG data precies wordt gegenereerd. Maar als mijn vermoeden klopt dan kloppen jouw resultaten ook.

Bij de /dev/zero test ben ik eerder geneigd te denken dat je I/O-capped bent. Laat eens wat van gstat zien (op de Disks -> I/O monitor pagina) tijdens een /dev/zero bench. En misschien ook benchmarks van je disks afzonderlijk op de Disks -> Benchmark -> Simple (eerste tabblad).

[FDMK]

Ik gebruik een RAIDZ met 4 schijven, version 5, zfs 28 en no sector override. Op mijn host staat HT enabled.
Net even opnieuw geinstalleerd, nu zonder compressie.

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 8 GiB
Data source : /dev/random
Read throughput : 7.4 GB/s = 6.9 GiB/s
Write throughput: 71.2 MB/s = 67.9 MiB/s

Wat betreft IO-cap zou goed kunnen bedenk ik me nu althans ~250mb zit tegen de max aan van sata300. Klopt het dat je geen bench en IO-meter tegelijk kan zien?

[Verwijderd]

Nee, nog niet. De pool benchmark is een 'foreground task' en lighttpd is geconfigureerd om maar één proces te gebruiken denk ik? Ik had zoiets ook een keer, in elk geval. Maar je kunt het ook op de commandline doen:

gstat -f "ada[0-9]+p2"
of:
gstat -f "^gpt\/"

evenals:
zpool iostat -v <poolnaam> 2

Rooke schreef op vrijdag 03 februari 2012 @ 20:02:
Ik gebruik een RAIDZ met 4 schijven, version 5, zfs 28 en no sector override.

Probeer eens een RAID0 en kijk wat voor performance je dan krijgt.
Bedenk dat je je schijven kunt partitioneren zodat je ze voor een OS pool en een test pool gebruikt. Dat kan met de partition map editor op de Disks pagina. Twee partities maken met een label naam.

Net even opnieuw geinstalleerd, nu zonder compressie.

Je read throughput is veel te hoog omdat je test size te laag is, dan komt een groot deel uit het RAM. Je write is te laag omdat je weer /dev/random gebruikt.

En verder, je hoeft niet opnieuw te installeren. De compressie die je bij het installeren aanvinkt geldt alleen voor de ZFSguru filesystems en dus niet voor de rest van je pool. Compressie is iets wat per filesystem geregeld kan worden, dus tenzij je zelf dingen doet staat compressie gewoon uit voor alle andere filesystems. Dit kun je controleren op de Files pagina, met een drop-down box voor compressie.

Of op de command line:
zfs get compression

En in het bijzonder gaat het dan om de hoofdfilesystem, dus in jouw geval "Tank". Als daar compressie off staat kun je gewoon /dev/zero gebruiken. En dat is standaard ook zo, tenzij je dat zelf hebt aangepast. Je kunt beter compressie alleen voor specifieke filesystems aanzetten, zodat het standaard uitblijft. Als je compressie op je hoofd filesystem (Tank) aanzet, en je maakt een nieuw filesystem, dan krijgt die standaard ook de compressie mee door inheritance. Je kunt het wel specifiek uit zetten maar dan is het default on. Ik raad dat dus af!

[ Voor 81% gewijzigd door Verwijderd op 03-02-2012 20:18 ]

[3d0zer]

.

[matty___]

Rooke schreef op vrijdag 03 februari 2012 @ 20:02:
Ik gebruik een RAIDZ met 4 schijven, version 5, zfs 28 en no sector override. Op mijn host staat HT enabled.
Net even opnieuw geinstalleerd, nu zonder compressie.

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 8 GiB
Data source : /dev/random
Read throughput : 7.4 GB/s = 6.9 GiB/s
Write throughput: 71.2 MB/s = 67.9 MiB/s

Wat betreft IO-cap zou goed kunnen bedenk ik me nu althans ~250mb zit tegen de max aan van sata300. Klopt het dat je geen bench en IO-meter tegelijk kan zien?

hoeveel GB ram heb je? Lijkt er meer op dat je je arc cache aan het benchmarken bent.
Test met iobench oid. en met 2x je ram size

[Verwijderd]

Hij kan gewoon de test size omhoog gooien, zijn eerdere benchmarks met 32GiB test size gaven wel goede scores, rond 250MB/s. Voor 4 schijven in RAID-Z wel redelijk denk ik, zeker omdat dit geen optimale config is voor 4K disks.

Bedenk ook dat je op de Disks->Benchmark pagina de advanced benchmark kan starten, mits je geen pools op de disks/partitie hebt staan. Dan krijg je mooie grafiekjes van allerlei configuraties.

[matty___]

Verwijderd schreef op vrijdag 03 februari 2012 @ 22:45:
Hij kan gewoon de test size omhoog gooien, zijn eerdere benchmarks met 32GiB test size gaven wel goede scores, rond 250MB/s. Voor 4 schijven in RAID-Z wel redelijk denk ik, zeker omdat dit geen optimale config is voor 4K disks.

Bedenk ook dat je op de Disks->Benchmark pagina de advanced benchmark kan starten, mits je geen pools op de disks/partitie hebt staan. Dan krijg je mooie grafiekjes van allerlei configuraties.

vond ik altijd het mooi aan iobench. Die doet ook gelijk random write en reads.

[FDMK]

Verwijderd schreef op vrijdag 03 februari 2012 @ 22:45:
Hij kan gewoon de test size omhoog gooien, zijn eerdere benchmarks met 32GiB test size gaven wel goede scores, rond 250MB/s. Voor 4 schijven in RAID-Z wel redelijk denk ik, zeker omdat dit geen optimale config is voor 4K disks.

Bedenk ook dat je op de Disks->Benchmark pagina de advanced benchmark kan starten, mits je geen pools op de disks/partitie hebt staan. Dan krijg je mooie grafiekjes van allerlei configuraties.

Wat is wel een optimale config voor 4k disks? EARX zouden 4k disks moeten zijn maar als ik no override kies dan wordt er automatisch 512k gekozen. Daar moet ik nog even naar kijken.

Ik heb een bench gedaan over 64GiB en de IO in de gaten gehouden:

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 228.2 MB/s = 217.6 MiB/s
Write throughput: 232 MB/s = 221.3 MiB/s

L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
0 0 0 0 0.0 0 0 0.0 0.0| gpt/BOOT1
10 867 0 0 0.0 865 73389 7.9 99.0| gpt/DT10
10 843 0 0 0.0 841 71272 8.1 95.5| gpt/DT11
10 869 0 0 0.0 867 73516 7.9 93.8| gpt/DT12
10 835 0 0 0.0 833 70550 8.2 95.1| gpt/DT13

[matty___]

Rooke schreef op vrijdag 03 februari 2012 @ 22:54:
[...]

Wat is wel een optimale config voor 4k disks? EARX zouden 4k disks moeten zijn maar als ik no override kies dan wordt er automatisch 512k gekozen. Daar moet ik nog even naar kijken.

Ik heb een bench gedaan over 64GiB en de IO in de gaten gehouden:

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 228.2 MB/s = 217.6 MiB/s
Write throughput: 232 MB/s = 221.3 MiB/s

L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name
0 0 0 0 0.0 0 0 0.0 0.0| gpt/BOOT1
10 867 0 0 0.0 865 73389 7.9 99.0| gpt/DT10
10 843 0 0 0.0 841 71272 8.1 95.5| gpt/DT11
10 869 0 0 0.0 867 73516 7.9 93.8| gpt/DT12
10 835 0 0 0.0 833 70550 8.2 95.1| gpt/DT13

Misschien makkelijker: gstat -a

[Verwijderd]

512B (bytes) ja, dat is de standaard sectorsize, en huidige 4K sector disks emuleren 512B sectors dus je moet handmatig die override op 4K zetten. Voor native 4K sector disks hoef je niets te doen, maar die bestaan nog niet, helaas.

Optimale configuraties voor 4K sector schijven:
RAID-Z: 3, 5 en 9 disks
RAID-Z2: 4, 6 en 10 disks
RAID-Z3: 5, 7 en 11 disks

En 99% busy betekent dat je disks bottlenecked zijn. Waarschijnlijk omdat je geen optimale configuratie draait (RAID-Z met 4 disks). Je schijven moeten dan afwisselend af en toe en sector emuleren dus eerst lezen alvorens ze kunnen schrijven. Dat lezen zie je niet met gstat, want dat gebeurt intern en weet de host niets van.

[ Voor 31% gewijzigd door Verwijderd op 03-02-2012 22:59 ]

[FDMK]

matty___ schreef op vrijdag 03 februari 2012 @ 22:56:
[...]

Misschien makkelijker: gstat -a

Ik ben lerende Was/ben niet zo'n hele CLI held, op cisco ios na dan.

[Verwijderd]

Nadeel van gstat -a is dat je devices er meerdere malen in ziet staan. De device node zelf (ada2) dan de partitie (ada2p2) en dan je label (gpt/LABEL). Maar wel handig om te weten en snel even te kijken.

[fluppie007]

Eerste test op de nieuwe server ( Gigabyte Z68, Intel i5 2500K, Corsair 32GB DDR3 RAM ):

Niet-optimale pool van 4 disks ( Samsung F4EG HD204UI 2TB ) op de Intel Z68 chipset

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool (7.25T, 0% full)
Test size : 16 GiB
Data source : /dev/zero
Read throughput : 305.8 MB/s = 291.7 MiB/s
Write throughput: 84.6 MB/s = 80.7 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/zero
Read throughput : 310.4 MB/s = 296 MiB/s
Write throughput: 88.3 MB/s = 84.2 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 302.3 MB/s = 288.3 MiB/s
Write throughput: 82 MB/s = 78.2 MiB/s

[Verwijderd]

Teleurstellende write scores. Maak je pool eens aan met 4KiB sectorsize override, welke snelheden haal je dan?

[fluppie007]

Verwijderd schreef op zaterdag 04 februari 2012 @ 00:30:
Teleurstellende write scores. Maak je pool eens aan met 4KiB sectorsize override, welke snelheden haal je dan?

Deze benchmarks zijn gedaan met volgende pool-settings:
Filesystem v4
Pool v15
Raid-5 / Raid-Z
Default sector size

[Verwijderd]

Dat begrijp ik, en de pool versie maakt verder niets uit. Dat is alleen voor extra features. De snelheid wordt bepaald door je hardware, je OS, ZFS implementatie, pool configuratie en tuning settings.

[ Voor 4% gewijzigd door Verwijderd op 04-02-2012 00:42 ]

[fluppie007]

Tweede test op de nieuwe server ( Gigabyte Z68, Intel i5 2500K, Corsair 32GB DDR3 RAM ):

Niet-optimale pool van 4 disks ( Samsung F4EG HD204UI 2TB ) op de Intel Z68 chipset met 4K sector override

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool4KOverride (7.25T, 0% full)
Test size : 16 GiB
Data source : /dev/zero
Read throughput : 300.2 MB/s = 286.2 MiB/s
Write throughput: 104.2 MB/s = 99.4 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool4KOverride (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/zero
Read throughput : 300 MB/s = 286.1 MiB/s
Write throughput: 105.4 MB/s = 100.5 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : TestPool4KOverride (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 298 MB/s = 284.2 MiB/s
Write throughput: 103.5 MB/s = 98.7 MiB/s

[ Voor 14% gewijzigd door fluppie007 op 04-02-2012 01:09 ]

[Verwijderd]

Niet echt veel beter. Wat als je een mirror maakt van 4 schijven? Dus eerst een mirror van 2 disks maken en later de andere 2 toevoegen als mirror op de Pools -> Expand pagin.

En nogmaals; die disks->Benchmark is eigenlijk veel beter omdat die alle combinaties test en je ook een sectorsize override checkbox hebt; dan kun je twee benchmarks draaien één zonder override en één met dan heb je alle configuraties getest en kun je misschien zien waarom de performance zo slecht is; met name de write performance.

Als je hulp nodig hebt met die benchmark of hoe je meerdere partities maakt, dan hoor ik het wel.

[FDMK]

Verwijderd schreef op vrijdag 03 februari 2012 @ 22:56:
512B (bytes) ja, dat is de standaard sectorsize, en huidige 4K sector disks emuleren 512B sectors dus je moet handmatig die override op 4K zetten. Voor native 4K sector disks hoef je niets te doen, maar die bestaan nog niet, helaas.

Optimale configuraties voor 4K sector schijven:
RAID-Z: 3, 5 en 9 disks
RAID-Z2: 4, 6 en 10 disks
RAID-Z3: 5, 7 en 11 disks

En 99% busy betekent dat je disks bottlenecked zijn. Waarschijnlijk omdat je geen optimale configuratie draait (RAID-Z met 4 disks). Je schijven moeten dan afwisselend af en toe en sector emuleren dus eerst lezen alvorens ze kunnen schrijven. Dat lezen zie je niet met gstat, want dat gebeurt intern en weet de host niets van.

Ik wil overigens ook die advanced benchmarking doen in de disk tab maar volgens mij zit daar een typo :

sudo: /usr/local/www/zfsguru//benchmark.php: command not found

Ik heb overigens een testje gedaan met RAIDZ2 zoals je zei:

ZFSguru 0.2.0-beta4 pool benchmark
Pool : Tank (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 166.2 MB/s = 158.5 MiB/s
Write throughput: 169.2 MB/s = 161.4 MiB/s

Raid0(2disk):

ZFSguru 0.2.0-beta4 pool benchmark
Pool : RAID0 (3.62T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 220.7 MB/s = 210.4 MiB/s
Write throughput: 191.3 MB/s = 182.4 MiB/s


Main objective is eigenlijk om mn clients en eventueel VM's de gbit pijp dicht te trekken, volgens mij ben ik daar in geslaagd maar wil kijken of er nog meer uit te halen is.

[ Voor 7% gewijzigd door FDMK op 04-02-2012 20:58 ]

[Verwijderd]

Je 4-disk RAID-Z2 kan max. schrijven zoals een 2-disk RAID0 dus je hebt maar een kleine penalty van de dubbele parity; ziet er goed uit, behalve misschien de iets lage read score.

Je RAID0 scores zien er natuurlijk heel goed uit. Kun je dat ook met 4 schijven doen? Heb je je OS al op een kleine partitie gezet zodat je eenvoudig alle 4 schijven in een pool config kunt draaien? Bijvoorbeeld eerst een 10GiB partitie voor OS en daarna datapartitie voor je grote ZFS pool. Dan maak je van de kleine 10GiB partities op disk1 en disk2 een mirror aan wat je als systeemdisk gebruikt, dan heb je nog steeds 4 schijven/partities over om allerlei pool configuraties te kunnen draaien.

Die advanced benchmark werkt waarschijnlijk niet door mijn werk in beta4 aan de simple benchmark. Maar kun je dit eens proberen op een root command prompt:
chmod 775 /usr/local/www/zfsguru/benchmark.php
chmod 775 /usr/local/www/zfsguru/benchmarks

[jwpmzijl]

@CiPHER
Ik heb zfsguru vandaag gedownload en zit er wat mee te "spelen". Heb diverse dingen die waarschijnlijk bugs zijn ontdekt. Klopt het dat bugs in het zfsguru forum geplaatst moeten worden of hebben jullie een andere methode ?

Ter info, ik probeer een pool te maken van met afwijkende sector size en dat vind zfsguru 0.2.0-beta4 niet zo leuk ....

code:

Failure: execution failed for command: /sbin/gnop create -S 65536 /dev/gpt/rr1
 Failure: 
execution failed for command: /sbin/gnop create -S 65536 /dev/gpt/rr2
 Failure: 
execution failed for command: /sbin/gnop create -S 65536 /dev/gpt/rr3
 Failure: 
execution failed for command: /sbin/gnop create -S 65536 /dev/gpt/rr4
 Failure: 
execution failed for command: /sbin/gnop create -S 65536 /dev/gpt/rr5
 Failure: 
execution failed for command: /sbin/zpool create -o version=28 -O version=4 -O atime=off test1 raidz gpt/rr1.nop gpt/rr2.nop gpt/rr3.nop gpt/rr4.nop gpt/rr5.nop
 Failure: 
execution failed for command: /usr/sbin/chown -R 1000:1000 /test1
 Notice: 
command output:
gnop: Provider gpt/rr1.nop already exists.
 Notice: 
command output:
gnop: Provider gpt/rr2.nop already exists.
 Notice: 
command output:
gnop: Provider gpt/rr3.nop already exists.
 Notice: 
command output:
gnop: Provider gpt/rr4.nop already exists.
 Notice: 
command output:
gnop: Provider gpt/rr5.nop already exists.
 Notice: 
command output:
cannot create 'test1': invalid argument for this pool operation
 Notice: 
command output:
chown: /test1: No such file or directory

[Verwijderd]

Je hebt al eerder die disks gebruikt voor een sectorsize override. Dan moet je dat geen 2e keer doen (waarschuwt de web-interface niet voor inderdaad). Dus 2e keer gewoon sectorsize override uitlaten.

Als je reboot dan is de sectorsize override weer weg. Het gaat erom dat je een pool aanmaakt terwijl tenminste één disk een sectorsize heeft van 4KiB. Dan wordt de pool 'ashift=12' gemaakt, wat je kunt zien op de Pools pagina als je je pool aanklikt, dan zie je: "this pool is optimized for 4K sector disks (ashift=12)".

Ik moet wel zeggen dat 64KiB sectorsize absoluut niet oké is voor een echte server; voor testdoeleinden prima verder maar normaal gebruik je de override voor 4KiB sectors.

[ Voor 30% gewijzigd door Verwijderd op 05-02-2012 00:03 ]

[FDMK]

Verwijderd schreef op zaterdag 04 februari 2012 @ 23:42:
Je 4-disk RAID-Z2 kan max. schrijven zoals een 2-disk RAID0 dus je hebt maar een kleine penalty van de dubbele parity; ziet er goed uit, behalve misschien de iets lage read score.

Je RAID0 scores zien er natuurlijk heel goed uit. Kun je dat ook met 4 schijven doen? Heb je je OS al op een kleine partitie gezet zodat je eenvoudig alle 4 schijven in een pool config kunt draaien? Bijvoorbeeld eerst een 10GiB partitie voor OS en daarna datapartitie voor je grote ZFS pool. Dan maak je van de kleine 10GiB partities op disk1 en disk2 een mirror aan wat je als systeemdisk gebruikt, dan heb je nog steeds 4 schijven/partities over om allerlei pool configuraties te kunnen draaien.

Die advanced benchmark werkt waarschijnlijk niet door mijn werk in beta4 aan de simple benchmark. Maar kun je dit eens proberen op een root command prompt:
chmod 775 /usr/local/www/zfsguru/benchmark.php
chmod 775 /usr/local/www/zfsguru/benchmarks

Die chmod fixt het helaas niet de knop of actie die benchmark.php aanroept zit daar niet de fout? Aangezien er een dubbele "/" in het pad staat.

RAID0 over 4 disken:

ZFSguru 0.2.0-beta4 pool benchmark
Pool : RAID0 (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 344.7 MB/s = 328.7 MiB/s
Write throughput: 348.8 MB/s = 332.7 MiB/s

Als systeemdisk(en) heb ik 2 vmdk's(mirror) van 5GiB die op een intel320 ssd staan. Swapping heb ik uit gezet vanuit de redenatie dat ik genoeg geheugen heb en het niet zie gebeuren dat er geswapt moet worden.

[Goderic]

Op FOSDEM was er een voordracht over Illumian, dit is de nieuwe naam voor de vernieuwde Nexenta Core (die naam zorgde blijkbaar voor verwarring).
Het is de bedoeling dat dit een echt community project wordt, ondersteund door Nexenta Systems (en dus niet omgekeerd). Het enige verschil met OpenIndiana is dat Illumian apt gebruikt en OpenIndiana IPS. Er zal dus ook meer samenwerking tussen deze distributies zijn.

Ik heb ook gevraagd hoe het met de 18TB limiet zit in NexentaStor Community edition: Deze limiet zit enkel in de closed source webinterface. Aangezien die in PHP geschreven is zou het ook mogelijk moeten zijn om de limiet er weer uit te halen...

[Verwijderd]

gila@illumian:~$ uname -a
SunOS illumian 5.11 78dda8d6098f i86pc i386 i86pc Solaris
gila@illumian:~$

Loopt als een niet NS-trein =) illumian is een distro van illumos, de 18TB limiet is op beperking op de community edition van Nexenta; dat is niet alleen een interface ofzo hoor veel van de illumos ontwikkelaars staan op de payrol van Nexenta.

[Goderic]

Verwijderd schreef op zondag 05 februari 2012 @ 22:56:
[...]


Loopt als een niet NS-trein =) illumian is een distro van illumos, de 18TB limiet is op beperking op de community edition van Nexenta; dat is niet alleen een interface ofzo hoor veel van de illumos ontwikkelaars staan op de payrol van Nexenta.

En die 18TB limiet zit dus enkel in de webinterface van de community edition van Nexenta.
Als je via de commandline werkt zul je die 18TB limiet niet tegenkomen. (En dat heb ik niet zelf verzonnen, dat heeft een illumos onwikkelaar die bij Nexenta werkt me weten te vertellen)

[Verwijderd]

Rooke schreef op zondag 05 februari 2012 @ 09:49:
[...]

Die chmod fixt het helaas niet de knop of actie die benchmark.php aanroept zit daar niet de fout? Aangezien er een dubbele "/" in het pad staat.

Nee, voor Unix is ///usr///local////etc hetzelfde als /usr/local/etc. Maar morgen zou beta5 uit moeten komen die de benchmark fixt. Wel de moeite waard trouwens, want je krijgt dan een mooi overzicht van eventuele bottlenecks.

Swapping heb ik uit gezet vanuit de redenatie dat ik genoeg geheugen heb en het niet zie gebeuren dat er geswapt moet worden.

Hm het is anders wel aan te raden de swap aan te laten staan. Zeker in combinatie met tmpfs en tijdens de installatie is het belangrijk dat je swap hebt. Als je voor swap kiest, wordt deze als 'sparse zvol' aangemaakt dus je kunt hem 8GiB maken het kost je niets aan ruimte totdat er daadwerkelijk geswapt wordt. Dus eigenlijk weinig reden om geen swap in te schakelen als dit in sommige gevallen nodig is (details weet ik ook niet). Je kunt achteraf op de Files->Volumes pagina een nieuwe zvol aanmaken en als swap activeren.

[Verwijderd]

Hallo allemaal,

Ik ben helemaal nieuw met ZFS en ik ben van plan om het op te zetten als test datastore in een VMware omgeving.
De planning is om openindiana + napp-it te instaleren op een dl380 G5 met daaronder een diskshelf (spare voorraad)
de diskshelf bestaat uit 5 x 1 terrabyte schijven en in de dl380 komen 2 ssd's (read cache) en 2 15k scsi schijven (write cache).
Nu is het hier een discussie hoe we de schijven van de diskshelf aan de openindiana aanbieden..
De shelf is aangesloten op een P812 raidcontroller, de bedoeling was om hier doormiddel van raid 10 de schijven aan openindiana aan te bieden zodat we de zekerheid hebben van de hardware raid.

wat zijn jullie aanbevelingen om dit wel of niet te doen?

[FireDrunk]

ZFS is juist ontwikkeld om hardware RAID te vervangen. Dit vanwege het verhaal dat Bad Sectors op een schijf direct betekend dat een schijf uit een array gegooid word, terwijl dat helemaal niet nodig is.

Voor ZFS wil je het liefst dat de disks allemaal direct zonder enige vorm van RAID zichtbaar zijn voor ZFS.

Als het echt niet anders kan, is RAID10 wel je beste optie denk ik.

[Verwijderd]

Ik snap dat ze sneller uit een array worden gegooid maar er zit goede garantie op deze disken hebben hier een spare voorraad voor liggen dus vervangen we (defecte of mindere) schijven liever wat sneller omdat het een (semi) productie omgeving betreft. of is de raidz van zfs ook voldoende betrouwbaar binnen mijn opstelling?
en zal ik hier wat terug zien in de performance?
of zien jullie een beter opstelling met de dezelfde hardware?

[Femme]

Het mooie van zfs icm met een redundant raid-level is dat je checksumming hebt én de mogelijkheid om data te repareren (mbv parity bits). Als je de redundancy laat afhandelen door een raid-controller kan zfs deze redundancy niet benutten voor self-healing als de integriteit van de opgeslagen gevens (door een mismatch met de checksum) niet is te vertrouwen. De raid-controller beschermt wel tegen falende harde schijven maar van een bitje dat per ongeluk omvalt of om wat voor reden dan ook verkeerd op de disk aankomt zal hij nooit weet hebben. Zfs valideert elke keer bij het inlezen de integriteit van de data door de checksum van de ingelezen data te vergelijken met een checksum die eerder werd opgeslagen op de disks.

Als je per se de raid-controller wil gebruiken kun je de disks het beste als losse volumes aanbieden aan zfs. Je kunt 'm ook vervangen door een kale sas host bus adapter met een LSI2008- of LSI1068E-controller met vier externe poorten om 'm met de disk array te verbinden. De disks kun je gewoon gebruiken.

[ Voor 31% gewijzigd door Femme op 07-02-2012 13:37 ]

[FireDrunk]

Dat laatste is inderdaad de beste optie, maar je moet wel hopen dat in de externe behuizing geen SAS-expander zit die roet in het eten gooit. Bij een LSI2008 werken expanders, bij LSI1068 niet. Bovendien moet je hopen dat er een expander in zit die uberhaupt word ondersteund.

[Verwijderd]

Bedankt voor jullie aanbevelingen, maar bij het vervangen van disks met een hardware raidset is het eenvoudig om snel een disk te wisselen en klaar data wordt er zelf weer opgezet zonder maar ook een console te openen, ook kwam hier de opmerking hoevaak komt het voor dat een bitje omvalt/niet juist aankomt. bij het terugzetten van schijf met ZFS raid wordt het opbouwen van de schijf gedaan door de bovenliggende hardware (meer overhead?)
De features die mij/ons het meeste aanstonden van ZFS zijn vooral de hybride pool voordelen door het koppelen van SSD's en sata schijven.
of is het met deze argumenten helemaal niet juist om om voor ZFS te kiezen?
want bij het gebruik van raid 10 mis ik toch alleen de eerste 2 puntjes van het lijstje voordelen?

[Femme]

FireDrunk schreef op dinsdag 07 februari 2012 @ 13:55:
Dat laatste is inderdaad de beste optie, maar je moet wel hopen dat in de externe behuizing geen SAS-expander zit die roet in het eten gooit. Bij een LSI2008 werken expanders, bij LSI1068 niet. Bovendien moet je hopen dat er een expander in zit die uberhaupt word ondersteund.

Ik blijf het maar een raar verhaal vinden van die sas-expanders. Sas-expanders worden op grote schaal ingezet in enterprise storage opslagsystemen, ook die van Sun en Oracle zelf, en nu zou het opeens niet werken in combinatie met zfs?

Toen sas net op de markt was heb ik wat compatibliteitsissues meegemaakt. Je zou verwachten dat zes jaar later wel verholpen zijn.

[FireDrunk]

Nee nee, ik bedoel dat een expander niet werkt met een bepaalde controller, ZFS kan er prima mee overweg.

[Verwijderd]

Ik heb anders aardig wat (te) lage scores gezien bij systemen met expanders. Mijn theorie is dat bij RAID-Z met een aardige hoeveelheid disks, zoals 10-disk RAID-Z2, de I/O in kleine blokjes verloopt: maximaal 16KiB (128K record size / 8 data disks). Het kan zo zijn dat expanders weinig moeite hebben met grote requests maar wel moeite hebben met hordes van kleine requests, en daardoor de latency teveel toeneemt waardoor je niet het maximale uit de schijven krijgt. RAID-Z is door zijn variabele stripesize erg uniek en je kunt dus (performance) problemen krijgen terwijl die op traditionele platforms niet voorkomen.

Wat betreft Bildoes: ZFS is het tegenovergestelde van Hardware RAID zo ongeveer, dus waarom wil je deze twee combineren? Het is algemeen bekend dat ZFS veel liever zelf in controle is over de disks. Doe je dat niet dan verlies je een van de belangrijkste ZFS voordelen: self-healing. Voor ZFS draai je dan een single disk RAID0 array; geen redundante array! ZFS heeft geen toegang tot de redundantie van de hardware RAID array.

Qua bad sectors loop je ook risico. Als je nou één schijf verliest en je voegt een nieuwe schijf toe, en twee andere schijven hebben ook een onleesbare sector, dan is je hele array failed (wel recoverable; maar niet makkelijk). Met ZFS heb je dat soort problemen niet.

Ander klein voorbeeld: ZFS gebruikt redundante metadata, zelfs op een RAID0 of single disk pool. Alleen moet het wel zelf controle hebben over de schijven om gegarandeerd de 'ditto copies' zoals die heten op verschillende schijven te plaatsen en niet beide kopiën op dezelfde schijf. Echter, als je hardware RAID gebruikt dan kan ZFS maar één device zien en is het dus prima mogelijk dat een deel van je ditto copies op dezelfde schijven neerkomen. Zo kan je belangrijke en kwetsbare metadata alsnog corrumperen en dan is je array FAULTED met alles erop foetsie, al heb je 300 spare disks gereed staan.

[Q]

jwpmzijl schreef op maandag 23 januari 2012 @ 02:11:
[...]

[Long post warning]

Zo'n lange post en dan zie ik hem over het hoofd. Wel interessante resultaten.

Ik haal over NFS met Linux + Round Robin ook iets van 180 Mb/s gemiddeld. Met twee kaarten. Zoveel ontloopt het niet dus.

Multipath IO is op deze wijze wel aardig, maar tja.

Als ik voor weinig geld een SAN achtig iets moet bouwen zou ik 2e hands een stapel infiniband kaartjes inslaan en daarmee aan de slag gaan, + glas.

[jwpmzijl]

Q schreef op dinsdag 07 februari 2012 @ 18:58:
[...]
Zo'n lange post en dan zie ik hem over het hoofd. Wel interessante resultaten.

Hoi, Q wel op blijven letten hé

Heb inmiddels wat gespeeld met de volgende alternatieven Freenas, Openfiler, FreeBSD+zfsguru maar heb de behaalde resultaten van Windows 2008R2 nog niet kunnen evenaren. Dat zal voornamelijk te maken hebben met de igSt iScsi target die naar mijn mening minder presteerd. Ook het feit dat voor mijn hardware niet de juiste drivers voorhanden lijken te zijn.

Heb inmiddels ook met Windows 8 server wat zitten te klooien maar kreeg daarop Multipath i/o niet meer aan de praat (het is een developer preview hé). Moet nog kijken naar de nieuwe storage pools functies en ReFS van Windows 8 server.

Maar goed dit is het grote ZFS topic. Het is jammer dat ik OpenIndiana nog niet heb kunnen testen. Moet toch eens wat meer compatibele hardware in huis halen maar dat zal nog wel ff op zich laten wachten. Toch lokt de combinatie van Comstar voor iScsi en ZFS voor opslag. Onder OpenIndiana moet dat mogelijk zijn.

[Verwijderd]

Heb inmiddels wat gespeeld met de volgende alternatieven Freenas, Openfiler, FreeBSD+zfsguru maar heb de behaalde resultaten van Windows 2008R2 nog niet kunnen evenaren

Om daar nog wat over op te merken: als je in ZFSguru de ZVOL als 'sync=off' aanmaakt, dan zullen je write speeds vele malen hoger liggen afhankelijk van je client workload. Als je nog tijd hebt kun je dat nog uitproberen. Was er een bijzondere reden waarom je geen Samba/CIFS wilde gebruiken?

[jwpmzijl]

Ik ben aan het testen of ik het aandurf om enkele test omgevingen te virtualiseren met een storagebox op basis van ZFS. Het virtualisatieplatform is HyperV en met iScsi heb ik het meeste ervaring dus maak ik daar ook nu gebruik van.

Maar zal binnenkort jouw advies over sync=off eens testen.

[fluppie007]

Iemand een idee wat deze "medium error" wilt zeggen ?
Kan het gerelateerd zijn aan mijn performance problemen ?

edit:

Volgens mij komt dit van mijn DVD-rom drive...
Ik las in het ZFS forum dat je moet installeren voor benchmark tests te doen...
Even gedaan en ik krijg het volgende:

Niet-optimale pool van 4 disks ( Samsung F4EG HD204UI 2TB ) op de LSI 9220-8i met 4K sector override

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 16 GiB
Data source : /dev/zero
Read throughput : 184.6 MB/s = 176.1 MiB/s
Write throughput: 182.5 MB/s = 174.1 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 32 GiB
Data source : /dev/zero
Read throughput : 328.3 MB/s = 313.1 MiB/s
Write throughput: 146.7 MB/s = 139.9 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 320 MB/s = 305.2 MiB/s
Write throughput: 297.3 MB/s = 283.5 MiB/s

ZFSguru 0.2.0-beta4 pool benchmark
Pool : FlupZFS (7.25T, 0% full)
Test size : 128 GiB
Data source : /dev/zero
Read throughput : 307 MB/s = 292.8 MiB/s
Write throughput: 281.3 MB/s = 268.3 MiB/s

[ Voor 78% gewijzigd door fluppie007 op 12-02-2012 16:22 ]

[Verwijderd]

Als ik boot met mijn LiveCD krijg ik ook altijd 2 van die errors; ik denk dat dat commando's zijn die een CD/DVD station niet ondersteund en dus 'normaal' dat je die krijgt. Als je niet zou kunnen lezen van je DVD tijdens het installeren, zal je een foutmelding krijgen omdat hij checksum controleert. Als er dus één byte niet goed is tijdens het installeren/kopiëren dan merk je dat.

Als je gewoon hebt kunnen installeren is er met je CD/DVD zelf niets mis lijkt me. Wat ik wel vreemd vind is dat je bij de 16 en 32 gigabyte writes veel lagere writes krijgt; kan het zijn dat je bij de eerste bench nog wat dingen op de achtergrond deed?

[fluppie007]

Verwijderd schreef op zondag 12 februari 2012 @ 16:53:
...
Als je gewoon hebt kunnen installeren is er met je CD/DVD zelf niets mis lijkt me. Wat ik wel vreemd vind is dat je bij de 16 en 32 gigabyte writes veel lagere writes krijgt; kan het zijn dat je bij de eerste bench nog wat dingen op de achtergrond deed?

Zou het te maken kunnen hebben met dat ik 32GiB RAM heb ?
Verder ben ik naar 0.1.9 gegaan om de advanced benchmark te kunnen doen. Klopt het dat je hiervoor geen pool mag hebben aangemaakt ?

Hmmm....

code:

ZFSGURU-benchmark, version 1
Test size: 8.000 gigabytes (GiB)
Test rounds: 3
Cooldown period: 2 seconds
Sector size override: default (no override)
Number of disks: 4 disks
disk 1: gpt/Disk1
disk 2: gpt/Disk2
disk 3: gpt/Disk3
disk 4: gpt/Disk4


* Test Settings: TS8; 
* Tuning: AMIN=32m; AMAX=64m; 
* Stopping background processes: sendmail, moused, syslogd and cron
* Stopping Samba service

Now testing RAID0 configuration with 4 disks: cinvalid vdev specification
use '-f' to override the following errors:
/dev/gpt/Disk1 is part of potentially active pool 'FlupZFS'

* ERROR during "zpool create"; got return value 1
cannot open 'gurubenchmarkpool': no such pool

[ Voor 39% gewijzigd door fluppie007 op 12-02-2012 17:00 ]

[Verwijderd]

De advanced benchmarks heeft lege disks nodig ja. Althans, lege partities; je kunt meerdere partities op één disk hebben en dus één disk voor meerdere pools gebruiken. Maar voor een goede test kun je beter dedicated disks gebruiken en een USB stick of losse schijf voor het systeem.

In jouw geval heb je een disk (Disk1) waar al een pool (FlupZFS) op staat, en die benchmark wil hem niet zomaar overschrijven.

Had je trouwens alle benchmarks hieboven met de LiveCD of Root-on-ZFS gedaan? Als die eerste twee benches van de livecd afkomen dan snap ik de scores al veel beter.

[fluppie007]

Verwijderd schreef op zondag 12 februari 2012 @ 17:28:
De advanced benchmarks heeft lege disks nodig ja. Althans, lege partities; je kunt meerdere partities op één disk hebben en dus één disk voor meerdere pools gebruiken. Maar voor een goede test kun je beter dedicated disks gebruiken en een USB stick of losse schijf voor het systeem.

In jouw geval heb je een disk (Disk1) waar al een pool (FlupZFS) op staat, en die benchmark wil hem niet zomaar overschrijven.

Had je trouwens alle benchmarks hieboven met de LiveCD of Root-on-ZFS gedaan? Als die eerste twee benches van de livecd afkomen dan snap ik de scores al veel beter.

De benches van vandaag zijn met Root-on-ZFS gedaan, die van pakweg een week geleden met de LiveCD.
Ik zal een SSD gebruiken om ZFSguru op te installeren.

Ik heb die pool ( FlupZFS ) met de liveCD gedestroyed maar toch vindt die disk benchmark hem nog. Hoe kan ik ervoor zorgen dat die 'hidden' of 'destroyed' pools niet meer gevonden kunnen worden ? Door een zero-write te doen ? Maar dat duurt natuurlijk erg lang als ik dat elke keer voor de 4 disks moet doen...

Kan ik die disk benchmark vanop de liveCD runnen ? Want ik moet een pool aanmaken om te kunnen installeren.

[Verwijderd]

Nee gewoon naar Pools pagina en klik op Display hidden pools ofzoiets. Dan kan je je pool importeren als het goed is, en daarna DESTROYen ook op de Pools pagina. Daarna kun je veilig verder. Zero-write op alle vier disks werkt ook maar is onnodig.

De Advanced Disk benchmark kun je van livecd draaien, maar dat is niet verstandig. Je krijgt namelijk lagere scores door de strenge ZFS tuning. Dus eerst installeren en een reboot, dan draai je Root-on-ZFS en kun je volop benchmarken.

[ Voor 32% gewijzigd door Verwijderd op 12-02-2012 17:50 ]

[fluppie007]

Hmmm. Na de (succesvolle) Root-on-ZFS installatie ( live cd beta4, upgrade naar beta5 ) zegt hij:
No ZFS pools located, can't boot.

Nogtans heb ik een pool 'BootZFS' aangemaakt met Raid0 / geen redundancy op de 120GB Intel SSD.
Doe ik iets fout ?

[Verwijderd]

Hey Beta5 is released.

Wat betreft je probleem: heb je via de welcome wizard of handmatig je pool / disk labels aangemaakt? Ik zal eens hetzelfde proberen met de beta4 livecd!

[fluppie007]

Verwijderd schreef op zondag 12 februari 2012 @ 23:15:
Hey Beta5 is released.

Wat betreft je probleem: heb je via de welcome wizard of handmatig je pool / disk labels aangemaakt? Ik zal eens hetzelfde proberen met de beta4 livecd!

Eerste poging: eerst via de wizard. Vertrokken vanuit de beta4 live cd, meteen de upgrade gedaan naar beta 5. Daarna de installatie gestart. "can't boot"

Tweede poging: de beta4 live cd genomen, naar 0.1.9 gedowngrade en manueel een pool aangemaakt. Filesystem v4 en ZFS v28 ipv de recommended setting van v15/16. "can't boot"

Hij is nu terug met de liveCD aan het booten. Verschil met daarnet is dat ik nu de SSD als bootschijf probeer te gebruiken...

[Verwijderd]

Bij mij werkt het gewoon, in Virtualbox dan.

Wat voor hardware draaide je ook alweer, wat voor disks en vanaf welke disk boot je (boot sequence). Heb je sectorsize override gedaan of iets anders bijzonders? Op welke controller zitten je disks?

[fluppie007]

Verwijderd schreef op zondag 12 februari 2012 @ 23:39:
Bij mij werkt het gewoon, in Virtualbox dan.

Wat voor hardware draaide je ook alweer, wat voor disks en vanaf welke disk boot je (boot sequence). Heb je sectorsize override gedaan of iets anders bijzonders? Op welke controller zitten je disks?

inventaris: Server ATX

De storage disks zitten op de LSI controller, de SSD zit op de eerste SATA poort van de Z68 chipset.
Goede vraag, zou hij dan eerst die LSI disks detecteren ipv mijn SSD ...

[Verwijderd]

Oke maar hoe is je BIOS ingesteld? Dat hij eerst van de SSD boot? Dan is het wel vreemd dat dat niet werkt als je je SSD nieuw hebt geformatteerd, pool hebt gemaakt en geïnstalleerd. Dat zou gewoon moeten werken.

Kun je eens op de Disks pagina naar je SSD gaan en de bootcode controleren met beta5? Is die up-to-date? Je zou dan een groen vinkje moeten zien.

[ Voor 26% gewijzigd door Verwijderd op 12-02-2012 23:46 ]

[fluppie007]

Verwijderd schreef op zondag 12 februari 2012 @ 23:44:
Oke maar hoe is je BIOS ingesteld? Dat hij eerst van de SSD boot? Dan is het wel vreemd dat dat niet werkt als je je SSD nieuw hebt geformatteerd, pool hebt gemaakt en geïnstalleerd. Dat zou gewoon moeten werken.

Kun je eens op de Disks pagina naar je SSD gaan en de bootcode controleren met beta5? Is die up-to-date? Je zou dan een groen vinkje moeten zien.

Gezien het vroeger een windows disk was ben ik hem nu even aan het zero writen. Zou niet langer dan 20-30min moeten duren voor een 120GB SSD zou ik denken ? Zal zo nog een keer de installatie proberen en dan die bootcode checken.
Als het dan nog niet werkt zal ik eens in de BIOS spitten. Zou alleen niet weten hoe ik die LSI BIOS als 2nd boot device moet instellen .

[Verwijderd]

SSD moet je niet zero writen, maar secure erasen. Je kunt ook erase partition areas doen via de Disks pagina (geen disk aanklikken; in dat dropdown boxje). TRIM erase is wat je wilt.

Nog iets: draai je AHCI mode op je Intel controller? Je hebt niet toevallig je SSD op de Marvell controller aangesloten hè? Die had jouw mobo volgens mij wel. Verder kan ik me nog BIOS-update bedenken, maar ik zou dat pas doen als je andere dingen hebt uitgesloten.

[fluppie007]

Verwijderd schreef op maandag 13 februari 2012 @ 00:01:
SSD moet je niet zero writen, maar secure erasen. Je kunt ook erase partition areas doen via de Disks pagina (geen disk aanklikken; in dat dropdown boxje). TRIM erase is wat je wilt.

Nog iets: draai je AHCI mode op je Intel controller? Je hebt niet toevallig je SSD op de Marvell controller aangesloten hè? Die had jouw mobo volgens mij wel. Verder kan ik me nog BIOS-update bedenken, maar ik zou dat pas doen als je andere dingen hebt uitgesloten.

Staat op AHCI, en Native Mode staat enabled.

SATA Port0-3 Native Mode (Intel Z68 Chipset). Specifies the operating mode of the integrated SATA controllers.

Disabled : Allows the SATA controllers to operate in Legacy IDE mode.
In Legacy mode the SATA controllers use dedicated IRQs that cannot be shared with other device. Set this option to Disabled if you wish to install operating systems that do not support Native mode.

Enabled : Allows the SATA controllers to operate in Native IDE mode. Enable Native IDE mode if you wish to install operating systems that support Native mode. (Default)

[Verwijderd]

Wordt je SSD als 'ada' herkend of als 'ad'? Dat laatste betekent IDE/ATA terwijl 'ada' voor AHCI disks wordt gebruikt. Dus zo kun je het ook zien. Maar beide zouden bootable moeten zijn, dus ik begrijp er niet zoveel van.

Ben benieuwd wat je bevindingen zijn na een tijdje stoeien? En dingen nog even goed controleren, kan zijn dat een klein foutje zoals op een geom disk geinstalleerd te hebben, voor dit soort dingen zorgt.

[fluppie007]

Verwijderd schreef op maandag 13 februari 2012 @ 00:17:
Wordt je SSD als 'ada' herkend of als 'ad'? Dat laatste betekent IDE/ATA terwijl 'ada' voor AHCI disks wordt gebruikt. Dus zo kun je het ook zien. Maar beide zouden bootable moeten zijn, dus ik begrijp er niet zoveel van.

Als 'ada' disk. Maar booten lukt niet .

Edit:
De SSD los op de Z68 chipset werkt ( alle kabels LSI controller uitgetrokken ).
De SSD alleen op de LSI controller werkt ook.
De SSD samen met de Samsung schijven op de LSI werk niet.
De SSD op de Z68 chipset en de Samsung schijven op de LSI werkt niet.

"Missing Bootloader" is de foutmelding die ik dan krijg te zien.
Volgens mij zit er nog een bootpartitie verstopt in die Samsung schijven die er niet helemaal uit is. Zelfs na formatteren of manueel wissen van de 256kb grote boot partitie blijf ik die foutmelding krijgen... Frustratie !

[ Voor 42% gewijzigd door fluppie007 op 13-02-2012 02:21 ]

[DrFlash]

fluppie007 schreef op maandag 13 februari 2012 @ 00:25:
[...]
"Missing Bootloader" is de foutmelding die ik dan krijg te zien.
Volgens mij zit er nog een bootpartitie verstopt in die Samsung schijven die er niet helemaal uit is. Zelfs na formatteren of manueel wissen van de 256kb grote boot partitie blijf ik die foutmelding krijgen... Frustratie !

Je zal de "boot order" in de bios moeten aanpassen om de goede schijf als eerste te pakken.

[Oid]

ik heb van het weekend mijn moederbord vervangen omdat de oude wat troubles gaf. nu heb ik de laatste freebsd geinstalleerd en daarna zfsguru e.d.

Nu is mijn NFS read performance echt verschrikkkkelijk! 8 MB/s tegenover 100 MB/s wat het eerst was.

Samba performance en benchmark zijn allemaal hetzelfde gebleven, ook de Write performance is hetzelfde gebleven op NFS alleen de read performance is dus in elkaar gedonderd.

Ik heb dit getest met Crystaldiskmark 3 in een ESX 5 server 2008 machine die zijn schijf heeft op de NFS share. Voorheen Read: 108 MB/s nu 8 MB/s

Hieronder wat instellingen:

Hoop dat iemand wat kan zeggen heb al vanalles geprobeerd:

code:

Software  
Product ZFSguru 0.2.0-beta5 
Product build date 2012-Feb-12 @ 18:40 UTC 
Distribution type unknown 
System version unknown (checksum: 0) 
FreeBSD version 9.0-RELEASE 
ZFS version SPA: 28, ZPL: 5 

Hardware  
Processor Intel(R) Pentium(R) CPU G620 @ 2.60GHz 
Processor architecture amd64 (64-bit) 
Processor frequency 2200 MHz ( scales from 200 MHz to 2600 MHz )  
Memory size 7.7 GiB, of which 7.5 GiB kernel memory (307.2 GiB max.)  
Number of recognized disks 7

code:

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : tank (10.9T, 58% full)
Test size       : 64 GiB
Data source     : /dev/zero
Read throughput : 385.9 MB/s = 368 MiB/s
Write throughput: 289.1 MB/s = 275.7 MiB/s

vergelijkbaar met de vorige keer: Oid in "Het grote ZFS topic"

/etc/rc.conf

code:

hostname="nas"
ifconfig_em0="DHCP"
sshd_enable="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"

# Local services
zfs_enable="YES"
powerd_enable="YES"

# Network services
samba_enable="YES"
lighttpd_enable="YES"   # This enables the Lighttpd webserver

# NFS
rpcbind_enable="YES"
nfs_server_enable="YES"
nfsv4_server_enable="YES" #HEB IK LATER TOEGEVOEGD, GEEN VERSCHIL
nfsuserd_enable="YES"#HEB IK LATER TOEGEVOEGD, GEEN VERSCHIL
mountd_enable="YES"
mountd_flags="-r"
rpc_lockd_enable="YES"
rpc_statd_enable="YES"

# Synchronise time
ntpdate_enable="YES"
ntpdate_hosts="2.nl.pool.ntp.org"

# disable Sendmail
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
webmin_enable="YES"

code:

Interface em0
Name Value Action 
Interface name em0  
Identification Intel(R) PRO/1000 Network Connection 7.2.3  
Status active  
Link speed 1000baseT <full-duplex>  
Flags UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST  
Capabilities RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC  
MAC address 00:1b:21:b3:ad:18  
MTU 1500 bytes  
DHCP client  DHCP and other configuration planned for a future release

code:

 zpool status
  pool: tank
 state: ONLINE
 scan: scrub repaired 0 in 5h59m with 0 errors on Mon Jan 16 13:37:31 2012
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            da2p2   ONLINE       0     0     0
            da3p2   ONLINE       0     0     0
            da4p2   ONLINE       0     0     0
            da1p2   ONLINE       0     0     0
            da0p2   ONLINE       0     0     0
            da5p2   ONLINE       0     0     0
        logs
          da6p3     ONLINE       0     0     0
        cache
          da6p4     ONLINE       0     0     0

/boot/loader.conf:

code:

# enable AHCI driver
ahci_load="YES"

# tweak useful for some virtualization engines
#kern.hz="100"

# kernel memory - not required on amd64 and FreeBSD8+
vm.kmem_size="11.6g"
#vm.kmem_size_max="4096m"

# ZFS tweaks
#vfs.zfs.arc_meta_limit="512m"
vfs.zfs.arc_min="3.1g"
vfs.zfs.arc_max="4.6g"
#vfs.zfs.zfetch.array_rd_sz="16m"
#vfs.zfs.zfetch.block_cap="512"
#vfs.zfs.vdev.min_pending="4"
#vfs.zfs.vdev.max_pending="64"
vfs.zfs.prefetch_disable="1"

last but not least:

code:

zfs set sync=disabled tank/iso
zfs set sync=disabled tank/vmware

[Ultraman]

Je hebt al vanalles geprobeerd geef je aan: Wat dan? Geef dat eens aan voordat we hier gaan zitten roepen en jij alleen maar kunt zeggen "al gedaan".
Staat op je lijstje ook /boot/loader.conf tweaking ?

Want ik zie daar allerlei dingen instaan die ik op FreeBSD, met een vergelijkbaar systeem, niet nodig heb.
Zou zeer goed kunnen dat die tweaks van ZFSGuru zijn, daar weet CiPHER vast het fijne van. Die heren weten waar ze mee bezig zijn, dus zullen er vast een verklaring voor hebben. En hij zal dan ook vast met een behulpzame post komen betreffende je probleem.

Maar de vraag blijft: heb je daar al mee gespeeld?
Ik zie onder andere dat de ARC grootte zelf geregeld wordt en gelimiteerd tot 4.6GB. Wat is daar de onderbouwing voor? Niet dat het direct verkeerde tuning is op deze manier, want hij is groot genoeg om fatsoenlijk te moeten kunnen presteren.

Interessanter vind ik echter het uitschakelen van prefetching. Je hebt 8GB RAM toch? Doorgaans schakelt FreeBSD prefetching in vanaf 4GB RAM, voor zover ik weet. En ik lees her en der dat het voor reads een aardige boost kan geven. Nou is 8MB/s wel heel weinig, dus het zal vast niet alleen aan prefetching liggen.
Maar comment bij wijze van experiment eens de ARC tuning zodat deze automatisch wordt geregeld en zet vfs.zfs.prefetch_disable een op "0", waarmee je prefetch inschakeld.

sync uitschakelen op je filesystems heeft te maken met writes, tezamen met NFS async mounten op je client zou dat goede prestaties moeten geven. En die is dus goed gebleven zoals je aangeeft. Dat is in ieder geval goed.

[ Voor 13% gewijzigd door Ultraman op 13-02-2012 13:05 ]

[Oid]

ik had de prefetch eerst op 0 staan, toen was het hetzelfde ergens kwam ik tegen om die uit te schakelen dat had ik dus getest, zal het nog een keer terug zetten.

De writes zitten op de 50 MB/s

Die andere waardes heb ik zelf mee zitten spelen, maar weer teruggezet zoals ze stonden. zal de prefetch nog eens doen.

bedankt in ieder geval!

[ Voor 27% gewijzigd door Oid op 13-02-2012 13:08 ]

[Ultraman]

ik lees her en der dat vdev.max_pending ook een interessante tunable kan zijn.
En soms zie ik ook kern.minvnodes en kern.maxvnodes voorbij komen.
Die laatste twee heb ik nog nooit mee gespeeld, dus heb ik geen advies voor.

Maar vdev.max_pending zou je nog eens kunnen verlagen. Bijvoorbeeld naar 8.
Of gooi zowel min als max van die eens naar 1 en kijk wat het voor resultaat geeft, dat soort extremen aftasten kan soms wel eens inzicht geven in wat een tunable nu eigenlijk doet.
Experimenteer, dan weet je ook meteen wat het in jouw situatie doet

Ik neem hierbij wel even aan dat je backups van de data hebt, ondanks dat dit in theorie je pool niet zou slopen kun je altijd beter het zekere voor het onzekere nemen

---

Zelf trouwens twee weekjes terug eindelijk de spullen klaar om het plan wat ik al een jaar lang had uit te voeren: mijn server een beetje upgraden en herinstalleren met FreeBSD.
Na allerlei experimentjes is het er dus van gekomen en het beestje loopt nu.
Wel is er een diskje uit geknald, vrij vlot na het bouwen begon een van mijn Barracuda LPs te tikken als een malle. Na een firmware upgrade lijkt het opgelost.
Echter heeft hij tevens 394 reallocated sectors en is de performance van de disk is onder de maat, dus die gaat RMA. Wordt geDBANed met nwipe terwijl je dit leest.

[ Voor 26% gewijzigd door Ultraman op 13-02-2012 13:30 ]

[Verwijderd]

@Ultraman
Kan ook met FreeBSD:

dd if=/dev/random of=/dev/DISK bs=1m

En eventueel herhalen, maar dat is eigenlijk onzin met de huidige datadichtheid; recovery door oude sporen van magnetisering is extreem moeilijk van ruis te onderscheiden. Maargoed als je paranoid bent, draai je hem 16 keer in een scriptje of in een loop de hele nacht.

@Oid: welke scores haal je nu precies met sync=off ? Kun je je client laten mounten met -o nolock optie zodat hij local file locking gebruikt? FreeBSD 9 heeft veel NFS veranderingen als je eerst 8.2 draaide, en nieuwe defaults. Dus wellicht dat je probleem hiermee te maken heeft.

Doorgaans schakelt FreeBSD prefetching in vanaf 4GB RAM, voor zover ik weet.

Dat werkt iets subtieler. Bij minder dan 4GiB 'available' RAM krijg je een waarschuwing tijdens het booten dat prefetching standaard wordt uitgeschakeld. Heb je precies 4GiB, daar gaat daar sowieso de kernel vanaf (~30MB) en wordt prefetching dus uitgeschakeld. Heb je 5GiB dan wordt het standaard ingeschakeld, maar logischer is dan 6 of 8 gig. Dus je kunt zeggen je hebt > 4GiB RAM nodig om prefetching automatisch ingeschakeld te krijgen. Heb je minder, dan moet je het handmatig aanzetten via tuning.

Je kunt het ook zien op de System->Tuning pagina, of je genoeg RAM hebt voor prefetching. Dan krijg je een groen regeltje en hoef je dus geen tuning toe te passen. FreeBSD 9 heeft ook eigenlijk geen kmem tuning meer nodig. Het beperken van ARC is ook minder nodig, alhoewel dat wel nuttig kan zijn met een grote L2ARC of wanneer je VMs ernaast wilt gaan draaien.

Probeer eens die kmem en arc tuning met een # inactief te markeren. En test met sync=off en laat zien welke commando's je gebruikt op je client en hoe je filesystem mounted is (mount output).

[Ultraman]

Verwijderd schreef op maandag 13 februari 2012 @ 17:25:
@Ultraman
Kan ook met FreeBSD:

dd if=/dev/random of=/dev/DISK bs=1m

En eventueel herhalen, maar dat is eigenlijk onzin met de huidige datadichtheid; recovery door oude sporen van magnetisering is extreem moeilijk van ruis te onderscheiden. Maargoed als je paranoid bent, draai je hem 16 keer in een scriptje of in een loop de hele nacht.

Ik ben bekend met dd en dat is inderdaad ook een leuke methode. Maar het gaat me nu niet per se om data destructie, meer om disk stress. nwipe, gebaseerd op dban, maakt het makkelijk om random data uit te poepen en ook verify steps er tussendoor te doen. Ik wil namelijk dat de disk ook leest en zo alle sectoren getest worden. Beetje als "badblocks" uit e2fsprogs. Dat was hiervoor ook een geschikte tool geweest, maar ik had nwipe nog nooit gebruikt, dus ik dacht ik geef die eens een slinger. En ik vind het wel een handige tool.
Bereiken wat je wilt bereiken op weer eens een andere manier, zo leer je nog eens wat.

Dat werkt iets subtieler. Bij minder dan 4GiB 'available' RAM krijg je een waarschuwing tijdens het booten dat prefetching standaard wordt uitgeschakeld. Heb je precies 4GiB, daar gaat daar sowieso de kernel vanaf (~30MB) en wordt prefetching dus uitgeschakeld. Heb je 5GiB dan wordt het standaard ingeschakeld, maar logischer is dan 6 of 8 gig. Dus je kunt zeggen je hebt > 4GiB RAM nodig om prefetching automatisch ingeschakeld te krijgen. Heb je minder, dan moet je het handmatig aanzetten via tuning.

Meer dan 4GB RAM zet prefetching default aan. Prima uitleg. Ik wilde het gewoon kort houden

Probeer eens die kmem en arc tuning met een # inactief te markeren. En test met sync=off en laat zien welke commando's je gebruikt op je client en hoe je filesystem mounted is (mount output).

Eensch. Benieuwd of het helpt.

Ik ben trouwens wat aan het stoeien met powerd. Want er wordt maar 1 C-state gedetecteerd voor mijn Athlon II processor. Heeft blijkbaar te maken met het feit dat default de APIC timer wordt gebruikt waardoor FreeBSD de C1E state blokkeert en mogelijk het BIOS wat maskeert. Ik moet er nog echt in duiken en fine-tunen. Niet echt ZFS related, maar heb jij, of iemand anders, daar misschien een goede bron voor?

[FDMK]

Verwijderd schreef op vrijdag 03 februari 2012 @ 22:56:
512B (bytes) ja, dat is de standaard sectorsize, en huidige 4K sector disks emuleren 512B sectors dus je moet handmatig die override op 4K zetten. Voor native 4K sector disks hoef je niets te doen, maar die bestaan nog niet, helaas.

Optimale configuraties voor 4K sector schijven:
RAID-Z: 3, 5 en 9 disks
RAID-Z2: 4, 6 en 10 disks
RAID-Z3: 5, 7 en 11 disks

En 99% busy betekent dat je disks bottlenecked zijn. Waarschijnlijk omdat je geen optimale configuratie draait (RAID-Z met 4 disks). Je schijven moeten dan afwisselend af en toe en sector emuleren dus eerst lezen alvorens ze kunnen schrijven. Dat lezen zie je niet met gstat, want dat gebeurt intern en weet de host niets van.

Nu beta 5 de advanced disk benchmarking gefixt heeft kom ik toch wel op rare waardes als je het afzet tegen de optimale configuraties hierboven.

ZFSGURU-benchmark, version 1
Test size: 64.000 gigabytes (GiB)
Test rounds: 2
Cooldown period: 10 seconds
Sector size override: 4096 bytes
Number of disks: 4 disks
disk 1: gpt/TANK10.nop
disk 2: gpt/TANK11.nop
disk 3: gpt/TANK12.nop
disk 4: gpt/TANK13.nop


* Test Settings: TS64; TR2; CD10; SECT4096;
* Tuning: KMEM=21g; AMIN=5.6g; AMAX=8.4g; PFD=0;
* Stopping background processes: sendmail, moused, syslogd and cron
* Stopping Samba service

Now testing RAID0 configuration with 4 disks: cWmRzmId@cWmRzmId@
READ: 313 MiB/sec 320 MiB/sec = 317 MiB/sec avg
WRITE: 364 MiB/sec 369 MiB/sec = 366 MiB/sec avg
raidtest.read: 81 72 = 76 IOps ( ~5016 KiB/sec )
raidtest.write: 78 72 = 75 IOps ( ~4950 KiB/sec )
raidtest.mixed: 67 65 = 66 IOps ( ~4356 KiB/sec )

Now testing RAIDZ configuration with 4 disks: cWmRzmId@cWmRzmId@
READ: 225 MiB/sec 227 MiB/sec = 226 MiB/sec avg
WRITE: 244 MiB/sec 245 MiB/sec = 245 MiB/sec avg
raidtest.read: 63 64 = 63 IOps ( ~4158 KiB/sec )
raidtest.write: 61 62 = 61 IOps ( ~4026 KiB/sec )
raidtest.mixed: 56 58 = 57 IOps ( ~3762 KiB/sec )

Now testing RAIDZ2 configuration with 4 disks: cWmRzmId@cWmRzmId@
READ: 155 MiB/sec 158 MiB/sec = 157 MiB/sec avg
WRITE: 165 MiB/sec 165 MiB/sec = 165 MiB/sec avg
raidtest.read: 55 57 = 56 IOps ( ~3696 KiB/sec )
raidtest.write: 57 57 = 57 IOps ( ~3762 KiB/sec )
raidtest.mixed: 46 52 = 49 IOps ( ~3234 KiB/sec )

[Oid]

Verwijderd schreef op maandag 13 februari 2012 @ 17:25:
knip

code:

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :    12.260 MB/s
          Sequential Write :    53.515 MB/s
         Random Read 512KB :    17.125 MB/s
        Random Write 512KB :    44.833 MB/s
    Random Read 4KB (QD=1) :    11.811 MB/s [  2883.6 IOPS]
   Random Write 4KB (QD=1) :     2.124 MB/s [   518.6 IOPS]
   Random Read 4KB (QD=32) :   105.637 MB/s [ 25790.2 IOPS]
  Random Write 4KB (QD=32) :     2.547 MB/s [   621.8 IOPS]

  Test : 1000 MB [C: 10.8% (10.8/99.9 GB)] (x5)
  Date : 2012/02/14 0:07:02
    OS : Windows Server 2008 R2 Enterprise Edition (Full installation) SP1 [6.1 Build 7601] (x64)

ik kan niet mounten met speciale codes omdat ik een mount doe vanuit de esx vpshere console, en daar kan ik geen opties opgeven.

ik ga je verder tips proberen.

ben bang dat het idd te maken heeft met van 8.2 naar 9 maarja dan ga ik weer terug naar 8.2 want die waardes waren veel beter.

bedankt alvast, kom er nog op terug.

heb het aangepast:

code:

-----------------------------------------------------------------------
CrystalDiskMark 3.0.1 x64 (C) 2007-2010 hiyohiyo
                           Crystal Dew World : http://crystalmark.info/
-----------------------------------------------------------------------
* MB/s = 1,000,000 byte/s [SATA/300 = 300,000,000 byte/s]

           Sequential Read :    13.616 MB/s
          Sequential Write :    58.384 MB/s
         Random Read 512KB :    29.113 MB/s
        Random Write 512KB :    48.609 MB/s
    Random Read 4KB (QD=1) :    12.472 MB/s [  3044.8 IOPS]
   Random Write 4KB (QD=1) :     0.993 MB/s [   242.4 IOPS]
   Random Read 4KB (QD=32) :   106.004 MB/s [ 25879.9 IOPS]
  Random Write 4KB (QD=32) :     1.515 MB/s [   369.9 IOPS]

  Test : 1000 MB [C: 10.7% (10.7/99.9 GB)] (x5)
  Date : 2012/02/14 0:34:58
    OS : Windows Server 2008 R2 Enterprise Edition (Full installation) SP1 [6.1 Build 7601] (x64)

ik ga nog verder speuren!

[ Voor 26% gewijzigd door Oid op 14-02-2012 00:36 ]

[fluppie007]

code:

ZFSGURU-benchmark, version 1
Test size: 64.000 gigabytes (GiB)
Test rounds: 3
Cooldown period: 5 seconds
Sector size override: 4096 bytes
Number of disks: 4 disks
disk 1: gpt/StorageDisk1.nop
disk 2: gpt/StorageDisk2.nop
disk 3: gpt/StorageDisk3.nop
disk 4: gpt/StorageDisk4.nop


* Test Settings: TS64; CD5; SECT4096; 
* Tuning: KMEM=47.9g; AMIN=6.4g; AMAX=16g; 
* Stopping background processes: sendmail, moused, syslogd and cron
* Stopping Samba service

Now testing RAIDZ configuration with 2 disks: cWmRd@cWmRd@cWmRd@
READ:   92 MiB/sec  95 MiB/sec  91 MiB/sec  = 92 MiB/sec avg
WRITE:  88 MiB/sec  79 MiB/sec  74 MiB/sec  = 80 MiB/sec avg

Now testing RAIDZ configuration with 3 disks: cWmRd@cWmRd@cWmRd@
READ:   199 MiB/sec 200 MiB/sec 195 MiB/sec = 198 MiB/sec avg
WRITE:  254 MiB/sec 260 MiB/sec 231 MiB/sec = 248 MiB/sec avg

Now testing RAIDZ configuration with 4 disks: cWmRd@cWmRd@cWmRd@
READ:   298 MiB/sec 297 MiB/sec 300 MiB/sec = 298 MiB/sec avg
WRITE:  302 MiB/sec 319 MiB/sec 315 MiB/sec = 312 MiB/sec avg

Now testing RAIDZ2 configuration with 3 disks: cWmRd@cWmRd@cWmRd@
READ:   109 MiB/sec 111 MiB/sec 102 MiB/sec = 107 MiB/sec avg
WRITE:  72 MiB/sec  82 MiB/sec  68 MiB/sec  = 74 MiB/sec avg

Now testing RAIDZ2 configuration with 4 disks: cWmRd@cWmRd@cWmRd@
READ:   222 MiB/sec 220 MiB/sec 222 MiB/sec = 221 MiB/sec avg
WRITE:  245 MiB/sec 196 MiB/sec 251 MiB/sec = 231 MiB/sec avg

Topwaarde is RAIDZ met 4 disks @ 312 MiB/s write en 298 MiB/s read ? Dat is een 'niet geoptimaliseerde pool' en toch geeft die de beste resultaten ?

[Verwijderd]

Dat is niet zo vreemd, want je hebt een disk extra om data te verwerken.

Kijk eens naar de RAID-Z van 3 disks met 248MB/s write. Dat is heel hoog omdat je maar effectief 2 disks kunt gebruiken, dus bijna 125MB/s per disk. Ga je naar 4 disks dan zie je maar een kleine toename in de writes; maar wel een toename in de reads waarbij het sectorprobleem minder groot is. Immers bij het schrijven van een gedeelte van een 4K sector moet de hardeschijf intern die sector eerst inlezen voordat hij hem kan overschrijven, om zo de oude en nieuwe data te migreren. Dit is de sectorsize emulatie die de schijf verricht. Alleen hedendaagse 4K Advanced Format hardeschijven werken zo.

Zou je naar 5 disks RAID-Z gaan, dan zou je een veel grotere toename moeten zien bij met name de writes. Ook bij RAID-Z2 zie je dat de optimalisatie klopt. Bij 3 disks een lage write maar bij 4 disks wel 231MB/s. Met slechts effectief 2 schijven beschikbaar voor write is dat dus ook ongeveer ~125MB/s dus uitstekend.

Wel zie ik dat je snelheden best schommelen, voor een echt nauwkeurige meting moet je het aantal test runs hoger maken dan 3. Aan de andere kant, het gaat om een indicatie van performancetrends en die kun je zo goed waarnemen en dat kan helpen je te beslissen welke pool configuratie je gaat draaien.

[fluppie007]

Na de advanced benchmark onder ZFS guru 0.2 beta5

Ik zal vermoedelijk voor 9 disks in RAID-Z gaan. 5 disks zijn nieuw en kan ik gelijk mee starten. De andere 4 kan ik pas gebruiken na het overpompen van de data. Dat is dan een pool met 5 echte en 4 memory disks ?

Vb. van een echte disk: da0 GPT: StorageDisk1 2 TB 1.8 TiB 4 KiB <ATA SAMSUNG HD204UI 0001>

Memory disks, 4K Sector en 1.8 TiB groot ? Welke memory backing ?
Dan data overpompen, memory disks deleten en de 4 nieuwe toevoegen ?

[ Voor 59% gewijzigd door fluppie007 op 14-02-2012 09:38 ]