Het grote ZFS topic

[]Byte[]

Heeft er misschien iemand ervaring met het flashen van een M1015 op een GigaByte G1 Sniper 3 board?

Zodra ik een 'megarec -writesbr 0 sbrempty.bin' doet, krijg ik de melding:

Warning! IO Base address high. Currently not supported

No MR controller(s) found.

(deze gevolgd)
ik had een link gevonden die de 'oplossing' had om in een ander PCIe slot te prikken... maar dat werkt bij mij dus niet

[ Voor 14% gewijzigd door ]Byte[ op 25-10-2013 10:06 ]

[FireDrunk]

Bij sommige borden heb je gewoon pech, daar werkt het niet. De G1 Sniper zal er daar wel een van zijn...

[]Byte[]

Dan zal ik een ander bordje moeten gaan halen...

Is er ergens een overzicht van borden waarbij het nog meer niet werkt?

Dacht een mooi bordje te hebben voor voldoende geheugen, PCIe slots, onboard GPU en twee NIC's. (én dat ik ergens gelezen had dat je het best een 7x-chipset board kon gebruiken)
Niet dus...

[ Voor 15% gewijzigd door ]Byte[ op 25-10-2013 10:58 ]

[syl765]

Is het niet handiger om even rond te kijken of vragen wie er een boardje heeft waar het misschien wel in werkt.
Flashen doe je niet zo vaak en om nu een heel nieuw board aan te schaffen alleen voor het flashen is ook zo wat.

gr
Johan

[HyperBart]

Kort vraagje.

Ik dacht dat het volgende mogelijk was met ZFS:

Je hebt een disk die early warnings geeft van falen, je koopt een vervanger.

Is het dan een handig idee, om alle data van die falende disk over te kopieren met dd naar de nieuwe disk, de nieuwe disk in de array te plempen en te laten scrubben? Ik redeneer: de disk heeft dezelfde data, als een ANDERE disk in de array tijdens de scrub/resilver een probleem detecteert, heeft de vervanger misschien nog de originele data.

Of is dit nu kletskoek?

Wie kan er een verhaaltje rond bakken?

[Xudonax]

Ik heb met een falende schijf gewoon de schijf eruit getrokken en toen ik een vervanger had die erin gestoken. Werkt an sich gewoon goed. Ik denk dat als je doet wat jij zegt, en je gebruikt een GPT partitietabel, dat ZFS/het OS het verschil tussen de schijven niet gaat zien. En wat er dan gebeurd is een groot raadsel (voor mij iig)

[Verwijderd]

Dat moet je dus nooit doen omdat unique identifiers uniek horen te zijn. En als je systeem twee schijven ziet met dezelfde GUID weet ik niet precies hoe dat gaat reageren. Ik weet van Windows dat schijven met een ruwe NTFS 1:1 kopie onzichtbaar worden gemaakt, of dat voor beide schijven (cloons) geldt weet ik niet.

Maar ruw 1:1 kopie moet je nooit doen behalve voor datarecovery enzo. Je moet ZFS de schijf laten vervangen. Die kan het dan het beste en controleert tegelijk de integriteit tijdens het rebuilden (resilveren). Stel je overige disks hebben allemaal fouten op één punt dan kan de disk die je vervangt (en straks geen onderdeel meer is van de pool) dan nog steeds data aanleveren tijdens het resilver proces. Kortom, ZFS resilvert heel slim en je moet het gewoon op die manier doen. Op jouw manier ben je ZFS om de tuin aan het leiden en dat heeft alleen maar nadelen voor zover ik kan zien.

Tenzij je pool helemaal vol is, is het ook sneller om ZFS te laten resilveren omdat die niet alle data maar alleen in gebruik zijnde data gaat resilveren. Dus een pool voor 20% vol betekent ongeveer 5 keer snellere resilvertijd.

[]Byte[]

Oke... weer een paar stappen verder. Maar...

megarec -writesbr 0 sbrempty.bin
megarec -cleanflash 0

zijn beide goed gegaan.
Na de reboot...
netjes naar de 3e stap....

sas2flsh -o -f 2118it.bin -b mptsas2.rom

En toen....

ERROR: Failed to initialize PAL. Exiting program

Een beetje google doet wonderen... schijnt soms voor te komen met bepaalde borden (waarom ik nu weer)
1 van de mogelijk oplossingen... ander bord... heb ik niet
andere oplossing, via de UEFI

Ik naar de UEFI toe... krijg ik de melding: No LSI SAS adapters found!

Iemand nog een goed idee?

[Verwijderd]

Pak een ander mobo? Als je zelf maar één systeem hebt kun je bij vrienden/kennissen proberen. Prop je controller even in een ander systeem en flashen en klaar.

In andere systemen werkt het weer wel zoals het hoort. Dat flashen via DOS blijft natuurlijk een beetje irritant. Ik zou er niet teveel mee kutten en gewoon een ander mobo pakken totdat het werkt.

Overigens: je hoeft niet persé de boot ROM te flashen. Bij het commando laat je dit dan weg. Dan wordt je controller volgens mij niet meer tijdens de BIOS/POST herkend maar alleen in je operating system. Dat voorkomt nog wat issues en is sneller, maar je verliest dan boot support via de controller.

[syl765]

@ hyperbart.

Wij hebben een pool bestaande uit gespiegelde vdevs..
Toen wij zagen dat 1 van de schijven errors begon te vertonen hebben we een nieuwe disk aan deze vdev gekoppeld.
zpool attach poolnaam gpt/disk-zonderproblemen gpt/disk-nieuw.
Je maakt dan eigenlijk tijdelijk een 3-way mirror.
Zfs gaat dan zelf de disk spiegelen en toen deze klaar was hebben we de falende disk verwijdert.
Zo hebben we voorkomen dat de vdev in een degraded state kwam.

Ik denk alleen dat het niet werkt met een raidz(x) vdev.
Volgens mij kun je niet een disk aan een disk van een raidz vdev koppelen
Aangezien wij alleen met mirrors werken heb ik dit nog nooit geprobeerd.


@ }BYTE{
Als je in de buurt van Uitgeest woont, kun je even langskomen.
Ik gebruik altijd een oude ML 150 om dit te doen.

gr
Johan

[ Voor 8% gewijzigd door syl765 op 25-10-2013 14:59 ]

[HyperBart]

Verwijderd schreef op vrijdag 25 oktober 2013 @ 13:59:
Maar ruw 1:1 kopie moet je nooit doen behalve voor datarecovery enzo. Je moet ZFS de schijf laten vervangen. Die kan het dan het beste en controleert tegelijk de integriteit tijdens het rebuilden (resilveren). Stel je overige disks hebben allemaal fouten op één punt dan kan de disk die je vervangt (en straks geen onderdeel meer is van de pool) dan nog steeds data aanleveren tijdens het resilver proces. Kortom, ZFS resilvert heel slim en je moet het gewoon op die manier doen. Op jouw manier ben je ZFS om de tuin aan het leiden en dat heeft alleen maar nadelen voor zover ik kan zien.

Oh dus tijdens een replace is ZFS zo intelligent om de spindle die vervangen wordt toch nog te gebruiken als er problemen zijn met een andere disk op de array?

[]Byte[]

Verwijderd schreef op vrijdag 25 oktober 2013 @ 14:54:
Pak een ander mobo?

Al gedaan... In de Gigabyte G1.Sniper 3, deed ie het helemaal niet.
En in de andere PC (MSI Z77A-G43) wilde hij wel clearen, maar na de reboot werd ie niet meer gevonden.
Net ff bij mijn lokale computerboer langs geweest.
Daar gingen in ieder geval de LED's weer branden (wat bij de MSI ook niet gebeurde na de reboot hmmm, dat was de controller die ik nog niet geflashed had...), maar de sas2flsh blijft zeuren dat ie geen controller kan vinden.
(ook niet met de -list)

[ Voor 5% gewijzigd door ]Byte[ op 25-10-2013 16:29 ]

[Verwijderd]

HyperBart schreef op vrijdag 25 oktober 2013 @ 15:46:
[...]


Oh dus tijdens een replace is ZFS zo intelligent om de spindle die vervangen wordt toch nog te gebruiken als er problemen zijn met een andere disk op de array?

Zeker! Je ziet ook in de zpool status output dat in plaats van de oude disk er een nieuwe 'disk' bij is gekomen:

code:

Replacing
  /dev/ada4 (resilvering)
  /dev/ada5

In dit geval is /dev/ada5 de oude disk, die nog steeds onderdeel is van de zpool configuratie totdat het replacen is voltooid. Daarna neemt ada4 de plek in van ada5.

Op dezelfde manier gebeurt het als je een RAID0/stripe disk wilt replacen. Dan heeft hij natuurlijk wel de originele disk nodig. Maar op deze manier een RAID-Z rebuilden/replacen is natuurlijk véél veiliger omdat je tijdens het rebuilden nog gewoon volledige redundancy hebt. Traditioneel RAID5 betekent dat je bij het verwisselen van een disk degraded draait en dus ook gelijk risico loopt zoals bij bad sectors op de overige schijven. ZFS is natuurlijk superieur.

[Pantagruel]

HyperBart schreef op vrijdag 25 oktober 2013 @ 12:24:
Kort vraagje.

Ik dacht dat het volgende mogelijk was met ZFS:

Je hebt een disk die early warnings geeft van falen, je koopt een vervanger.

Is het dan een handig idee, om alle data van die falende disk over te kopieren met dd naar de nieuwe disk, de nieuwe disk in de array te plempen en te laten scrubben? Ik redeneer: de disk heeft dezelfde data, als een ANDERE disk in de array tijdens de scrub/resilver een probleem detecteert, heeft de vervanger misschien nog de originele data.

Of is dit nu kletskoek?

Wie kan er een verhaaltje rond bakken?

Ik heb het in t verleden wel eens voor de lol getest, maar uiteindelijk duurde de dd/dd_rescue langer dan de het resilvering proces met een verse disk in de array. (Ik moet eerlijkheidshalve wel zeggen dat de dd/dd_rescue op een oude Athlon XP werd gedaan, terwijl de resilver op een C2D 6600 liep)

[]Byte[]

syl765 schreef op vrijdag 25 oktober 2013 @ 14:56:
@ }BYTE{
Als je in de buurt van Uitgeest woont, kun je even langskomen.
Ik gebruik altijd een oude ML 150 om dit te doen.

Lol... tnx!
106 km is niet echt 'in de buurt' te noemen...
Goeie tip... Dat is waar ook. Ik heb nog een ML110 in de hoek staan... Ik kan eens kijken of het me daarmee gaat lukken.
Als het dan nog niet lukt, kan ik eventueel van de week eens kijken als ik op mijn werk in A-dam zit. Daar vandaan is het een stuk korter bij.

[FireDrunk]

Omg Arnhem hier. Ook genoeg hardware liggen.

[Ultimation]

Ik ben op dit moment bezig met het upgraden van mijn ESXi server. Onderdeel daarvan is een nieuwe controller + harde schijven. Ik ben nu bezig de basis opnieuw te configureren en weldra de harde schijven binnen zijn alle data van de oude schijven over te zetten naar de nieuwe. Op dit moment gebruik ik NAS4Free en heb daar niet echt klachten over. Wat ik het fijne vind aan NAS4Free vergeleken met FreeNAS is dat de interface simpeler is, het naar mijn idee stabieler draait en NAS4Free veel verder voorruit is dan FreeNAS. De interface van NAS4Free is dan nog wel niet zo simpel als de interface van ZFSGuru.

Affijn ik sta dus voor de keuze. Ik zou nu (makkelijk) over kunnen stappen naar een ander ZFS platform. Ik zou best willen overstappen naar ZFSGuru alleen ik ben nog niet helemaal overtuigd van ZFSGuru. Ik ben fan van de eenvoudige manier van beheren onder ZFSGuru. Onder NAS4Free zit ik soms te klooien met het rechten systeem. Dan heeft de user die ik gebruik voor mijn datasets "ineens" geen rechten meer op de datasets en moet ik dat opnieuw instellen. Daarin tegen vind ik de mogelijkheden tot het aanleggen van aparte accounts onder ZFSGuru weer beknopt. Alles is altijd maar open en direct zichtbaar (wat in een hoop gevallen ook handig is).

Ik zoek eigenlijk een paar voor en tegens aangaande mijn afweging over ZFSGuru en NAS4Free.

[Verwijderd]

Het is best een makkelijke keuze denk ik: NAS4Free en FreeNAS zijn meer uitontwikkeld, volwassener, meer features. ZFSguru is gemakkelijker in het gebruik en doet dingen meer 'vanilla' dan de overige twee projecten; die Nieuwe versie van ZFSguru

Rechten (permissies) is altijd een lastig punt bij een NAS vooral als je meerdere protocollen gebruikt. Maar zeker in de nieuwe versie van ZFSguru is dat sterk verbeterd met drag-and-drop interface waarbij je users, groepen en wachtwoorden/permissies per share kunt instellen. Maar die versie moet je nog zeker tot december voor wachten.

Voor de rest is het denk ik vooral veel voorkeur. ZFSguru heeft een bepaalde structuur van pagina's en bepaalde logica. FreeNAS en NAS4Free hebben weer hun eigen stijl. Het moet je ook goed liggen dus. Er is geen één beste project voor iedereen. Bovendien veranderen de projecten dus het kan zijn dat nu NAS4Free voor jou beter is en pas als de nieuwe rechtenstructuur er is dat ZFSguru dan beter is, bijvoorbeeld.

Gewoon zelf uitproberen en vaak geldt ook: als het goed werkt lekker zo laten. Als je nu goede ervaringen hebt met NAS4Free moet je dat ook laten meetellen.

[]Byte[]

syl765 schreef op vrijdag 25 oktober 2013 @ 14:56:
Ik gebruik altijd een oude ML 150 om dit te doen.

Geniaal! Met mijn ML110 werkt het in 1 keer!
Ik was al beetje bang dat ie gebricked was.
Ik heb ze nu op fw P17 draaien!
Nu nog ff ZFSguru er goed op raggen (heb er ook al 2 SSD'd in zitten - 120 GB Vertex3 en een 128 GB Samsung 840), en heb ik weer een een stukje opslag met 10 * 4 TB in RAID-Z2

[ Voor 33% gewijzigd door ]Byte[ op 26-10-2013 14:27 ]

[dere12]

Ik heb net de startpost gelezen en ben onder de indruk van ZFS. Nu sta ik op het punt om een Synology NAS te kopen (2-bay / Raid 1) en vroeg ik me af of voor een veilige backup het dan gebruikelijk is om een brazos / kabini systeem met ZFS ernaast te hebben?

Nu is mijn Raid-1 mijn feitelijke "backup" voor mijn digitale archief...

[Kortfragje]

BAGGER!

Draaide net een smart short test na het moederbord vervangen te hebben en Ubuntu opnieuw geinstalleerd te hebben.. helemaal happy totdat...

tik...zoem...tik...zoem... -->Disk fail..

niet getreurd tot op heden want RaidZ2, dus morgen een nieuwe disk halen en erin zetten (net uitgezet, hoeft niet online te blijven).

Ik had echter nog wel een vraagje wat de beste methode is, de disk is faulted / weg (wordt niet meer gedetecteerd door het moederbord). Ik gebruik aliassen die gedefinieerd zijn in /etc/zfs/vdev_id.conf. De faulted disk is 2tb4, een nieuwe disk zal dan 2tb6 worden.


Nu lees ik dat de procedure is:

1 zpool offline zfspool 2tb4

2 fysiek vervangen van de disk (ik heb geen hotswap, dus machine moet uit..)

3 zpool replace zfspool 2tb4 2tb6

Klopt dat / kan dat? of is het verstandiger beide disks in de machine te hebben ten tijde van de replace en daarna te verwijderen?

[Compizfox]

Neuh, zou prima moeten werken wat jij beschrijft.

De oude disk wordt niet meer gezien door je HBA, dus kun je hem net zo goed eruit halen. Dat zou niets uit mogen maken.

[Durandal]

dere12 schreef op zaterdag 26 oktober 2013 @ 21:45:
Ik heb net de startpost gelezen en ben onder de indruk van ZFS. Nu sta ik op het punt om een Synology NAS te kopen (2-bay / Raid 1) en vroeg ik me af of voor een veilige backup het dan gebruikelijk is om een brazos / kabini systeem met ZFS ernaast te hebben?

Nu is mijn Raid-1 mijn feitelijke "backup" voor mijn digitale archief...

Als je veilig wilt zou ik het andersom doen; ZFS primair, en daarnaast iets voor de backups. Je Synology kan last van bitrot hebben en dan weet hij niet welke disk nu de goede is.

[Verwijderd]

dere12 schreef op zaterdag 26 oktober 2013 @ 21:45:
Ik heb net de startpost gelezen en ben onder de indruk van ZFS. Nu sta ik op het punt om een Synology NAS te kopen (2-bay / Raid 1) en vroeg ik me af of voor een veilige backup het dan gebruikelijk is om een brazos / kabini systeem met ZFS ernaast te hebben?

Nu is mijn Raid-1 mijn feitelijke "backup" voor mijn digitale archief...

Als je Synology fijn vindt werken maar je wilt toch de veiligheid van ZFS, dan kun je Synology en ZFS inderdaad combineren. Je kunt de kosten van een ZFS server heel laag houden, zeker met een Kabini systeem, al duurt dat nog even voordat bordjes met deze SoC-chip op de markt komen. Intel is nu net iets eerder met de nieuwe Bay Trail Atom processoren.

Kortfragje schreef op zondag 27 oktober 2013 @ 00:05:
Ik had echter nog wel een vraagje wat de beste methode is, de disk is faulted / weg (wordt niet meer gedetecteerd door het moederbord).
(..)
Klopt dat / kan dat? of is het verstandiger beide disks in de machine te hebben ten tijde van de replace en daarna te verwijderen?

Het is normaliter beter om de 'foute' schijf in je systeem te hebben als deze nog wel functioneert, maar bijvoorbeeld teveel bad sectors heeft. ZFS kan dan de redundancy van deze schijf gebruiken ook al is de schijf voor de helft corrupt. Echter, bij jou wordt de schijf niet meer gedetecteerd dus dat voordeel valt weg, bovendien heb je RAID-Z2 waardoor je tijdens het rebuilden nog gewoon redundantie hebt.

[Kortfragje]

Hmm so far so good...

Alias werkte idd niet.. maar het ziet er ok uit..

code:

root@gertdus-server:~# zpool status
  pool: zfspool
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
    continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
  scan: resilver in progress since Sun Oct 27 13:23:55 2013
    25.2G scanned out of 7.14T at 233M/s, 8h54m to go
    5.04G resilvered, 0.34% done
config:

    NAME                                             STATE     READ WRITE CKSUM
    zfspool                                          DEGRADED     0     0     0
      raidz2-0                                       DEGRADED     0     0     0
        2tb1                                         ONLINE       0     0     0
        2tb2                                         ONLINE       0     0     0
        2tb3                                         ONLINE       0     0     0
        replacing-3                                  UNAVAIL      0     0     0
          2tb4                                       UNAVAIL      0     0     0
          scsi-SATA_WDC_WD20EFRX-68_WD-WCC300687955  ONLINE       0     0     0  (resilvering)
        2tb5                                         ONLINE       0     0     0

errors: No known data errors

  pool: zfspool2
 state: ONLINE
  scan: scrub repaired 0 in 1h6m with 0 errors on Mon Oct 14 18:56:30 2013
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool2    ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        1tb1    ONLINE       0     0     0
        1tb2    ONLINE       0     0     0

errors: No known data errors

[FREAKJAM]

Mijn Bitfenix Phenom Micro Atx gister ontvangen en gekeken hoeveel hdd's erin passen:



Kan maximaal 5 3.5" schijven kwijt. Ik denk dat ik nu voor 5x3TB 4x4TBga in RAIDZ2. Die 5de hdd daar bovenin is niet zo praktisch.

[ Voor 25% gewijzigd door FREAKJAM op 27-10-2013 16:17 ]

[Habana]

Het grote ZFS topic

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

Mijn vergelijkbare ZFS doos om je een idee te geven:
http://i1260.photobucket..../IMG_0725_zps3794c8d1.jpg

[ Voor 25% gewijzigd door Habana op 27-10-2013 16:06 ]

[Mystic Spirit]

Na een hoop testen ben ik zover dat ik een ZFS server in ga zetten voor mijn dagelijkse opslag. Momenteel draai ik nog een 5 bay Synology NAS voor mijn dagelijkse opslag met 5x2Tb in RAID5. Nu wil ik een toekomstbestendige HDD configuratie kiezen voor mijn nieuwe file server. Hierbij zit ik vooral met de vraag wat een verstandige start is voor als ik in de toekomst meer opslag nodig heb.

De situatie is als volgt:

Huidige Synology NAS:

#	Product	Prijs	Subtotaal
5	Seagate Barracuda Green ST2000DL003, 2TB	€ 0,-	€ 0,-
1	Synology Disk Station DS509+	€ 0,-	€ 0,-
Bekijk collectie Importeer producten		Totaal	€ 0,-

De Synology heeft effectief ongveer 7,2TB aan ruimte waarvan nu ongeveer 7TB in gebruik is. De NAS is inmiddels zo'n 4 jaar oud en ik ben door de jaren heen van 500GB schijven naar 1TB naar 2 TB gegaan. Ik ben dus weer toe an een upgrade aangezien mijn ruimte weer op begint te raken.

In de nieuwe situatie (ook al vaker in dit topic gedeeld) komt het geheel in een VM (ESXi) die nu de volgende specs heeft:

#	Product	Prijs	Subtotaal
1	Intel Core i5 3470 Boxed	€ 162,10	€ 162,10
1	MSI B75MA-P45	€ 53,80	€ 53,80
1	Seagate Barracuda 7200.14 ST2000DM001, 2TB	€ 73,86	€ 73,86
1	Chieftec Mesh CT-01B	€ 43,94	€ 43,94
1	Corsair Vengeance CMZ16GX3M2A1600C9	€ 152,30	€ 152,30
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 118,58	€ 118,58
1	Samsung 840 series Pro 256GB	€ 194,50	€ 194,50
Bekijk collectie Importeer producten		Totaal	€ 799,08

Nu zit ik met het dilemma hoe ik het beste mijn ZFS file server kan gaan configureren qua HDD's met daarbij in gedachte houdend dat ik veilig wil kunnen uitbreiden en de wet van More ongeveer van toepassing is op mijn datagebruik Hierbij vind ik dat t/m 5 schijven RAID-Z voldoende is, maar daar boven moet het toch wel RAID-Z2 worden.

Door de IBM HBA ben ik beperkt tot 8 poorten en houd ik volgens mij maar twee plausibele mogelijkheden over namelijk:

• 2 vdevs in RAID-Z een vdev van 3 en een vdev van 5 schijven (al dan niet om te smelten tot 1 pool)
• 1 vdev in RAID-Z2 van 8 schijven

Een eventuele derde mogelijkheid zou zijn om een vdev te maken van 7 schijven in RAID-Z, maar zoals gezegd lijkt me dat niet zo verstandig. Of zetten jullie wel vdevs van 7 schijven met maar 1 parity disk in?

Ik neig nu naar beginnen met een vdev van 5 x 4Tb schijven in RAID-Z. Daarmee verdubbel ik mijn huidige opslagcapaciteit naar 16TB en kan ik weer even vooruit. In de toekomst zou het upgrade pad dan zijn te wachten op 8TB schijven (als die er komen) en daar een 3 disk RAID-Z vdev van te maken en alle data erheen kopieren en vervolgens een nieuwe 5 disk vdev en de boel weer terug. Eventueel kan ik dan ondertussen nog 3 van mijn oude schijven daarnaast inzetten voor testdoeleinden.
Andere mogelijkheid is een vdev van 8 x 3TB disks (is goedkoper in aanschaf €/GB) Daarmee komt mijn effectieve opslag op 18TB. Het upgrade pad in de toekomst zou dan zijn om 1 voor 1 disks te vervngen voor een grotere capaciteit en iedere keer de vdev te laten herstellen terwijl ik toch nog 1 parity disk over heb. Dat betekent wel dat ik geen ruimte meer heb om mijn huidige schijven te hergebruiken.
Het liefst zou ik een pad kiezen waarbij ik mijn huidige schijven zou kunnen hergebruiken, maar daar zie ik geen mogelijkheden toe waarbij ik ook nog extra capaciteit overhoud met minimale investering. Er zijn immers 5 schijven in gebruik voor de productie en ik heb er slechts 1 over die nu in de VM zit voor testdoeleinden.

Wat denken jullie dat de beste keuze is?
PS: Ik weet dat 8 schijven niet standaard in de huidige case gaan passen Daar zoek ik nog een oplossing voor. Andere suggesties m.b.t. het systeem zijn uiteraard ook welkom, maar wil het hier toch zoveel mogelijk ZFS gericht houden.

[FREAKJAM]

Ah indeed. 4 disks is beter voor RAIDZ2. Ik heb trouwens de nieuwe Micro Atx variant, daar kan ik de hdds niet zo mooi onder elkaar ordenen als bij jou. Nice setup! Ook erg tof die watercooling

[ Voor 10% gewijzigd door FREAKJAM op 27-10-2013 16:22 ]

[Habana]

[quote]Mystic Spirit schreef op zondag 27 oktober 2013 @ 16:14:

Door de IBM HBA ben ik beperkt tot 8 poorten en houd ik volgens mij maar twee plausibele mogelijkheden over namelijk:
[list]

Je hebt toch ook nog je vijf Sata poorten van je mobo + je acht van je IBM HBA maakt 13 in totaal, heb je toch al wat meerdere mogelijkheden, toch?

@mannen onder Aha weer wat geleerd....

[ Voor 5% gewijzigd door Habana op 27-10-2013 17:13 ]

[FireDrunk]

Hij gebruikt ESXi, daardoor valt de onboard controller af.

[ Voor 54% gewijzigd door FireDrunk op 27-10-2013 16:52 ]

[Mystic Spirit]

Ik gebruik ESXi inderdaad waardoor de onboard controler afvalt. Anders was ik met zekerheid voor de 5x 4TB gegaan omdat ik er dan makkelijk nog eens 5 en 3 naast kon prikken. Dat zit er helaas niet in.

Blijven mijn 2 andere opties over....

Edit (extra optie):
Ik zit net te denken. Ik kan ook een vdev maken op 4 x 4TB schijven met partities van 2TB en een 2TB schijf erbij voor een 5 disk RAID-Z. Dan zou er genoeg ruimte zijn om mijn huidige data over te zetten. Vervolgens prik ik er nog eens 3 x 2TB schijven bij (die uit mijn NAS komen) en maak een RAID-Z2 vdev erbij van dezelfde grote. Vervolgens kopieer ik de data van de ene vdev naar de ander en bouw een nieuwe Z2 vdev op en voeg deze toe aan de pool van de andere Z2 vdev.

Op die manier heb ik een goede redundante setup. Hoef ik maar 4 schijven aan te schaffen. Kan ik 4 schijven uit mijn huidige setup hergebruiken en heb ik toch een verdubbeling van capaciteit.

Hoe klinkt dat jullie in de oren? Is dat een verstandige keuze?

[ Voor 61% gewijzigd door Mystic Spirit op 27-10-2013 17:25 ]

[sphere]

Habana schreef op zondag 27 oktober 2013 @ 15:57:
Het grote ZFS topic

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

Mijn vergelijkbare ZFS doos om je een idee te geven:
http://i1260.photobucket..../IMG_0725_zps3794c8d1.jpg

Welke case is dat?

[ESteg]

sphere schreef op zondag 27 oktober 2013 @ 18:06:
[...]

Welke case is dat?

Een pricewatch: BitFenix Prodigy Zwart, als ik het goed zie.

[Habana]

sphere schreef op zondag 27 oktober 2013 @ 18:06:
[...]

Welke case is dat?

FYI, Bitfenix Prodigy met twee maal Lian-Li EX-H33 gestapeld.

[FREAKJAM]

Ik heb nu toch echt mijn configuratie compleet. Nu nog de juiste distro kiezen. Op dit moment heeft FreeNAS als enige een Plex plugin beschikbaar. Zou toch heel graag ZFSGuru willen proberen.

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1230 V3 Boxed	€ 214,-	€ 214,-
1	Supermicro X10SL7-F	€ 229,60	€ 229,60
4	WD Green WD40EZRX, 4TB	€ 150,10	€ 600,40
1	Sandisk Extreme USB 3.0 Flash Drive 16GB Zwart	€ 22,-	€ 22,-
2	BitFenix Spectre All White, 120mm	€ 5,19	€ 10,38
1	Kingston ValueRAM KVR16E11K4/32	€ 299,-	€ 299,-
1	Seasonic G-Serie 360Watt	€ 57,-	€ 57,-
1	Crucial 2.5" M500 240GB	€ 133,49	€ 133,49
1	Intel DC S3500 (2,5") 80GB	€ 91,95	€ 91,95
Bekijk collectie Importeer producten		Totaal	€ 1.657,82

[ Voor 229% gewijzigd door FREAKJAM op 27-10-2013 21:09 ]

[]Byte[]

Yesssss.... Heb net ZFSguru geïnstalleerd, en loopt als een zonnetje.
Gelijk maar 9.2 er opgezet!
Maar nu even de vraag die ik heb:
Ik heb 16GB in die box zitten, en 10 * 4 TB in RAID-Z2
Wat is de 'beste performance tuning' die ik aan zou kunnen zetten?
Ik heb 'm nu staan op: Performance tuning - use most of RAM + prefetch

[ISaFeeliN]

Tussen neus en lippen door.. FreeBSD 10.0 (waarvan nu de beta1 uit is), heeft ook flink wat toevoegingen in de installer gekregen. Vanuit de installer kan nu direct voor (boot from) ZFS gekozen worden, je kunt stripes maken, mirror, raidz1, z2 en z3, en dat allemaal met of zonder GELI encryptie. Vette hap!

[Verwijderd]

Nieuwe release: ZFSguru 9.2-001

Nog niet aangekondigd maar al wel te downloaden: ZFSguru met 9.2-001 systeemversie. Nieuw in deze release is onder andere ZFS v5000 en nieuwe/updated services. En natuurlijk gebaseerd op de nieuwe FreeBSD 9.2 final release.

Downloaden:

• ZFSguru 9.2-001 LiveCD (337MB)
• ZFSguru 9.2-001 LiveCD met grafische omgeving (Gnome) (605MB)
• ZFSguru 9.2-001 LiveCD met grafische omgeving en moderne KMS drivers voor Intel GPUs (603MB)

Update: merk op dat de grafische LiveCD niet kan worden gebruikt om de grafische services te installeren op je pool; die moet je alsnog los downloaden via de web-interface en kunnen dus niet van de LiveCD worden geplukt. Geef je niets om testen en wil je voor het echt installeren, kun je dus prima de normale .iso pakken zonder grafische interface; ook al wil je die wel installeren op je server. Dat doe je dan gewoon na de installatie, zodra je de LiveCD niet meer gebruikt.

@FREAKJAM: deze versie heeft ook een Plex service addon. Met web-panel interface.

[ Voor 22% gewijzigd door Verwijderd op 27-10-2013 22:26 ]

[FREAKJAM]

CiPHER, held!
Kijk er nu al uit om het te installeren in ESXi. Wat raad je aan, met of zonder Gnome?

[ Voor 67% gewijzigd door FREAKJAM op 27-10-2013 22:00 ]

[FireDrunk]

@CiPHER, is PHP eindelijk geupdate?

[Verwijderd]

PHP? Euh, 5.4.21. Op wat voor update wacht je dan? 5.5? Meestal is het geen slecht idee om de voorgaande stable branch te draaien, idem met netatalk/mysql/samba en mogelijk nog meer software. Maar binnenkort misschien wel over op 5.5. Maar er is altijd kans op breakage met die grote releases; net zoals 5.4 ook de AjaxPlorer al om zeep had geholpen, die nog wel werkte onder PHP 5.3.

[FireDrunk]

Mja, misschien dat ik idd nog in mijn hoofd zat met PHP5.3.

Ik weet nog dat ik een ZFSguru update deed vanaf de portstree, en toen sloopte ik heul veul

[Verwijderd]

Kan opzich wel. Er is nu de System-Portstree-Latest service die via portsnap dus wordt gedownload. Dan heb je de nieuwste portstree. Daarna zou je alle ports moeten updaten voordat je nieuwe dingen gaat installeren, omdat anders je problemen krijgt dat hij nieuwere dependencies nodig heeft en je oudere versies hebt geïnstalleerd.

Nadat je ports hebt geupdate, kan het zijn dat services via ZFSguru niet meer goed installeren. Dus je kunt het beste eerst alle ZFSguru services downloaden en installeren die je wilt, dan pas ports updaten en dan niets meer veranderen qua ZFSguru services. Zo doe ik het in elk geval.

Want mijn machines draaien ook niet de laatste versie. Ik ben voor mijn backup machines ook heel conservatief. Lekker een oude versie met wat custom scripts. Werkt allemaal prima, weinig reden om te updaten. Mijn live servers (2) heb ik wel meestal op de nieuwste versie draaien.

[GioStyle]

Habana schreef op zondag 27 oktober 2013 @ 18:31:
[...]


FYI, Bitfenix Prodigy met twee maal Lian-Li EX-H33 gestapeld.

Nice! Heb je daar veel voor moeten modden?

[FREAKJAM]

TLER heb je alleen nodig voor 'slechte' RAID engines. Dat betekent dat voor software RAID of ZFS onder een non-Windows operating system, je geen TLER nodig hebt. Echter, dit gaat alleen op als je zoals jij inderdaad chipset SATA (HBA) dus zonder RAID chip gebruikt.

Als je FakeRAID gaat gebruiken of Hardware RAID heb je TLER nodig en dan zijn de Greens in principe ongeschikt, dat kun je allemaal nalezen op dit forum.

Aangezien ik wil gaan voor een X10SL7 met een LSI2308, zijn de WD Greens geen optie right?

[ Voor 43% gewijzigd door FREAKJAM op 27-10-2013 23:44 ]

[Verwijderd]

LSI is een uitzondering, die kan wel tegen timeouts. Mijn controller kan ik zelfs de timeouts in de eigen (BIOS) setup instellen. Dus deze controllers kun je in IT en IR mode met niet-TLER schijven gebruiken.

De LSI controller die je noemt kan mogelijk ook met IT-firmware worden geflashed. Dat zou je even moeten opzoeken. Een goede site daarvoor is ServeTheHome, met name supermicro bordjes met onboard LSI flashen enzovoort.

Het is trouwens ook weer niet zo cruciaal dat TLER uit moet staan. Het is beter, met name in gevallen waarin je degraded draait - dus met één of meer disks minder. Het is in feite de laatste defensie-linie in het geval de redundancy faalt en de hardeschijf nog een kans heeft om een bad sector te kunnen lezen - wat soms ook wel lukt na veel herhalen. Het advies is dus TLER uit voor ZFS indien mogelijk.

[Kortfragje]

And all is well again.. moet zeggen dat het een en ander wel een stuk makkelijker ging dan vorige ervaring met raid sets...

code:

root@gertdus-server:~# zpool status
  pool: zfspool
 state: ONLINE
  scan: resilvered 1.43T in 9h10m with 0 errors on Sun Oct 27 22:34:01 2013
config:

    NAME                                           STATE     READ WRITE CKSUM
    zfspool                                        ONLINE       0     0     0
      raidz2-0                                     ONLINE       0     0     0
        2tb1                                       ONLINE       0     0     0
        2tb2                                       ONLINE       0     0     0
        2tb3                                       ONLINE       0     0     0
        scsi-SATA_WDC_WD20EFRX-68_WD-WCC300687955  ONLINE       0     0     0
        2tb5                                       ONLINE       0     0     0

errors: No known data errors

  pool: zfspool2
 state: ONLINE
  scan: scrub repaired 0 in 1h6m with 0 errors on Mon Oct 14 18:56:30 2013
config:

    NAME        STATE     READ WRITE CKSUM
    zfspool2    ONLINE       0     0     0
      mirror-0  ONLINE       0     0     0
        1tb1    ONLINE       0     0     0
        1tb2    ONLINE       0     0     0

errors: No known data errors

[FREAKJAM]

Ik kan de 2308 in IT flashen mode, dat weet ik toevallig.( heb al veel gelezen op het internet voordat ik mn hardware ga kopen ) Ik duik even in de documentatie van de LSI controller, just to be sure:

IO Timeout for [selected] Devices: This field displays the time (in seconds)
which the host uses to timeout IOs for the following device types.
The default setting is 10.
- 00h (Direct Access)
- 01h (Sequential Access)
- 04h (Write Once)
- 07h (Optical)
- 0Eh (Simplified Direct Access)

Bedoel je dit?

Over TLER gesproken, ik had op het FreeNAS forum ook gepost over mijn setup en mijn thread is uitgemond in een hevige discussie over URE en TLER. Wellicht informatief.

Mijn brein kraakt tenminste op dit moment zo erg dat ik door de bomen het bos niet meer zie en niet de juiste keuze durf te maken met betrekking tot mijn schijven:

• - WD green of WD red
• - aantal hard disks (4 of 5)
• - 3 of 4TB
• - RAIDZ of RAIDZ2

[ Voor 80% gewijzigd door FREAKJAM op 28-10-2013 12:36 ]

[Kortfragje]

Gebaseerd op mijn persoonlijke ervaringen.

Ik zou je aanraden om disks te kopen ongeachte green of red, persoonlijk heb ik een mix van green en red uit verschillende series (dit om te voorkomen dat er een serie fout de oorzaak is van meerdere disks die falen).

Head parking is eenvoudig uit te zetten / veranderen met idle3tools (te compileren van source http://idle3-tools.sourceforge.net/).

Omdat ZFS een software raid is, kan deze ook met green disks overweg (red disks hebben TLER omdat hardware controllers nogal lastig kunnen zijn, ZFS heeft hier geen last van).

Ik zou gaan voor RAIDZ2 (zie ook mijn ervaringen hierboven). De restore was snel en het was een fijn idee dat er nog een disk kon falen zonder ernstige gevolgen. De kosten wegen voor mij op tegen de baten (+/- 60 euro extra bij 2 TB disks in mijn geval).

Als je 3 / 4 TB disks wil gebruiken is RAIDZ2 sowieso erg verstandig (dit omdat de rebuild tijd groter wordt bij grotere disks EN dat de kans op een error groter wordt bij het gebruik van dezelfde disks)..

[ Voor 10% gewijzigd door Kortfragje op 28-10-2013 13:02 . Reden: typo's ]

[FREAKJAM]

Vergeet niet dat ik onder ESXi RAIDZ(2) wil draaien:

Dus:

• ESXi booten vanaf USB
• ZFSGuru in een VM (stored op een SSD)
• Onboard LSI2308 geflashed naar IT mode zodat ik mijn volledige HBA kan doorgeven aan ESXi

Ik denk dat ik dan weldegelijker TLER drives nodig heb ondanks dat het feit dat ik de LSI2308 naar IT (non raid) mode ga flashen?

[ Voor 11% gewijzigd door FREAKJAM op 28-10-2013 13:34 ]

[Verwijderd]

Nee, LSI kan ook in IR mode prima met non-TLER (WD Green) drives. Heel veel mensen draaien hun ZFS box ook met LSI controller en WD Green disks, dat is de klassieke ZFS setup.

Op dat forum van FreeNAS worden een aantal dingen gezegd die niet kloppen. Moet nog kijken of ik zin heb om te registreren daar...

[FireDrunk]

Ik zou de moeite niet nemen. Het zit daar vol met mensen van de oude garde die zweren bij hardware raid...

@FREAKJAM, je moet je niet vergissen in ESXi icm VT-d. In principe zou je setup (qua disks en controllers) niet anders moeten zijn dan een regulier systeem. ZFS kan *echt* bij de disks, en of dat nou via ESXi verloopt of via Xen maakt niet uit als je voor VT-d kiest.

Dus roepen dat je TLER nodig hebt omdat je ESXi gebruikt is onzin.

[FREAKJAM]

Dan heb ik je post verkeerd gelezen denk ik in het ESXi topic. Ik denk trouwens eerder hardop, dan dat ik dingen roep

Als je onder ESXi RAID5 wil draaien, moet je een RAID controller en TLER schijven nemen.
Als je ZFSguru wil gebruiken, en daar RAID-Z (=RAID5) wil doen, moet je met VT-d aan de slag met een losse HBA.

Ik wil mijn LSI2308 flashen naar IT-mode en de HBA doorgeven aan ESXi. ZFSGuru wil ik in een VM draaien.
Omdat ik de LSI2308 flash naar IT (non raid) mode, blijft ZFS het geheel dus eigenlijk gewoon zien als een software raid, wat dus TLER schijven overbodig maakt? Zeg (roep) ik het zo goed dan?

[ Voor 5% gewijzigd door FREAKJAM op 28-10-2013 14:00 ]

[FireDrunk]

Dat klopt ja.

Er is voor ZFS geen verschil tussen een controller die fysiek benaderbaar is, en een controller die via VT-d doorgegeven wordt.

[FREAKJAM]

Thanks.

4x4TB WD green wordt het dan in RAIDZ2. Ik kan max 5 schijven kwijt in mijn case, maar 5 schijven in RAIDZ2 is niet een aan te raden setup. Neem de disks wel eerst even mee naar mijn werk om ze daar in een makkelijke fat client te proppen, zodat ik met UBCD waar WDIDLE3 op staat de headparking kan uitschakelen.

Mijn eerste post over mijn eerste ZFS-projectje is alweer van 9 september, en dan is dan nu toch echt het moment daar om dan alles te bestellen haha! Echt heel veel gehad aan de posts van allerlei mensen in dit topic, waarvoor dank.

[FireDrunk]

Dat maakt niet zoveel uit hoor, ik heb hier 4*4TB in RAIDZ, en dat werkt prima, snelheden zijn ook prima.

Die optimale size is leuk, maar het is geen doodzonde hoor.

Waarom wil je de videokaart behouden icm ESXi?

[ Voor 12% gewijzigd door FireDrunk op 28-10-2013 14:34 ]

[Mystic Spirit]

Ik ga toch mezelf even quoten... In het geweld rond de nieuwe ZFSguru zijn mijn twee posts misschien een beetje ondergesneeuwd.

Post 1: http://gathering.tweakers.net/forum/view_message/41114374
Post 2: http://gathering.tweakers.net/forum/view_message/41114639

Belangrijkste deel uit post twee. De optie die ik waarschijnlijk definitief wil gaan gebruiken:

Mystic Spirit schreef op zondag 27 oktober 2013 @ 17:02:
-KNIP-

Ik zit net te denken. Ik kan ook een vdev maken op 4 x 4TB schijven met partities van 2TB en een 2TB schijf erbij voor een 5 disk RAID-Z. Dan zou er genoeg ruimte zijn om mijn huidige data over te zetten. Vervolgens prik ik er nog eens 3 x 2TB schijven bij (die uit mijn huidige NAS komen) en maak een RAID-Z2 vdev erbij van dezelfde grote. Vervolgens kopieer ik de data van de ene vdev naar de ander en bouw een nieuwe Z2 vdev op en voeg deze toe aan de pool van de andere Z2 vdev.

Op die manier heb ik een goede redundante setup. Hoef ik maar 4 schijven aan te schaffen. Kan ik 4 schijven uit mijn huidige setup hergebruiken en heb ik toch een verdubbeling van capaciteit.

Paar vragen hierbij:

1. Zien jullie extra risico's in deze oplossing ten opzichte van allemaal gelijke schijven gebruiken?
2. Zien jullie slimmere partitie mogelijkheden?
3. Ben ik meer geheugen nodig als ik op deze manier ga opdelen? (ik heb totaal 16gb maar moet ook gebruikt worden voor andere VM's)
4. Heb ik beperkingen in het kiezen van het OS door deze opstelling. (Ik neig naar ZFSGuru, maar wil misschien toch Nas4Free)

[ Voor 4% gewijzigd door Mystic Spirit op 28-10-2013 14:40 ]

[FREAKJAM]

FireDrunk schreef op maandag 28 oktober 2013 @ 14:33:
Dat maakt niet zoveel uit hoor, ik heb hier 4*4TB in RAIDZ, en dat werkt prima, snelheden zijn ook prima.

Die optimale size is leuk, maar het is geen doodzonde hoor.

Waarom wil je de videokaart behouden icm ESXi?

Videokaart wil ik niet meer behouden. Dat betreft mijn allereerste post en gaandeweg ben ik op een totaal andere setup uitgekomen in een totaal nieuwe doos. Mijn huidige doos behoud ik en daar installeer ik de Plex client op, of wellicht behoud ik mijn XBMC installatie en gebruik ik geen Plex op ZFSGuru. (Ik ga dus media streamen van ZFSdoos naar client, mijn huidige HTPC).

• X10SL7, waarvan ik die LSI2308 flash naar IT-mode. Dual nic ga ik gebruiken voor pfSense. (WAN/LAN)
• 4x4TB in RAIDZ of RAIDZ2 (ben ik dus nog niet helemaal uit)
• Sandisk Extreme USB om ESXi 5.1 (of 5.5) vanaf te booten. Ben me bewust van de restricties in ESXi 5.5
• 32GB ram (kan ook vooruit met 16G natuurlijk)
• M500 voor VM storage (datacontainer ESXi)
• S3500 voor ZIL/L2ARC op dezelfde SSD.

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1230 V3 Boxed	€ 214,-	€ 214,-
1	Supermicro X10SL7-F	€ 229,60	€ 229,60
4	WD Green WD40EZRX, 4TB	€ 149,50	€ 598,-
1	Sandisk Extreme USB 3.0 Flash Drive 16GB Zwart	€ 22,-	€ 22,-
2	BitFenix Spectre All White, 120mm	€ 5,19	€ 10,38
1	Kingston ValueRAM KVR16E11K4/32	€ 299,-	€ 299,-
1	Seasonic G-Serie 360Watt	€ 57,-	€ 57,-
1	Crucial 2.5" M500 240GB	€ 136,92	€ 136,92
1	Intel DC S3500 (2,5") 80GB	€ 91,95	€ 91,95
Bekijk collectie Importeer producten		Totaal	€ 1.658,85

[FireDrunk]

Mystic Spirit schreef op maandag 28 oktober 2013 @ 14:36:
Ik ga toch mezelf even quoten... In het geweld rond de nieuwe ZFSguru zijn mijn twee posts misschien een beetje ondergesneeuwd.

Post 1: http://gathering.tweakers.net/forum/view_message/41114374
Post 2: http://gathering.tweakers.net/forum/view_message/41114639

Belangrijkste deel uit post twee. De optie die ik waarschijnlijk definitief wil gaan gebruiken:


[...]


Paar vragen hierbij:

1. Zien jullie extra risico's in deze oplossing ten opzichte van allemaal gelijke schijven gebruiken?
2. Zien jullie slimmere partitie mogelijkheden?
3. Ben ik meer geheugen nodig als ik op deze manier ga opdelen? (ik heb totaal 16gb maar moet ook gebruikt worden voor andere VM's)
4. Heb ik beperkingen in het kiezen van het OS door deze opstelling. (Ik neig naar ZFSGuru, maar wil misschien toch Nas4Free)

1) 2 VDEV's is altijd riskanter dan 1 VDEV. Of het een aanvaardbaar risico is, moet je zelf weten.
2) niet echt, behalve dat je de oude schijven probeert te verkopen, en daar gewoon nieuwe 4TB schijven voor terugkoopt. Dan kan je een RAIDZ2 van 6*4TB maken...
3) Ik heb hier 4*4TB op 8GB, en dat werkt prima, er is zelfs nog ruimschoots geheugen *vrij*
4) Nee, het kan wel zijn dat je met de commandline aan de slag moet, omdat ZFSguru (denk ik) deze opstelling niet via de webinterface voor je kan maken.

FREAKJAM schreef op maandag 28 oktober 2013 @ 14:49:
[...]


Videokaart wil ik niet meer behouden. Dat betreft mijn allereerste post en gaandeweg ben ik op een totaal andere setup uitgekomen in een totaal nieuwe doos. Mijn huidige doos behoud ik en daar installeer ik de Plex client op, of wellicht behoud ik mijn XBMC installatie en gebruik ik geen Plex op ZFSGuru. (Ik ga dus media streamen van ZFSdoos naar client, mijn huidige HTPC).

• X10SL7, waarvan ik die LSI2308 flash naar IT-mode. Dual nic ga ik gebruiken voor pfSense. (WAN/LAN)
• 4x4TB in RAIDZ of RAIDZ2 (ben ik dus nog niet helemaal uit)
• Sandisk Extreme USB om ESXi 5.1 (of 5.5) vanaf te booten. Ben me bewust van de restricties in ESXi 5.5
• 32GB ram (kan ook vooruit met 16G natuurlijk)
• M500 voor VM storage (datacontainer ESXi)
• S3500 voor ZIL/L2ARC op dezelfde SSD.

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1230 V3 Boxed	€ 214,-	€ 214,-
1	Supermicro X10SL7-F	€ 229,60	€ 229,60
4	WD Green WD40EZRX, 4TB	€ 149,50	€ 598,-
1	Sandisk Extreme USB 3.0 Flash Drive 16GB Zwart	€ 22,-	€ 22,-
2	BitFenix Spectre All White, 120mm	€ 5,19	€ 10,38
1	Kingston ValueRAM KVR16E11K4/32	€ 299,-	€ 299,-
1	Seasonic G-Serie 360Watt	€ 57,-	€ 57,-
1	Crucial 2.5" M500 240GB	€ 136,92	€ 136,92
1	Intel DC S3500 (2,5") 80GB	€ 91,95	€ 91,95
Bekijk collectie Importeer producten		Totaal	€ 1.658,85

1) Waarom een Sandisk Extreme voor iets bazaals als ESXi... ESXi draait volledig in RAM, en gebruikt de USB stick alleen voor configuratie. Dat ding slijt nooit.. Koop liever 2 goedkope USB sticks, zodat je er 1 op reserve hebt liggen.
2) Waarom een S3500? Een M500 is ook prima voor L2ARC en ZIL, en is wat goedkoper. Ik gok ook dat een M500 iets sneller is.


Verder ziet je setup er prima uit.

[FREAKJAM]

FireDrunk schreef op maandag 28 oktober 2013 @ 15:03:

1) Waarom een Sandisk Extreme voor iets bazaals als ESXi... ESXi draait volledig in RAM, en gebruikt de USB stick alleen voor configuratie. Dat ding slijt nooit.. Koop liever 2 goedkope USB sticks, zodat je er 1 op reserve hebt liggen.
2) Waarom een S3500? Een M500 is ook prima voor L2ARC en ZIL, en is wat goedkoper. Ik gok ook dat een M500 iets sneller is.


Verder ziet je setup er prima uit.

1) Goed punt. Op basis van CiPHER zijn blog had ik deze keuze gemaakt. Dit is de beste stick om een OS vanaf te draaien, maar ESXi is natuurlijk geen OS. Ik zal 2 goedkopere stickies nemen.
2) Ik had eerst de M500 in gedachte voor L2ARC/ZIL, maar volgens CiPHER zijn blog is de S3500 net iets beter. Maar als voor mijn setup de M500 ook goed is, dan neem ik liever de M500 120GB natuurlijk, aangezien die toch weer wat cheaper is, plus 40GB meer.

[FireDrunk]

Mja, ik snap CiPHER's punt wel. Het is wat gevaarlijker om relatief veel data in DRAM te hebben staan. Hoe meer data er in DRAM staat, hoe langer je powercaps het uit moeten houden om de data veilig te stellen.
Bij Intel hebben ze dus bijna geen "dirty pages" (bytes die in DRAM zitten, maar nog niet op flash staan). Dit gaat heel duidelijk ten koste van de IOPS (7000 random write bij Intel vs 15000 bij een M500).

Aan de andere kant denk ik, als Crucial belooft dat PowerCaps werken, maakt het geen barst uit hoeveel writes ze in DRAM stoppen, zolang die powercaps het uithouden bij powerloss, komt het toch wel goed...

Misschien dat CiPHER even kan uitleggen waarom hij minder dirty pages beter vindt?

[Mystic Spirit]

FireDrunk schreef op maandag 28 oktober 2013 @ 15:03:
[...]

1) 2 VDEV's is altijd riskanter dan 1 VDEV. Of het een aanvaardbaar risico is, moet je zelf weten.

Wat maakt 2 vdev's riskanter dan 1?
Welk risico zie ik over het hoofd? Het enige extra risico dat ik zie is dat ik 2 degraded vdev's heb op het moment dat er een 4TB disk uitvalt. Maar het probleem is even groot als ik 1 vdev heb van 4TB schijven met een defecte disk.

2) niet echt, behalve dat je de oude schijven probeert te verkopen, en daar gewoon nieuwe 4TB schijven voor terugkoopt. Dan kan je een RAIDZ2 van 6*4TB maken...

Mijn "probleem" met deze oplossing is dat ik dan in de toekomst nooit de 2 extra poorten op mijn HBA in kan zetten. Dat beperkt de opslag vergroting.

3) Ik heb hier 4*4TB op 8GB, en dat werkt prima, er is zelfs nog ruimschoots geheugen *vrij*

Goed om te weten. Ik heb nu in de testopstelling 6GB toegewezen. Dat kan ik altijd nog vergroten als het nodig blijkt te zijn.

4) Nee, het kan wel zijn dat je met de commandline aan de slag moet, omdat ZFSguru (denk ik) deze opstelling niet via de webinterface voor je kan maken.

Volgens mij valt dat wel mee. Ik heb nu in mijn testopstelling ook een 2TB en 1TB gecombineerd middels de webinterface

[...]


1) Waarom een Sandisk Extreme voor iets bazaals als ESXi... ESXi draait volledig in RAM, en gebruikt de USB stick alleen voor configuratie. Dat ding slijt nooit.. Koop liever 2 goedkope USB sticks, zodat je er 1 op reserve hebt liggen.
-KNIP-

Interessante opmerking (beetje offtopic) maar je kan toch de USB stick niet mirroren dus de tweede USB stick ligt naar mijn idee ergens te verinteresten.

[FireDrunk]

Mystic Spirit schreef op maandag 28 oktober 2013 @ 15:24:
[...]

Wat maakt 2 vdev's riskanter dan 1?
Welk risico zie ik over het hoofd? Het enige extra risico dat ik zie is dat ik 2 degraded vdev's heb op het moment dat er een 4TB disk uitvalt. Maar het probleem is even groot als ik 1 vdev heb van 4TB schijven met een defecte disk.

[...]

Je redundancy daalt altijd. Hoe je het ook wend of keert. 2* RAIDZ is altijd onveiliger dan 1xRAIDZ2. Stukje kansberekening.

Mijn "probleem" met deze oplossing is dat ik dan in de toekomst nooit de 2 extra poorten op mijn HBA in kan zetten. Dat beperkt de opslag vergroting.
[...]

SSD's?

Goed om te weten. Ik heb nu in de testopstelling 6GB toegewezen. Dat kan ik altijd nog vergroten als het nodig blijkt te zijn.
[...]

Volgens mij valt dat wel mee. Ik heb nu in mijn testopstelling ook een 2TB en 1TB gecombineerd middels de webinterface
[...]

Goed om te weten, ik heb al een tijdje geen ZFSguru meer gebruikt.

Interessante opmerking. (beetje offtopic, maar je kan toch de USB stick niet mirroren dus een USB stick ligt naar mijn idee ergens te verinteresten.

Is ook niet nodig, ESXi gebruikt je USB stick echt alleen tijdens het booten, en om wat configuratie op te zetten. Verder staat het ding gewoon stil. Een Sandisk Extreme is gemaakt voor random writes, welke ESXi alles behalve doet...

Ik bedoelde meer van, het is zonde als je USB stick sterft (vanwege gewone failure) en je hebt geen reserve USB stick liggen om ESXi weer op te zetten... Als je dan pfSense op je ESXi draait kan je hele huis niet internetten tot je een USB stickje gehaald / besteld hebt... Toch jammer.

Mirroren is ook helemaal niet nodig, failure rate van USB sticks is niet extreem hoog, het is meer een impact verkleining dan een risico verkleining.

[FREAKJAM]

Kun je met de USB image tool de stick niet clonen?

[FireDrunk]

Ja hoor, dat kan prima.

[HMS]

Trouwens, tijdens het opzetten van mijn ZFS VM kreeg ik met geen mogelijkheid de PCH werkend met VT-d. De SCU werkte wel direct...

Ik heb een SuperMicro X9SRL-F mobo (http://www.supermicro.nl/...ard/xeon/c600/x9srl-f.cfm)

[FireDrunk]

Ik geloof dat er ook een heel aantal mensen waren die datzelfde probleem hadden met [H/Z/B/Q]85/87 borden. Zeker goed om naar uit te kijken inderdaad.

Voor de mensen die wat meer geld willen spenderen:

pricewatch: Seagate 600 Pro 100GB
http://www.hardwarecanuck...pro-400gb-ssd-review.html

De nieuwe Seagate 600 Pro begint eindelijk leverbaar te worden. Deze SSD heeft ook Supercaps en is nog weer een stuk sneller dan een M500. De SSD is geschikt voor zowel L2ARC als ZIL.
Volgens Seagate is de SSD geoptimaliseerd voor Reads, maar hij kan ook zeker goed meekomen qua Writes. In de real-world benchmarks staat hij 9/10 bovenaan. (Kijk je dus niet scheef op synthetische benchmarks

PS: Ik hou even een slag om de arm dat het 100GB model goed mee kan komen met de 400GB versie. Hij zal uiteraard minder presteren, maar wel in verhouding tot kleinere versies van alle andere gelijksoortige modellen.

[ Voor 74% gewijzigd door FireDrunk op 28-10-2013 15:43 ]

[Verwijderd]

FireDrunk schreef op maandag 28 oktober 2013 @ 15:21:
Mja, ik snap CiPHER's punt wel. Het is wat gevaarlijker om relatief veel data in DRAM te hebben staan. Hoe meer data er in DRAM staat, hoe langer je powercaps het uit moeten houden om de data veilig te stellen.

En daar zit het punt. Intel 320 has 256K SRAM buffer in de chip zelf, en gebruikte de DRAM niet voor write-back of user data, alleen voor caching van de mapping table.

Crucial M500 houdt tot 6MiB uit mijn hoofd (of was het nou 4MiB?) aan write-back in de DRAM-chip. De capacitors in deze SSD houden het maar een fractie van een seconde vol; niet genoeg om de 4MiB weg te schrijven. Volgens mij is het zo ontworpen dat alleen de actuele write afgerond wordt en de SSD daarna gewoon afsluit dus de buffered writes in de DRAM gewoon wegdondert. Dat is geen probleem bij normaal gebruik omdat journaling hiertegen beschermt en synced writes met FLUSH CACHE commando de DRAM buffer niet vaak zo groot laat worden; het dwingt de SSD om de write eerst te bevestigen voordat het aan de overige requests kan beginnen. Het ontwerp is dan gericht op het voorkomen van corruptie op NAND-niveau maar beschermt dus niet volledig de write-back, zoals de Intel 320 wel deed.

Bij SLOG gaat het puur om de writes en bij stroomstoring komt het er dus op aan wat er van de ZIL over is. Als je een SSD gebruikt die seconden tot minuten aan data kwijt kan zijn (Samsung) doordat een oudere versie van de mapping tables wordt teruggezet, dan kun je je voorstellen dat deze SSDs niet erg geschikt zijn voor de functie van SLOG / dedicated ZIL.

Maar het zou kunnen dat M500 of Intel 320 / S3500 niet veel uitmaakt, omdat het synced writes betreffen. Hoe dan ook, zou ik voor betrouwbaarheid toch nog wel voor Intel kiezen. En zo duur zijn ze niet. M500 is ook een leuke SSD.

[FireDrunk]

Ah, ik was in de veronderstelling dat Crucial's PowerCaps het wel vol zouden houden. Misschien moeten we ze dat eens vragen? Contactformulier ingevuld

[ Voor 12% gewijzigd door FireDrunk op 28-10-2013 16:13 ]

[Verwijderd]

Het is echt maar een paar microseconden dacht ik. De caps van de 320 zijn ook veel groter terwijl die een veel minder grote write buffer heeft. Maar ben benieuwd wat Crucial er zelf over te melden heeft.

[Mystic Spirit]

FireDrunk schreef op maandag 28 oktober 2013 @ 15:29:
[...]

Je redundancy daalt altijd. Hoe je het ook wend of keert. 2* RAIDZ is altijd onveiliger dan 1xRAIDZ2. Stukje kansberekening.

[...]

SSD's?

[...]

-KNIP-

Je mist even dat ik twee keer RAID-Z2 maak en niet twee keer Z1
((4 x 2 tb partities van een 4tb hdd) + (2 x 2tb schijven voor Z2))x 2 = 2 x Z2 config van 8tb bestaande uit totaal 8 hdd's.
Ben je dan met me eens dat de kansberekening vrijwel hetzelfde uitvalt als met 6x4tb in Z2?

De SSD's voor caching zijn wel een puntje inderdaad, maar ben nog steeds in twijfel of ik dat nou zo'n goed idee vind.... Tuurlijk gaat het de performance helpen, maar er gaat bij mij vooral sequeltieel gelezen en geschreven worden, waardoor het voordeel van die SSD volgens mij niet zo heel veel gaat opleveren.

De random writes gaan vooral plaats vinden in VM's op de SSD die al voor de images gebruikt wordt.

Of ga ik het heel erg merken dat ik geen chaching heb op SSD?

[FireDrunk]

2*RAIDZ2 is zeker goed, maar dat kost je dan weer relatief veel schijven. Je offert de helft van je schijven op (4 van de 8 als ik het goed begrijp) terwijl er 4 parities berekend moeten worden (2 per vdev). Je pool is dus ernstig traag denk ik. Je zal sequentieel misschien de snelheid halen van 3-4 schijven, terwijl je 8 schijven gebruikt. Erg zonde dus.

Dan kan je beter mirrors maken. Hoe je upgrade scenario er dan uit ziet, weet ik even niet, maar mirrors zijn vele malen sneller en veel makkelijker op te breken (je kan disks heel makkelijk in en uit mirrored vdevs halen). RAIDZ2 is vele malen ingewikkelder.

Caching is niet verplicht, maar het helpt natuurlijk wel. Als je geen VM's op je pool draait is het zeker niet nodig zoals je zelf al aangeeft.

[ Voor 10% gewijzigd door FireDrunk op 28-10-2013 20:34 ]

[Mystic Spirit]

Je hebt wel een punt met de mirrors, maar naar mijn idee houd ik dan toch effectief minder ruimte over. Nu begin ik te twijfelen aan mijn berekening. Ik dacht effectief meer ruimte over te houden met mijn Z2 oplossing, maar theoretisch zou dat niet kloppen.

mirror is:
vdev1 = 4TB + 4TB(mirror)
vdev2 = 4TB + 4TB(mirror)
vdev3 = 2TB + 2TB(mirror)
vdev4 = 2TB + 2TB(mirror)
-----------------------------------------
Totaal = 12TB uit 8 HDD's


Z2 is:
vdev1 = (2TB[p1hdd1] + 2TB[p1hdd2] + 2TB[p1hdd3] + 2TB[p1hdd4] + 2TB[hdd5] + 2TB[hdd6]) - 2x 2TB pariteit
vdev2 = (2TB[p2hdd1] + 2TB[p2hdd2] + 2TB[p2hdd3] + 2TB[p2hdd4] + 2TB[hdd7] + 2TB[hdd8]) - 2x 2TB pariteit
---------------------------------------------------------------------------------------------------
Totaal = 16TB

Lijkt toch wat vreemd....

[jadjong]

En al die partities komen in een enkele pool? Dat wordt kansloos traag. Elke write wordt verdeeld over de beschikbare vdevs, die verdelen de write weer over de beschikbare schijven. Omdat bij jou twee vdevs gebruik maken van dezelfde schijf zal die opgesplitste write weer op een enkele schijf terecht komen, maar dan wel in twee stukjes, 2TB van elkaar verwijderd. Lekker skippen met die leesarm bij elke read/write
Ik gok op 20% van de performance ten opzichte van een 'grote' Rz2.

[Mystic Spirit]

Dat is inderdaad wel een goed punt. Waarom heb ik dat niet eerder bedacht...

Ik was er nog niet uit of ik er een of twee pools van wilde maken, maar zelfs bij twee pools blijft het niet heel handig om een HDD twee keer aan te laten sturen.... en dat doe ik dan ook nog eens 4 keer.

Idee kan de prullenbak in dan maar paar extra euro's uitgeven en een goede config. Blijkt toch altijd goedkoop weer duurkoop te zijn

Terug naar de basisopties:
6 disks Z2 met optie voor twee poorten cache
8 disks Z2 geen cache
of toch 7 disks Z2 met een fout in block size en dus effectief ruimte verlies...

[ Voor 17% gewijzigd door Mystic Spirit op 29-10-2013 03:24 ]

[Durandal]

Terug naar de basisopties:
6 disks Z2 met optie voor twee poorten cache
8 disks Z2 geen cache
of toch 7 disks Z2 met een fout in block size en dus effectief ruimte verlies...

Ik zal wel iets gemist hebben, maar dat moederbord heeft 8 SAS poorten en 6 SATAs. Opties genoeg toch?

[FireDrunk]

ESXi, ESXi, ESXi

@MS, ik zou voor 7*4TB RAIDZ2 gaan in 1 keer en later cache en ZIL toevoegen op 1 SSD.
Dat ruimteverlies valt wel mee. enkele tientallen GB's op een hele pool volgens mij.
CiPHER heeft een keer ergens een berekening gemaakt.

Je KAN natuurlijk ook een ander klein risico nemen, en dat is ZIL en L2ARC via RDM doen. RDM in ESXi 5.5 is stukken verbeterd door de AHCI controller. Dan kan je 8*4TB doen en ZIL en L2ARC later toevoegen via RDM.

[ Voor 30% gewijzigd door FireDrunk op 29-10-2013 09:23 ]

[Bigs]

Het lijkt mij dat de performance hit van RDM (hoe klein ook) ervoor zorgt dat het niet echt de moeite waard is om zo'n device in te zetten als ZIL of L2ARC.

[FREAKJAM]

Toch nog een vraagje over ZIL/L2ARC:
Ik ga mijn ZFS alleen gebruiken om media te sharen. (Plex, XBMC wat dan ook). Lees toch best wel veel op het internet dat een ZIL/L2ARC eigenlijk teveel van het goede is:

For your stated use case - storage of videos, pictures and media - you don't really need a separate SSD for ZIL/L2ARC. Your application is basically "write once, infrequently, and read one file at a time". You won't see any benefit from a dedicated ZIL or L2ARC SSD.

Hoe denken jullie hierover?

[u_nix_we_all]

FREAKJAM schreef op dinsdag 29 oktober 2013 @ 11:56:
Toch nog een vraagje over ZIL/L2ARC:
Ik ga mijn ZFS alleen gebruiken om media te sharen. (Plex, XBMC wat dan ook). Lees toch best wel veel op het internet dat een ZIL/L2ARC eigenlijk teveel van het goede is:


[...]


Hoe denken jullie hierover?

Volledig mee eens, een ZIL helpt vooral voor random IO en dat heb je niet/nauwelijks, en een L2ARC voegt niet zoveel toe behalve verhoogd geheugengebruik. Je kunt je geld beter besteden aan meer geheugen.

[FireDrunk]

Bigs schreef op dinsdag 29 oktober 2013 @ 09:47:
Het lijkt mij dat de performance hit van RDM (hoe klein ook) ervoor zorgt dat het niet echt de moeite waard is om zo'n device in te zetten als ZIL of L2ARC.

Nope, niet waar (in mijn ogen). RDM heeft echt geen performance impact (die ik ooit gemerkt hebt iig).
ZIL en L2ARC hebben zin omdat de SSD de writes offload ten opzichte van de HDD.

Ik heb liever een SSD via RDM als ZIL dan helemaal geen ZIL.

Ik heb ergens een prachtig diagrammetje gezien, waarin je ziet dat de software latency vaak wel meevalt, maar dat de link transfer en de controller veel meer uitmaken op het geheel.

Stel je ram-to-cache (controller naar ssd/disk cache) latency is 60µs, dan is waarschijnlijk meer dan 30-40 µs daarvan transfer en controller latency, en de rest is software. Als RDM al een procentuele vertraging oplevert, is dat nog steeds maar miniscuul in verhouding tot de totale tijd.

Een LSI controller die het request door zijn lokale CPU af moet handelen, is misschien nog wel veel langzamer.

Een ZIL/L2ARC SSD op RDM *KAN* in potentie dus nog sneller zijn dan een SSD op een LSI controller in een PCIe slot welke je via VT-d doorgeeft, simpelweg omdat een true AHCI controller veel minder logica bevat en dus sneller requests forward dan een LSI controller.

@FREAKJAM, u_nix_we_all

Een SSD is nog altijd een orde van grootte goedkoper dan geheugen, en je kan een veel grotere SSD kopen dan dat je RAM kan inprikken op je PC. Hierdoor kan je redelijk goedkoop ARC maken.

Groot voordeel van L2ARC is dat door directories met veel files browsen vele malen sneller en soepeler gaat dan zonder L2ARC. Ook hoeven je disks pas op te spinnen als er data vanaf moet komen die niet in L2ARC staat. Als je dus alleen maar even wil kijken in je Backups directory wanneer je voor het laatst een backup gemaakt hebt (om maar even een voorbeeld te noemne), hoeven je disks helemaal niet op te spinnen.

[ Voor 20% gewijzigd door FireDrunk op 29-10-2013 12:34 ]

[Mystic Spirit]

FireDrunk schreef op dinsdag 29 oktober 2013 @ 09:22:
ESXi, ESXi, ESXi

@MS, ik zou voor 7*4TB RAIDZ2 gaan in 1 keer en later cache en ZIL toevoegen op 1 SSD.
Dat ruimteverlies valt wel mee. enkele tientallen GB's op een hele pool volgens mij.
CiPHER heeft een keer ergens een berekening gemaakt.

Je KAN natuurlijk ook een ander klein risico nemen, en dat is ZIL en L2ARC via RDM doen. RDM in ESXi 5.5 is stukken verbeterd door de AHCI controller. Dan kan je 8*4TB doen en ZIL en L2ARC later toevoegen via RDM.

Ik zal nog even verder zoeken naar die berekning van CiPHER. Er staat wel wat in de startpost. Daar wordt trouwens een config van 6 dataschijven en 2 pariteitschijven ook overgeslagen als goede optie. Vraag me af waarom. Wellicht dat iemand me dat nog uit kan leggen? Er wordt uitgegaan van een macht van 2 en ik snap dat 6 daar niet bij hoort, maar ik zou eerder een veelvoud van 2 verwachten.

Als het qua performance en dataverlies niet uitmaakt of ik kies voor 6+2 of 5+2 dan ga ik voor de 5 plus twee en houd ik een poort vrij voor SSD voor L2ARC. ZIL op een SSD ben ik niet zo'n fan van. Dat vind ik afbreuk doen aan de alle moeite die ik doe om me data veilig te stellen.

Cache via RDM laten verlopen zou kunnen, maar om de AHCI controler op te zetten heb je een betaald product van VMware nodig. Dat kan je oplossen met gedoe met trials etc. maar dat zie ik niet zo zitten. Of is er inmiddels een mogelijkheid om dit zonder betaalde producten goed te managen?

[Bigs]

FireDrunk schreef op dinsdag 29 oktober 2013 @ 12:31:
[...]

Nope, niet waar (in mijn ogen). RDM heeft echt geen performance impact (die ik ooit gemerkt hebt iig).
ZIL en L2ARC hebben zin omdat de SSD de writes offload ten opzichte van de HDD.


[uitleg]

I stand corrected. Als je alle lag bij elkaar optelt is RDM inderdaad verwaarloosbaar. Logisch ook aangezien je gewoon een hele LUN 1:1 doorgeeft aan je VM.

[FireDrunk]

Nou ja, wat je zegt klopt wel, RDM heeft vast wel ergens een miniscule software lag... Ergens moet er namelijk beslist worden dat het niet lokaal afgehandeld moet worden, maar in een VM.

Enige wat ik denk is dat dat relatief ten opzichte van het grote geheel, geen reet boeit

Mystic Spirit schreef op dinsdag 29 oktober 2013 @ 13:37:
[...]

Ik zal nog even verder zoeken naar die berekning van CiPHER. Er staat wel wat in de startpost. Daar wordt trouwens een config van 6 dataschijven en 2 pariteitschijven ook overgeslagen als goede optie. Vraag me af waarom. Wellicht dat iemand me dat nog uit kan leggen? Er wordt uitgegaan van een macht van 2 en ik snap dat 6 daar niet bij hoort, maar ik zou eerder een veelvoud van 2 verwachten.

Als het qua performance en dataverlies niet uitmaakt of ik kies voor 6+2 of 5+2 dan ga ik voor de 5 plus twee en houd ik een poort vrij voor SSD voor L2ARC. ZIL op een SSD ben ik niet zo'n fan van. Dat vind ik afbreuk doen aan de alle moeite die ik doe om me data veilig te stellen.

Cache via RDM laten verlopen zou kunnen, maar om de AHCI controler op te zetten heb je een betaald product van VMware nodig. Dat kan je oplossen met gedoe met trials etc. maar dat zie ik niet zo zitten. Of is er inmiddels een mogelijkheid om dit zonder betaalde producten goed te managen?

ZFS werkt met records van 128KiB. 128KiB/6 is nog steeds geen mooi getal. (namelijk 21,3KiB).
Dat betekend dus dat als je RAIDZ2 gebruikt met 8 schijven je schijven per stuk 21,3KiB per record moeten schrijven. Omdat dat niet past, moeten ze of 22K (als je 512bytes sectoren gebruikt) of 24K (als je een 4k optimized pool hebt) moeten schrijven wat dus 0,7 of 2,7KiB meer is dan nodig.

6* 0,7 KiB = 4,2KiB per 128K teveel. In verhouding bij 512bytes sectoren dus ~4% ruimteverlies.
6* 2,7 KiB = 16,2KiB per 128K teveel. In verhouding bij 4k sectoren dus ~10% ruimteverlies.

Mijn eigen voorbeeld: Ik heb 4*4TB in RAIDZ(1), met een 4K optimized pool.
128/3 = 42,6KiB per disk per record. Dat wordt dus 44KiB per disk per record.
Dat is 1.4KiB teveel. 3*1.4KiB = 4,2KiB per record meer, dus ~4% ruimteverlies.

[ Voor 80% gewijzigd door FireDrunk op 29-10-2013 13:52 ]

[]Byte[]

FireDrunk schreef op dinsdag 29 oktober 2013 @ 12:31:
RDM heeft echt geen performance impact (die ik ooit gemerkt hebt iig).

Als je het wel had gemerkt zou ik het een prestatie vinden.
Vroeger was het wel een issue.
Maar sinds 4.0 is dat al helemaal geen issue meer.

[Mystic Spirit]

FireDrunk schreef op dinsdag 29 oktober 2013 @ 13:43:
Nou ja, wat je zegt klopt wel, RDM heeft vast wel ergens een miniscule software lag... Ergens moet er namelijk beslist worden dat het niet lokaal afgehandeld moet worden, maar in een VM.

Enige wat ik denk is dat dat relatief ten opzichte van het grote geheel, geen reet boeit


[...]


ZFS werkt met records van 128KiB. 128KiB/6 is nog steeds geen mooi getal. (namelijk 21,3KiB).
Dat betekend dus dat als je RAIDZ2 gebruikt met 8 schijven je schijven per stuk 21,3KiB per record moeten schrijven. Omdat dat niet past, moeten ze of 22K (als je 512bytes sectoren gebruikt) of 24K (als je een 4k optimized pool hebt) moeten schrijven wat dus 0,7 of 2,7KiB meer is dan nodig.

6* 0,7 KiB = 4,2KiB per 128K teveel. In verhouding bij 512bytes sectoren dus ~4% ruimteverlies.
6* 2,7 KiB = 16,2KiB per 128K teveel. In verhouding bij 4k sectoren dus ~10% ruimteverlies.

Mijn eigen voorbeeld: Ik heb 4*4TB in RAIDZ(1), met een 4K optimized pool.
128/3 = 42,6KiB per disk per record. Dat wordt dus 44KiB per disk per record.
Dat is 1.4KiB teveel. 3*1.4KiB = 4,2KiB per record meer, dus ~4% ruimteverlies.

Ik ben even aan het zoeken gegaan en stuite op deze thread: http://forums.servethehom...fs-non-power-2-vdevs.html hier lijkt de real life situatie af te wijken van de theoretische berekening. Hij lijkt het in zijn posts ook nog niet helemaal doorgrond te hebben.

Heeft het misschien temaken met wat er opgeslagen wordt? Veel grote files betekend minder ruimteverlies, omdat de blocks vol gemaakt worden en je slechts verlies hebt bij de laatste block?

[FireDrunk]

Andersom volgens mij, ZFS kent een variabele stripe size, dus volgens mij word juist bij files kleiner dan 128KiB geen ruimte verloren.

Maar goed, ik ben ook geen ZFS programmeur, dit is alleen de theorie die ik er op los kan laten

[]Byte[]

FireDrunk schreef op dinsdag 29 oktober 2013 @ 19:26:
Andersom volgens mij, ZFS kent een variabele stripe size, dus volgens mij word juist bij files kleiner dan 128KiB geen ruimte verloren.

Maar goed, ik ben ook geen ZFS programmeur, dit is alleen de theorie die ik er op los kan laten

Klopt!
Zie hier.

[...]
Dynamische stripesizes maakt ZFS ongevoelig voor 'write hole'.
[...]

Verder was ik ook nog deze ook ooit nog eens tegen gekomen.

ZFS uses variable-sized blocks of up to 1024 kilobytes. If data compression (LZJB or LZ4) is enabled, variable block sizes are used. If a block can be compressed to fit into a smaller block size, the smaller size is used on the disk to use less storage and improve IO throughput at the cost of increased CPU use for the compression and decompression operations.

[ Voor 29% gewijzigd door ]Byte[ op 29-10-2013 19:55 ]

[Mystic Spirit]

Ok, maar wat betekend dit dan voor een niet passende block size met het aantal schijven. Betekend dat vooral performance verlies of kost het nou ook echt ruimte?

Ik kan er ook niet echt een heldere uitleg over vinden ergens. Wat best wel raar is... er moeten toch meer mensen tegen dit issue aangelopen zijn.

[Verwijderd]

Klopt niet; ook bij kleine writes gaat ruimte verloren. De variabele stripesize zorgt ervoor dat alle writes naar RAID-Z in één fase gebeuren dus alle disks één write opdracht. Dit in tegenstelling tot klassiek RAID5 waarbij kleine writes in twee fasen gebeuren, eerst parity lezen van de overige blocks, dan nieuwe parity calculeren en het geheel wegschrijven. Dus lezen + schrijven wat zorgt voor non-atomicity. Dat is de infamous RAID5 write-hole.

Maar dat staat los van de discussie over verloren ruimte bij RAID-Z families. Het punt is dat je met blokjes werkt zo groot als de sectorsize, en daar kun je niet omheen. Dus als je 70 bytes wilt schrijven naar een disk, dan gaat dat opgevuld worden naar 512 of 4096 bytes afhankelijk van de ashift setting van de ZFS pool. Dat opvullen wordt 'padding' genoemd.

Echter, het leuke is dat die padding niet gelijk hoeft te zijn voor alle disks. Zo kan het voorkomen dat de ene disk meer padding heeft dan de andere, en dit later weer wordt afgewisseld. Dit effect kun je goed waarnemen met gstat (FreeBSD/ZFSguru) terwijl je enkele lichte writes doet met dd.

Ik kan nog eens wat testjes doen om precies te achterhalen hoe het werkt, maar volgens mij klopt het aardig zo.

[FireDrunk]

Dat zie ik inderdaad wel veel, variabele writes per disk. Waar je bij MDADM altijd even veel writes naar een raid member hebt, heb je dat bij ZFS niet.

[Mystic Spirit]

Even kijken of ik het kan vatten in een rekenvoorbeeld.

Ik heb een vdev met 3 dataschijven en 2 parity schijven, een blocksize van 4096 bytes en schrijf een file weg van 12288 bytes. Dan vul ik dus precies 3 blocks van 4096 bytes en gaat er geen ruimte verloren.

Als ik op dezelfde vdev een file schrijf van 83 bytes dan verlies ik (3 x 4096) - 83 = 12205 bytes omdat een block nou eenmaal een block is.

Zou dan het effect van een aantal schijven dat niet voorkomt in de macht van 2 toch minder ernstig zijn voor het verlies van ruimte bij het gebruik van grote files en vooral impact hebben op de performance? Of gooi je bij een config van 5 data schijven echt gewoon sowieso 15% van je capaciteit weg?

Een procentje (of 2 a 3) vindt ik nog wel te overleven want dan heb je max 5 x 3 = 15 procent verlies en is je laatste schijf dus voor 85% effectief. Maar bij een verlies van ruimte boven de 10% moet je je toch achter je oren gaan krabben, want dan is de laatste schijf die je erbij plaats maar voor slechts 50% effectief en daar worden het dure gigabytes van.

[FireDrunk]

Het gaat om machten van 2, niet om veelvouden van 2.

2,4,8,16,32 etc.
en niet
2,4,6,8,10,12,14 etc

5 data disks is 128/5 = 25.6KB per schijf, dat wordt dus 26KB (52 sectoren van 512 bytes) of 26KB (6 sectoren van 4K).

Verlies bij 512 byte sectorgrootte is dus 1KB per disk, dus 5KB per 5, en dus 5/128e = 3,9%
Verlies bij 4K sectorgrootte 1KB per disk, dus hetzelfde: 3,9%.

Waar (denk ik) het grootste verschil in zit, is hoe ZFS oneven grootte files verdeeld.

16.1K op 5 schijven is 4*4KB en 1 keer 0.1K. Als het op die manier verdeeld word, heb je alleen op de laatste schijf padding naar 4K.

Ik meen mij te herinneren dat hele kleine files ook in metadata konden worden opgeslagen... En dat dat daar dus ook nog wel wat mee gewonnen werd...

[ Voor 32% gewijzigd door FireDrunk op 29-10-2013 20:52 ]

[Mystic Spirit]

Jullie zullen wel helemaal gek van mij worden, maar ik probeer dit toch te doorgronden.

Ik heb daarom een tabel gemaakt, maar die lijkt ook ergens mis te gaan. Ik ga hierbij uit van een 4k blocksize en de 128k stripe. Dan kom ik toch op schrikbarende getallen....

Aantal Disks	Stripe/Disk	Stripe naar boven afgerond en deelbaar door 4	% verlies
1	128	128	0%
2	64	64	0%
3	42.66666667	44	3%
4	32	32	0%
5	25.6	28	9%
6	21.33333333	24	13%
7	18.28571429	20	9%
8	16	16	0%
9	14.22222222	16	13%
10	12.8	16	25%
11	11.63636364	12	3%
12	10.66666667	12	13%
13	9.846153846	12	22%
14	9.142857143	12	31%
15	8.533333333	12	41%
16	8	8	0%
17	7.529411765	8	6%
18	7.111111111	8	13%
19	6.736842105	8	19%
20	6.4	8	25%
21	6.095238095	8	31%
22	5.818181818	8	38%
23	5.565217391	8	44%
24	5.333333333	8	50%
25	5.12	8	56%
26	4.923076923	8	63%
27	4.740740741	8	69%
28	4.571428571	8	75%
29	4.413793103	8	81%
30	4.266666667	8	88%

Ik snap dat tot 30 door gaan een beetje een theoretisch iets is, maar het gaat even om het voorbeeld. Bij 32 loopt hij weer netjes naar 0% verlies. Klopt deze tabel naar jullie inzicht?

[tvwes]

Mystic Spirit schreef op dinsdag 29 oktober 2013 @ 20:22:
Even kijken of ik het kan vatten in een rekenvoorbeeld.

Ik heb een vdev met 3 dataschijven en 2 parity schijven, een blocksize van 4096 bytes en schrijf een file weg van 12288 bytes. Dan vul ik dus precies 3 blocks van 4096 bytes en gaat er geen ruimte verloren.

Als ik op dezelfde vdev een file schrijf van 83 bytes dan verlies ik (3 x 4096) - 83 = 12205 bytes omdat een block nou eenmaal een block is.

RAID-Z gebruikt variable stripe widths. Er wordt precies genoeg weggeschreven om te voldoen aan het redundancy niveau van het vdev. Dus raid-z2 met bovenstaand voorbeeld kost drie blokken (ook niet waar overigens) een data block en twee pariteits blokken allemaal op een andere drive. Ook al heeft je vdev daarnaast nog andere drives, die worden niet gebruikt voor het opslaan van dit bestand. Je kan immers die drives probleemloos verliezen zonder iets aan de redundancy van dit bestand te veranderen. Dit bestand is opgeslagen op 1 data drive en 2 parity drives.
Ik schreef eerder dat het niet waar is dat deze file je maar drie blokken kost. De metadata komt er nog bij en het hangt ervan af af deze file in zijn eentje in een txg zit of dat er nog andere file bij zaten. In dat laatste geval is het wat efficienter.

TIP: gebruik geen RAIDZ voor kleine files, als mail stores etc. Je grote binaries prima. Gebruik altijd mirror's kost minder ruimte en (veel) betere performance. Je kan beter verschillende zpool's aanmaken omzo de workload te optimaliseren.

[]Byte[]

Mystic Spirit schreef op dinsdag 29 oktober 2013 @ 21:47:
Jullie zullen wel helemaal gek van mij worden, maar ik probeer dit toch te doorgronden.

Geeft niets... Zo leer ik er ook nog wat van
Of je uberhaupt RAID-Z(n) sets zo extreem groot (16+) wil bouwen... lijkt mij niet.
Is ie straks 3 weken aan het rebuilden bij uitval van een disk.
Daarom heb ik ook een RAID-Z2 van 10 disks gemaakt. (netto dus 8 disks, en daarmee 0%)
Als ik die pool moet uitbreiden kan ik nog een RAID-Z2 van 6 disks maken en dan zit m'n chassis vol.

[FREAKJAM]

Mystic:
Iemand in dit topic is ook flink aan het rekenen geweest

[analog_]

Mystic Spirit schreef op dinsdag 29 oktober 2013 @ 21:47:
Jullie zullen wel helemaal gek van mij worden, maar ik probeer dit toch te doorgronden.

Ik heb daarom een tabel gemaakt, maar die lijkt ook ergens mis te gaan. Ik ga hierbij uit van een 4k blocksize en de 128k stripe. Dan kom ik toch op schrikbarende getallen....



Ik snap dat tot 30 door gaan een beetje een theoretisch iets is, maar het gaat even om het voorbeeld. Bij 32 loopt hij weer netjes naar 0% verlies. Klopt deze tabel naar jullie inzicht?

Fixed for you.

[ Voor 14% gewijzigd door analog_ op 29-10-2013 22:56 ]

[FireDrunk]

Ik ben ook een beetje bezig:

Geen idee of dit precies klopt.