Het grote ZFS topic

[ItsValium]

Een klant vroeg me vandaag of ik voor zo weinig mogelijk een nas/san kon bouwen met zo hoog mogelijke iops met redundantie voor minimum 2 schijfdefecten, opslagcapaciteit hoeft maar een dikke 300gb te zijn. Ik dacht onmiddellijk aan een ZFS appliance met een RAIDZ2 gebouwd uit kleinere intel 320 SSD's. Of een striped mirror config (RAID10) met dezelfde SSD's.

Heeft hier iemand ervaring met pure SSD-pools en wat mag ik als performance verwachten? Ik heb wel een aantal SSD's om mee te testen maar geen tien natuurlijk.

[FireDrunk]

Waarom zou het niet gaan? Stop er ook nog eens veel geheugen in, en je het IOPS als een malle.

Ik zou 8 SSD's kopen en in setjes van 2 zetten. ZFSGuru en fatsoenlijke Monitoring bouwen die SMART in de gaten houdt. Afhankelijk van de load, 2 of 4 netwerkkaarten in een Aggregate en 16GB (of meer natuurlijk) geheugen.

En werken met NFS of iSCSI. SMB is niet leuk voor IOPS.

[ Voor 62% gewijzigd door FireDrunk op 14-02-2012 16:48 ]

[ItsValium]

Het zou sowieso via NFS gebeuren, het betreft data voor simulaties (kleine datablokken maar wel beschikbaar voor een cluster met iets meer dan 600 cores, vandaar de nood voor hoge IOPS)

Als chassis wordt het waarschijnlijk volgende : Supermicro SC213A-R720LPB (16*hotswap 2,5" sata) met een 16-tal intel 320 SSD's, 2 M1015 controllers geflashed naar IT-mode samen met een Supermicro X9SCM-F moederbordje en 32GB (4*8) aan geheugen. Daarin dan 16 intel 320 SSD's (80 of 120 GB eens de klant weet hoeveel storage er echt nodig is), een 4*2,5" enclosure met nog eens 4 intel 320 SSD's (40GB) voor het OS aangesloten rechtstreeks op het moederbord. En 1 of 2 10Gbit Intel NIC's erbij.

Lijkt mij een BOM aan IOPS voor een redelijk budget vergeleken met de SSD oplossingen van de grote storageproviders.

De offerte gaat binnenkort de deur uit, als die aangenomen wordt dan ben ik echt benieuwd wat soort performance daaruit komt!

[webfreakz.nl]

ItsValium schreef op dinsdag 14 februari 2012 @ 19:18:
Het zou sowieso via NFS gebeuren, het betreft data voor simulaties (kleine datablokken maar wel beschikbaar voor een cluster met iets meer dan 600 cores, vandaar de nood voor hoge IOPS)

Als chassis wordt het waarschijnlijk volgende : Supermicro SC213A-R720LPB (16*hotswap 2,5" sata) met een 16-tal intel 320 SSD's, 2 M1015 controllers geflashed naar IT-mode samen met een Supermicro X9SCM-F moederbordje en 32GB (4*8) aan geheugen. Daarin dan 16 intel 320 SSD's (80 of 120 GB eens de klant weet hoeveel storage er echt nodig is), een 4*2,5" enclosure met nog eens 4 intel 320 SSD's (40GB) voor het OS aangesloten rechtstreeks op het moederbord. En 1 of 2 10Gbit Intel NIC's erbij.

Lijkt mij een BOM aan IOPS voor een redelijk budget vergeleken met de SSD oplossingen van de grote storageproviders.

De offerte gaat binnenkort de deur uit, als die aangenomen wordt dan ben ik echt benieuwd wat soort performance daaruit komt!

Heb je http://www.anandtech.com/...-testing-and-benchmarking al eens gelezen? Misschien is L2ARC interessant. Ik weet niet hoeveel performance dat 600-core-cluster écht nodig heeft, maar iets zegt me dat een enkele CPU te weinig prestaties gaat leveren.

[ItsValium]

@webfreakz.nl

L2ARC zal in dit geval weinig toevoegen, gezien je die opbouwt uit SSD's en de pool al volledig uit SSD's zou bestaan. Misschien heb je wel gelijk ivm de CPU. In overleg met de klant zal ik sowieso een testopstelling bouwen met voornoemde specificaties, als daar een CPU bottleneck op zit dan wordt het een dual-cpu bordje. De kost hiervan (upgrade mobo en cpu's) kan ik dan ook recupereren bij hergebruik van de onderdelen.

In het artikel dat je linkt kon ik niet snel vinden hoe ze hun ZFS-pool opgebouwd hadden, maar gezien de setup een hoop mirrors zou zijn en er geen compressie of deduplication zou ingesteld staan denk ik niet dat de CPU zoveel te doen krijgt. Ik kan hier natuurlijk verkeerd zijn. Na het testen zou ik meer weten.

[Oid]

Oid schreef op dinsdag 14 februari 2012 @ 00:09:
[...]

knip

blijkbaar heeft het toch iets te maken met esx:

code:

[root@localhost nfstemp]# dd if=/dev/zero of=zero.file bs=1M count=2048
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 37.127 seconds, 57.8 MB/s
[root@localhost nfstemp]# dd if=zero.file of=/dev/null bs=1M
2048+0 records in
2048+0 records out
2147483648 bytes (2.1 GB) copied, 18.6456 seconds, 115 MB/s
[root@localhost nfstemp]# dd if=/dev/zero of=zero4.file bs=1M count=4096
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 75.5699 seconds, 56.8 MB/s
[root@localhost nfstemp]# dd if=zero4.file of=/dev/null bs=1M
4096+0 records in
4096+0 records out
4294967296 bytes (4.3 GB) copied, 37.3526 seconds, 115 MB/s
[root@localhost nfstemp]# dd if=/dev/zero of=zero8.file bs=1M count=8192
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 152.211 seconds, 56.4 MB/s
[root@localhost nfstemp]# dd if=zero8.file of=/dev/null bs=1M
8192+0 records in
8192+0 records out
8589934592 bytes (8.6 GB) copied, 74.3868 seconds, 115 MB/s

mijn mount op centos 5.7, virtueel op lokale hardeschijf in esx:

code:

[root@localhost nfstemp]# mount
/dev/mapper/VolGroup00-LogVol00 on / type ext3 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
/dev/sda1 on /boot type ext3 (rw)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
10.87.28.10:/mnt/tank/vmware on /mnt/nfstemp type nfs (rw,addr=10.87.28.10)

ik vond wel dit http://christopher-techni...s-nfs-on-zfs-for-esx.html, maar vind het wat gevaarlijk klinken, weet iemand er meer van?

[ Voor 9% gewijzigd door Oid op 14-02-2012 22:51 ]

[syl765]

NFS op een van een ZFS pool waar je sync niet uitzet, is een no go.

syl765 in "Het grote ZFS topic"

In deze post staat ook een link, daar zet ik op een gegeven moment de sync uit.
Performance gaat dan echt omhoog.

Een dual core is volgens mij niet echt nodig, memory dat is wat je wilt.
Wij gebruiken ook de supermicro rackservers (alleen de 3,5 inch varianten) en we hebben nog geen enkele problemen ondervonden.
Echter booten wij wel van twee apparte schijven die op de controller van het moederboard zitten.
Hier door is het makkelijker de pool op te pakken en te verplaatsen zonder dat je rekening hoeft te houden met het OS.

Onze pools bouwen we op met mirrors, is wel wat prijziger maar geeft je veel meer ruimte schijfjes te verliezen.
Wij gebruiken de normale FreeBSD 9 release, geen ZFS guru of andere OS'en.

Booten van af de backplane gaf hier en daar toch wat rare problemen.

Gr
Johan

[FireDrunk]

Uh, mirrors is leuk, maar je kan niet 2 schijven uit dezelfde mirror verliezen. Je hebt dus nooit meer veiligheid dan RAIDZ...

[Oid]

syl765 schreef op woensdag 15 februari 2012 @ 09:03:


knip

sync staat uit. verder gaat het om een thuis omgeving dus niet heel spannend. wat gewoon raar is dat nu freebsd 9 er op staat esx slecht omgaat met nfs, voorheen haalde ik 100 MB/s nu 10MB/s dat vind ik raar en dat vind ik jammer.

OS (FREEBSD 9) staat op een aparte SSD samen met SLOG en L2ARC

[nielsdc]

FireDrunk schreef op woensdag 15 februari 2012 @ 09:09:
Uh, mirrors is leuk, maar je kan niet 2 schijven uit dezelfde mirror verliezen. Je hebt dus nooit meer veiligheid dan RAIDZ...

Meerdere mirrors gestriped kan je wel sommige multiple disk failures opvangen. Een zpool van 5x2 disks kan met veel geluk een 5 disk failure aan, wat je bij raidz of raidz2 nooit gaat lukken. Met veel pech kan je ook met 2 disk failures al je data kwijt zijn, maar het blijft beter dan raidz.

[FireDrunk]

Klopt allemaal, maar Mirrors zijn dus niet per definitie veiliger. De kans is alleen beter. Bij RAIDZ2 kunnen er bijvoorbeeld altijd 2 disks falen... Dat is een gegeven, geen kans.

Mirrors zijn op andere vlakken ook weer veel beter hoor, begrijp me niet verkeerd. Uitbereiden is makkelijker, en performance is hoger.

* FireDrunk wil met de tijd ook naar een 4x2 (of zelfs 5x2) ZFS opstelling.

[ Voor 11% gewijzigd door FireDrunk op 15-02-2012 11:48 ]

[Dadona]

Je zit dan natuurlijk nog wel met de zwakste schakel en mogelijk verschillende harde schijf karakteristieken. Ik heb hier twee arrays, F3EG en WD20EARS schijven. Zowel in sectorgrootte als in spindown (van de WD20EARS heb ik de aggressieve headpark uitgezet) zijn ze anders. De F3EG is nog altijd een soort van headpark aan het doen. Een ander aspect waar je aan moet denken is dat je dan ook meer schijven aan laat terwijl de performance niet nodig is. Dat is ook de reden dat ik voor twee arrays ging, er zullen geregeld backups worden gemaakt, voor langere tijd, waarbij dan één array uit kan blijven.

[FireDrunk]

Je hebt dus echt 2 verschillende pools, en niet alleen 2 vdev's? Merk je dat dan niet in performance? Of heb je zo'n asociale batterij disks?

[fluppie007]

Wat zouden jullie doen met ( als redundancy belangrijker is dan prestaties ):

5 nieuwe & lege 2TB schijven
4 gebruikte 2TB schijven beschikbaar na overkopiëren data van oude homeserver.

Bv.

1. Aanmaken RAID-Z pool met 5 2TB schijven.
2. Data overkopiëren ( 2-3 TB ) op deze pool
3. 4 schijven bijmonteren
4. Nieuwe RAID-Z2 pool maken met 4 2TB schijven
Eindresultaat: 1x RAID-Z pool met 5 disks ( "ideale" config ) en 1x RAID-Z2 pool met 4 disks ( "ideale" config )
8 TB + 4 TB = 12 TB

of

1. Aanmaken RAID-Z2 pool met 4 2TB schijven.
2. Data overkopiëren ( 2-3 TB ) op deze pool
3. 4 schijven bijmonteren
4. Expansion van de bestaande RAID-Z2 pool met de extra disks.
Eindresultaat: 1x RAID-Z2 pool met 9 disks ( "niet-ideale" config )
14 TB

of

1. Aanmaken RAID-Z pool met 5 2TB schijven.
2. Data overkopiëren ( 2-3 TB ) op deze pool
3. 4 schijven bijmonteren
4. Expansion van de bestaande RAID-Z pool met de extra disks.
Eindresultaat: 1x RAID-Z pool met 9 disks ( "ideale" config )
16TB

Kan ik in ZFSguru het tabblad expansion gebruiken als er al data op de pool staat ?

[ Voor 3% gewijzigd door fluppie007 op 15-02-2012 20:45 ]

[Verwijderd]

RAID-Z met 9 disks vind ik echt te weinig bescherming. Als het je om de bescherming gaat, denk ik dat je RAIDZ2 als sterke voorkeur moet hanteren.

Ik dacht zelf aan een 6-disk RAID-Z2 en een andere pool met 3 disks in RAID-Z. Die hoofd pool heeft dan optimale bescherming. De tweede pool met slechts 3 schijven is kleiner, maar heeft dezelfde overhead (33%) als de 6-disk RAID-Z2 en kun je voor sommige aparte dingen gebruiken misschien, data die iets minder bescherming nodig heeft en RAID-Z voldoende is.

Nu kun je ook in één pool zowel de RAID-Z2 en de RAID-Z onderbrengen, maar ik zou dat niet doen. Als er iets met je RAID-Z gebeurt dan heb je niets aan de RAID-Z2 bescherming met 2 parity disks. Met aparte pools voorkom je dus dat de RAID-Z2 te lijden heeft onder de mindere bescherming die RAID-Z van 3 disks biedt.

Je kunt in ZFSguru de pool create pagina gebruiken om de pool aan te maken en de Expansion tab om een nieuwe vdev toe te voegen; maar in mijn voorstel hierboven gaat het om twee losse pools dus maak je (nu nog geen) gebruik van expansion tab. Wel kun je later als je nog schijven erbij koopt, je 3-disk RAID-Z misschien verwijderen en een tweede 6-disk RAID-Z2 aan je hoofdpool toevoegen, zodra je uitbreidt naar 12 disks. Dat meer voor de toekomst enzo, zodat je nog perspectief hebt mocht je meer data willen kunnen opslaan.

[Femme]

Wat ook nog kan is een zpool bestaande uit drie vdev's met drie disks in raid-z. Dat levert je 12TB opslagcapaciteit op en zal het beste presteren. De prestaties van raid-z en raid-z2 schalen matig bij een toenemend aantal disks.

[Verwijderd]

Dat komt vooral omdat bij meer disks de stripesize per disk heel laag wordt. Maar een 6-disk RAID-Z2 heeft maar 4 data disks dus 128K / 4 = 32K blocks. Dat is nog best goed te doen hoor; de overhead wordt pas groot bij 16K en 8K blocks, waarbij je snelheid omlaag gaat.

Maar het zijn allemaal afwegingen, want een grote RAID-Z2 biedt zowel bescherming als lage overhead. Een 10-disk RAID-Z2 bijvoorbeeld heeft maar 20% redundancy terwijl het wel 2 disk failures kan opvangen. Dan is het mogelijk niet zo erg dat je iets mindere performance scaling hebt dan meerdere vdevs.

En hij wilde ook RAID-Z2 vanwege bescherming; dat kwam eerst en daarna pas performance. Performance is dus niet het hoofddoel, en de gigabit is in combinatie met grote bestanden toch de logische bottleneck.

[iRReeL]

Ik heb nu pas geupdate naar beta4 vanwege virtual box en het ziet er erg goed uit Virtual box werkt en ook sabnzb etc. Mooi werk

[Dadona]

FireDrunk schreef op woensdag 15 februari 2012 @ 14:36:
Je hebt dus echt 2 verschillende pools, en niet alleen 2 vdev's? Merk je dat dan niet in performance? Of heb je zo'n asociale batterij disks?

Ja, ja, nee. Ik heb twee Pools met elk drie schijven. Zou ik één pool hebben met twee vdevs dan zou de tweede set ook online zijn. Als mijn backup dan wat langer zou duren (single disc aan de zendende kant) dan ben ik zes schijven aan het bezighouden. Daarnaast vraag ik mij af wat de prestaties sowieso zijn bij een combinatie van 4KB (we20ears) en 512kB (f3eg).

[FireDrunk]

Zolang je ashift gebruikt maakt dat toch maar minimaal uit? 4K sturen naar een 512b disk is wat langzamer (omdat het intern 4 IO's worden), maar 512b sturen naar een 4k disk is veel erger (omdat je disk voor elke random 512bytes 4k moet overschrijven.)

[ Voor 23% gewijzigd door FireDrunk op 16-02-2012 13:06 ]

[matty___]

ik zie hier alleen wd en samsung hd's langskomen.

niemand ervaring met de 2TB/3TB schijven van hitachi? (Deskstar 7K3000)

zijn nog steeds 512bit schijven en lekker snel (7200 + 64mb cache)

[magistus]

Hier naar volle tevredenheid 4x2 TB Hitachi's (en 16x400G). Geen idee qua snelheden, zijn allemaal LUKS-versleuteld dus dat is wel een vertragende factor, naast de niet ideale 4-disks in RAIDZ1 en geforceerde ashift=12 setting

[ Voor 60% gewijzigd door magistus op 17-04-2012 22:55 . Reden: nevermind, geen dode disk maar ZFS fragmentatie issues ]

[Verwijderd]

Hitachi en Samsung zijn mijn favoriete merken; het meest innoverend met nieuwe plattergrootte's. Wellicht ook om die reden overgenomen; te snel innoverend en dus een spelbreker voor de winsten van de grotere fabrikanten: Seagate en Western Digital. Twee merken waar ik weinig mee heb; deze willen het liefst zo langzaam mogelijk innoveren en komen zeer langzaam met nieuwe plattergroottes. Vaak ook minder snel, zuinig en stil dan Samsung bijvoorbeeld. Maar de verschillen zijn ook weer niet supergroot; toch is het jammer dat we afgelopen jaren eigenlijk geen vooruitgang hebben geboekt op gebied van mechanische storage. 1TB platter disks zijn er ook nog nauwelijks.

Dat de meeste Hitachi schijven nog 512-byte sectoren hebben kan handig zijn als je een niet-optimale RAID-Z wilt aanmaken. De cache-grootte is totaal irrelevant. Een paar megabyte hebben schijven nodig om write buffering en read-ahead toe te passen; maar schijven worden echt niet opeens beter door de 16MB cache chip te vervangen door 256MB of iets in die richting. Je RAM is toch altijd groter en cached dus veel meer.

Zaken om naar te kijken bij hardeschijven:
1) plattergrootte; plattergrootte; plattergrootte; belangrijke spec van elke hardeschijf
2) spindle speed (5400/7200rpm)
3) SATA interface (SATA/600 heeft iets lagere latency dan SATA/300)

De Hitachi 5K4000 en de 7K4000 gebruiken 1TB platters. Edit: lijken toch 800GB platters te zijn. Alleen de 7K1000.D en 5K1000.B zijn 1TB platters.

[ Voor 3% gewijzigd door Verwijderd op 16-02-2012 17:37 ]

[matty___]

Verwijderd schreef op donderdag 16 februari 2012 @ 16:51:


Dat de meeste Hitachi schijven nog 512-byte sectoren hebben kan handig zijn als je een niet-optimale RAID-Z wilt aanmaken.

Wat versta je onder niet optimaal? ik dacht dat juist de 4k langzamer zijn en dat shift ook maar een noodoplossing is

[Verwijderd]

Optimale configuraties:
- alle mirrors
- alle stripes
- RAID-Z: 3, 5, 9 disks
- RAID-Z2: 4, 6, 10 disks
- RAID-Z3: 5, 7, 11, 19 disks

Bij RAID-Z is het belangrijk dat je met een power-of-two aantal data schijven uitkomt. Een 6-disk RAID-Z2 heeft 2 (virtuele) parity disks en dus 4 data schijven. Je krijgt dan 128K / 4 = 32K en dat is een getal wat goed werkt met 4K sectors (32K/4K levert geen breuk op maar een geheel getal, dus hoeft er geen emulatie plaats te vinden).

4K sectors zijn sneller en kunnen meer ruimte op de platter gebruiken voor de opslag van data. Ze hebben ook per sector meer ECC beschikbaar, maar de hoeveelheid data en dus kans op bitflips is ook toegenomen. De uBER blijft dus ongeveer gelijk; de rate waar schijven de gegevens niet meer kunnen lezen door onvoldoende ECC correctie.

Ashift een noodoplossing? Nee hoor, dat is prima geregeld. Tijdens het aanmaken van je pool wordt gekeken naar de disk met de grootste sectorsize. Deze instelling wordt gebruikt voor alle disks; omdat het verband houdt met hoe ZFS data schrijft met name bij RAID-Z.

ashift=9 betekent 2^9 = 512 bytes
ashift=12 betekent 2^12 = 4 kilobytes

Dat is de praktijk, maar theoretisch zijn ook andere ashift-waarden mogelijk, zoals 8K sector disks of zelfs lager dan 512 bytes, wat zeer ongebruikelijk is overigens. Maar ik snap niet waarom ashift een noodoplossing is? Dat geldt eerder voor andere filesystems, die altijd maar 512 bytes aannemen en files op 4K boundaries alignen. ZFS is juist beter voorbereid op de toekomst met de automatische detectie van sector size.

Het punt is alleen dat Solaris zelf geen goede infrastructuur heeft voor 4K disks, maar bij FreeBSD kun je GNOP gebruiken om je 4K disk ook echt 4K sectorsize te geven. De huidige 4K schijven rapporteren namelijk als 512 bytes sectorsize om compatible te blijven met oudere software.

[matty___]

Verwijderd schreef op donderdag 16 februari 2012 @ 18:55:
Optimale configuraties:
- alle mirrors
- alle stripes
- RAID-Z: 3, 5, 9 disks
- RAID-Z2: 4, 6, 10 disks
- RAID-Z3: 5, 7, 11, 19 disks

Bij RAID-Z is het belangrijk dat je met een power-of-two aantal data schijven uitkomt. Een 6-disk RAID-Z2 heeft 2 (virtuele) parity disks en dus 4 data schijven. Je krijgt dan 128K / 4 = 32K en dat is een getal wat goed werkt met 4K sectors (32K/4K levert geen breuk op maar een geheel getal, dus hoeft er geen emulatie plaats te vinden).

4K sectors zijn sneller en kunnen meer ruimte op de platter gebruiken voor de opslag van data. Ze hebben ook per sector meer ECC beschikbaar, maar de hoeveelheid data en dus kans op bitflips is ook toegenomen. De uBER blijft dus ongeveer gelijk; de rate waar schijven de gegevens niet meer kunnen lezen door onvoldoende ECC correctie.

Ashift een noodoplossing? Nee hoor, dat is prima geregeld. Tijdens het aanmaken van je pool wordt gekeken naar de disk met de grootste sectorsize. Deze instelling wordt gebruikt voor alle disks; omdat het verband houdt met hoe ZFS data schrijft met name bij RAID-Z.

ashift=9 betekent 2^9 = 512 bytes
ashift=12 betekent 2^12 = 4 kilobytes

Dat is de praktijk, maar theoretisch zijn ook andere ashift-waarden mogelijk, zoals 8K sector disks of zelfs lager dan 512 bytes, wat zeer ongebruikelijk is overigens. Maar ik snap niet waarom ashift een noodoplossing is? Dat geldt eerder voor andere filesystems, die altijd maar 512 bytes aannemen en files op 4K boundaries alignen. ZFS is juist beter voorbereid op de toekomst met de automatische detectie van sector size.

Het punt is alleen dat Solaris zelf geen goede infrastructuur heeft voor 4K disks, maar bij FreeBSD kun je GNOP gebruiken om je 4K disk ook echt 4K sectorsize te geven. De huidige 4K schijven rapporteren namelijk als 512 bytes sectorsize om compatible te blijven met oudere software.

thx voor de uitleg. waarom ik het een noodoplossing noem is dat het toch flink voor wat posts in freebsd-current en fs heeft gezorgd tot iemand met het idee kwam om het met ashift aan te pakken

zolang je met ashift meot werken vind ik het geen nette oplossing maar dat is mijn mening.

misschien dat ze toch nog met een sectorsize parameter in zpool create komen zodat de gnop overbodig wordt.

[Verwijderd]

De ashift pool parameter zit volgens mij al sinds de originele ZFS implementatie ingebouwd, dus ik weet niet wat je bedoelt met 'met het idee kwam om het met ashift aan te pakken'?

ZFS heeft dus allang automatische detectie van sectorsize waardoor alles prima automatisch zou moeten werken. Het probleem is dat 4K schijven en SSDs sectoren nog als 512 bytes rapporteren, waardoor de automatische detectie niet werkt.

Om dit probleem te tackelen kun je met GNOP de disk een 4K sectorsize meegeven voordat je de pool aanmaakt, dan krijgt de pool een ashift=12 mee in plaats van ashift=9 en dan werkt het dus beter op 4K disks. ZFSguru heeft dit ingebouwd zodat je dat zonder commando's op de shell kunt doen. Je ziet dan een optie "Optimize for 4K disks", simpel zat.

Als er iets een noodoplossing is, dan is het wel dat 4K schijven nu nog 512 bytes rapporteren om compatible met oude software te blijven. Idealiter identificeren deze schijven gewoon 4K sectors, zodat ze ook nooit emulatie hoeven uit te voeren.

[ Voor 13% gewijzigd door Verwijderd op 16-02-2012 20:27 ]

[matty___]

Verwijderd schreef op donderdag 16 februari 2012 @ 20:26:
De ashift pool parameter zit volgens mij al sinds de originele ZFS implementatie ingebouwd, dus ik weet niet wat je bedoelt met 'met het idee kwam om het met ashift aan te pakken'?

oh? als ik een ufs aanmaak kan ik met -f 4096 dit mooi oplossen. geen gnop voor nodig. dus ik zou graag een zpool create data -f 4096 willen zien.

bij mij is -f een parameter weet niet waar jij het dan over hebt.

ja gnop is een geom class die zit er al lang in. maar dat staat totaal los van zfs imo

Als er iets een noodoplossing is, dan is het wel dat 4K schijven nu nog 512 bytes rapporteren om compatible met oude software te blijven. Idealiter identificeren deze schijven gewoon 4K sectors, zodat ze ook nooit emulatie hoeven uit te voeren.

dat zou idd de uiteindelijke oplossing zijn.

[ Voor 28% gewijzigd door matty___ op 16-02-2012 21:57 ]

[Verwijderd]

De Fragmentation size is iets anders dan sectorsize, alhoewel dat heel dicht bij elkaar ligt. In principe is de frag size gelijk aan de sector size of een veelvoud daarvan. Alle I/O is overigens altijd een veelvoud van de sector size, waarbij voornamelijk naar LBA getallen wordt gerefereerd. Als LBA0 de eerste sector is van een 4K disk, dan is LBA2 de derde sector die begint op 8K en gaat tot 12K van de disk capacity. De frag size is een filesystem attribuut wat aangeeft wat de minimum grootte per file is. Die kan groter en héél theoretisch zelfs lager zijn dan de sectorsize.

In plaats van handmatig tuning uit te voeren, heeft ZFS juist automatische detectie van de disks die je gebruikt. Als één van die disks zegt hey ik heb 4K sectors, dan wordt daar rekening mee gehouden en krijgt de pool ashift=12 mee.

Het probleem is dat die automatische detectie niet werkt voor 4K schijven die rapporteren als 512B, en je dus wél een handmatige override zou willen hebben. Die ontbreekt bij ZFS; je kunt niet met zpool create -o ashift=12 .. een pool aanmaken. Dat zou nog een aanwinst zijn, maar de GNOP-methode werkt onder BSD in elk geval prima.

[ Voor 7% gewijzigd door Verwijderd op 17-02-2012 00:36 ]

[justice strike]

ik zit mij een ongeluk te zoeken maar ik kan het nergens vinden... dus wellicht dat iemand het hier weet.

Weet iemand wat de processor requirements zijn tov the throughput van ee zfs partitie. Het enige wat ik kwa requirements kan vinden is dat je veel geheugen nodig hebt.

Het lijkt me echter dat de checksumming toch wel enige beperkingen opleggen aan de maximum throughput. Ik wil namelijk een servertje bouwen met een ultra low power g540 (voor 24/7 draaien). Ik heb echter het donkerubruine vermoeden dat deze wat underpowered zal worden voor een zfs server.

iemand die hier wat helderheid over kan verschaffen?

[CurlyMo]

justice strike schreef op vrijdag 17 februari 2012 @ 08:21:
ik zit mij een ongeluk te zoeken maar ik kan het nergens vinden... dus wellicht dat iemand het hier weet.

Weet iemand wat de processor requirements zijn tov the throughput van ee zfs partitie. Het enige wat ik kwa requirements kan vinden is dat je veel geheugen nodig hebt.

Het lijkt me echter dat de checksumming toch wel enige beperkingen opleggen aan de maximum throughput. Ik wil namelijk een servertje bouwen met een ultra low power g540 (voor 24/7 draaien). Ik heb echter het donkerubruine vermoeden dat deze wat underpowered zal worden voor een zfs server.

iemand die hier wat helderheid over kan verschaffen?

Ja, alle hedendaagse processoren gaan dat gewoon met gemak kunnen, mits je geen compressie en dedup gebruikt. Er zijn eerder berichten geweest over proc. usage voor een parity berekeningen en die is echt minimaal.

[justice strike]

CurlyMo schreef op vrijdag 17 februari 2012 @ 09:12:
[...]


Ja, alle hedendaagse processoren gaan dat gewoon met gemak kunnen, mits je geen compressie en dedup gebruikt. Er zijn eerder berichten geweest over proc. usage voor een parity berekeningen en die is echt minimaal.

en hoe zit het dan met compressie en dedup?

[ Voor 5% gewijzigd door justice strike op 08-03-2013 09:43 ]

[DrFlash]

justice strike schreef op vrijdag 17 februari 2012 @ 10:32:
[...]

en hoe zit het dan met compressie en dedup?

deze gebruiken veel cpu cycles omdat er juist op dat moment veel berekend moet worden. normale opslag kost niet zoveel cpu maar wel veel IO waarbij de IO over het algemeen eerst door het geheugen loopt ook vanwege caching.

[justice strike]

DrFlash schreef op vrijdag 17 februari 2012 @ 11:09:
[...]


deze gebruiken veel cpu cycles omdat er juist op dat moment veel berekend moet worden. normale opslag kost niet zoveel cpu maar wel veel IO waarbij de IO over het algemeen eerst door het geheugen loopt ook vanwege caching.

ok maar in welke orde van grootte hebben we het dan over? want ik kan daar geen zinnige vergelijkingen over vinden.

[Verwijderd]

Ik draai ZFS ook op een ultra low-power AMD Geode chipje van 2W met 1GB RAM. Nee, dan wordt het geen snelheidsmonster, maar als je gewoon standaard storage zonder CPU-verslindende features gebruikt dan gaat het prima werken.

De-dup is een heel ander geval; daar heb je veel L1ARC en L2ARC voor nodig. Als je deduptabels niet in de L1 of L2 cache passen, gaat het extreem traag worden. LZJB compressie kan wel op bijvoorbeeld het filesystem waar je logs worden weggeschreven (/var) maar GZIP compressie moet je niet doen.

Checksums kosten helemaal niet veel CPU performance nee, de meeste CPU kracht is nodig voor het opsparen en knippen en plakken van I/O requests. Dit is vooral geheugen-intensief.

Maar Justice Strike; wat wil je precies bereiken? Er zijn genoeg low-power builds besproken hier, die tegen de 10W aan het stopcontact verbruiken. Denk je daar onder te komen? Verder geef je ook geen details wat voor configuratie (disks, ram, controller) je denkt nodig te hebben. Je zult zelf eerst duidelijk moeten aangeven wat je wilt voordat ik hier specifieker op kan ingaan. Maar low-power ZFS is zeker mogelijk; ik draai het en anderen ook.

[Ultraman]

Ik gebruik een Athlon II 245 in mijn server, en ik heb ook een Athlon X2 4600+ gebruikt. Een Celeron G540 is naar mijn verwachting vlotter dan die twee. En zowel de A245 als 4600+ deden alles op hun sloffen. Ook lzjb compressie is geen enkel probleem, of je zou een extreem veel I/O en slecht comprimeerbare files moeten hebben. Maar je gebruikt compressie toch niet op een volume waar je files op zet die slecht comprimeren.

Maak je dus niet druk dat je processorkracht tekort zou komen, dan kom je heus niet met een Celeron G540.

Daarnaast zag ik een aantal posts terug een vraag over performance van ashift=12 op 512b disks?
Ik kan daar geen tot verwaarloosbaar verschil in performance ontdekken. Die benchmark heb ik o.a. gedaan met bonnie++ op een single Hitachi 5K3000 2TB disk.

[Verwijderd]

Waren die Hitachi disks niet 512-byte sector? Ah zo, dat was ook de opzet.

Nee het punt van die ashift=12 is dat 4K sector disks geen emulatie te hoeven uitvoeren, omdat ze zich voordoen als 512-byte sector schijven. Normale schijven met 512-bytes sectoren doen helemaal geen emulatie, dus zie ik ook niet in hoe dat sneller zou kunnen zijn. Eerder langzamer voor kleine bestandjes, omdat je veel ongebruikte ruimte in je sectoren ongebruikt laat.

De 'slack' (verspilling door allocation) wordt dus groter naarmate de ashift hoger wordt. Dit is alleen een probleem als je filesystem veel kleine bestandjes bevat, zoals een kleine USB stick met allemaal systeembestanden kan mogelijk een probleem worden.

Dus in principe gewoon ashift=9 gebruiken (hoef je niets voor te doen) voor 512B disks. Maar besef je wel dat als in de toekomst native 4K schijven uitkomen die zich ook als 4K sectors identificeren, dat je die NIET kunt toevoegen aan je ashift=9 pool!

[ Voor 103% gewijzigd door Verwijderd op 17-02-2012 23:37 ]

[Ultraman]

Verwijderd schreef op vrijdag 17 februari 2012 @ 23:32:
Waren die Hitachi disks niet 512-byte sector? Ah zo, dat was ook de opzet.

Nee het punt van die ashift=12 is dat 4K sector disks geen emulatie te hoeven uitvoeren, omdat ze zich voordoen als 512-byte sector schijven. Normale schijven met 512-bytes sectoren doen helemaal geen emulatie, dus zie ik ook niet in hoe dat sneller zou kunnen zijn. Eerder langzamer voor kleine bestandjes, omdat je veel ongebruikte ruimte in je sectoren ongebruikt laat.

Klopt. Zolang 4K schijven 512b emulatie blijven doen zullen/kunnen we er omheen werken door met GNOP virtuele apparaten te maken met een 4K sector size.

De 'slack' (verspilling door allocation) wordt dus groter naarmate de ashift hoger wordt. Dit is alleen een probleem als je filesystem veel kleine bestandjes bevat, zoals een kleine USB stick met allemaal systeembestanden kan mogelijk een probleem worden.

Inderdaad, dat is een klein nadeel. Maar, zoals je al aangeeft, merk je daar alleen wat van wanneer je met veel kleine files werkt. Ik gebruik mijn ztank pool, met ashift=12, enkel voor /home op mijn server. Qua kleine files valt dat mee, enkel een handjevol dotfiles en wat git repositories. Het merendeel van dat grote volume wordt ingenomen door muziek, video en foto's, plus nog een stapel ebooks welke ook met gemak boven de 4K uit komen.

Mijn root (zroot/freebsd9[/subdirs]) staat op een aparte zroot pool, welke uit een mirror van 320GB schijven bestaat.
Binnen dezelfde pool zit tevens een zroot/incoming filesystem welke gebruikt wordt door downloads, bijvoorbeeld middels torrents. Die blijven daar maar tijdelijk, wat bewaard wordt verhuist naar de ztank en de rest verdwijnt weer. Zo voorkom ik fragmentatie op mijn ztank en omdat ze op zroot weer gedelete worden komt daar de ruimte ook weer vrij.

Dus in principe gewoon ashift=9 gebruiken (hoef je niets voor te doen) voor 512B disks. Maar besef je wel dat als in de toekomst native 4K schijven uitkomen die zich ook als 4K sectors identificeren, dat je die NIET kunt toevoegen aan je ashift=9 pool!

Dit is de hoofdreden dat ik van ztank een ashift=12 heb gemaakt, met 512b schijven. Ik ondervind geen hinder van ashift=12 op dat volume, terwijl ik wel een disk zonder problemen kan vervangen met een Advanced Format (4K) schijf mocht dat ooit nodig zijn.

[fluppie007]

De server is sinds vannacht eindelijk up and running ! Heb hulp gehad van een vaardige tweaker !
Vanmorgen na een hele nacht files kopiëren dan maar gelijk eens gebenchmarked .

Bootschijf met FreeBSD en VM's in VirtualBox
Intel X25-M 120GB SSD

ZFSguru 0.2.0-beta5 pool benchmark
Pool : OpstartZFS (111G, 13% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 256.6 MB/s = 244.7 MiB/s
Write throughput: 88.1 MB/s = 84 MiB/s

RAID-Z pool
3x Samsung 204UI F4EG 2TB

ZFSguru 0.2.0-beta5 pool benchmark
Pool : Storage1ZFS (5.44T, 50% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 172.3 MB/s = 164.4 MiB/s
Write throughput: 182.5 MB/s = 174.1 MiB/s

Raid-Z2 pool
6x Samsung 204UI F4EG 2TB

ZFSguru 0.2.0-beta5 pool benchmark
Pool : Storage2ZFS (10.9T, 25% full)
Test size : 64 GiB
Data source : /dev/zero
Read throughput : 345.3 MB/s = 329.3 MiB/s
Write throughput: 412.3 MB/s = 393.2 MiB/s

[justice strike]

Verwijderd schreef op vrijdag 17 februari 2012 @ 15:33:
Maar Justice Strike; wat wil je precies bereiken? Er zijn genoeg low-power builds besproken hier, die tegen de 10W aan het stopcontact verbruiken. Denk je daar onder te komen? Verder geef je ook geen details wat voor configuratie (disks, ram, controller) je denkt nodig te hebben. Je zult zelf eerst duidelijk moeten aangeven wat je wilt voordat ik hier specifieker op kan ingaan. Maar low-power ZFS is zeker mogelijk; ik draai het en anderen ook.

Ik wil een huidige dual athlon 1600 mp vervangen met een low power server. Daarbij gaat het voornamelijk om het draaien als samba server en webserver.

Ik wil dat hij wat minder stroom gebruikt dan nu, de schijven die er in komen zijn hoogstwaarschijnlijk een set oude 160gb seagates (4 stuks) en een set nieuwe 500gb schijven daarbij gaat het voornamelijk om crash recovery. Dus dat betekent z2 (waarschijnlijk). Ik wil het goedkoop doen, maar ik wil er voor waken dat ik niet een te langzame cpu koop. Ik zat te denken aan 8 tot 16 gb. SSD zal ik waarschijnlijk niet doen (tenzij het ergens goedkoop op de kop te tikken is)

[webfreakz.nl]

justice strike schreef op zaterdag 18 februari 2012 @ 13:40:
[...]

Kijk eens naar Verwijderd in "Het grote DIY RAID NAS topic deel 3" en de posts ervoor / erna.

Wat voldoet er aan die builds niet voor jouw situatie?

Pas dat binnen het budget? Zo nee, wat is dan je budget..

Je hebt het over "een set nieuwe 500gb schijven", hoeveel stuks zijn dat er dan? 2? 3? 4? 4+?

[justice strike]

webfreakz.nl schreef op zaterdag 18 februari 2012 @ 14:45:
[...]


Kijk eens naar Verwijderd in "Het grote DIY RAID NAS topic deel 3" en de posts ervoor / erna.

Wat voldoet er aan die builds niet voor jouw situatie?

Pas dat binnen het budget? Zo nee, wat is dan je budget..

Je hebt het over "een set nieuwe 500gb schijven", hoeveel stuks zijn dat er dan? 2? 3? 4? 4+?

dat past wel binnen het budget. Maar het gaat er niet alleen om om een systeem te bouwen, maar ook dat ik inzicht heb in hoe de processor load zich verhoudt met deze zaken.

ik dacht zelf aan een intel low power processor en wat desktop schijven. Aangezien die schijven er al zijn gaat dat dus niet in combinatie met die pico psu.

[mca2]

Na enig pielen heb ik mijn server draaien:
- Athlon 3000+
- 3GB pc3200
- 3 x 320GB 7200rpm WD PATA (ZFS-pool)
- 1 x 200GB 7200rpm WD PATA (OS)

Ik draai nu FreeBSD 9.0 met zpool v28 en zfs v5

code:

FreeBSD FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:15:25 UTC 2012     [e-mail]:/usr/obj/usr/src/sys/GENERIC  i386

Ik heb om de eerste performance te bekijken even een grote zpool RaidZ gemaakt van de 3 x 320GB en ben eens in de weer gegaan met Bonnie:

code:

[root@FreeBSD /tank]# bonnie++ -d /tank -s 6000 -r 3000 -u root
Using uid:0, gid:0.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
FreeBSD       6000M    49  95 41043  25 19207   9   141  97 42791   8  71.3   2
Latency              1802ms    2002ms    1442ms     284ms   51687us    9833ms
Version  1.96       ------Sequential Create------ --------Random Create--------
FreeBSD             -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 11923  94 +++++ +++ 11232  97  8826  69 +++++ +++ 11068  95
Latency             27764us     175us     221us     210ms      87us     195us
1.96,1.96,FreeBSD,1,1329609041,6000M,,49,95,41043,25,19207,9,141,97,42791,8,71.3,2,16,,,,,11923,94,+++++,+++,11232,97,8826,69,+++++,+++,11068,95,1802ms,2002ms,1442ms,284ms,51687us,9833ms,27764us,175us,221us,210ms,87us,195us

Is dit een handig bonnie commando om mee te benchen en is de performance goed/slecht? En heeft er iemand suggesties voor tuning instellingen zoals prefetch en kmem?

[FireDrunk]

40MB/s lezen en schrijven. Is niet echt heel veel, maar erg denderende specs heb je ook weer niet.
Je zou geforceerd prefetching aan kunnen zetten, maar met 3GB is dat niet aan te raden.

[matty___]

mca2 schreef op zondag 19 februari 2012 @ 09:25:

[/code]

Is dit een handig bonnie commando om mee te benchen en is de performance goed/slecht? En heeft er iemand suggesties voor tuning instellingen zoals prefetch en kmem?

bonnie en iobench zijn echte benchmark tools die verschillende zaken testen. je kunt met de verschillende raid sets spelen en afhankelijk van je workload de juiste kiezen.

veel random io heb je meer aan raid10 etc is mijn ervaring. (raidz1 met 4 disks -> bittorrent client die eerst het bestand aanmaakt met 000 en en het dan stukje voor stukje opvuld -> kopieren naar andere schijf -> 10mb/s )

met kmem win je nix en daar moet je vanaf blijven tenzij je met erg weinig geheugen werkt of op i386.

prefetch moet je uitproberen wat beter voor je werkt. ik heb het aanstaan met 4gb

[ Voor 12% gewijzigd door matty___ op 19-02-2012 13:09 ]

[justice strike]

nog een andere vraag (waar ik het antwoord niet vna kan vinden). Maakt het eigenlijk nog uit of je een betrouwbare ssd hebt voor zil of l2arc? Ik zat namelijk te denken. IPV geld uit te geven aan een dure ssd kun je ook een paar goedkope (maar onbetrouwbare) sandforce schijven halen die alles versnellen (moet kunnen toch voor cache? of is dit niet een slim idee?)

[matty___]

justice strike schreef op zondag 19 februari 2012 @ 14:14:
nog een andere vraag (waar ik het antwoord niet vna kan vinden). Maakt het eigenlijk nog uit of je een betrouwbare ssd hebt voor zil of l2arc? Ik zat namelijk te denken. IPV geld uit te geven aan een dure ssd kun je ook een paar goedkope (maar onbetrouwbare) sandforce schijven halen die alles versnellen (moet kunnen toch voor cache? of is dit niet een slim idee?)

ssd van samsung of een m4?

waarvoor ga je de server gebruiken? ten slotte heb je pas iets aan de cache als het blokje voor een 2de keer wordt opgehaald en het niet in de arc past.

vervolgens wordt wel je lan de bottlenek.

[ Voor 16% gewijzigd door matty___ op 19-02-2012 14:24 ]

[Ultraman]

justice strike schreef op zondag 19 februari 2012 @ 14:14:
nog een andere vraag (waar ik het antwoord niet vna kan vinden). Maakt het eigenlijk nog uit of je een betrouwbare ssd hebt voor zil of l2arc? Ik zat namelijk te denken. IPV geld uit te geven aan een dure ssd kun je ook een paar goedkope (maar onbetrouwbare) sandforce schijven halen die alles versnellen (moet kunnen toch voor cache? of is dit niet een slim idee?)

Voor L2ARC hoef je geen dure jongen met bijvoorbeeld supercaps te pakken. Het gaat immers om cache.
Als jij zeker weet dat je baat hebt bij L2ARC, dan kun je hiervoor een goedkopere SSD prima inzetten.
Mocht die SSD er uit klappen of anderzijds in rook op gaan dan heb je enkel geen L2ARC meer.

Voor ZIL wil je meer betrouwbaarheid. Voor pool versie 19 was het zelfs zo dat indien een extern LOG device defect raakte je de kans liep dat je je pool verloor. Dat is gelukkig niet meer zo.
Echter als je de ZIL op een SSD hebt staan zonder supercaps en de stroom valt weg tijdens een schrijfoperatie is de kans wel aanwezig dat je data verliest omdat de SSD nog niet zijn eigen buffers naar het flash geheugen heeft kunnen wegschrijven, of nog erger: gedeeltes overschrijft die deze niet moest overschrijven of halverwege het bijwerken van zijn data tabellen stopt en corrupt raakt. Daarom raad men aan om een SSD met supercaps te gebruiken voor ZIL, omdat zij hun write netjes kunnen beëndigen, wat dus de duurdere SSDs zijn.
Hier is zeker meer over geschreven in deze draad; CiPHER zal daar vast ergens een hele duidelijke post over hebben gemaakt. Zoek eens rond of je zoiets kutn vinden of op het web waarom een duurdere SSD voor ZIL wordt aangeraden als je (meer) onderbouwing wilt zien.
Verder is het natuurlijk ook afhankelijk van de data die je op ZFS pools gaat zetten. Als het veel media files zijn of bestanden waar je anderszijds toch een backup van gaat hebben, kun je het risico ook voor lief nemen en twee goedkope SSDs mirroren of nog iets meer risico nemen met een single

Ben je er verder van overtuigt dat je profijt hebt van een L2ARC en SLOG ?
Want dat is wel afhankelijk van je workload. Zeker voor SLOG geldt dat het pas echt helpt wanneer er (veel) (kleinere) sync writes worden gedaan. Dus een situatie waar hard disks en hun seek tijden een bottleneck vormen.

En je kunt het ook altijd eerst zonder L2ARC en SLOG device gaan proberen. Misschien is die performance wel goed genoeg voor je. Ik weet niet wat je van plan bent of wat de workload gaat zijn, dat weet jij

Daarbij gaat het voornamelijk om het draaien als samba server en webserver.

Vond net bovenstaande quote. Hoe grootschalig ga je? Is dit voor jou persoonlijk of is dit een server waar veel mensen (simultaan) gebruik van maken?
Alleen je Samba kan leunen op sync writes, maar volgens mij is dat een kwestie van hoe je deze configureert.
In de hoek van sync mounted NFS shares, iSCSI en databases, is waar je echt sync writes hebt. Dus ik vraag me af of je je wel druk hoeft te maken over een separate ZIL.

[ Voor 25% gewijzigd door Ultraman op 19-02-2012 15:01 ]

[Verwijderd]

mca2 schreef op zondag 19 februari 2012 @ 09:25:
Na enig pielen heb ik mijn server draaien:
- Athlon 3000+
- 3GB pc3200
- 3 x 320GB 7200rpm WD PATA (ZFS-pool)
- 1 x 200GB 7200rpm WD PATA (OS)

Besef je dat deze schijven veel stroom trekken. 4 oude schijfjes = 4x8W = 32W. Ongeveer evenveel als 55 notebookschijven. Bij het opspinnen zitten ze vaak tegen de 30W per stuk aan.

Het draaien van deze schijven kost je per jaar dus 64 euro voor de schijven alleen; oftewel 5 euro per maand. Je kunt FreeBSD/ZFSguru direct naar je ZFS pool installeren, dan heb je geen losse 200GB systeemdisk nodig. Scheelt alweer 16 euro per jaar.

Ik draai nu FreeBSD 9.0 met zpool v28 en zfs v5

Je hebt geen 64-bit CPU? Dat is een GROOT nadeel!

Is dit een handig bonnie commando om mee te benchen en is de performance goed/slecht? En heeft er iemand suggesties voor tuning instellingen zoals prefetch en kmem?

Bonnie is niet een heel geschikte benchmarks omdat het geen cooldown toepast. Terwijl ZFS nog data aan het schrijven is, start bonnie alweer de volgende bench. Bonnie is net als HDTune alleen geschikt voor standaard storage en niet voor RAID arrays.

Bovendien moet je test size ongeveer 8 keer je RAM filecache zijn. Dus 64GiB testen ipv 6GiB. Het beste doe je dat met dd:

# dd write 64GB file:
dd if=/dev/zero of=/pad/naar/storage/zerofile.dat bs=1m count=64000

# dd read file again
dd if=/pad/naar/storage/zerofile.dat of=/dev/null bs=1m

Zorg wel dat compressie is uitgeschakeld op het filesystem waar je naartoe schrijft (compressie staat standaard uit).

[mca2]

FireDrunk schreef op zondag 19 februari 2012 @ 11:05:
40MB/s lezen en schrijven. Is niet echt heel veel, maar erg denderende specs heb je ook weer niet.
Je zou geforceerd prefetching aan kunnen zetten, maar met 3GB is dat niet aan te raden.

Ik dacht dat ZFS vooral veel plezier had van geheugen en niet zo zeer cpu. Of is de PATA interface ook zoveel slechter dan SATA en geeft dat nog veel winst?

Verwijderd schreef op zondag 19 februari 2012 @ 14:59:
[...]

Besef je dat deze schijven veel stroom trekken. 4 oude schijfjes = 4x8W = 32W. Ongeveer evenveel als 55 notebookschijven. Bij het opspinnen zitten ze vaak tegen de 30W per stuk aan.

Het draaien van deze schijven kost je per jaar dus 64 euro voor de schijven alleen; oftewel 5 euro per maand. Je kunt FreeBSD/ZFSguru direct naar je ZFS pool installeren, dan heb je geen losse 200GB systeemdisk nodig. Scheelt alweer 16 euro per jaar.

Sja, die 3 x 320 had ik nog liggen. Ik zat ook te kijken naar 3 x 2TB setup op een brazos bordje maar dat is met de huidige HDD prijzen belachelijk en kwam ik totaal op een kleine 500euro. Dus deze zijn voor de time-being. En ik weet dat je je OS ook in de pool kan zetten maar ik wil de pool laten downspinnen, dat scheelt weer wat verbruik.

[...]
Je hebt geen 64-bit CPU? Dat is een GROOT nadeel!

Ehhh, ik heb een Athlon 64 3000+ Ik ga zo maar eens in de weer met de AMD64 distro

[...]
Bonnie is niet een heel geschikte benchmarks omdat het geen cooldown toepast. Terwijl ZFS nog data aan het schrijven is, start bonnie alweer de volgende bench. Bonnie is net als HDTune alleen geschikt voor standaard storage en niet voor RAID arrays.

Bovendien moet je test size ongeveer 8 keer je RAM filecache zijn. Dus 64GiB testen ipv 6GiB. Het beste doe je dat met dd:

# dd write 64GB file:
dd if=/dev/zero of=/pad/naar/storage/zerofile.dat bs=1m count=64000

# dd read file again
dd if=/pad/naar/storage/zerofile.dat of=/dev/null bs=1m

Zorg wel dat compressie is uitgeschakeld op het filesystem waar je naartoe schrijft (compressie staat standaard uit).

Compressie staat uit maar ik zal eens met dd in de weer.

[ Voor 0% gewijzigd door mca2 op 19-02-2012 17:01 . Reden: typo ]

[FireDrunk]

Ik denk dat x64 vs x86 het probleem vooral is

[matty___]

Verwijderd schreef op zondag 19 februari 2012 @ 14:59:


Bonnie is niet een heel geschikte benchmarks omdat het geen cooldown toepast. Terwijl ZFS nog data aan het schrijven is, start bonnie alweer de volgende bench. Bonnie is net als HDTune alleen geschikt voor standaard storage en niet voor RAID arrays.

Als je flink data aan het overpompen bent pas je toch ook geen cooldown toe?

[Verwijderd]

Voor en na de benchmark. Het punt is dat Bonnie verschillende benchmarks doet en daartussen geen cooldown toepast. Dus na het schrijven is bonnie klaar en begint met de leestest, terwijl write-mechanismes waaronder ZFS dan nog writes in hun buffer hebben. Bij de handmatige dd tests moet je zelf wachten na de write test, of een 'sync' uitvoeren zoals ik vaak doe.

Daarnaast is ook de test grootte belangrijk. Als deze te laag is, kan een groot gedeelte van de writes en vervolgens reads volledig in de RAM uitgevoerd worden, dus dan test je niet je disk I/O maar je buffercache performance. Je test size moet grofweg 8 keer je RAM zijn voor een nauwkeurige meting.

[mca2]

Verwijderd schreef op zondag 19 februari 2012 @ 14:59:
[...]
Bovendien moet je test size ongeveer 8 keer je RAM filecache zijn. Dus 64GiB testen ipv 6GiB. Het beste doe je dat met dd:

# dd write 64GB file:
dd if=/dev/zero of=/pad/naar/storage/zerofile.dat bs=1m count=64000

# dd read file again
dd if=/pad/naar/storage/zerofile.dat of=/dev/null bs=1m

Na enig stoeien draait de boel weer en nu onder AMD64

code:

FreeBSD FreeBSD 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012     [e-mail]:/usr/obj/usr/src/sys/GENERIC  amd64

Ik heb 3GB geheugen dus ik heb het bij 24GB testfiles gehouden (duurt ook minder lang en ZFS krijgt toch maar 2GB om mee te spelen) met de volgende resultaten:

code:

[user@FreeBSD /tank]$ dd if=/dev/zero of=/tank/zerofile.dat bs=1m count=24000
24000+0 records in
24000+0 records out
25165824000 bytes transferred in 415.263798 secs (60602018 bytes/sec)

[user@FreeBSD /tank]$ dd if=/tank/zerofile.dat of=/dev/null bs=1m
24000+0 records in
24000+0 records out
25165824000 bytes transferred in 407.419089 secs (61768888 bytes/sec)

Dus zo'n 58MB/s schrijven en 59MB/s lezen. Wat moeten we daar nou eens van zeggen…

Tijdens de test bleef de kernel zitten op 19MB geheugengebruik, dan een hele tijd niets en de bovenste 2GB gingen natuurlijk helemaal vol. Valt hier nog wat te winnen? Of stel dat ik ik er nog 1GB bij stop, wordt het daar veel sneller van?

[Verwijderd]

Op wat voor controllers zitten je disks? Mag ik je zpool status output eens zien?

[justice strike]

Ultraman schreef op zondag 19 februari 2012 @ 14:42:
[...]
Vond net bovenstaande quote. Hoe grootschalig ga je? Is dit voor jou persoonlijk of is dit een server waar veel mensen (simultaan) gebruik van maken?
Alleen je Samba kan leunen op sync writes, maar volgens mij is dat een kwestie van hoe je deze configureert.
In de hoek van sync mounted NFS shares, iSCSI en databases, is waar je echt sync writes hebt. Dus ik vraag me af of je je wel druk hoeft te maken over een separate ZIL.

Nou het is een server waar 3 mensen op gaan werken (+ webserver). Ik wil het in principe beschikbaar stellen via gigabit, en wil dat iedereen het gebruikt alsof het een lokal schijf is (omdat mensen zo koppig zijn om niet te backuppen). Dus dat wordt een d schijf of een map in de documenten structuur.

Wat dat betreft zijn er dus 2 zaken waar ik denk dat de bottleneck zal zitten.

1. gigabit... het is niet makkelijk deze vol te trekken. Toentertijd emt een athlon 1600 kreeg ik max 40 tot 60 mb per sec over gigabit... hier was de processor een bottleneck.

2. Ik wil zfs z2 raid gebruiken (dus double parity) ook een processor intensive proces.

Als de server maar snel genoeg is om lokaal aan te voelen dan ben ik tevree. In het ergste geval dus 3 clients over een gigabit lijn.

Ik denk dus dat er met name 3 dingen zijn waar ik goed op moet letten.

1. Hoeveel proc power kost het voor het berekenen van double parity.
2. Hoeveel proc power is er nodig voor gigabit (maar dit is wellicht een punt wat niet meer speelt)
3. moet er ivm kleine documenten gedacht worden aan l2arc of zil drive.

[Femme]

Ik ben hier aan het testen met een doos die pieken haalt van 1GB/s over quad port fibre channel en ik heb nog nooit een hoge processorbelasting gezien. Het ding heeft een 2,2GHz quad-core Opteron-processor. Zolang je geen compressie en/of dedupe doet is de processorbelasting minimaal. Aangezien jij slechts gigabit ethernet hebt kan de cpu-belasting nooit hoog worden want die zal afhankelijk zijn van de transfer rate.

L2arc zal zeker helpen om de prestaties te verbeteren. Een logdevice heeft alleen zin als er synchrone schrijfacties plaatsvinden. In mijn tests met ntfs op een zvol is de hoeveelheid synchrone schrijfacties minimaal gebleken. In het beste geval leverde een logdevice een prestatiewinst op van vijf procent. Ik zou eerst eens een partitie van een ssd of een losse drive die je nog over hebt als logdevice inzetten zodat je via zpool iostat -v kunt zien of er veel naar geschreven wordt.

[Verwijderd]

Een betere tool zal zijn arcstat. Een script die gebruik maakt kstat counters.

[Femme]

De arcstat.pl die ik ergens vandaan heb gevist geeft me volgens mij alleen stats over de adaptive replacement cache en niet de zfs intent log. Voor arc-stats vind ik arc_summary.pl veel nuttiger.

[Verwijderd]

er is ook een zil stat

[iRReeL]

Ik heb een melding op de disk pagina van high load cycles maar het lukt mij niet dit te verhelpen. Het liefste zou ik een spindown van 1 of 2 uur willen instellen maar het zijn WD Green EARS disks dus wellicht kunnen ze ook continue blijven draaien. Verder zitten 8 disks van de pool op een M1015 dus ik begrijp dat spindown ook erg lastig is.

ada0 Healthy 30°C • 86°F 277 91909 0 0 active • 0 passive 1.1 years
da3 Healthy 26°C • 79°F 280 85123 0 0 active • 0 passive 1.1 years

Bij de disks>advanced krijg ik geen opties om de APM op 254 in te stellen?
Disk Power APM AAM
ada0 ready unknown unknown

Volgens camcontrol Identify heeft de disk geen APM opties?
device model WDC WD20EARS-00MVWB0
firmware revision 50.0AB50
serial number WD-WMAZA0029253
WWN 50014ee600348083

PIO supported PIO4
DMA supported WDMA2 UDMA6

Feature Support Enabled Value Vendor
read ahead yes yes
write cache yes yes
flush cache yes yes
overlap no
Tagged Command Queuing (TCQ) no no
Native Command Queuing (NCQ) yes 32 tags
SMART yes yes
microcode download yes yes
security yes no
power management yes yes
advanced power management no no
automatic acoustic management yes no 254/0xFE 128/0x80
media status notification no no
power-up in Standby yes no
write-read-verify no no
unload no no
free-fall no no
data set management (TRIM) no

Dit nog geprobeerd om APM uit te schakelen maar krijg een "error sending command"
camcontrol cmd ada0 -a "EF 85 00 00 00 00 00 00 00 00 00 00"

Iemand een idee hoe ik dan spindown kan instellen / uitschakelen?

[Dadona]

Google eens op wdidle3, komt door de headpark van WD

[mca2]

Verwijderd schreef op maandag 20 februari 2012 @ 00:38:
Op wat voor controllers zitten je disks? Mag ik je zpool status output eens zien?

Ze zitten alle vier op de onboard ata-133 controller van de nvidia nforce4 chipset.

code:

[user@FreeBSD ~]$ zpool status
  pool: tank
 state: ONLINE
 scan: scrub repaired 0 in 0h5m with 0 errors on Sun Feb 19 23:20:14 2012
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            ada1    ONLINE       0     0     0
            ada2    ONLINE       0     0     0
            ada3    ONLINE       0     0     0

errors: No known data errors

[Verwijderd]

Wat voor performance verwacht je hiervan? Het heeft de performance van 1 enkele disk dus lijkt me helemaal zo gek nog niet?

[mca2]

Verwijderd schreef op maandag 20 februari 2012 @ 21:55:
Wat voor performance verwacht je hiervan? Het heeft de performance van 1 enkele disk dus lijkt me helemaal zo gek nog niet?

Uhh, theoretisch gezien zou een schijf 133MB/s moeten doen. 70 a 80 MB/s zou een individuele schijf toch wel moeten kunnen doen?

[Verwijderd]

ZFS spreekt je devices tegelijk aan; bij PATA moeten ze op elkaar wachten. Dus dat is het probleem. Als je elke schijf een eigen PATA kabel geeft zal het al beter gaan. Maar misschien dat die PATA gewoon op PCI bus zit? Ik weet niet hoe dat vroeger ging. Ik weet wel dat in die tijd de gigabit LAN vaak op de PCI bus zat ook in de tijd dat chipsets al PCI-express hadden, althans best vaak; was waarschijnlijk goedkoper nog in die tijd.

ZFS werkt lekker als elke schijf 'dedicated' bandwidth heeft. Met name de latencies zjin belangrijk. Je kunt eens met gstat -a kijken naar je schijven en de latencyverschillen bekijken. Die zouden sterk moeten wisselen zelfs met simpele sequential workloads.

[ Voor 23% gewijzigd door Verwijderd op 20-02-2012 23:32 ]

[Ultraman]

Die PATA controller zal waarschijnlijk in de South Bridge zitten ingebakken en het is goed mogelijk dat de South Bridge middels een HyperTransport Link aan de North Bridge hangt, waardoor je daar niet een dergelijke bottleneck zou hebben.
Echter sla je de spijker op zijn kop betreffende de PATA controller zelf. Per kanaal is theoretisch maximum 133MB/s. Zodra jij twee apparaten aan één kanaal hangt zal die bandbreedte dus gedeeld moeten worden. En aangezien er tegen de 60MB/s gehaald wordt lijkt dat te gebeuren.

[FireDrunk]

Ter verduidelijking van Ultraman:

nForce design tussen 4 en 750 verschilt niet zoveel.

[ Voor 6% gewijzigd door FireDrunk op 21-02-2012 09:29 ]

[justice strike]

Femme schreef op maandag 20 februari 2012 @ 10:30:
Ik ben hier aan het testen met een doos die pieken haalt van 1GB/s over quad port fibre channel en ik heb nog nooit een hoge processorbelasting gezien. Het ding heeft een 2,2GHz quad-core Opteron-processor. Zolang je geen compressie en/of dedupe doet is de processorbelasting minimaal. Aangezien jij slechts gigabit ethernet hebt kan de cpu-belasting nooit hoog worden want die zal afhankelijk zijn van de transfer rate.

L2arc zal zeker helpen om de prestaties te verbeteren. Een logdevice heeft alleen zin als er synchrone schrijfacties plaatsvinden. In mijn tests met ntfs op een zvol is de hoeveelheid synchrone schrijfacties minimaal gebleken. In het beste geval leverde een logdevice een prestatiewinst op van vijf procent. Ik zou eerst eens een partitie van een ssd of een losse drive die je nog over hebt als logdevice inzetten zodat je via zpool iostat -v kunt zien of er veel naar geschreven wordt.

Ik meen mij te vergissen. Maar ik dacht altijd dat parity toch een processor intensive berekening was (mede ook de reden waarom software raid vroeger nooit echt aansloeg).

De normale cpu's zouden geen problemen moeten hebben maar het lijkt mij dat double parity toch wel flink inhakt op de prestaties van een atom of een fusion processor (zoals hierboven geopperd is). Of heb ik het nu echt helemaal bij het verkeerde eind (fyi ik had nog een 3ware escalade gekocht omdat de athlon 1600 xp het niet trok en ik dacht dat de atom daar net onder zat kwa prestaties).

[Femme]

justice strike schreef op dinsdag 21 februari 2012 @ 12:21:
[...]

Ik meen mij te vergissen. Maar ik dacht altijd dat parity toch een processor intensive berekening was (mede ook de reden waarom software raid vroeger nooit echt aansloeg).

De normale cpu's zouden geen problemen moeten hebben maar het lijkt mij dat double parity toch wel flink inhakt op de prestaties van een atom of een fusion processor (zoals hierboven geopperd is). Of heb ik het nu echt helemaal bij het verkeerde eind (fyi ik had nog een 3ware escalade gekocht omdat de athlon 1600 xp het niet trok en ik dacht dat de atom daar net onder zat kwa prestaties).

Ik haalde zeven jaar geleden met een 1,4GHz Opteron al schrijfsnelheden van 400MB/s op een HighPoint-raidadapter die de cpu gebruikte voor parityberekening. Op een doosje dat aan een gigabit netwerk hangt en dus sowieso niet met meer dan 125MB/s zal schrijven zal parityberekening echt geen bottleneck zijn.

[The Executer]

Ik ben een beetje aan het spelen met Freenas (8.0.3) op een VM om eens te kijken wat het beste gaat bevallen. Nu ben ik bekend dat er niet "zomaar" schijven toegevoegd kunnen worden. Nu ben ik aan het kijken op welke manier dit op te lossen is.

Ik heb een pool aangemaakt, waarin 4 schijven zitten. De pool draait gewoon, is benaderbaar etc. Nu heb ik nog 4 schijven toegevoegd aan de VM. Hoe krijg ik deze nu aan de bestaande pool, zodat deze groter wordt? Moet ik dan de schijven aan de pool toevoegen, of moet ik een 2e raidset aanmaken van die 4 schijven, en ze dan toevoegen? Gister heb ik hiervan wel wat informatie gevonden, maar op deze manier zou je meer ruimte kwijtraken dan wanneer je direct alle schijven in een pool hangt. Ik kan de pagina niet meer terugvinden waarop dit stond. Iemand die mij een zetje kan geven in de goede richting?

[CurlyMo]

The Executer schreef op dinsdag 21 februari 2012 @ 14:07: een 2e raidset aanmaken van die 4 schijven, en ze dan toevoegen?

Bij deze het setje in de goede richting De manier die je hier beschrijft is de enige manier waarop je een ZFS pool kunt uitbreiden.

[The Executer]

CurlyMo schreef op dinsdag 21 februari 2012 @ 14:19:
[...]


Bij deze het setje in de goede richting De manier die je hier beschrijft is de enige manier waarop je een ZFS pool kunt uitbreiden.

Dan heb ik dat dus goed begrepen. Binnen de Freenas webgui kan ik wel een 2e volume aanmaken, maar dit wordt een 2e pool. Moet ik dan de 2e pool koppelen aan de 1e? En klopt het dat je met deze manier dan schijfruimte verliest ten opzichte van een volledige pool van bijvoorbeeld 8 schijven?

[Femme]

Is het niet makkelijker om gewoon de command-line te gebruiken?

zpool add tank raidz1 disk1 disk2 disk3

en hoppa je hebt een vdev met drie disks in raid-z1 aan je pool toegevoegd. Dat gedoe met een gui (napp-it) ben ik al meteen mee gekapt toen ik zag hoe simpel de syntax van de zfs tools is.

[ Voor 24% gewijzigd door Femme op 21-02-2012 14:30 ]

[FireDrunk]

Wat zou beter zijn:

4 Mirrors van 2 disks ( 8 disks totaal ), of 3 RAIDZ pools VDEV's van 3 disks ( 9 disks ) in 1 pool?

[ Voor 10% gewijzigd door FireDrunk op 21-02-2012 14:40 ]

[Femme]

Het verschil tussen raid-10, raid-z1 en raid-z2 is in normaal desktopgebruik (als je zfs gebruikt in een san via iscsi, fibre channel oid) niet zo groot. Raid-10 is meestal wel iets sneller bij een gelijk aantal disks. Je ziet het verschil vooral in de random i/o-prestaties die veel hoger zijn in raid-10 of een constructie waarin meerdere raid-z1-vdev's worden gestriped.

Ik denk dat een stripe van drie raid-z1-vdev's in dit geval meestal wel sneller zal zijn.

[Verwijderd]

Voor random read zouden de mirrors koning moeten zijn, omdat mirror vdevs afzonderlijk kunnen worden aangesproken. De twee RAID-Z vdevs doen I/O per groep van 3, en je kan disk 1 dus niet iets anders laten doen dan disk 2.

In veel gevallen is de lagere random I/O van RAID-Z niet zo erg, omdat je met L2ARC caching en SLOG buffering de hardeschijven voornamelijk sequential I/O laat doen, waar RAID-Z vaak beter in is dan mirror doordat je meer schijven effectief beschikbaar hebt om data naar te schrijven.

En nog reactie op hierboven ergens:

justice strike schreef op dinsdag 21 februari 2012 @ 12:21:
[...]

Ik meen mij te vergissen. Maar ik dacht altijd dat parity toch een processor intensive berekening was (mede ook de reden waarom software raid vroeger nooit echt aansloeg).

Daar zit je dus helemaal naast. Oude CPUs zijn prima in staat ontzettend snel pariteit te berekenen. Dat is extreem simpel en helemaal niet het zwaarste onderdeel van een RAID5 driver.

Als je Ubuntu Linux opstart, kun je tijdens de boot een mini-benchmark voorbij zien komen; waar je kunt zien dat zelfs oude systemen sneller dan 5 gigabyte per seconde parity kunnen uitrekenen. Maar een RAID5 driver doet veel meer. De meeste CPU-tijd gaat zitten in het knippen en plakken van I/O request; de combine-engine. Die is constant requests aan het opsparen en knipt en voegt ze samen tot blokjes met een specifieke 'magische' grootte. RAID5 schrijft maar iets van 10MB/s zonder deze write combine techniek.

De reden dat RAID niet echt is doorgedrongen tot het Windows platform is zijn slechte ondersteuning. Windows boot niet of nauwelijks van software RAID en de eigen software RAID voorzieningen zijn erg karig. Daarom dat Hardware RAID groot is geworden, iets wat misschien wel nooit was gebeurd als Windows goede RAID-ondersteuning had ingebouwd. Dan gebruikten we nu allemaal software RAID omdat er geen reden is dit te offloaden naar een aparte dure RAID-kaart.

Conclusie: je kunt prima RAID6 / double parity RAID laten uitvoeren door je AMD Brazos low-power processortje; werkt prima.

[ Voor 61% gewijzigd door Verwijderd op 21-02-2012 15:19 ]

[FireDrunk]

4 vdev's zijn wel veel beter voor de stripe (veelvoud van 2) dan dat de RAIDZ zijn (3 vdev's).
Er zul dus neem ik aan alleen een hoge sequential read zijn, als de software ook daadwerkelijk wat queue depth doet, en niet sequentieel grote blokken opvraagd, of denk ik verkeerd?

[Mescaline]

Weet iemand of er met deze ontwikkelingen ook over nagedacht wordt om het uitbreiden van de vdev's mogelijk te maken, zonder meteen weer nieuwe parity te moeten offeren?

Het laatste wat ik er over gehoord heb is dat er geen reallocatie-mogelijkheden zijn ontwikkeld, die wel nodig zouden zijn om dit mogelijk te maken (en da's ook heel logisch als je naar het on-disk formaat kijkt), maar da's alweer een jaartje ofzo geleden.

[CurlyMo]

Mescaline schreef op dinsdag 21 februari 2012 @ 16:08:
Weet iemand of er met deze ontwikkelingen ook over nagedacht wordt om het uitbreiden van de vdev's mogelijk te maken, zonder meteen weer nieuwe parity te moeten offeren?

Het laatste wat ik er over gehoord heb is dat er geen reallocatie-mogelijkheden zijn ontwikkeld, die wel nodig zouden zijn om dit mogelijk te maken (en da's ook heel logisch als je naar het on-disk formaat kijkt), maar da's alweer een jaartje ofzo geleden.

Die mogelijkheden staan inderdaad in de planning maar zoals je weet zijn er nog steeds problemen met de licentie van ZFS door Oracle. Hierdoor kan de opensource community max. versie 28 aanbieden. Mocht dit veranderen door bijv. de onlangs gelekte broncode versie 31 (dacht ik) dan zal dit forum een van de eerste plaatsen zijn waarop je hoort

Uitbreiden van alleen de vdev's zonder nieuwe parity is dus nog steeds niet mogelijk.

[FireDrunk]

Veel van de developers van de originele ZFS zitten tegenwoordig bij NetApp heb ik gehoord (zitten vast ZFS features in WAFL te knutselen), dus ik gok dat er veel dingen op een laag pitje staan.

Aan de andere kant is de FreeBSD community bereid gevonden om toch door te gaan met developen van ZFS.
Probleem blijft dat als Oracle ZFS toch geheel opensource maakt en alles gaat vrijgeven, het misschien voor kan komen dat bij het mergen van code problemen ontstaan. Ook dat maakt weer dat er niet echt veel nieuwe features aan ZFS toegevoegd worden, maar dat vooral stabiliteit en performance tweaks gedaan worden.

[donnie1992]

Iemand die mij wat duidelijkheid kan verschaffen hierover?
HP Microserver ZFS+ Freenas naar Ubuntu & XMBC

[Verwijderd]

Bij NetApp zitten ze niet believe me =) Ze zitten bi Delphix, Joyent of Nexenta niet alleen ZFS ontwikkelaars trouwens.

[FireDrunk]

Tis maar wat ik hier bij een bedrijf gehoord heb waar we 3500 NetApp's hebben staan, dus ik geloof mijn bron wel . De harde kern misschien niet, maar als er zakjes met geld rinkelen, gaan veel mensen overstag

Ondanks alles heb (ook) ik het gevoel dat de ontwikkeling van ZFS niet super hard gaat.

[ Voor 17% gewijzigd door FireDrunk op 21-02-2012 22:21 ]

[Verwijderd]

- zfs resumable send/recv
- zfs written properties
- new libzfs (libzfscore)
- ZIO io throttle
- vele fixes
- zfs properties
- deferred destroy (background)

kan nog wel wat oprakelen dus ik denk dat je hooguit de verkeerde bronnen leest. Maar geloof jij rustig je netapp mannen als ze niet de hardcore mensen hebben hebben ze mooi de verkeerde

[CurlyMo]

Verwijderd schreef op dinsdag 21 februari 2012 @ 23:26:
- zfs resumable send/recv
- zfs written properties
- new libzfs (libzfscore)
- ZIO io throttle
- vele fixes
- zfs properties
- deferred destroy (background)

kan nog wel wat oprakelen dus ik denk dat je hooguit de verkeerde bronnen leest. Maar geloof jij rustig je netapp mannen als ze niet de hardcore mensen hebben hebben ze mooi de verkeerde

Aangezien we niet allemaal sporadisch hier langskomen en een rake opmerking plaatsen is het misschien goed om de opmerkingen die je plaatst wat meer toe te lichten. Ik heb namelijk niet echt een idee wat precies deze features/fixed inhouden. Dus graag meer toelichting!

[FireDrunk]

Ik zeg ook niet dat ik blij ben dat NetApp zich ermee bemoeid Liever niet zelfs. NetApps zijn leuk, maar *veel* te duur voor wat ze kunnen. Laat Oracle ZFS lekker opensource maken, dan heeft iedereen er wat aan

[Verwijderd]

Okay fair enough.

Zfs send/recv heeft geen resume optie. Dus je start het en kan het niet stoppen of je moet overnieuw beginnen, best lastig. Door speciale markers wordt er remote bijgehouden over hoe ver je was. Dit lijkt simpel, maar zfs end-to-end verhaal? is nog best veel werk omdat halve hashes berekend moeten worden want je wilt niet op het einde pas de checksum mismatch vinden. Ook is hiervoor een berekening nodig hoe groot de delta is (weet je nu niet) en bij zpool slit moet je reguid kunne gebruiken.

zfs written properties, staan toe dat je tussen snapshots kan zien wat er is geschreven en zfs een voorspelling kan geven hoeveel ruimte je vrij maakt na het verwijderen van een snapshot(s). Tevens als je nu snapshots wilt verwijderen kun je een range opgeven.

libzfs: deze is niet stabiel. Het enige stabiele is het zfs/zpool commando die geen program interface op leveren voor bedrijfven als delphix en nexenta die veel met ZFS doen. De nieuwe libzfs zal dingen bevatten als:

zfs_create( nv_list_t *names, nv_list_t *options, nvlist_list_t **results) een dunne laag naar de ioctl. Verder is libzfs niet threadsafe wat ook voor de nodig problemen kan zorgen vooral met 5000+ datasets.


de fixes, o.a

l2arc lekt, SLOG regressie, etc.. etc

zfs properties:

om er voor te zorgen dat ondisk format consistent blijft komen er extra properties bij die er voor kunnen zorgen dat zpool versie A functie A wel ondersteunt en zpool versie B niet. Het wel of niet hebben properties moet je dan expliciet op enabled zetten. Ook een disable zorgt voor reverten van functies als het mogelijk is, dit is belangrijk om differentiatie tussen bv. BSD pools en illumos based pools te voorkomen. Dit is heel veel werk geweest en heeft zowaar 1 van de weinige bits gekost die de blk_pt nog over heeft.

zio throttle:

simpel een dataset trottle op basis van zones zodat je per dataset kan opgeven hoeveel IO er mag gedaan worden. (vertalen: pr0n hogere PRIO dan dan download itunes)

Hope that helps

[Bolk]

nieuws: Intel introduceert opvolger caching-ssd

Ideale L2ARC/SLOG device?

[FireDrunk]

Waarom? €5,- / GiB. Das duur...

[Verwijderd]

Je wilt liever MLC hebben; meer opslag per euro, meer performance per euro. SLC is alleen nodig voor speciale gevallen. En een 20GB 25nm SLC en 64GB 25nm MLC verschilt ook niet zo bijster veel in write endurance, als het je daar om ging.

Het punt is vooral dat een kleine 20GB SSD meer write cycles nodig heeft dan dat je een veel grotere SSD als cache zou gebruiken. De Intel 311 is totaal niet interessant voor ZFS.

Bovendien heeft de 311 geen supercaps; dus SLOG valt al gelijk af. De Crucial M4 64GB is een veel betere cachingschijf.

[Verwijderd]

ZeusRAM voor SLOG, ZeusIOPS voor L2ARC.

[Verwijderd]

Leuk, maar een Intel 320 valt denk ik eerder in het budget voor een hobby NAS.

Een Crucial M4 64GB doet bijvoorbeeld al 60.000+ random read IOps, leuk als L2ARC.

Ik vind het altijd een uitdaging een kwalitatief zo goed mogelijke setup te bouwen voor zo weinig mogelijk geld. Het gaat dus bijvoorbeeld om performance per euro en niet zozeer om absolute prestaties. Een batterij van zulke disks kan uitstekend concurreren met de 120.000 IOps van ZeusIOps en tegen flink lagere kosten.

[FireDrunk]

120k iops valt inderdaad wel mee toch? 4 Crucials haal je dat vast ook mee?

[Verwijderd]

Ja, mits je voldoende ruimte reserveert als spare; anders zakt de IOps wel in. Ook is die IOps gemeten met 8GiB LBA range; de IOps met full LBA range zijn vaak flink lager. Het kan zijn dat de ZeusIOPS het daar flink beter doet dan de Crucial.

Maar toch; ik kies liever voor snelle goedkope SSDs en dan lekker veel ervan. Dan heb je een leuker product dan een enkel duur product wat je ook niet kan opsplitsen naar verschillende systemen; iets wat ik veel doe met hardware.

[FireDrunk]

Precies, Mocht ik overstappen op ZFS, dan heb ik 4 * Instel Postville 80GB SSD's liggen om in die bak te stoppen Dat moet toch zeker wel 2 of 4 * gigabit vol krijgen

[Megalith]

Na een aantal dingen uitgeprobeerd te hebben op verschillende platforms (FreeNas, ZFSGuru en OpenIndiana) heb ik mijn ZFS testserver icm OpenIndiana +Nappit en fibrechannel ook aan de gang. Testsysteempje bestaat uit een Core i3 2100, 16GB RAM, Intel 320 120GB SSD en vier WD20EARS (2TB) in een RAIDZ2 opstelling met de SSD als read-cache device.
FreeBSD was eerder eigenlijk al afgevallen omdat er geen LDAP ondersteuning in de kernel ingebouwd zat en mijn fibrechannel hba niet native ondersteund werd (HP FC2242, rebranded Emulex LPe11002 DP). Initiator is een Server 2008 bak die deze target in eerste instantie alleen zal gebruiken om Hyper-V machines op op te slaan. Als de opstelling me na een aantal maanden testen goed bevalt zal ik ook de raid6 set van mijn areca naar zfs migreren. Maar daar ben ik nog een beetje voorzichtig mee omdat ik het OS niet zo goed ken dat ik alle familiefoto's ed. er zomaar aan over wil laten.

Ik moet zeggen dat ik ontzettend blij ben geworden van de presaties van ZFS! Het is alleen erg jammer dat Solaris (voor zover ik weet) geen ondersteuning biedt om je SSD zowel als read als write cache te gebruiken. Het gebruik van read cache is erg goed te zien in de CrystalDisk benchmark, uitgevoerd op de Windows server, dus over FibreChannel. Al helemaal omdat er slechts twee disks gebruikt worden. Bij quedepth 32 bijna 56k IOPS bij read actions en maar 1600 write IOPS.


VS CrystalDisk benchmark op de Areca


ZFS version is nu nog 15, maar wellicht dat ik hem wil upgraden naar 28 zodat ik hem bij hoge nood ook nog kan importen onder FreeBSD. Verder heb ik ook nog geen tuning o.i.d gedaan. Iemand tips voor tuningoptions die de (write) performance positief beïnvloeden?

[Femme]

fcg123 schreef op donderdag 23 februari 2012 @ 17:27:
Solaris (voor zover ik weet) geen ondersteuning biedt om je SSD zowel als read als write cache te gebruiken.

Dat kan gewoon. Via format > partition kun je de ssd in partities opdelen en die partities kun je vervolgens als cache of log device inzetten. De guid van het ding is dan guid van de disk op +s0 (of ander nummer van de partitie, dus de eerste partitie van c28t5002538043584D30d0 heet c28t5002538043584D30d0s0). Ik heb alleen begrepen dat Solaris in dat geval geen controle meer heeft over de write back cache van het log device en deze niet geforceerd kan flushen, maar het is de vraag in hoeverre dat belangrijk is bij ssd's.

[ Voor 14% gewijzigd door Femme op 23-02-2012 17:38 ]

[CurlyMo]

Femme schreef op donderdag 23 februari 2012 @ 17:35:
[...]


Dat kan gewoon. Via format > partition kun je de ssd in partities opdelen en die partities kun je vervolgens als cache of log device inzetten. De guid van het ding is dan guid van de disk op +s0 (of ander nummer van de partitie, dus de eerste partitie van c28t5002538043584D30d0 heet c28t5002538043584D30d0s0). Ik heb alleen begrepen dat Solaris in dat geval geen controle meer heeft over de write back cache van het log device en deze niet geforceerd kan flushen, maar het is de vraag in hoeverre dat belangrijk is bij ssd's.

Volgens mij was de conclusie tussen een discussie tussen Gila en CiPHER hier dat Solaris dit ondertussen wel ondersteund.

[Verwijderd]

Volgens Gila was dat inderdaad het geval, en sloeg de beperking van FLUSH commando's alleen op het UFS bestandssysteem, wat onder Solaris geen flushes kan sturen o.i.d. Het had volgens Gila niets te maken met het advies alleen 'whole disks' te gebruiken volgens de Solaris best practices guide.

Voor cache is het gemis van flush niet erg want dat zijn toch async writes. Voor SLOG ligt dat natuurlijk heel anders aangezien die juist dedicated sync writes krijgt en niets anders.

[ Voor 14% gewijzigd door Verwijderd op 23-02-2012 17:50 ]