Het grote ZFS topic

[Verwijderd]

Volgens die link:

Now testing raidz2 configuration with 4 disks......@......@......@
READ: 161 MiB/sec 157 MiB/sec 158 MiB/sec = 159 MiB/sec avg
WRITE: 50 MiB/sec 49 MiB/sec 50 MiB/sec = 50 MiB/sec avg

Now testing raidz2 configuration with 6 disks......@......@......@
READ: 402 MiB/sec 400 MiB/sec 402 MiB/sec = 401 MiB/sec avg
WRITE: 232 MiB/sec 234 MiB/sec 234 MiB/sec = 234 MiB/sec avg

Dat zijn toch redelijk grote verschillen van een 6 disk RAID-Z2 versus 4 disk. Ook wil ik opmerken dat dit de max snelheden zijn die je zonder SSD ooit op die pool zult zien; naarmate de pool gevuld wordt en HDDs op het langzamere gedeelte werken en fragmentatie ook toeneemt, zal de performance afnemen. Om die reden wil je een gezonde marge hebben zodat je in elk geval je gigabit link wel optimaal kunt benutten.

[voodooless]

Dat is dus de allereerste bench... Kijk even wat pagina's verder, dan zul je zien dat de verschillen best wel meevallen.

[Verwijderd]

alle begin is moeilijk

wat ik eigenlijk wilde zien is de sector size nu ik 4 dezelfde 204 drives in een pool heb
ashift=9 means optimized for 512-byte sectors
ashift=12 means optimized for 4K sectors

en ik lees het volgende mbt L2ARC cache :

'I have zfs cache (L2ARC) on SSD ocz revox2.

But i read that L2ARC was designed to either improve performance or do nothing, so there isn't
anything that should be bad. To explain what is meant by do nothing - if you
use the L2ARC for a streaming or sequential workload, then the L2ARC will
mostly ignore it and not cache it. This is because the default L2ARC settings
assume you are using current SSD devices, where caching random read
workloads is most favorable.

Anybody know how i can tune L2ARC's settings for working L2ARC with a streaming or sequential workload?

In FreeNAS 8 RC4:
freenas# sysctl vfs.zfs.l2arc_noprefetch
vfs.zfs.l2arc_noprefetch: 0

But I don't know how I can edit sysctl.conf for working vfs.zfs.l2arc_noprefetch=1 after reboot? '

als je nu voornamelijk films streamt vanaf je zfs pool .. dan heeft een cache geen zin want zfs gebruikt het toch niet ?

* iets gevonden :

There are some changes that can be made to improve performance in certain situations and avoid the bursty IO that's often seen with ZFS.

Loader tunables (in /boot/loader.conf):

# Disable ZFS prefetching

# http://southbrain.com/sou...are-comes-slowly-zfs.html
# Increases overall speed of ZFS, but when disk flushing/writes occur,
# system is less responsive (due to extreme disk I/O).
# NOTE: Systems with 4 GB of RAM or more have prefetch enabled by default.
vfs.zfs.prefetch_disable="1"

# Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This
# should increase throughput and decrease the "bursty" stalls that
# happen during immense I/O with ZFS.
# http://lists.freebsd.org/...2009-December/007343.html
# http://lists.freebsd.org/...2009-December/007355.html
vfs.zfs.txg.timeout="5"

Sysctl variables (/etc/sysctl.conf):


# Increase number of vnodes; we've seen vfs.numvnodes reach 115,000
# at times. Default max is a little over 200,000. Playing it safe...
# If numvnodes reaches maxvnode performance substantially decreases.
kern.maxvnodes=250000


# Set TXG write limit to a lower threshold. This helps "level out"
# the throughput rate (see "zpool iostat"). A value of 256MB works well
# for systems with 4 GB of RAM, while 1 GB works well for us w/ 8 GB on
# disks which have 64 MB cache. <<BR>>

vfs.zfs.txg.write_limit_override=1073741824

Be aware that the vfs.zfs.txg.write_limit_override tuning you see above
may need to be adjusted for your system. It's up to you to figure out
what works best in your environment.

[ Voor 147% gewijzigd door Verwijderd op 10-04-2011 15:59 ]

[FireDrunk]

Nee, cache heeft eigenlijk nooit zin voor film data.. De data van films word maar 1 keer gelezen, niet meerdere keren.. Cache is er om veel opgevraagde data snel te kunnen leveren.. Het heeft niet eens zoveel te maken met sequentieel of random, maar met hoe vaak dezelfde data opgevraagd word.

[Verwijderd]

FireDrunk schreef op zondag 10 april 2011 @ 13:59:
Nee, cache heeft eigenlijk nooit zin voor film data.. De data van films word maar 1 keer gelezen, niet meerdere keren.. Cache is er om veel opgevraagde data snel te kunnen leveren.. Het heeft niet eens zoveel te maken met sequentieel of random, maar met hoe vaak dezelfde data opgevraagd word.

ok.. logisch maar toch stelt iemand die vraag op het ZFS gedeelte van het FreeNAS forum.

weet jij btw antwoord op die andere vraag, hoe ik vanaf de commandline in freenas de sectorsize op kan vragen ? had iets gezien van: zdb -e <poolname> | grep ashift maar dat werkt niet ..

[FireDrunk]

Uh, ik zal vanavond eens kijken, dan ben ik weer in de gelegenheid om mijn ZFS bak aan te slingeren

[leuk_he]

kut

bedoelde je

code:

su

Verwijderd schreef op zondag 10 april 2011 @ 14:06:
[...]

weet jij btw antwoord op die andere vraag, hoe ik vanaf de commandline in freenas de sectorsize op kan vragen ? had iets gezien van: zdb -e <poolname> | grep ashift maar dat werkt niet ..

http://opensolaris.org/jive/thread.jspa?messageID=506409

zdb -C

Werkt echter niet op freenas. ik kreeg het niet aan de gang.

sectorsize zou ook per vdev moeten zijn.

Overigens als je enkel met zfs wil experimenteren zou je beter opensolaris/openindiana of met solaris express 11 (testing only license) kunnen test, daar draait de laatste versie van zfs en zfs is immers het best geintegreed op solaris system

[Verwijderd]

FireDrunk schreef op zondag 10 april 2011 @ 15:13:
Uh, ik zal vanavond eens kijken, dan ben ik weer in de gelegenheid om mijn ZFS bak aan te slingeren

na een terrasje..zou ik niet doen

[Verwijderd]

Werkt echter niet op freenas. ik kreeg het niet aan de gang.

gelukkig..ligt het is een keer niet aan mij

[Verwijderd]

zdb -e <naamvandepool> | grep ashift

Werkt dat wel? <naamvandepool> vervangen door de naam. Kan wel zijn dat FreeNAS dingen als grep mist; dat is wel irritant; sommige cruciale basisdingen zijn eruit gestript.

Sectorsize kun je direct controleren met diskinfo:
diskinfo -v /dev/ad4

Maar dat is vrijwel altijd 512 bytes ook voor Samsung F4 die 4K sector native is maar 512 bytes emuleert. Dus daar kun je niet veel aan zien, behalve als je met GNOP gaat spelen, die sectorsize van 512 bytes naar 4K kan veranderen, maar werkt maar eenmalig (niet na een reboot). De ashift methode is wel een goede; ZFS blijft dan de disks als 4K sector disks beschouwen ook al is de sectorsize weer terug naar 512-byte ipv 4K.

Overigens als je enkel met zfs wil experimenteren zou je beter opensolaris/openindiana of met solaris express 11 (testing only license) kunnen test, daar draait de laatste versie van zfs en zfs is immers het best geintegreed op solaris system

Solaris heeft inderdaad wel wat voordelen boven FreeBSD (kernel-level CIFS en iSCSI driver; beter memory allocation; nieuwere ZFS versies), maar heeft ook nadelen:
- Solaris kan niet booten van RAID-Z / RAID-Z2; eigenlijk alleen van makkelijke levels zoals single disks en mirrors
- Solaris kan alleen flush commando's sturen op whole disks en niet op partities; een groot gemis vooral als je een SSD wilt partitioneren voor meerdere functies
- Solaris mist een GEOM I/O framework die bijvoorbeeld veilig kan optimaliseren voor 4K sector disks

Ook is de hardware support van Solaris wat minder dan BSD, maar Linux staat daar weer boven. Uiteindelijk kunnen het dus allerlei redenen zijn om voor je nieuwe ZFS NAS voor het een of het ander te kiezen, ik zou niet direct willen stellen dat Solaris de betere keuze is. Waarschijnlijk heeft FreeBSD zelfs een betere toekomst, omdat het niet vastzit aan een commerciëel bedrijf als Oracle. SE11 is nog niet vrijgegeven onder CDDL als ik het goed begrepen heb.

Wat betreft toekomst van ZFS is het enigszins onzeker. IllumOS en FreeBSD zouden samen verder sleutelen aan ZFS, buiten Oracle om. Elke code die Oracle als CCDL uitgeeft zou geimporteerd kunnen worden, tot nu is de laatste CDDL versie 28. Dat is ook de versie die FreeBSD 9 op dit moment draait, en komt waarschijnlijk ook naar de volgende 8.3 release. In de mailinglists valt te lezen dat ZFS v28 op FreeBSD al goed draait door het harde werk van een handjevol ZFS devs. De verwachting was dat er over een maand ZFS v28 stabiel verklaard kan worden en naar 8-STABLE geïmporteerd wordt.

Best goed nieuws dus; ZFS is echt niet dood zoals sommigen zeiden na de overname. Nu draai ik overigens nog ZFS v15; een goede stabiele release met alle core ZFS functies. Wel mis je dan de-duplication (v21) en encryption (v30) - maar zelf vind ik de "remove log device" functionaliteit van v19 de grootste reden om over te stappen; dan is het gebruik van SLOG op een SSD een stuk veiliger geworden en kun je met 4 gigabyte SSD ruimte al enorm de snelheid van je pool verhogen.

[Verwijderd]

ZFS v28 ? dan is FreeNAS 8 alweer flink achterhaald voor het uitkomt ..

[ Voor 3% gewijzigd door Verwijderd op 10-04-2011 16:55 ]

[leuk_he]

Verwijderd schreef op zondag 10 april 2011 @ 16:49:
ZFS v28 ? dan is FreeNAS 8 alweer flink achterhaald voor het uitkomt ..

Freebsd v8 heeft ook een experimentele tak waar v28(volgens mij laatste vrijgeven tak van zfs) in zit. v30/31b zit alleen in de (NOG) closed source solaris XE

[Verwijderd]

leuk_he schreef op zondag 10 april 2011 @ 17:00:
[...]


Freebsd v8 heeft ook een experimentele tak waar v28(volgens mij laatste vrijgeven tak van zfs) in zit. v30/31b zit alleen in de (NOG) closed source solaris XE

verwacht volgende week nog wat schijven en dan kan ik los (tot. 12 x 2 tb)

[FireDrunk]

12x2TB? ben je zo'n Pr0n freak?

[Verwijderd]

FireDrunk schreef op zondag 10 april 2011 @ 18:52:
12x2TB? ben je zo'n Pr0n freak?

ik wilde eigenlijk starten met 6 tb en later nog eens 6.. maar de paashaas is langsgeweest vandaar, dan maar in 1 x.. wellicht raidz3 ..maar eerst poosje prutsen.

nee , wel veel 'overig'

[FireDrunk]

Als in "Niet classificeerbare Pr0N"

[MadMike261]

Kan iemand hier mij het verschil uitleggen tussen:
- FreeBSD
- kFreeBSD (lijkt op Debian met FreeBSD kernel?, wat betekent dat voor de functionaliteit?)

En tussen:
- FreeBSD 7.4 (geen zfs?)
- FreeBSD 8.2 (wel zfs?)

Heb google gebruikt, maar blijft beetje vaag voor mij.

[FireDrunk]

kFreeBSD is Debian met een FreeBSD kernel... Beetje vreemde combinatie, maar het werkt omdat het allemaal Unix compatible is (met een beetje houtje touwtje werk)
Dat betekend dat je gewoon apt, ifconfig en de hele mikmak hebt, alleen niet de standaard Linux Kernel.
ZFS werkt er op. Maar je hebt bijvoorbeeld geen VMWare Tools...

[Verwijderd]

kFreeBSD kun je zien als Linux zonder Linux kernel. Je hebt dan dus een Ubuntu-achtig OS met verder alle voordelen van Linux, maar wel met FreeBSD kernel. Dat heeft nadelen (mindere hardware support met name) maar ook voordelen zoals dezelfde kernel-level implementatie van ZFS als in echt FreeBSD, het GEOM I/O framework, SMP innovaties, ULE CPU scheduler en andere BSD-specifieke voordelen. Grootste nieuwtje daarvan is dat je dus een soort Ubuntu met de ZFS implementatie van FreeBSD kunt hebben.

VMWare tools zijn er dacht ik wel voor FreeBSD hoor, is een port voor, die waarschijnlijk een kernel module maakt. Datzelfde geldt voor Virtualbox.

FreeBSD 7.0 is de eerste BSD versie met ZFS erin; versie 6 en nog 'experimental'.
FreeBSD 8.0 is de eerste BSD versie met een stabiel verklaarde ZFS, versie 13.
FreeBSD 7.4 is de versie die na 8.0 kwam die de 7.x branch alsnog een nieuwere versie gegeven heeft, vergelijkbaar met wat 8.0 draait.
FreeBSD 8.1 kreeg v14
FreeBSD 8.2 kreeg v15 en een heleboel fixes en andere veranderingen.
FreeBSD 9.0 kreeg een tijdje geleden v28, daarvoor waren dat losse patchsets.

FreeBSD 8.2 is nu dé release om te draaien, met ZFS v15. FreeBSD 8.3 krijgt dan v28 na de zomer ofzo, maar al daarvoor wordt v28 stabiel verklaard en verwerkt in 8-STABLE.

[Verwijderd]

zfsguru.. zelfde 'zfs motor' als FreeNAS , mijn indruk, meer snelheidsfluktuatie , min of meer even snel.

[leuk_he]

Verwijderd schreef op maandag 11 april 2011 @ 00:23:

zfsguru.. zelfde 'zfs motor' als FreeNAS , mijn indruk, meer snelheidsfluktuatie , min of meer even snel.

Heb je gezien dat er ook een 1.7 (oudere) preview versie is met een zfs pool versie 28?

/Edit: ik ben met zfs aan het experimenteren om de features, niet om de snelheid, en ja juist daarom ben ik met openindiana (met de manuals van opensolaris ) aan het testen, omdat de integratie tussen zfs en openinidana vele malen completer is dan in freenas.

[ Voor 30% gewijzigd door leuk_he op 11-04-2011 11:40 ]

[Verwijderd]

leuk_he schreef op maandag 11 april 2011 @ 10:54:
[...]

Heb je gezien dat er ook een 1.7 (oudere) preview versie is met een zfs pool versie 28?

eerlijk gezegd had ik er overheen gekeken.



is zfs pool 28 sneller tov 15 ? inmiddels OpenIndiana aan het bekijken

[ Voor 23% gewijzigd door Verwijderd op 11-04-2011 12:06 ]

[Verwijderd]

Wat betreft snelheid: dat kun je niet zomaar vergelijken. ZFS v15 kan nieuwere code hebben dan ZFS v28. De versies geven ook alleen maar veranderingen in on-disk format aan; niet de code achter ZFS zelf. Er zijn bijvoorbeeld enorm veel verbeteringen in v15 gekomen die de performance en stabiliteit sterk hebben verbeterd, maar wat geen incompatibele on-disk format changes tot gevolg heeft.

Dus een versie van ZFS is eigenlijk een ingewikkeld iets; de versies zeggen eigenlijk alleen iets over features; niet over performance.

ZFS versie 31 heeft wel een hybrid allocator, wat metadata sneller maakt op RAID-Z zonder SSDs. In feite wordt de metadata mirrored opgeslagen ipv RAID-Z wat in sommige gevallen een aardig verschil kan uitmaken. Maar verder zijn de meeste performanceverbeteringen onafhankelijk van de ZFS versies.

[Verwijderd]

Wat betreft snelheid: dat kun je niet zomaar vergelijken. ZFS v15 kan nieuwere code hebben dan ZFS v28.

OK.. maar ik, als leek, kijk gewoon naar .. 'hoe snel is mijn samba share, gisteren met FreeNAS 8 ( ZFS15) /raidz gem. 100 mb .. stabiel (schrijven / 66 lezen), daar ben ik tevreden mee.

Maar aangezien ik ook andere taken heb/wil moet ik toch naar een wat volwaardiger systeem toe (wel met ZFS), met alle gevolgen van dien want ... lezen/prutsen/falen/lezen/vragen ..

(het lijkt mij leuk om tzt een lcd info panel erin te fabrieken (via usb)...)

maar inmiddels ben ik ook bij ZFS 28 aangekomen (tussen het zonnen door)



* resultaat 1e bonnie ++ > http://img232.imageshack.us/img232/6155/bonnieone.jpg

natuurlijk een SMB share aangemaakt:
schrijven _{van windows client naar OpenIndiana zfs 28 pool :}

lezen :



- in vergelijking met FreeNAS/ZFS 15 is OpenIndiana/ZFS 28 met lezen cifs ca. 15% sneller !

ga hetzelfde nog eens proberen met een ssd cache aan de poel ..

[ Voor 35% gewijzigd door Verwijderd op 11-04-2011 20:59 ]

[FireDrunk]

Sequentieel zal het wel niet zo veel uitmaken... random uiteraard wel...

[Verwijderd]

Ik zag tijdens het schrijven af en toe wat glitches. Wil eens zien of een cache dat opvangt.

[x-RaY99]

Glitches? Dipjes in het netwerk verkeer?

Ben al enige tijd (na wat gefoeter met HP P400 en Adaptec 5805 raid controllers) aan het testen met ZFS.
Dit in combinatie met 24 2TB schijven. Als test gebruik ik hooguit 6 a 12 schijven, maar ten alle tijden heb ik last van dipjes in het netwerk, 4sec 50%, 2sec niets, 4sec 50% 2 sec niets, etc.
Hardware is een ION bordje met 1,6Ghz atom, 4gb geheugen, gbit netwerk, 8-port HBA kaartje. Snelheid tests lokaal zijn voor zover ik kan bepalen prima (ruim 100MB/s). Ook al een sneller bord geprobeerd (i.c.m. core i7, 4GB) zelfde resultaat, overigens wel hogere pieken. Zowel over FTP als CIFS, betreffen altijd grote bestanden.

Zowel met losse FreeBSD installaties als met FreeNAS. Schijven die ik gebruik zijn wel type 4kb sectors. Zou meer geheugen dit verhelpen? Lijkt net alsof het dus enkel bij netwerk verkeer fout gaat, buffer die vol loopt?

[FireDrunk]

Klinkt als een gare driver of slechte kabels... probeer eens een crosskabeltje.

[Verwijderd]

x-RaY99 schreef op dinsdag 12 april 2011 @ 08:16:
Glitches? Dipjes in het netwerk verkeer?

Zowel met losse FreeBSD installaties als met FreeNAS. Schijven die ik gebruik zijn wel type 4kb sectors. Zou meer geheugen dit verhelpen? Lijkt net alsof het dus enkel bij netwerk verkeer fout gaat, buffer die vol loopt?

idd.. had in open indiana de performance monitor mee laten lopen tijdens het schrijven van die 40 gb testfile.. en ik zag af en toe een dipje (naar 0?) in het netwerkverkeer.. prachtige screenshotjes zitten maken maar aangezien ik nogal is van os wissel zijn die ook weg

ik gebruik een aparte intel nic .. maar lijkt idd iets in het netwerkgebeuren te zijn, niet zo ernstig dat je kan spreken van een zaagtand overigens...

[Verwijderd]

FireDrunk schreef op dinsdag 12 april 2011 @ 08:37:
Klinkt als een gare driver of slechte kabels... probeer eens een crosskabeltje.

kabel kan.. ligt een 10 mtr utp los richting keuken

[Verwijderd]

Dips in het netwerkverkeer duiden waarschijnlijk op trage transaction groups. Dus geen probleem met je netwerk zelf, maar ZFS die niet snel genoeg transacties kan afsluiten. Dat kan je verhelpen met wat tuning, zodat de transacties kleiner worden. Dan heb je een lagere allround snelheid maar veel minder dips. De transactie-achtige werking van ZFS is echter wel diep begraven in het ontwerp. Sequential write is voor ZFS een best wel ingewikkelde operatie, in tegenstelling tot vrijwel alle andere filesystems (die ook veel minder bescherming bieden in zo'n situatie).

Overigens is 4GiB RAM voor 24 schijven wel extreem slecht; je haalt dan maar een fractie wat de schijven theoretisch kunnen doen (24 * 140MB/s ~= 3,3GB/s). De optimale hoeveelheid die ik heb gelezen is 2 gigabyte per hardeschijf; zodat je op 48GB voor zo'n config zou neerkomen. Dan kom je uit op 360 euro; maar dan heb je wel voldoende DIMM slots nodig. Atom platform is gelimiteerd tot 4GB en daarom als ZFS server minder geschikt. Voor max 6 disks wel prima maar 4 gig voor 24 schijven is natuurlijk wel heel dun bezaaid. Logisch dat je transaction groups erg lang duren.

Wel kun je denk ik prima performance krijgen met wat tuning, die 3,3GB/s ga je natuurlijk nooit halen met zulke hardware, maar 100MB/s zou je wel kunnen halen als alles meezit. Voor FreeBSD tuning van transaction groups kun je de volgende dingen in /boot/loader.conf zetten:

vfs.zfs.txg.write_limit_override=67108864
vfs.zfs.txg.synctime=2
vfs.zfs.txg.timeout=10

Vooral dat eerste zorgt dat je transaction groups max 64MiB groot kunnen zijn. Met deze instellingen rebooten en je netwerktransfers zouden veel smoother moeten zijn met geen of minder dips. Kun je dit testen?

[Verwijderd]

x-RaY99 heeft de glitches geconstateerd in ZFS met FreeBSD en FreeNAS, ook met 2 TB schijven en mij viel het gisteren op met OpenIndiana/Napp-it.
Ik weet niet of tuning van de bootloader ook werkt voor opensolaris.

zal vandaag trachten wat screenshotjes van dit gebeuren te maken.

[x-RaY99]

Dank voor de tips!

Het klopt inderdaad dat het allemaal erg karig is, zeker vergeleken met de 24 schijven.
Nu had in den beginne het idee om een Adaptec 5805 controller te gebruiken, dat werkt prima op het Atom bordje aangezien een hoop dan door de controller geregeld word. Daar stond dan ook 2008R2 server op.
Echter knalde mijn array's er iets te vaak uit wat uiteindelijk op incompatibiliteit duide tussen de controller, intel enclosures en de schijven. Echter haalde ik toen wel dik 100MB/s lezen/schrijven over het netwerk.

Ben het met je eens dat ik met een "software-raid" (ZFS is veel meer dan dat) hier nooit duizeling wekkende prestaties zal halen, eigenlijk is het enige wat die bak moet gaan doen archiveren, eens in de week tot een paar honderd GB aan data ontvangen en af en toe eens wat lees acties. Het zou dan op die momenten wel erg fijn zijn om de gbit verbinding vol te trekken.

Zojuist heb ik op het andere test systeem (die i7 met ook 4GB geheugen), 4 WD EARS schijven in een raidz gezet. Dit met een installatie van OpenIndiana met napp-it.
Met FreeNAS haalde ik op dit systeem gisteren pieken van 60-70% en dips van enkele seconden 0%. Nu haal ik pieken van 80% en dips van 25-30% (en dat continue, dus zaagtanden), gemiddeld genomen over een file van 100GB 63MB/s.

Bij het Atom systeem kan ik pas vanavond weer (ben nu @ work) en dan zal ik de transaction groups tuning eens proberen. Kan dit ook bij het OpenIndiana systeem?

[edit] zouden de 4kb sectoren hier nu ook iets mee te maken moeten hebben? Of is dat alleen op de algehele performance (zeg van theoretisch 140MB/s per schijf naar 100MB/s per schijf)?

[ Voor 6% gewijzigd door x-RaY99 op 12-04-2011 09:11 ]

[Verwijderd]

* opgelost

[ Voor 97% gewijzigd door Verwijderd op 12-04-2011 18:33 ]

[Verwijderd]

het installen van openindiana op een usb sticky maar even aan de kant gegooid en een verse 1 tb sata disk opgeofferd (overkill..ik weet het)

nieuwe pool aangemaakt met 4 x 204's en dit maal 60 gb ssd write cache.. en ineens valt mijn oog op het volgende in napp-it (mooi mooi) :



hij staat dus op 512b sektor size terwijl deze pool 4k sektorsize kan, blijkbaar moet je dat toch zelf ergens gaan instellen.
ik ga nieuwe poging doen die evt. glitches in beeld te krijgen.

[Verwijderd]

Solaris kan niet direct voor 4K optimaliseren. Alleen met gevaarlijke ZFS patched binaries kan dat, die in sommige gevallen schijnt je pool corrupt te maken. Ik zou daar voorzichtig mee zijn.

Ik heb wel gelezen over de pool ashift=12 maken onder BSD platform en dan weer importeren op het Solaris platform, dat schijnt wel te kunnen.

[dutch_warrior]

Ik quote even een stukje uit een post van mezelf uit het DIY raid nas topic.
De vragen in deze post kunnen denk ik beter hier beantwoord worden.

dutch_warrior schreef op zaterdag 09 april 2011 @ 16:23:
Freenas 8.0 kan bijna alles wat ik nodig heb, ik vraag me echter een aantal dingen af namelijk:
- Hoe zit het met de toekomst van ZFS, ik weet dat deze vraag al heel vaak is gesteld en ik lees overal op internet ook verschillende meningen erover maar ik ben benieuwd hoe er hier tegenaan gekeken wordt.
- Hoe zit het met BTRFS, ik heb het idee dat het nog wel enige tijd gaat duren voordat BTRFS geschikt is voordat ik mijn data aan een BTRFS volume kan toevertrouwen, of vergis ik mij nu ?
- Een tijd geleden heb ik in het DIY raid nas topic nogal wat gedoe gelezen over de EARS schijven en de 4K sectors, deze schijven werkten nog niet echt super met Freenas toendertijd. Is het feit dat ik EARS schijven gebruik nog steeds van belang voor mijn keuze van een OS ?
- Ergens staat de stelregel dat je 1 GB ram nodig hebt per 1TB data, maar 8GB voor een BSD installatie met 8TB storage pool is wel genoeg lijkt me ?

Mijn voorkeur gaat op dit moment uit naar het zelf inrichten van een Linux systeem omdat ik daarmee meer ervaring heb. Aan de andere kant wil ik me ook graag verdiepen in ZFS en BSD maar ik ben bang dat ik dan tijd en moeite steek in een oplossing welke over niet al te lange tijd weer helemaal anders moet.
Misschien dat de mensen hier mij wat advies kunnen geven ?

[Verwijderd]

dutch_warrior schreef op dinsdag 12 april 2011 @ 13:14:
Ik quote even een stukje uit een post van mezelf uit het DIY raid nas topic.
De vragen in deze post kunnen denk ik beter hier beantwoord worden.


[...]

volg je voorkeur en bouw een linux/zfs systeem .. ik probeer momenteel alles wat los en vast zit aan zfs en vooralsnog wint openindiana/napp-it .. maar freenas 8 werkt ook prima.

[Verwijderd]

Leg eerst eens uit wat je precies wilt? Een ZFS NAS of juist een multi-functionele server? Als je met name om de dataopslag gaat en je wilt veilige opslag dan is ZFS je beste keuze. Btrfs is nog niet stabiel genoeg, en heeft ook geen software RAID; het is enkel een filesystem dus in principe niet vergelijkbaar met ZFS. Maar het is wel het enige FOSS filesystem wat ook checksums gebruikt om de integriteit van je data te bewaken, dus in die zin is het wél vergelijkbaar met ZFS. Ik denk dat dat een meerjaren plan wordt, maar heb ook niet zoveel ervaring met Btrfs.

1GB RAM stelregel is per disk; niet per TB ofzo. Het gaat om de snelheid per disk, je hebt x aantal RAM nodig per 100MB/s aan performance. Als je disks gezamenlijk maar 100MB/s doen (4 disks van 25MB/s) dan heb je niet zoveel RAM nodig. Als ze 3,2GB/s kunnen doen dan heb je wel enorm veel RAM nodig om dat enigszins te halen. 8 gig lijkt me prima; het is ook maar een stelregel. Wel kun je stellen dat ZFS performance veel afhangt van het geheugen.

[Verwijderd]

af en toe glitch.. hier 10 gb via smb van win client naar pool zfs 28

* opnieuw opgebouwd, nu met zfs 15.. exact hetzelfde beeld

---

openindiana oi-dev-148-x86/napp-it 0.415p
intel(R) Core(TM) i3 CPU 540 @ 3.07GHz
MSI H55M-ED55 - Micro ATX
Intel PRO/1000 GT Netwerkadapter
8 GB : 2 x 4 GB - DIMM 240-pins - DDR3 - 1333 MHz / PC3-10600 - CL9 - 1.5 V - ni
Intel RAID Controller SASUC8I (IT flashed)
4 x Samsung EcoGreen F4EG HD204UI in raidz
1 x OCZ agility2 60 gb ssd poolcache
boot'disk hd103sj
level one gsw o841 switch

---

[ Voor 80% gewijzigd door Verwijderd op 12-04-2011 18:34 ]

[dutch_warrior]

x-RaY99 schreef op dinsdag 12 april 2011 @ 09:09:
Dank voor de tips!

Zojuist heb ik op het andere test systeem (die i7 met ook 4GB geheugen), 4 WD EARS schijven in een raidz gezet. Dit met een installatie van OpenIndiana met napp-it.
Met FreeNAS haalde ik op dit systeem gisteren pieken van 60-70% en dips van enkele seconden 0%. Nu haal ik pieken van 80% en dips van 25-30% (en dat continue, dus zaagtanden), gemiddeld genomen over een file van 100GB 63MB/s.

Bij het Atom systeem kan ik pas vanavond weer (ben nu @ work) en dan zal ik de transaction groups tuning eens proberen. Kan dit ook bij het OpenIndiana systeem?

[edit] zouden de 4kb sectoren hier nu ook iets mee te maken moeten hebben? Of is dat alleen op de algehele performance (zeg van theoretisch 140MB/s per schijf naar 100MB/s per schijf)?

Wat jij hier beschrijft heb ik ook gehad met 2TB WD EARS in ZFS.
Echter met 1TB seagate 7200.11 schijven ook. Bij de WD schijven dacht ik dat het iets te maken had met het gebruik van de P400 controller maar ook op een onboard controller was in mijn network traffic een blok patroon te zien.
Ik heb toen Freenas 7,x gelaten voor wat het was en hoopte dat dit in 8.0 beter zou zijn.
Ben wel benieuwd naar de performance van ZFS onder Open Indiana, doet dit daar ook voor ?

[dutch_warrior]

Verwijderd schreef op dinsdag 12 april 2011 @ 13:20:
Leg eerst eens uit wat je precies wilt? Een ZFS NAS of juist een multi-functionele server? Als je met name om de dataopslag gaat en je wilt veilige opslag dan is ZFS je beste keuze. Btrfs is nog niet stabiel genoeg, en heeft ook geen software RAID; het is enkel een filesystem dus in principe niet vergelijkbaar met ZFS. Maar het is wel het enige FOSS filesystem wat ook checksums gebruikt om de integriteit van je data te bewaken, dus in die zin is het wél vergelijkbaar met ZFS. Ik denk dat dat een meerjaren plan wordt, maar heb ook niet zoveel ervaring met Btrfs.

1GB RAM stelregel is per disk; niet per TB ofzo. Het gaat om de snelheid per disk, je hebt x aantal RAM nodig per 100MB/s aan performance. Als je disks gezamenlijk maar 100MB/s doen (4 disks van 25MB/s) dan heb je niet zoveel RAM nodig. Als ze 3,2GB/s kunnen doen dan heb je wel enorm veel RAM nodig om dat enigszins te halen. 8 gig lijkt me prima; het is ook maar een stelregel. Wel kun je stellen dat ZFS performance veel afhangt van het geheugen.

Ja oke in de originele post stond iets meer informatie, over de hele geschiedenis.
Ik wil alleen een goede OS keuze doen zodat ik de juiste onderdelen voor dat OS kan kiezen.
Het doel is een NAS bouwen voor storage, de machine zet ik alleen aan wanneer het nodig is.
Ik heb erg veel ghost images en wil deze veilig opslaan voor beperkte duur vandaag ook mijn interesse voor een ZFS based nas.

Hoe zit het met de ZFS ontwikkelingen binnen Open Indiana dan, ZFS wordt nu closed source ontwikkeld dus in principe zal het steeds minder uitmaken of je Open Indiana of BSD gebruikt lijkt me ?
Napp-it ziet er opzich wel goed uit .

[leuk_he]

dutch_warrior schreef op dinsdag 12 april 2011 @ 14:05:
[...]

Hoe zit het met de ZFS ontwikkelingen binnen Open Indiana dan, ZFS wordt nu closed source ontwikkeld dus in principe zal het steeds minder uitmaken of je Open Indiana of BSD gebruikt lijkt me ?
Napp-it ziet er opzich wel goed uit .

ZFS blijft onder een cddl license. Echter de source wordt niet meer real time gereleased naar open source versies. Eerst wordt de enterprice versie uitgebracht, en dan achteraf een keer de source. Beetje zelfde wat google nu doet met android. Wel releasen van source, maar met een tijsvertraging, zodat niet partners een tijdsvertraging hebben. (en dus concurrentie nadeel). Hoeveel vertraging is onduidelijk, dus daar laat je geen community op draaien.

quote: http://mail.opensolaris.o...s/2010-August/059310.html

We will distribute updates to approved CDDL or other open source-
licensed code following full releases of our enterprise Solaris
operating system. In this manner, new technology innovations will
show up in our releases before anywhere else. We will no longer
distribute source code for the entirety of the Solaris operating
system in real-time while it is developed, on a nightly basis.

Anyone who is consuming Solaris code using the CDDL, whether in pieces
or as a part of the OpenSolaris source distribution or a derivative
thereof, would therefore be able to consume any updates we release at
that time, under the terms of the CDDL, LGPL, or whatever license
applies.

Als je nu hardware koopt en beslists zou ik gebruiken wat NU goed werkt. Voor een NAS lijkt waar je veel disken voor hebt en hardware die ondersteund wordt in openinidana is dat een goede keus.

Heb minder disken die je wilt verdelen in partities enzo dan gaat dat wellicht makkelijker met freebsd. (diskpartitities editen onder opensolaris heeft me 3 keer doen vloeken en toen heb ik de VM weggemikt, )

[YaaD]

Ik wil graag even inhaken op het geheugen verhaal van CiPher. Die stelt dat er per schijf 1GB geheugen nodig is. Wat als het geheugen bijvoorbeeld 4GB is per 6 schijven? Zou dit de performance veel beinvloeden?

Hoe zou de performance zijn op een onboard CPU bijvoorbeeld? Ik zit te denken aan de E350 chip...

[x-RaY99]

dutch_warrior schreef op dinsdag 12 april 2011 @ 13:39:
[...]

Ben wel benieuwd naar de performance van ZFS onder Open Indiana, doet dit daar ook voor ?

Met OpenIndiana haal ik pieken van 80% en dips van 25-30% (en dat continue, dus zaagtanden), gemiddeld genomen over een file van 100GB 63MB/s. (zoals in mijn laatste post te lezen valt)

Heb toch het idee dat het aan de hoeveelheid geheugen ligt, zojuist e.a. getest op een oud dual cpu (intel 5000 chipset met 2xquad's) en 12GB geheugen getest. (met dezelfde 4 2TB schijven) Daar haal ik nu over 100GB gemiddeld 95MB/s writes en 105MB/s reads over een gbit netwerk. Er zitten soms nog enkele dipjes in het netwerk maar dat is op 1 hand te tellen voor de volledige transfer.

Blijft voor mij de vraag nog staan of de optimalisaties naar 64MiB transaction groups ook onder OpenIndiana kunnen worden toegepast?

[Arnoud1]

'Approximately 64 KB of memory is consumed per mounted ZFS file system. On systems with 1,000s of ZFS file systems, provision 1 GB of extra memory for every 10,000 mounted file systems including snapshots. Be prepared for longer boot times on these systems as well. '

Vanwaar dus die regel van 1GB per 1disk die jullie gebruiken?

Ik heb nog niet gelezen wat er op het forum staat, maar ik krijg zeer slechte prestaties met ZFS..
SFTP geeft max 2,3MB/s, (filezilla)
Via windows verkenner krijg ik 21-25MB/s
Als ik naar een filesysteem met gzip-9 schrijf dan stopt hij regelmatig voor ~30sec.. (gisteren zelfs server timeouts)

Het vreemde is dat het kopiëren vanaf een linux server (6tb aan data) wel vlot liep zonder crashes (2dagen bezig geweest)

Bij het kopiëren blijft mijn cpu steeds 33% idle, ook bij gzip-9

PC is een Celeron D420, Asus P5VD2 mobo, 2Gb DDR2, SASUC8I met 7 Seagate 1TB schijven, en 1 Seagate 80Gb voor het systeem (sata op mobo)
(Zwakke cpu, maar hij vervangt die E-350 die niet wil werken met SASUC8I)

Edit:
De snelheid is minder erg dan de stabiliteit. Server timouts wil ik echt niet!

[ Voor 4% gewijzigd door Arnoud1 op 12-04-2011 16:33 ]

[dutch_warrior]

@Arnoud1

Welk OS gebruik je ?
Tuning kan veel helpen maar 2GB is wel wat weinig lijkt me ?

[ Voor 86% gewijzigd door dutch_warrior op 12-04-2011 19:02 ]

[Verwijderd]

(Zwakke cpu, maar hij vervangt die E-350 die niet wil werken met SASUC8I)

dus het komt door de processor

[michiel.686]

Verwijderd schreef op dinsdag 12 april 2011 @ 19:19:
[...]


dus het komt door de processor

Nee joh, het ligt altijd aan de gebruiker.. Dat is toch wel bekend?

[Verwijderd]

michiel.686 schreef op dinsdag 12 april 2011 @ 19:22:
[...]


Nee joh, het ligt altijd aan de gebruiker.. Dat is toch wel bekend?

nou dat durf ik niet te stellen want Arnoud is er wel ingedoken dacht ik, alleen geen resultaat helaas en nu werkt het wel met een oude bios .. dus toch.

' Via windows verkenner krijg ik 21-25MB/s ' .. dat moet sneller kunnen

[ Voor 9% gewijzigd door Verwijderd op 12-04-2011 19:25 ]

[michiel.686]

Verwijderd schreef op dinsdag 12 april 2011 @ 19:24:
[...]


nou dat durf ik niet te stellen want Arnoud is er wel ingedoken dacht ik, alleen geen resultaat helaas en nu werkt het wel met een oude bios .. dus toch.

Dan ligt het dus toch niet aan de processor?

[x-RaY99]

Hierbij nog een screenshot van het copy'en van een windows box naar de OpenIndiana ZFS pool.
Dit dus over gbit, via cifs naar een dual quad met 12GB geheugen en 4 2TB schijven.

Je zou toch verwachten dat de gbit verbinding vol te trekken moet zijn. Volgens de benchmark in napp-it zou de pool 220MB/s write en 320MB/s read moeten kunnen doen. CPU usage staat bij seq write wel op 99%, maar dat is van 1 core.

[voodooless]

Kun je misschien wat testjes met iSCSI doen? Ik denk dat het daarbij makkelijker zal zijn om Gbit vol te krijgen. Je zou ook nog kunnen kijken of je iets kan met jumbo frames..

[x-RaY99]

Zal dat zo eens proberen, je verwacht een probleem met Samba?

Overigens zakt soms de performance toch nog een stukje in elkaar, dan worden het weer 30% dalen e.d.
Enige wat opvalt is dat gedurende deze periode (aantal minuten) het volgende proces boven aan de lijst staat:

2021 root 217 29 10 759M 755M sleep 0:12 0.25% zdb

[voodooless]

Samba? OpenIndiana kan toch af zonder samba? Schijnt efficiënter te zijn.

[x-RaY99]

Nam even gemakshalve aan dat de SMB-Server in OpenIndiana daadwerkelijk een samba server was.

[FireDrunk]

Joechee, even proberen of OpenIndiana wel snel is... Eindelijk een non-gui versie aan de praat gekregen met VMXNET3

Zometeen even NFS benchmarken!

[Verwijderd]

x-RaY99 schreef op dinsdag 12 april 2011 @ 20:01:
Hierbij nog een screenshot van het copy'en van een windows box naar de OpenIndiana ZFS pool.
Dit dus over gbit, via cifs naar een dual quad met 12GB geheugen en 4 2TB schijven.

Je zou toch verwachten dat de gbit verbinding vol te trekken moet zijn. Volgens de benchmark in napp-it zou de pool 220MB/s write en 320MB/s read moeten kunnen doen. CPU usage staat bij seq write wel op 99%, maar dat is van 1 core.

[afbeelding]

ZFS28 en raidz neem ik aan ?

en waar boot je vanaf .. hoeveel gb (10= advised min. 3.7) ..

ik heb hetzelfde ook nog een keer geprobeerd met een nieuwe pool , ditmaal zfs15 >

http://img197.imageshack.us/img197/9800/zfs15.jpg

enige verschil in setup is nu wel dat het OS boot vanaf een hd ipv een ssd (, ik heb geen idee hoe de i/o is en in hoeverre dat dit uitmaakt maar ik denk niet al te veel )

OS staat op rpool en die gebruikt rpool/dump en rpool/swap die hier beiden verwijzen naar de hd, ik kan nog is proberen om die naar een ssd cache volume te laten wijzen maar ik gebruik al voldoende geheugen (8 gb)

vrijdag prik ik er puur voor de leuk nog 8 gb bij om is te kijken..

[Verwijderd]

FireDrunk schreef op dinsdag 12 april 2011 @ 20:48:
Joechee, even proberen of OpenIndiana wel snel is... Eindelijk een non-gui versie aan de praat gekregen met VMXNET3

Zometeen even NFS benchmarken!

yesssss

dat is iets dat ik mij ook afvroeg, is er, buiten de gui natuurlijk, verschil in de server versie en de gui versie kwa snelheid.. ook nog eens testen maar.

wat mij niet lukte is de update manager te starten.. os is geinstalled vanaf live disk, maar hij blijft volhouden dat het nog steeds een live disk is.

[ Voor 15% gewijzigd door Verwijderd op 12-04-2011 20:57 ]

[Verwijderd]

voodooless schreef op dinsdag 12 april 2011 @ 20:23:
Samba? OpenIndiana kan toch af zonder samba? Schijnt efficiënter te zijn.

en hoe 'klets ik dan met mijn winhoos bak ?

[x-RaY99]

Hmm, met iSCSI haal ik 86-96% van de gbit. Ziet er al weer ietsjes beter uit.
Zo maar eens proberen om dat op het atom bordje hier thuis te zetten.

Kletsen met windows zou dan ook nog met NFS kunnen en FTP natuurlijk.

[FireDrunk]

NFS en Windows gaan niet echt samen... Werkt wel, maar veel performance zal je er niet uit halen...
SMB is voor windows gewoon het snelst omdat het een kernel protocol is... (Wat ook voor Solaris geld.)
Dus de hoogste snelheid tussen Solaris en Windows haal je waarschijnlijk met SMB

Misschien nog ergens een keer TCP_NO_DELAY instellen, maar die trigger heb ik ook nog niet gevonden

[Arnoud1]

Verwijderd schreef op dinsdag 12 april 2011 @ 19:19:
[...]


dus het komt door de processor

Nee hoor, had het over dat asus bordje waar het niet mee werkt. Het bordje dat ik nu heb van asus is een oud bordje, compleet budget en daar werkt het wel op.

Ik ben nog steeds van mening dat asus de pcie specs soms niet volgt!

[Verwijderd]

Arnoud1 schreef op dinsdag 12 april 2011 @ 22:20:
[...]


Nee hoor, had het over dat asus bordje waar het niet mee werkt. Het bordje dat ik nu heb van asus is een oud bordje, compleet budget en daar werkt het wel op.

Ik ben nog steeds van mening dat asus de pcie specs soms niet volgt!

niet alleen asus hoor.. maar ik heb mijn asus bordje geruild voor msi met 2x pci-e en dat draait goed zover ik nu kan beoordelen.

[Arnoud1]

msi met zacate erop? Heb je dat gewoon kunnen omruilen bij de verkoper om de reden dat ze niet compatibel zijn? hoeveel weken heb je gewacht?

[Verwijderd]

Arnoud1 schreef op dinsdag 12 april 2011 @ 22:36:
msi met zacate erop? Heb je dat gewoon kunnen omruilen bij de verkoper om de reden dat ze niet compatibel zijn? hoeveel weken heb je gewacht?

nee, asus bordje heb ik weer verkocht en heb nav een amerikaans forum de gok gewaagd en DEZE gekocht met een i3 540 proc. .. geen spijt van en bordje is zeer uitbreidbaar.

[ Voor 5% gewijzigd door Verwijderd op 12-04-2011 23:13 ]

[dutch_warrior]

Ik heb besloten dat ik toch een nas ga bouwen met ZFS.
De primaire functie wordt nas en ik heb maar 1 echt belangrijk punt:
- Beheer via een (web)gui. Ik werk niet genoeg met Unix based os-en om de command-line configuratie te
onthouden, dus als ik iets zou moeten aanpassen is dat weer veel zoekwerk en een beetje riskant.

Ook kies ik graag een OS wat enigzins future proof is, welk OS zou ik het beste kunnen kiezen ?
- Open Indiana (met napp-it waarschijnlijk de beste keus ?)
- (Free)BSD
- Debian k/FreeBSD
De laatste heeft mijn voorkeur omdat ik al een beetje bekend ben met Debian en het GNU userland.
Maar ik vraag me alleen af wat de levensvatbaarheid is van k/FreeBSD aangezien het op de FreeBSD forums niet zo goed werd ontvangen . Wat ik me vooral afvraag hoe het zit met de ZFS development voor k/FreeBSD, zolang dit niet teveel achterloopt zou ik een redelijk stabiel systeem krijgen en altijd nog kunnen migreren naar een ander OS wanneer nodig toch ?

Ik wil eigenlijk geen kant en klare oplossing zoals Freenas, Nexenta of ZFS Guru gebruiken aangezien ik graag zelf dingen uitzoek en wil weten hoe mijn systeem is opgebouwd .

[ Voor 12% gewijzigd door dutch_warrior op 13-04-2011 00:28 ]

[Arnoud1]

Slechts 2GB ram, en toch geen swap in gebruik, Dus ik heb ram genoeg voor mijn ZFS... (Zie ook hieronder)
Of niet? Ik snap echt niet waarom er hier steeds aangeraden wordt om meer ram te gebruiken...
Kom ik nergens tegen op sites van Solaris, ZFS, wiki, ....

http://www.solarisinterna...iguration_Recommendations

System/Memory/Swap Space

* Run ZFS on a system that runs a 64-bit kernel
* One GB or more of memory is recommended.
* Approximately 64 KB of memory is consumed per mounted ZFS file system. On systems with 1,000s of ZFS file systems, provision 1 GB of extra memory for every 10,000 mounted file systems including snapshots. Be prepared for longer boot times on these systems as well.
* Because ZFS caches data in kernel addressable memory, the kernel sizes will likely be larger than with other file systems. You might configure additional disk-based swap areas to account for this difference on systems with limited RAM. You can use the size physical memory size as an upper bound for the extra amount of swap space that might be required. In any case, monitor swap space usage to determine if swapping occurs.
* For additional memory considerations, see Memory and Dynamic Reconfiguration Recommendations

[dutch_warrior]

Tja ik snapte dit ook niet helemaal maar bij Freenas 7.x hielp het wel degelijk als ik meer ram beschikbaar stelde voor ZFS.
Wellicht gaat ZFS meer ram gebruiken als er meer beschikbaar is of moet er toch nog iets getuned worden.
Op freenas moest in ieder geval gespeeld worden met kmem _size, maar ik had begrepen dat dit in de nieuwere ZFS versies niet nodig zou zijn.

[Faust]

goed nieuws voor OSX gebruikers:
http://webwereld.nl/nieuw...-terug-naar-mac-os-x.html

goed topic btw!

[dutch_warrior]

Ben benieuwd, in ieder geval wordt er dus aan gewerkt door iemand die veel kennis heeft van HFS+ binnen Mac OS .
Maar zolang Apple het zelf niet oppakt ben ik bang dat dit project weinig impact gaat hebben voor ZFS.
Meer platformen waarop ZFS werkt is natuurlijk geen slechte zaak en wellicht dat Don Brady ook veel kan betekenen voor de ontwikkeling van ZFS.

[Verwijderd]

dutch_warrior schreef op dinsdag 12 april 2011 @ 13:39:
Wat jij hier beschrijft heb ik ook gehad met 2TB WD EARS in ZFS.
Echter met 1TB seagate 7200.11 schijven ook. Bij de WD schijven dacht ik dat het iets te maken had met het gebruik van de P400 controller maar ook op een onboard controller was in mijn network traffic een blok patroon te zien.

Transaction groups zijn een cruciaal en fundamenteel onderdeel van ZFS en zul je dus op alle ZFS implementaties terug zien, van versie 1 tot versie 31. Hoe groot de 'dips' zijn hangt af van je configuratie, hardware en ZFS versie. Tuning wordt regelmatig aangehaald om optimale performance op jouw systeem te behalen.

Als je grote dips hebt, zegt dat iets over slechte configuratie of niet afdoende hardware. Bijvoorbeeld een CPU die niet snel genoeg kan comprimmeren/encrypten/deduppen, te weinig RAM om hele transaction groups in RAM te houden of een sub-optimale hardware configuratie (9 disks met 4K sectors in RAID-Z2).

dutch_warrior schreef op dinsdag 12 april 2011 @ 14:05:
[...]
Hoe zit het met de ZFS ontwikkelingen binnen Open Indiana dan, ZFS wordt nu closed source ontwikkeld dus in principe zal het steeds minder uitmaken of je Open Indiana of BSD gebruikt lijkt me ?

ZFS had een aantal core developers; die zijn nu vertrokken sinds Oracle de scepter zwaait. Wat nu over is, is iets bij Oracle zelf met andere ontwikkelaars, maar eigenlijk kun je stellen dat ZFS v28 de laatste echte ZFS versie is, en het nu aan de Top-Secret Working Group is om ZFS verder te ontwikkelen in OpenIndiana, IllumOS en FreeBSD.

FreeBSD heeft al diverse verbeteringen toegevoegd, en IllumOS heeft sommige userland utilities herschreven in C zodat ZFS niet meer op Python-ondersteuning leunt. De toekomst van ZFS is enigszins onzeker, maar ik verwacht meer van de open source community dan van Oracle.

Arnoud1 schreef op dinsdag 12 april 2011 @ 16:31:
'Approximately 64 KB of memory is consumed per mounted ZFS file system.

Dat heeft verder niets te maken met de RAM behoeftes van ZFS. Dit zijn de vereisten; ZFS heeft minimaal een aantal MB nodig; de rest is optioneel. Wel is de performance sterk gerelateerd aan de hoeveelheid RAM. ZFS performance schaalt naarmate je meer RAM toevoegt.

Als ik naar een filesysteem met gzip-9 schrijf dan stopt hij regelmatig voor ~30sec.. (gisteren zelfs server timeouts)

Dan kan je CPU de compressie niet aan. De compressie begint pas zodra een transaction group wordt verwerkt, niet daarvoor.

Arnoud1 schreef op woensdag 13 april 2011 @ 00:19:
Slechts 2GB ram, en toch geen swap in gebruik, Dus ik heb ram genoeg voor mijn ZFS...

ZFS RAM kan niet geswapped worden; het is Wired RAM; net als de kernel. Swappen is ook een gevaarlijk iets wat onder UNIX zeer conservatief mee wordt omgesprongen. Niet zonder redenen.

Ik snap echt niet waarom er hier steeds aangeraden wordt om meer ram te gebruiken...
Kom ik nergens tegen op sites van Solaris, ZFS, wiki, ....

When will ZFS use RAM?

Als je 300 gigabyte RAM hebt, zal ZFS het grootste gedeelte daarvan out-of-the-box gebruiken. Hoe meer RAM, des te beter de performance scaling. Dat merk je het meest als je van 4GB naar 8GB gaat, van 8 naar 16GB is al minder verschil, en daarna neemt het al snel af.

Gebruik je deduplication of L2ARC dan heb je extra RAM nodig. Per 80GB SSD L2ARC zou je 2GB RAM nodig hebben als ik me goed herinner. CPU performance heb je niet zo erg nodig mits je geen compressie of andere CPU-intensieve opties inschakelt. In zo'n geval is de performance sterk afhankelijk van de hoeveelheid RAM.

dutch_warrior schreef op woensdag 13 april 2011 @ 00:18:
Ik heb besloten dat ik toch een nas ga bouwen met ZFS.
De primaire functie wordt nas en ik heb maar 1 echt belangrijk punt:
- Beheer via een (web)gui. Ik werk niet genoeg met Unix based os-en om de command-line configuratie te
onthouden, dus als ik iets zou moeten aanpassen is dat weer veel zoekwerk en een beetje riskant.

Ook kies ik graag een OS wat enigzins future proof is, welk OS zou ik het beste kunnen kiezen ?

FreeNAS of ZFSguru geeft je een WebGUI en je kunt zelf nog andere dingen draaien en zelf mee rommelen. ZFSguru is volledig FreeBSD dus je kunt beginnen met de GUI en daarna dingen zelf instellen en installeren via een SSH shell. Prima keuze om mee te beginnen denk ik. FreeNAS is iets lastiger omdat hier heel veel standaard dingen uit het OS zijn gehaald (gestripped) en dus kun je niet zomaar andere software installeren.

Solaris platform kun je ook overwegen, met napp-it. De ZFSguru optie is makkelijker denk ik, maar misschien komt dat omdat ik FreeBSD beter ken. Wat betreft toekomstvastheid denk ik dat je bij FreeBSD platform (FreeNAS enzo) beter zit dan op het Solaris platform, maar daarover verschillen de meningen sterk en voor elk platform valt iets te zeggen.

Heb je zelf al e.e.a. uitgeprobeerd?

[Arnoud1]

Zucht, ik heb allerlei tweaks geprobeerd en krijg de performance onmogelijk omhoog. (eerder omlaag)
Systeem specs ga ik niet veranderen. (Celeron D420 en 2Gb DDR2)

Ubuntu: LVM en hardware raid = ~90MB/sec r/w, CPU 1% en bijna alle ram vrij
FreeBSD: ZFS en RaidZ = ~12MB/sec r/w, CPU 75% en 459MB ram vrij
en dit met 7 schijven...

Heb ook al samba tweaks geprobeerd en die doen niets

[x-RaY99]

Op het atom bordje met 4GB geheugen en 24x 2TB schijven (via de intel/lsi sas HBA) is de performance zoals te verwachten erg laag. Kernel tijd zit continue over de 90% met een 200MB vrij geheugen.

Zaagtanden ohne ende:



Dus op zoek naar een uATX bordje met een i5 en een sloot geheugen. Asus zou je moeten vermijden lees ik, gigabyte/msi zou dan wel kunnen. Max geheugen bij die bordjes is zo'n 16GB las ik, alleen de (vergelijkbare) supermicro bordjes kunnen 32GB ECC behappen.

[Arnoud1]

x-RaY99 schreef op woensdag 13 april 2011 @ 15:36:
Op het atom bordje met 4GB geheugen en 24x 2TB schijven (via de intel/lsi sas HBA) is de performance zoals te verwachten erg laag. Kernel tijd zit continue over de 90% met een 200MB vrij geheugen.

Zaagtanden ohne ende:

[afbeelding]

Dus op zoek naar een uATX bordje met een i5 en een sloot geheugen. Asus zou je moeten vermijden lees ik, gigabyte/msi zou dan wel kunnen. Max geheugen bij die bordjes is zo'n 16GB las ik, alleen de (vergelijkbare) supermicro bordjes kunnen 32GB ECC behappen.

Ik krijg ook zoiets, maar dan slechts 12-14% netwerkbelasting.
Ik gebruik ook die intel SASUC8i, vroeger 3ware 9650
4Gb moet ruim genoeg zijn. Ik lees wel dat FreeBSD enorm veel meer geheugen vraagt dan Solaris.
Mogelijks ligt het dus aan FreeBSD...
Samba onder ubuntu deed het perfect. Nu zou ik plots vanalles moeten tweaken..

i5 verbruikt veel teveel stroom voor mij. (95Watt zonder chipset)
enkel Low power Xeon zou ik nog overwegen, en daar heb je mooie bordjes voor! (http://ark.intel.com/Product.aspx?id=53401)

Ahja, momenteel verbruikt mijn serve 144Watt, voorheen had ik een opteron en dat was 200Watt (single cpu) en 250Watt (dual cpu). Het lijkt erop dat mijn schijven samen 110Watt verstoken dus hier kan ik niet aan ontsnappen.

Is het al iemand gelukt om de shijven idle te krijgen onder FreeBSD, en hoe met het in slaap brengen van de cpu of cpu down throttle?

[x-RaY99]

Voor mij is het puur een archief systeem welke eens in de week aan gaat om een 'backup' te maken. CPU verbruik maak ik me dan ook niet zo heel veel zorgen om.
Volgende is besteld; Gigabyte GA-H67M-UD2H-B3, i3-2120 en 16GB geheugen. Mocht de cpu nog een bottleneck vormen heb ik nog een i5-2500 uit een ander systeem waar ik nog meer kan testen.
Zou ik met de 24 schijven ook nog beter een raidz3 kunnen draaien? Het zijn overigens 16x samsung en 8x hitachi schijven. Beide wel 2TB en 4kb sectoren.

[Arnoud1]

Ik snap niet dat je redundantie toepast op een backup? Daarvoor zou ik geen raid gebruiken..
Raid gebruik je als je data online moet blijven. Backup om geen dataverlies te hebben als er iets misloopt.
Als je backup kapot gaat maak je gewoon een nieuwe. Waarom geen tapes?

Ik ken iemand die als systeem 2 atom's gebruikt:
4x2tb schijven in raid5 als Nas, en 3x2tb schijven als Backup. Beide dus 6TB. Backup gaat af en toe aan, kopieert het verschil en gaat daarna uit.
Momenteel nog linux, binnenkort ZFS voor de snapshots.
Dit is ideaal voor thuisgebruik.

Een backup blijft bij mij goedkoop.

[ Voor 3% gewijzigd door Arnoud1 op 13-04-2011 16:31 ]

[x-RaY99]

Je moet het meer als archief zien, de live variant is veel kleiner +/- 6TB (raid5 van 4 schijfjes).
Alle nieuwe data die daar bij komt word eens per week weg gezet op het archief. Dat archief is met een opstart tijd van een paar minuten ook 'snel' te raadplegen. De échte backup is op LTO4, die tapes liggen ergens anders, zie raid ook zeker niet als alternatief van een backup! Je zou het kunnen zien als een Disk-2-Disk backup welke het ook snel raadpleegbaar maakt. Iets wat met tapes altijd wat meer tijd kost.

ZFS is echter met de steeds groter wordende volume's wel handig i.v.m. de self healing eigenschap. Als het dan wel maar het netwerk een beetje vol kan trekken, iets wat de atom icm ZFS niet lukt.

[ Voor 3% gewijzigd door x-RaY99 op 13-04-2011 16:38 ]

[Arnoud1]

x-RaY99 schreef op woensdag 13 april 2011 @ 16:36:
Je moet het meer als archief zien, de live variant is veel kleiner +/- 6TB (raid5 van 4 schijfjes).
Alle nieuwe data die daar bij komt word eens per week weg gezet op het archief. Dat archief is met een opstart tijd van een paar minuten ook 'snel' te raadplegen. De échte backup is op LTO4, die tapes liggen ergens anders, zie raid ook zeker niet als alternatief van een backup! Je zou het kunnen zien als een Disk-2-Disk backup welke het ook snel raadpleegbaar maakt. Iets wat met tapes altijd wat meer tijd kost.

ZFS is echter met de steeds groter wordende volume's wel handig i.v.m. de self healing eigenschap. Als het dan wel maar het netwerk een beetje vol kan trekken, iets wat de atom icm ZFS niet lukt.

Dat klinkt inderdaad mooi.

Recent een systeem gezien waar er gewerkt werd op SAS schijven, een archief (zoals jij het noemt) met SATA schijven (sun) en dan nog een backuprobot... prachtig systeem!

Wat gebruik je als 'live' systeem?

[x-RaY99]

Het live systeem is nu een 'kant en klare' NAS van Synology, met dus 4x2TB schijven in SW raid5. Eigenlijk puur uit nood aangezien ik al heel wat maanden geleden dacht een mooie oplossing te hebben met de Adaptec 5805 en de 24 2TB schijven. Die combinatie bleek niet stabiel en zodoende moest ik een beetje gaan schuiven met schijfruimte/systemen. Die Synology gaat er dan straks uit en daarvoor komt dan de 5805 met wel compatible schijven. Welke dan in afgeslankte vorm (bijvoorbeeld 4 of 6 schijven) 24/7 aan staat.

In het archief gebruik ik nu 4 enclosures van Intel met geïntegreerde expander. Waardoor ik per 6 schijven maar 1 poort nodig heb. Nu met de Intel SASUC8I gebruik ik dus maar de helft van de poorten, kan ik nog eens uitbreiden naar 48 schijven :x Én dat bordje van Gigabyte heeft plek voor 2 kaarten...

[Verwijderd]

Arnoud1 schreef op woensdag 13 april 2011 @ 15:32:
Zucht, ik heb allerlei tweaks geprobeerd en krijg de performance onmogelijk omhoog. (eerder omlaag)
Systeem specs ga ik niet veranderen. (Celeron D420 en 2Gb DDR2)

Is die CPU wel 64-bit? Zo ja, heb je partities op je hardeschijven? Kun je eens een 'zpool status' laten zien. Waarmee heb je de disks geformat/aangemaakt? Als je zoiets ziet als ad4s1 dan betekent dat dat je partities gebruikt (de s1 suffix betekent MBR partitie 1; en 'p1' zou GPT partitie 1 betekenen).

Je scores zijn dermate laag dat ik een foute partitie vermoed in combinatie met 4K sector disks.

Arnoud1 schreef op woensdag 13 april 2011 @ 15:55:
[...]
Is het al iemand gelukt om de shijven idle te krijgen onder FreeBSD, en hoe met het in slaap brengen van de cpu of cpu down throttle?

CPU power management onder BSD doe je met 'powerd', simpelweg 'powerd' intypen of in /etc/rc.conf de regel powerd_enable="YES" toevoegen.

Disks downspinnen kan met atacontrol spindown of camcontrol standby commando, APM inschakelen kun je met een speciaal camcontrol commando; google even dan kom je iets tegen op freebsd forum. Als je zoekt met "black magic involved" kom je het vast wel tegen.

x-RaY99 schreef op woensdag 13 april 2011 @ 16:14:
Zou ik met de 24 schijven ook nog beter een raidz3 kunnen draaien? Het zijn overigens 16x samsung en 8x hitachi schijven. Beide wel 2TB en 4kb sectoren.

Het is beter om verschillende type schijven niet in dezelfde vdev te stoppen. Beter is 8x in een RAID-Z2 en de 16x in een RAID-Z3. Dan heb je dus wel 5 parity disks totaal.

Eén enkele RAID-Z3 kan ook. De meest optimale config is dan 19 disks. Minus de drie parity schijven kom je dan uit op 16 data schijven, een optimale configuratie voor 4K sector disks.

Weet je zeker dat die hitachi's 4K zijn? Ik ken niet veel Hitachi schijven met 4K sectors namelijk.

[x-RaY99]

Hmm, nu je het zegt, zal zo eens nazoeken of die Hitachi's inderdaad ook 4kb's zijn.
[edit] Ze zijn inderdaad 512b ipv 4kb... die dus in een losse vdev gooien.

Heb overigens net FreeNAS weer even getest met de:

vfs.zfs.txg.write_limit_override=67108864
vfs.zfs.txg.synctime=2
vfs.zfs.txg.timeout=10

Vooral dat eerste zorgt dat je transaction groups max 64MiB groot kunnen zijn. Met deze instellingen rebooten en je netwerktransfers zouden veel smoother moeten zijn met geen of minder dips. Kun je dit testen?

En dat geeft inderdaad een wat smoothere lijn, alleen wel overall gezien langzamer, zit nu tussen 20-24% resulteerd in 23MB/s.
Als ik die aanpassingen niet doe zit ik op pieken van 75% (en secondes niets) maar uiteindelijk gemiddeld op 45MB/s.

Kan ik hier nog iets verder aan doen, bijv naar 128MiB gaan?

Zojuist even op 128MiB gezet, wel weer wat haaien tanden (niet zoveel als zonder) en gemiddeld nu 40MB/s

[ Voor 14% gewijzigd door x-RaY99 op 13-04-2011 18:37 ]

[Snow_King]

Vandaag voor bij ons op het werk een Nexenta omgeving besteld met:

Gekozen voor twee 'head ends' die dmv van de HA plugin in een failover pair zullen staan.

Elke headend heeft:
* Dual Quad-Core CPU
* 24GB Ram
* 6x 160GB SSD (L2ARC)
* Dual 10Gbit

Hier onder komen twee LSI630J JBOD's te hangen met elk:

* 11x 1TB Seagate SAS 7200RPM
* 1x STEC Z4RZF3D-8UC 8GB SSD (ZIL)

Na gesprekken met Nexenta hadden we het volgende idee:

* 10 vdev's van elk 2 disks in mirror
* In elke JBOD één hot-spare
* In elke JBOD één ZIL device (STEC SSD)

Dit moet ons zo rond de ~10TB netto opleveren in een HA omgeving, via zfs send/receive zullen we onze backups richting een tweede machine maken (24x 2TB)

We zullen hier alleen NFS mee gaan doen, de reden waarom we uiteindelijk voor ZFS hebben gekozen:
* Snapshots
* Performance

Vooral het eerste is onder Linux lastig voor elkaar te krijgen, maar ook de SSD acceleratie is niet (goed) voor elkaar te krijgen.

In mijn eerste tests ben ik zeer tevreden over Nexenta, zit een makkelijke GUI bij, maar de core is en blijft natuurlijk ZFS, dat is ook de reden dat we het product gekozen hebben.

Wel twijfel ik nog of de 24GB ram voldoende zal zijn, maar dat is anders ook niet lastig er bij te schalen.

[Verwijderd]

ik wil een ipad napp-it app ..


iemand deze combi's al eens geprobeerd ?

- NexentaCore Platform (v3.0.1) & napp-it 0.416a

- OpenIndiana Build 148 x86 Server CD & napp-it 0.416a

[ Voor 69% gewijzigd door Verwijderd op 13-04-2011 20:57 ]

[Verwijderd]

wat een beest

[ Voor 54% gewijzigd door Verwijderd op 13-04-2011 21:54 ]

[dutch_warrior]

Verwijderd schreef op woensdag 13 april 2011 @ 14:19:
[...]
FreeNAS of ZFSguru geeft je een WebGUI en je kunt zelf nog andere dingen draaien en zelf mee rommelen. ZFSguru is volledig FreeBSD dus je kunt beginnen met de GUI en daarna dingen zelf instellen en installeren via een SSH shell. Prima keuze om mee te beginnen denk ik. FreeNAS is iets lastiger omdat hier heel veel standaard dingen uit het OS zijn gehaald (gestripped) en dus kun je niet zomaar andere software installeren.

Solaris platform kun je ook overwegen, met napp-it. De ZFSguru optie is makkelijker denk ik, maar misschien komt dat omdat ik FreeBSD beter ken. Wat betreft toekomstvastheid denk ik dat je bij FreeBSD platform (FreeNAS enzo) beter zit dan op het Solaris platform, maar daarover verschillen de meningen sterk en voor elk platform valt iets te zeggen.

Heb je zelf al e.e.a. uitgeprobeerd?

Ah bedankt voor de info .
Ja ik heb zelf al wel eens het 1 en ander uitgeprobeerd.
Ik heb een in VM-Ware de volgende zaken geinstalleerd:
- Freenas 8.0
- Open Indiana (de desktop versie)
- Debian/kFreeBSD(met xfce desktop omgeving.)

Debian/kFreeBSD voelt erg vertrouwd maar heeft me niet overtuigd qua stabiliteit.
Ik ben begonnen met een kaal systeem dus geen desktop enviroment en heb toch GDM en XFCE4 geinstalleerd, dit werkt allemaal vrij probleemloos maar dus niet helemaal probleemloos.
(shutdown werkt soms niet vanuit XFCE, dan moet ik een andere terminal openen en zelf halt invoeren omdat XFCE vast slaat maar niet doorzet met afsluiten.)

Freenas 8.0 Hierover was ik vrij tevreden, ik draaide in het verleden ook Freenas 7.x en heb toen ik de server waarop dit draaide destijds verkocht ook de 8.0 alpha getest maar ik wilde toch iets meer vrijheid want Freenas is inderdaad zoals je al zegt erg gestripped.

Ik ben wel blij om te lezen dat er voor FreeBSD ook actief wordt gewerkt aan ZFS.
Voor mezelf had ik nu de keuze tussen FreeBSD (based) en Open Indiana, maar mijn voorkeur gaat dan uit naar FreeBSD omdat het een OS wat al tijdje meedraait.
Aangezien ik ook regelmatig pf-sense inzet is het voor mij ook handiger om kennis op te doen van FreeBSD.

Dus het wordt wat mij betreft FreeBSD met of zonder ZFS-Guru, ik ga met deze 2 opties even aan de slag.
Ook moet ik nog even gaan uitzoeken hoe de support is van de hardware welke ik nu nog heb liggen, wellicht dat ik een ander moederbord moet kopen.

EDIT:
Ik moet me nog wel even verdiepen in de versie nummering van zpool .
Nog 1 vraagje, hoe zit het eigenlijk met Nexenta OS of NexentaStor, opzich lijk Nexentastor ook veelbelovend maar zit hier buiten de limiet van 18TB nog een addertje onder het gras ?
Voor zover ik nu zie is het ieder geval proprietary, dat is wel jammer.

[ Voor 6% gewijzigd door dutch_warrior op 13-04-2011 22:52 ]

[Arnoud1]

Verwijderd schreef op woensdag 13 april 2011 @ 17:45:
[...]

Is die CPU wel 64-bit? Zo ja, heb je partities op je hardeschijven? Kun je eens een 'zpool status' laten zien. Waarmee heb je de disks geformat/aangemaakt? Als je zoiets ziet als ad4s1 dan betekent dat dat je partities gebruikt (de s1 suffix betekent MBR partitie 1; en 'p1' zou GPT partitie 1 betekenen).

Je scores zijn dermate laag dat ik een foute partitie vermoed in combinatie met 4K sector disks.

CPU is 64-bit

nas# zpool status
pool: srv
state: ONLINE
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
srv ONLINE 0 0 0
raidz1 ONLINE 0 0 0
da0 ONLINE 0 0 0
da1 ONLINE 0 0 0
da2 ONLINE 0 0 0
da3 ONLINE 0 0 0
da4 ONLINE 0 0 0
da5 ONLINE 0 0 0
da6 ONLINE 0 0 0

errors: No known data errors

nas# zfs list -o name,compression
NAME COMPRESS
srv off
srv/archive on
srv/backup gzip-9
srv/dump off
srv/ebooks off
srv/fun off
srv/games gzip-9
srv/home off
srv/home/arnoud off
srv/music off
srv/pictures off
srv/software on
srv/videos off

4K sector disks heb ik niet, is 7x Seagate 7200.11 1TB

[Verwijderd]

ben een beetje aan het spelen met mirrors in de vdev



- Automatic ZFS Snapshot Rotation on FreeBSD
- Automatic ZFS Snapshot Rotation on FreeNAS

[ Voor 48% gewijzigd door Verwijderd op 14-04-2011 13:50 ]

[Arnoud1]

Verwijderd schreef op woensdag 13 april 2011 @ 17:45:
[...]

Is die CPU wel 64-bit? Zo ja, heb je partities op je hardeschijven? Kun je eens een 'zpool status' laten zien. Waarmee heb je de disks geformat/aangemaakt? Als je zoiets ziet als ad4s1 dan betekent dat dat je partities gebruikt (de s1 suffix betekent MBR partitie 1; en 'p1' zou GPT partitie 1 betekenen).

Je scores zijn dermate laag dat ik een foute partitie vermoed in combinatie met 4K sector disks.

Ik heb me even laten vangen. Partities op ZFS... Ik was net zo overtuigd dat dit niet meer nodig was (en ook niet bestond) met ZFS
Je hebt het waarschijnlijk over slices.

ZFS Best Practices Guide:
For production systems, use whole disks rather than slices for storage pools for the following reasons:

* Allows ZFS to enable the disk's write cache for those disks that have write caches. If you are using a RAID array with a non-volatile write cache, then this is less of an issue and slices as vdevs should still gain the benefit of the array's write cache.
* For JBOD attached storage, having an enabled disk cache, allows some synchronous writes to be issued as multiple disk writes followed by a single cache flush allowing the disk controller to optimize I/O scheduling. Separately, for systems that lacks proper support for SATA NCQ or SCSI TCQ, having an enabled write cache allows the host to issue single I/O operation asynchronously from physical I/O.
* The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
* ZFS pools (and underlying disks) that also contain UFS file systems on slices cannot be easily migrated to other systems by using zpool import and export features.
* In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.

Dit is het probleem dus niet.
Ik lees ook nergens iets over "Recommended pool sizes voor RAID-Z" waar het volgens sommigen 3,5 of 9 disks moet zijn... Toch niet in manuals of op officiele guides.

ZFS Best Practices Guide:
RAIDZ Configuration Requirements and Recommendations

A RAIDZ configuration with N disks of size X with P parity disks can hold approximately (N-P)*X bytes and can withstand P device(s) failing before data integrity is compromised.

* Start a single-parity RAIDZ (raidz) configuration at 3 disks (2+1)
* Start a double-parity RAIDZ (raidz2) configuration at 5 disks (3+2)
* Start a triple-parity RAIDZ (raidz3) configuration at 8 disks (5+3)
* (N+P) with P = 1 (raidz), 2 (raidz2), or 3 (raidz3) and N equals 2, 4, or 8
* The recommended number of disks per group is between 3 and 9. If you have more disks, use multiple groups.

Mogelijks heeft mijn probleem met het volgende te maken:
Die failures zien er niet goed uit. en met vm.kmem_size wordt afgeraden om kernel panics te voorkomen.

nas# vmstat -z
ITEM                     SIZE     LIMIT      USED      FREE  REQUESTS  FAILURES

16 Bucket:                152,        0,       30,       45,       55,        0
32 Bucket:                280,        0,       23,       33,       55,        0
64 Bucket:                536,        0,       41,        8,       82,      420
128 Bucket:              1048,        0,     3014,        1,     9410,    26388

Verder herkent FreeBSD enkel de C1 state van mijn CPU, terwijl hij (Celeron D 420) zeker C2 (wat ik wil gebruiken) aan moet kunnen..

[FireDrunk]

Heb je in je BIOS wel al die power management meuk aan staan? SpeedStep enzo...

[x-RaY99]

Gisteren de nieuwe setup geprobeerd (i3 2120 + 16GB geheugen) en dat werkt als een trein.
Viel me wel op dat ondanks de 24 disks (8x raidz2 + 16x raidz2) ik in de benchmark 'slechts' 260MB/s seq writes haal en 380MB/s seq reads.
Wellicht heeft het er iets mee te maken dat ik 'maar' 4 links gebruik van de intel/lsi SASUC8I HBA naar de enclosures. 1 link per 6 disks dus. Het is in ieder geval zat om een gbit vol te trekken
Dit alles onder OpenIndiana met Napp-it 0.416a.

Moet ook nog even de ideale configuratie van disks zien te vinden, heb er 24 in enclosures zitten, zou er nog 4-5 kwijt kunnen op het moederbord mocht dat in totaal een betere waarde zijn.

[FireDrunk]

Denk dat je links wel redelijk vol zitten ja. SATA 3GBit is in de praktijk zo'n 260MB/s, dat word dus zo'n 60MB/s per disk. Daar gaat waarschijnlijk nog wat switching tijd (van de enclosure) vanaf... Dus met 50MB/s per disk zit je waarschijnlijk wel beter in de richting.

Als jou 8 x raidz2 vdev 1 volume is, zouden die waardes dus helemaal niet gek zijn.
Zitten alle vdevs in 1 pool of zijn het verschillende volumes/pools?

[x-RaY99]

Die 2 raidz2 vdev's zitten in 1 pool.
Vraag me af (gaan we natuurlijk wel even testen) of 1 grote raidz3 sneller zal zijn, gezien de mix van 512b en 4kb sector drives.

[Snow_King]

x-RaY99 schreef op vrijdag 15 april 2011 @ 09:20:
Gisteren de nieuwe setup geprobeerd (i3 2120 + 16GB geheugen) en dat werkt als een trein.
Viel me wel op dat ondanks de 24 disks (8x raidz2 + 16x raidz2) ik in de benchmark 'slechts' 260MB/s seq writes haal en 380MB/s seq reads.
Wellicht heeft het er iets mee te maken dat ik 'maar' 4 links gebruik van de intel/lsi SASUC8I HBA naar de enclosures. 1 link per 6 disks dus. Het is in ieder geval zat om een gbit vol te trekken
Dit alles onder OpenIndiana met Napp-it 0.416a.

Moet ook nog even de ideale configuratie van disks zien te vinden, heb er 24 in enclosures zitten, zou er nog 4-5 kwijt kunnen op het moederbord mocht dat in totaal een betere waarde zijn.

Zou het niet helpen hier een ZIL in de vorm van een SSD aan toe te voegen? Bijv een X25-E 32GB? Die kan je dan direct op je moederbord prikken.

[FireDrunk]

x-RaY99 schreef op vrijdag 15 april 2011 @ 10:31:
Die 2 raidz2 vdev's zitten in 1 pool.
Vraag me af (gaan we natuurlijk wel even testen) of 1 grote raidz3 sneller zal zijn, gezien de mix van 512b en 4kb sector drives.

Er is al vaker langsgekomen dat je beter maximaal 9 drives in een vdev kan doen.
Ik zou zeggen pak 4 sets van 6 disks in raidz2. Dat kost je wel het meeste ruimte, maar is wel het snelst.

[Verwijderd]

[b]
Dit alles onder OpenIndiana met Napp-it 0.416a.

dat heb ik momenteel ook draaien.. zit alleen met dit, of is dit normaal ? :



heb geinstalled vanaf de live cd ..
* zojuist van 8 naar 16 gb.. merk nog weinig verschil

[ Voor 9% gewijzigd door Verwijderd op 15-04-2011 10:41 ]

[FireDrunk]

Waarom geen OpenIndiana zonder GUI installeren... NappIt werkt dan ook prima, maar je hebt geen (in mijn ogen) smerige GUI

[x-RaY99]

FireDrunk schreef op vrijdag 15 april 2011 @ 10:37:
[...]


Er is al vaker langsgekomen dat je beter maximaal 9 drives in een vdev kan doen.
Ik zou zeggen pak 4 sets van 6 disks in raidz2. Dat kost je wel het meeste ruimte, maar is wel het snelst.

Ok, laat ik voorop stellen dat het in principe een opslag bak/archief is met een 1gbit verbinding (wellicht later 2gb) wanneer ik dat vol krijg is het qua performance voor mij voldoende.

Wat ik wel belangrijk vind is dat alles 'goed' gedaan wordt. Als het betekend dat ik met 1 grote raidz3 meer kans op errors/failures krijg, bijvoorbeeld omdat disks zich 4 keer in de rondte moeten werken, aangezien het aantal disks niet ideaal is, dan is dat voor mij reden genoeg om meer disks op te offeren. Dus meer losse vdev's of SSD's erbij.

@borroz, dat scherm heb ik nog niet eerder gezien. Moet ook zeggen dat ik nog geen updates gedaan heb op de OpenIndiana box, zal dat dit weekend eens proberen.

[ Voor 8% gewijzigd door x-RaY99 op 15-04-2011 10:58 ]

[FireDrunk]

Hmm, lastige keuze in dat geval... Het is een beetje lastig om de beste performance/redundantie/overgebleden storage verhouding te vinden. Alles in 1 RAIDZ3 zal ook wel werken, maar je stripes worden heel klein. Bij het schrijven 1MB word er 1MB over 21 disks verspreid (in het geval van RAIDZ3) dat lijkt me niet echt wenselijk...

2 x 12 RAIDZ2 lijkt in dat geval wel redelijk goed, dan lever je 4 disks in en heb je 10 schrijvende disks in een vdev, dat is een mooi getal want dan kunnen je disks makkelijk full stripes schrijven.

[michiel.686]

@borroz: Ik had dezelfde melding in mijn VM test bakkie!