Het grote ZFS topic

[NetXtreme]

Maar ZFSGuru is gebaseerd op BSD? Hoe is het performance verschil tussen solaris en bsd met gebruik van ZFS?

[Sleepie]

Een pagina terug:
Sleepie in "Het grote ZFS topic"

(en FireDrunk's post eronder)

[NetXtreme]

Sleepie schreef op dinsdag 23 augustus 2011 @ 20:19:
Een pagina terug:
Sleepie in "Het grote ZFS topic"

(en FireDrunk's post eronder)

My bad... Beetje chaotisch de laatste tijd

Ik zal eens een wat gaan testen met een OS wat mij bevalt. Denk OpenIndiana, FreeNAS (cause i like webinterface) en Nexenta.

[Sleepie]

NetXtreme schreef op dinsdag 23 augustus 2011 @ 20:22:
[...]
My bad... Beetje chaotisch de laatste tijd

Ik zal eens een wat gaan testen met een OS wat mij bevalt. Denk OpenIndiana, FreeNAS (cause i like webinterface) en Nexenta.

Inderdaad, gewoon wat testen en kijken wat je bevalt.
Ik vond zelf de GUI van napp-it erg goed, helaas kreeg ik onder OpenIndiana met zijn kernel-based CIFS mijn shares niet geconfigureerd zoals ik het wilde hebben (shares public read/writeable zowel via Windows machines in een AD domain en via NFS voor Linux boxen).
Anders had ik nu nog OI met napp-it gebruikt.

Hoewel ik ZFSGuru ook wel mooi vind door de recht-toe-recht-aan eenvoudigheid van de GUI.
_{if that makes sense}

[warcow]

Uiteindelijk nu toch alle componenten besteld. Het volgende heb ik gehaald:
Asus E35M1-I (amd e-350 bordje met 6 x Sata)
6 keer de WD 3 TB harde schijf
8 gb DDR3

Draai hier nu sinds een uurtje Freenas op met ZFS RAID-Z2 en tot zover bevalt het prima.
Heb uiteindelijk toch voor Z2 gekozen na het lezen van de berichten hier.

[FireDrunk]

En het verbruik? Werkt spindown?

[warcow]

Of spindown werkt moet ik nog even controleren. Het verbruik zonder spindown is 50 Watt. Als hij stevig bezig is stijgt het verbruik naar max 70-75 Watt. (Spindown staat al wel aan, maar toen ik thuiskwam was het verbruik nog steeds 50 Watt dus ik hier kijk ik nog even naar)

Bij deze een screenshot van de statistieken. Tijdens deze statistieken beschrijf ik de nas vanaf een windows 7 pc met CIFS. Dit gaat volgens windows met 50 mb/s. (gigabit lan, ik lees vanaf een 500gb sata schijfje)


Advanced power management staat op level 1, wat doet dit precies? (kan het zo snel nergens vinden online)

edit: aha, volgens dit: http://support.freenas.org/ticket/242 moet de APM op minimaal 127 staan omdat de schijven anders meteen een spindown doen als er een paar seconden niks gebeurt. Het zou prima kunnen dat mijn schijven meteen al een spindown doen. (zo klinkt het ook steeds als ik weer iets probeer te lezen/schrijven)
In dat geval moet ik genoegen nemen met 50 Watt verbruik in spindown. Had liever 40 gezien maar dit is nog acceptabel.

[ Voor 32% gewijzigd door warcow op 24-08-2011 21:59 ]

[FireDrunk]

Load van 7 is toch best hoog... en je verstookt een hoop aan IRQ's... Vreemd...
Ben niet zo'n BSD expert, maar lijkt erop alsof je een IRQ Storm hebt...

[warcow]

Dat van de IRQ heb ik weinig verstand van, zou het continu proberen te downspinnen daar iets mee te maken kunnen hebben? Ik heb de APM op level 127 gezet maar het lijkt niets te veranderen. (Of mijn schijven zijn steeds aan het downspinnen, of ze doen dat nooit...)
Zal zo de APM eens op het hoogste niveau proberen, zien of dat wat uit maakt.

[ Voor 13% gewijzigd door warcow op 24-08-2011 22:46 ]

[FireDrunk]

rebootje?

[warcow]

Na het veranderen van zo'n instelling reboot ik steeds ja. Probeer zo de apm disabled en apm op hoogste waarde. (eerst een kopieeropdracht afwachten)

[terror538]

Ik draai nu ook al een behoorlijke tijd een ZFS storage bak, 3x 1TB waarvan ik bij alle 3 een 50 g slice heb voor het OS en een 4g slice voor swap, die 50g slices staan natuurlijk via geom mirror in raid 1 (heel vervelend alleen dat freebsd ergens sinds een patch in 9 bij het booten een check uitvoert waardoor ik "kern.geom.part.check_integrity=0" in de loader.conf moest zetten).

Aangezien ik nog maar enkele honderden gigjes vrij heb op mijn storage pool wordt het weer is tijd om uit te gaan breiden, ik zat er nu aan te denken om maar 3 2tb schijfjes erbij te knallen en evt. 2 ssd's als l2arc en zil.

Het probleem is helaas dat mijn mobo nog maar 2 vrije sata aansluitingen heeft. Ik wil dus sata port multipliers gaan gebruiken, de ssd's moeten wel een eigen sata poort krijgen, en waarschijnlijk ook de 1e 1tb disk (waar het os van boot).
Nou vraag ik mij af hoe vervelend FreeBSD het vind als ik gewoon een powerdown doe, de multiplier ertussen knal en 2 drives van mijn ZFS pool en geom_mirror migreer naar de multiplier. Weet ZFS ze gewoon te vinden aan de hand van iets als een UUID ofzo ? Of moet ik ZFS het echt vertellen, of zelfs de disks 1 voor 1 migreren ?

Het hele zooitje draait sowieso al in AHCI modus NQC en alles werkt al (althans volgens de dmesg) en port multipliers zouden ondersteund moeten worden.

[Ravefiend]

@warcom: kijk es wat vmstat -i precies terug geeft? Misschien dat je via die manier kan bepalen welk process verantwoordelijk is voor al die interrupt requests.

[Sleepie]

Is een AOC-SASLP-MV8 iets als HBA voor een ZFS systeem?

Ik lees er eerlijk gezegd al niet veel goeds over op internet, maar kan iemand dat misschien (uit ervaring?) bevestigen of ontkennen?

[Anoniem: 187449]

ik lees ook issues onder linux met dat controllertje ..

[Sneezydevil]

@sleepie een tijdje terug, met zo'n ding en CentOS lopen prutsen, maar dat ging niet zo soepeltjes.

Toevallig gisteren nog overwogen (Hij blijft aantrekkelijk kwa prijs) er nog eens 1 te gaan proberen onder FreeBSD, toch maar besloten om voor een kaartje met LSI chipset te gaan, vanwege het gemak.

Helaas dus geen recente ervaringen, maar niet echt goede ervaringen in het verdelen.


Ook nog even een vraag van mijn kant zijn er al mensen die FreeBSD met ZFS en ISCSI geprobeerd hebben, ik lees wat wisselende ervaringen, en wil voor mijn volgende projectje toch wel graag ISCSI.

[Anoniem: 15758]

terror538 schreef op donderdag 25 augustus 2011 @ 11:14:
Nou vraag ik mij af hoe vervelend FreeBSD het vind als ik gewoon een powerdown doe, de multiplier ertussen knal en 2 drives van mijn ZFS pool en geom_mirror migreer naar de multiplier. Weet ZFS ze gewoon te vinden aan de hand van iets als een UUID ofzo ? Of moet ik ZFS het echt vertellen, of zelfs de disks 1 voor 1 migreren ?

FreeBSD heeft een mooi GEOM framework en 'proeft' alle disks dus als je je disks anders aansluit zou dat geen enkele gevolgen mogen hebben. Andere controler etc. idem. Overigens kan ik port multipliers niet aanbevelen; dit is slecht voor de performance. Waarom geen extra PCIe controller? Oh en de meeste SSDs zijn niet geschikt als SLOG/ZIL disk; wil je zowel L2ARC als SLOG dan is de Intel 320 de enige consumenten SSD die hiervoor geschikt is. Helaas hebben de 40/80GB modellen wel een beperkte schrijfsnelheid. De 120GB is de sweet spot. Je kunt met 2 SSDs prima beide SSDs voor zowel L2ARC als SLOG gebruiken; in feite voor beide dus een RAID0 wat ZFS intern doet. Gewoon partities maken en 2x L2ARC en 2x SLOG maken.

Sleepie schreef op donderdag 25 augustus 2011 @ 23:00:
Is een AOC-SASLP-MV8 iets als HBA voor een ZFS systeem?

Niet doen, die Marvell chip krijg je alleen maar gezeik mee. Neem een controller op basis van LSI chip die worden veel beter ondersteund.

Sneezydevil schreef op vrijdag 26 augustus 2011 @ 07:30:
Ook nog even een vraag van mijn kant zijn er al mensen die FreeBSD met ZFS en ISCSI geprobeerd hebben, ik lees wat wisselende ervaringen, en wil voor mijn volgende projectje toch wel graag ISCSI.

Ik draai ook iSCSI; werkt prima verder. Ik raad echter aan iSCSI spaarzaam te gebruiken en zeker niet al je storage hierop te draaien. Met iSCSI emuleer je een virtuele hardeschijf waar je client PC dan bijvoobeeld NTFS filesystem op zet. Dat biedt dus veel minder veiligheid dan een native ZFS filesystem waarbij ZFS file-based checksums toepast.

iSCSI = SAN protocol, alleen de client heeft controle over het filesystem
Samba (CIFS) en NFS zijn NAS protocollen; de server heeft controle over het filesystem

Wel kun je prima Samba, NFS en iSCSI door elkaar gebruiken; door bijvoorbeeld een vaste 500GB als iSCSI disk te exporteren en de rest gewoon native storage. Je kunt zelfs remote booten van die iSCSI disk onder Linux OS bijvoorbeeld; en het dus als systeemdisk gebruiken. Voor Windows is iSCSI handig omdat dat niet als netwerkschijf wordt gezien, en je dus nare beveiligingen zoals in Photoshop en Outlook en nog wat meuk kunt omzeilen die gaan mekkeren als je een netwerkdisk wilt gebruiken. iSCSI disk wordt als lokale schijf gezien.

[ Voor 25% gewijzigd door Anoniem: 15758 op 26-08-2011 07:51 ]

[Sneezydevil]

Ik was van plan virtuele servers te booten met ISCSI. Hoe ik de main storage ging aanpakken was ik me nog niet zeker van. Ik heb eraan gedacht dit ook via ISCSI te doen, vanwege de windows rechten, maar dit is dus misschien af te raden?

Mssql databases vinden shares ook niet zo leuk, weet ik uit ervaring.


Ik vond het volgende:

The checksums are still happening on a zvol and on a file backed LUN. ZFS doesn't know anything about the file or data its storing...a bit is a bit to it. So it's still there and happening behind the scenes. NTFS however is just aware of the block device layer that is presented to it.

En dit:

Zfs checksums don't apply to files stored in a higher level disk format such as NTFS


Tijd om me even in te gaan lezen, hoe het nu in elkaar zit.

[Pantagruel]

Anoniem: 187449 schreef op donderdag 25 augustus 2011 @ 23:26:
ik lees ook issues onder linux met dat controllertje ..

Niet echt fraai dat een schijf of de gehele array er uit patst onder belasting, die HBA valt dus af.

Aan de hand van een ander draadje in het zuinige ESXi topic een zeer compact lijstje gemaakt met 'populaire' HBA's, populair omdat ze veel waar bieden voor de prijs.

Controller/HBA	3GB/6GB	3TB
LSI SAS 9211-8i (SAS9211-8I/SGL)	6GB/s	ondersteund
IBM M1015 (LSI SAS 9220-8i/9210-8i)	6GB/s	ondersteund
LSI LSI SAS3081E-R-SGL	3GB/s	ziet 2.2 TB
Intel RAID Controller SASUC8I	3GB/s	ziet 2.2 TB
IBM ServeRAID-BR10i (LSI SAS3082E-R)	3GB/s	ondersteund, firmware versie 2.72 vereist

Zoals ik al zei, compact

Ik heb nog niet verder gezocht of het feit dat de HBA slechts 2.2 TB van de 3 TB nog voor andere onhebbelijkheden zorgt. Mocht ik daar wat meer over vinden in de diverse fora dan volgt er wel een edit.

[ Voor 4% gewijzigd door Pantagruel op 27-09-2011 19:17 . Reden: Update ivm nieuwere firmware voor de BR10i die 3Tib drive ondersteuning geeft. ]

[Anoniem: 187449]

handig zo'n lijstje

als ik het zo lees kan je stellen dat HBA's met LSI chips goed worden ondersteund en dat er veel minder problemen mee zijn dan met controllers met marvel chips.

[Sleepie]

SuperMicro heeft naast de op Marvell controllers gebaseerde kaartjes ook nog wel op LSI chipjes gebaseerde kaartjes.
Bijvoorbeeld de pricewatch: Supermicro AOC-USAS-L8i (LSI1068E kloon, net als de SASUC8i).
Die zou je er nog bij kunnen zetten
(Let wel op, geen standaard formfactor dat kaartje)

[ Voor 7% gewijzigd door Sleepie op 26-08-2011 12:25 ]

[Pantagruel]

Sleepie schreef op vrijdag 26 augustus 2011 @ 12:24:
SuperMicro heeft naast de op Marvell controllers gebaseerde kaartjes ook nog wel op LSI chipjes gebaseerde kaartjes.
Bijvoorbeeld de pricewatch: Supermicro AOC-USAS-L8i (LSI1068E kloon, net als de SASUC8i).
Die zou je er nog bij kunnen zetten
(Let wel op, geen standaard formfactor dat kaartje)

Klopt is een UOI kaart (min of meer een 'op de kop' uitvoering van een normale PCIe kaart), maar dat zal een recht geaarde tweaker niet remmen. Een bracket verbuigen/modden of nylon afstandhouders werkt goed. In het geval van t laatste verlies je wel 2 slots voor t plaatsen van 1 kaart als je dit picje zo ziet:.



Maar als je de spacers op de juiste manier plaatst lijkt het dat je slechts 1 slot gebruikt en niet 2 posities gebruikt.



En inderdaad de HBA's met een Marvel chipset lijken voornamelijk kommer en kwel te veroorzaken.

[ Voor 5% gewijzigd door Pantagruel op 26-08-2011 13:16 ]

[terror538]

Anoniem: 15758 schreef op vrijdag 26 augustus 2011 @ 07:47:
[...]

FreeBSD heeft een mooi GEOM framework en 'proeft' alle disks dus als je je disks anders aansluit zou dat geen enkele gevolgen mogen hebben. Andere controler etc. idem. Overigens kan ik port multipliers niet aanbevelen; dit is slecht voor de performance. Waarom geen extra PCIe controller? Oh en de meeste SSDs zijn niet geschikt als SLOG/ZIL disk; wil je zowel L2ARC als SLOG dan is de Intel 320 de enige consumenten SSD die hiervoor geschikt is. Helaas hebben de 40/80GB modellen wel een beperkte schrijfsnelheid. De 120GB is de sweet spot. Je kunt met 2 SSDs prima beide SSDs voor zowel L2ARC als SLOG gebruiken; in feite voor beide dus een RAID0 wat ZFS intern doet. Gewoon partities maken en 2x L2ARC en 2x SLOG maken.

Thx
De performance hit van port multipliers zou (dacht ik dan) niet gigantisch moeten uitmaken, de drives vullen toch nooit de volledige 600MB/s helaas zijn er alleen maar 300MB/s PM beschikbaar en ben bang dat je het dan wel begint te voelen. PM zijn per poort wel iets goedkoper dan een nieuwe controller, maar ik was al van het idee afgestapt om PM te gebruiken maar juist een Supermicro LSI kaartje. Per poort ben ik dan +- een euro duurder uit maar dan heb ik wel meer performance dan dat ik met een PM zou halen, die euro wel waard dus.
Een ZIL wil ik vooral hebben om de klappen die ik met samba als erg storend ervaar goed op te vangen, mijn schrijfsnelheid klappert te erg zelfs na uitvoerig tweaken. Het is een beetje het bekende probleem waar er uiteindelijk gehangen wordt ook nadat het bestand volledig weggepompt is (maar voordat ZFS dus aan samba meld dat het on disk staat).
Is het performance verschil tussen die intel en bv een kingston s100 16gb zo groot dat het het enorme prijsverschil rechtvaardigd ? (omdat die 120 gig ook gewoon keiharde overkill zijn voor mij)

[Anoniem: 15758]

Dat 300MB/s delen werkt in de praktijk heel anders. Port multipliers en expanders kunnen de bandbreedte niet zomaar verdelen onder de aanwezige apparaten. Het werkt zo dat er een extra chip tussen zit die alle data opnieuw moet verzenden. Als ZFS data naar 4 disks tegelijk verstuurd kan dit door de Port Multiplier niet tegelijk naar de 4 disks worden verzonden maar één voor één. Door de werking van RAID-Z betekent dat de hoogste latency geldt voor alle schijven. Dus als de snelste disk 4ms is en de langzaamste disk (door de port multiplier) 10ms is, dan geldt die 10ms voor alle vier de schijven. Gevolg: je haalt flink lagere snelheden dan wanneer je dedicated bandwidth hebt voor elke schijf. PCIe en SATA zijn dedicated; ga dat dus niet verprutsen met zo'n port multiplier. Als je het al hebt kun je er mee leven, maar nu heb je nog de keuze; beter je geld investeren in een echte controller daar heb je op lange termijn veel meer aan.

Kingston maakt JMicron/Toshiba SSDs; deze ondersteunen geen NCQ dus gebruik je maximaal 1 kanaal bij random reads; ook de 4K write performance is erg laag. Deze SSDs zijn dus van alle SSDs het minst geschikt voor gebruik met ZFS; niet doen dus. De Intel 320 is de enige die geschikt is voor SLOG; wel met de firmware fix want die supercapacitors is waar het allemaal om draait. Zorg ook dat je de nieuwe stabiele versie van ZFS v28 op FreeBSD draait; versie 15 (de oude stabiele) betekent het verlies van SLOG dat je hele pool verloren is.

De Intel 320 120GB is qua opslag wel overkill; SLOG gebruikt maar een paar gig en L2ARC van 40GB heb je al enorm veel aan. Maar het gaat hierbij voornamelijk om de write snelheid; die is bij de 120GB versie op een redelijk niveau terwijl de 40 en 80GB een beperkte write performance hebben; opzich kun je de 80GB ook overwegen. Hou ook rekening mee dat L2ARC je extra RAM geheugen kost. Om 20GB vol te maken met 4K random reads heb je al 1 gigabyte RAM nodig; dus dat kan hard gaan. Onvoldoende RAM betekent dat ZFS maar beperkt de opslagcapaciteit van je L2ARC disk gebruikt.

[Femme]

Als een port multiplier command-based switching doet kan hij inderdaad maar commando's naar één disk tegelijkertijd versturen en moet hij wachten tot deze disk de transacties in de command queue heeft voltooid voordat een andere disk aan de beurt kan komen. Er is ook frame frame based switching mogelijk met sata port multipliers. In dat geval kan de host op elk moment commando's naar de disks achter de port multiplier sturen en zorgt de port multiplier voor het verdelen van de bandbreedte.

In een topologie waarin sas expanders worden gebruikt kunnen disks gewoon tegelijkertijd aangesproken worden. Sas expanders schalen uitstekend zonder noemenswaardig prestatieverlies. De bandbreedte is normaal gesproken erg hoog omdat de meeste expanders over minimaal een wide port van 4x 300MB/s met de host zullen beschikken. Ze worden op grote schaal toegepast in enterprise storagesystemen. Zodra er meer dan acht disks in een systeem gaan kun je er vanuit gaan dat er sas expanders worden toegepast om aan het gewenste aantal poorten te komen.

[Sleepie]

En de volgende vervangende disk is weer binnen hier

Ik moet zeggen, ik wordt toch wel erg blij van de resilver snelheid/tijden in vergelijk met een mdadm rebuild:

action: Wait for the resilver to complete.
 scan: resilver in progress since Sat Aug 27 11:50:42 2011
    359G scanned out of 4.26T at 530M/s, 2h8m to go
    35.8G resilvered, 8.24% done

[ Voor 3% gewijzigd door Sleepie op 27-08-2011 14:02 ]

[Anoniem: 77995]

Ik moet zeggen, ik wordt toch wel erg blij van de resilver snelheid/tijden in vergelijk met een mdadm rebuild:

Hmmm... dat is inderdaad niet slecht!

[warcow]

Ravefiend schreef op donderdag 25 augustus 2011 @ 12:59:
@warcom: kijk es wat vmstat -i precies terug geeft? Misschien dat je via die manier kan bepalen welk process verantwoordelijk is voor al die interrupt requests.

Heb het gedaan met dit resultaat:

code:

interrupt         total        rate
irq4:   uart0     11610      932
irq14: ata0       820          6
irq17: ehci0      34596       276
irq18: ohci0      74           0
irq19: ahci0      1592       12
cpu0: timer       247844     1985
irq256:re0        190         1
cpu1: timer       227802     1822

Bij het opstarten zie ik ook meerdere keren (6 keer, voor elke schijf?) de volgende regel:
ataidle the device does not support advanced power management

Volgens mij gaan mijn schijven ook nooit een spindown doen, wat ik steeds hoor zal wel het parkeren van de schijfkoppen zijn (?).
De schijven staan in het bios op AHCI, tot 5 minuten geleden was dat IDE. (Lijkt niks te veranderen.)
Cool n quiet staat aan in het bios.

[ Voor 8% gewijzigd door warcow op 27-08-2011 21:30 ]

[Femme]

In hoeverre is het mogelijk om suspend to ram te doen in besturingsssytemen die ZFS ondersteunen, zoals Nexenta en OpenIndiana, met hardware zoals LSI sas-controllers? Een ZFS-server hoeft voor mij niet permanent beschikbaar te zijn maar aangezien de inhoud van de ARC en L2ARC verloren gaan bij een reboot is het ook niet wenselijk om de server uit te zetten. Suspend to ram zou ideaal zijn (helemaal als er een handige mogelijkheid is om 'm remote wakker te schudden).

[ Voor 4% gewijzigd door Femme op 28-08-2011 01:59 ]

[Pantagruel]

Femme schreef op zondag 28 augustus 2011 @ 01:58:
In hoeverre is het mogelijk om suspend to ram te doen in besturingsssytemen die ZFS ondersteunen, zoals Nexenta en OpenIndiana, met hardware zoals LSI sas-controllers? Een ZFS-server hoeft voor mij niet permanent beschikbaar te zijn maar aangezien de inhoud van de ARC en L2ARC verloren gaan bij een reboot is het ook niet wenselijk om de server uit te zetten. Suspend to ram zou ideaal zijn (helemaal als er een handige mogelijkheid is om 'm remote wakker te schudden).

OpenIndiana, ZFSGuru en Freenas doen er nog niet aan (diverse requests gezien op de fora) dus op dit moment zul je het met FreeBSD moeten doen.

Het wakker schudden van je server is afhankelijk van WoL ondersteuning door je netwerkkaart/moederbord bios (in de regel bij server moederborden goed geregeld) en het gericht versturen van een 'magic-packet' . Her en der zijn er ook wel meldingen dat de Intel Pro/1000 MT WoL vanuit S3 doen zonder de noodzaak om een specifiek magic packet te sturen om ze wakker te krijgen.

Onder linux werkt het perfect, de file server gaat braaf uit als de data array al 30 minuten stil heeft gestaan.
Ookal gaat t verbruik niet terug naar nagenoeg nul, 8 W is altijd beter dan 60W bij idle.
Het magische pakketje stuur ik mbv Magic Packet sender

[ Voor 3% gewijzigd door Pantagruel op 28-08-2011 14:46 ]

[Dadona]

Pantagruel schreef op zondag 28 augustus 2011 @ 14:43:
[...]


OpenIndiana, ZFSGuru en Freenas doen er nog niet aan (diverse requests gezien op de fora) dus op dit moment zul je het met FreeBSD moeten doen.

ZFSGuru is FreeBSD met een web interface. Is die functionaliteit er dan toch uit gestript?

[Pantagruel]

Dadona schreef op zondag 28 augustus 2011 @ 14:49:
[...]
ZFSGuru is FreeBSD met een web interface. Is die functionaliteit er dan toch uit gestript?

Klopt als een zwerende vinger. Maar klaarblijkelijk is de liveCD dus flink besneden.

Een optie is om ZFSGuru handmatig na te installeren over een virgin FreeBSD install heen.
Op dit moment staat de hardware voor de EXSi/ZFS machine nog in bestelling, maat dit is zeker iets om eens uit te testen zodra de boel binnen is.

FreeNAS is trouwens ook een FreeBSD derivaat, maar dus eveneens gestript. Binnen het FreeNAS forum zijn er 2 navragen mbt STR en de hint om t via een bug report op de feature wish list te krijgen.

[ Voor 28% gewijzigd door Pantagruel op 28-08-2011 15:40 ]

[Dadona]

Bij FreeNAS merk je het overal dat het gestript is. Alleen al omdat de download kleiner is. Maar de ZFSGuru disc is qua formaat ongeveer even groot als de FreeBSD live cd.
Jammer genoeg lijkt er toch wat serieuze tegenslag te ontstaan in de ontwikkeling van FreeBSD. De vertraging loopt steeds meer op. Maar goed, Intel heeft de 320 ook nog niet op orde, dus of ik nu linksom of rechtsom moet wachten.

[Pantagruel]

Dadona schreef op zondag 28 augustus 2011 @ 16:07:
Bij FreeNAS merk je het overal dat het gestript is. Alleen al omdat de download kleiner is. Maar de ZFSGuru disc is qua formaat ongeveer even groot als de FreeBSD live cd.
Jammer genoeg lijkt er toch wat serieuze tegenslag te ontstaan in de ontwikkeling van FreeBSD. De vertraging loopt steeds meer op. Maar goed, Intel heeft de 320 ook nog niet op orde, dus of ik nu linksom of rechtsom moet wachten.

Tja, FreeBSD is af als 't af is

Opensolaris is ook een eventuele optie, daar schijnt STR, mits de hardware S3 goed doet, te werken.

[Dadona]

Standaard antwoord op de vraag 'wanneer is het af' inderdaad. OpenSolaris wil ik niet meer aan beginnen, met de overname en het de nek omdraaien zie ik dat als een dood spoor. Ik heb mijn zinnen gezet op FreeBSD en als ik dan maar iets langer moet wachten, dan is dat maar zo.

[Pantagruel]

Dadona schreef op zondag 28 augustus 2011 @ 16:36:
Standaard antwoord op de vraag 'wanneer is het af' inderdaad. OpenSolaris wil ik niet meer aan beginnen, met de overname en het de nek omdraaien zie ik dat als een dood spoor. Ik heb mijn zinnen gezet op FreeBSD en als ik dan maar iets langer moet wachten, dan is dat maar zo.

Heb je inderdaad een punt. De overname door Oracle heeft de toekomst van OpenSolaris onzeker gemaakt en alternatieven als OpenIndiana en Nexenta aangewakkerd.

Nexenta lijkt STR te doen, mits drivers en bios meespelen.

[Anoniem: 15758]

Pantagruel schreef op zondag 28 augustus 2011 @ 15:32:
Klopt als een zwerende vinger. Maar klaarblijkelijk is de liveCD dus flink besneden.
(..)
FreeNAS is trouwens ook een FreeBSD derivaat, maar dus eveneens gestript.

Ik kan er naast zitten; maar volgens mij klopt dit niet. FreeNAS is gestripped ja, maar ZFSguru niet. Ook niet de LiveCD; die gebruikt in elk geval dezelfde system image als na installatie.

Suspend-to-RAM is een APM/ACPI feature en dat zit in de kernel; als er iets in FreeNAS gestripped is zal het waarschijnlijk om de userland utilities gaan zoals acpiconf en zzz.

Zie voor meer informatie over Suspend-to-RAM in FreeBSD:
http://www.freebsd.org/doc/handbook/acpi-debug.html
En de meest makkelijke methode om te testen lijkt mij het zzz commando:
http://www.freebsd.org/cgi/man.cgi?query=zzz&sektion=8

Dadona schreef op zondag 28 augustus 2011 @ 16:07:
Jammer genoeg lijkt er toch wat serieuze tegenslag te ontstaan in de ontwikkeling van FreeBSD. De vertraging loopt steeds meer op. Maar goed, Intel heeft de 320 ook nog niet op orde, dus of ik nu linksom of rechtsom moet wachten.

Dat is normaal voor FreeBSD hoor. Zeker voor FreeBSD 9 verwacht ik dat de release engineering zo'n 2-3 maanden kan gaan duren. FreeBSD heeft een andere mentaliteit dan bijvoorbeeld Ubuntu die vaste data kent voor release cycles. FreeBSD heeft de mentaliteit it's done when it's done en volgens mij hebben ze in hun verleden nog nooit aan een release schedule gehouden. De vraag is dan ook niet óf er schedule slips zijn, maar in welke mate. Ik verwacht dat FreeBSD 9 zo in eind oktober misschien aan een release toe is; dat lijkt mij een realistische schatting. Het kan zelfs nog langer duren; er zitten enorm veel veranderingen in FreeBSD 9-CURRENT. Een leuk lijstje hiervoor is deze:
http://ivoras.net/freebsd/freebsd9.html

Let wel; sommige van die verbeteringen zitten ook al in FreeBSD 8.2 en de -STABLE branch; dat wordt MFC ofwel MergeFromCurrent genoemd.

[KennieNL]

Ik ben nu sinds vandaag ook even aan het verdiepen/knutselen met ZFS op FreeBSD 8.3 (beide zijn nog een beetje nieuw gezien ik meer Linux distros gewend ben). Dit allemaal om te testen virtueel in Virtualbox.

Nu wil ik ZFS on root eens testen, dit heb ik ook werkend gekregen.

Nu heb ik wat vragen:

Voor ZFS on root, kun je als beste voor je root en boot een aparte tank maken? Of gewoon 1 tank met meerdere pools (dit heb ik nu)?
Als je een keer je BSD opnieuw wilt installeren lijkt me 2 tanks wel handig, maar ik ben niet zeker of dit ook echt nodig is.


Is het erg belangrijk om je disken aligned (4kB sector disken) te hebben? en hoe pak je dit als beste aan onder ZFS? Tijdens het maken van de partitie in gpart? Tijdens het maken van een zfs tank?

Ik vind hier het een en ander wel op het internet, maar wil ff zeker zijn... wat ik heb gevonden is tijdens het aanmaken van de tank dat je 4kB moet opgeven.


EDIT: ohja ik gebruikt GPT based disks en geen bsdlabels

[ Voor 3% gewijzigd door KennieNL op 28-08-2011 21:54 ]

[Anoniem: 15758]

KennieNL schreef op zondag 28 augustus 2011 @ 21:49:
Ik ben nu sinds vandaag ook even aan het verdiepen/knutselen met ZFS op FreeBSD 8.3 (beide zijn nog een beetje nieuw

Dat is nogal een understatement; FreeBSD 8.3 bestaat nog niet.
Bedoel je FreeBSD 8.2 of bedoel je 8-STABLE wat in de toekomst 8.3 wordt? Die laatste heeft nu een stabiele versie van ZFS v28; welke ook door ZFSguru gebruikt wordt.

Nu wil ik ZFS on root eens testen, dit heb ik ook werkend gekregen.

Handmatig? Welke tools heb je gebruikt?

Voor ZFS on root, kun je als beste voor je root en boot een aparte tank maken? Of gewoon 1 tank met meerdere pools (dit heb ik nu)?

Even wat termen rechtzetten:

tank: dit wordt vaak als naam van je pool gebruikt; je kunt hem ook "floepsie" noemen; het blijft een pool
pool: een verzameling van vdevs waarop meerdere filesystems kunnen worden ondergebracht
vdev: een 'array' bijvoorbeeld een RAID-Z, een mirror of een enkele disk; een pool kan meerdere vdevs hebben
filesystem: een soort 'directory' met speciale eigenschappen; een pool kan meerdere filesystems hebben; er is altijd één hoofd filesystem met dezelfde naam als de pool. Bij het aanmaken van je pool heb je dus automatisch /tank als hoofd-filesystem bijvoorbeeld

Nu je vraag even anders formuleren:
Kan ik het beste ZFS op root installeren naar een aparte pool en dus ook aparte disks; of kan ik naar dezelfde pool installeren als waar mijn bestanden op staan?
Antwoord: in beide gevallen installeer je naar een eigen filesystem; de vraag is of je een aparte pool wilt gebruiken. Voor de performance is dat niet echt nodig en een gigabyte meer of minder hoef je ook niet om te huilen. Je kunt dus prima naar dezelfde pool installeren en dus één pool voor zowel systeem als data te gebruiken. Echter, booten van die pool lukt niet meer zodra je de pool van meerdere vdevs voorziet; dus uitbreiden kan dan niet meer. Het kan wel, maar dan is je systeem niet meer bootable en moet je een andere boot device gebruiken. Ook willen sommige mensen hun disks laten downspinnen; in zo'n geval is het ook beter je systeem op een andere device (USB stick; SSD) te installeren.

Als je een keer je BSD opnieuw wilt installeren lijkt me 2 tanks wel handig, maar ik ben niet zeker of dit ook echt nodig is.

Niet persé; je kunt gewoon je systeem naar een nieuw filesystem met andere naam installeren. Dat werkt overigens ook met ZFSguru. Die heeft ook een erg makkelijke Root-op-ZFS installatieprocedure wat eigenlijk alles voor je regelt. Maar zelf doen op FreeBSD leer je wellicht meer van.

Is het erg belangrijk om je disken aligned (4kB sector disken) te hebben? en hoe pak je dit als beste aan onder ZFS? Tijdens het maken van de partitie in gpart? Tijdens het maken van een zfs tank?

Ja dat kun je beter altijd doen; nooit geen vieze partities aanmaken. GPT partities kun je de data partitie het beste op 1 megabyte laten beginnen; de eerste megabyte gebruik je dan voor de GPT/MBR data en een boot partitie. Volgens mij doet ZFSguru dat ook op die manier; FreeNAS weet ik niet.

Verder is het belangrijk je 4K sector disks in de juiste configuratie te gebruiken. Single disks, RAID0 en mirror werkt altijd goed; maar bij RAID-Z en RAID-Z2 kun je het beste aan deze richtlijn houden:
RAID-Z: 3, 5 of 9 disks
RAID-Z2: 6 of 10 disks

Dat is de meest ideale configuratie voor 4K sector disks als Samsung F4EG en WD EARS. Als je afwijkt van die configuratie kun je met een 'sectorsize' GNOP-truucje de pool forceren grotere sectoren te gebruiken. Dit wordt ook wel de 'ashift-tweak' genoemd. Dit kun je handmatig doen met gnop en wordt ook door ZFSguru ondersteund.

[KennieNL]

Anoniem: 15758 schreef op zondag 28 augustus 2011 @ 22:06:
Dat is nogal een understatement; FreeBSD 8.3 bestaat nog niet.
Bedoel je FreeBSD 8.2 of bedoel je 8-STABLE wat in de toekomst 8.3 wordt? Die laatste heeft nu een stabiele versie van ZFS v28; welke ook door ZFSguru gebruikt wordt.

8-STABLE ja

Handmatig? Welke tools heb je gebruikt?

http://wiki.freebsd.org/ZFSOnRoot - onderaan de 2 links naar de GPT handleidingen

Even wat termen rechtzetten:

tank: dit wordt vaak als naam van je pool gebruikt; je kunt hem ook "floepsie" noemen; het blijft een pool
pool: een verzameling van vdevs waarop meerdere filesystems kunnen worden ondergebracht
vdev: een 'array' bijvoorbeeld een RAID-Z, een mirror of een enkele disk; een pool kan meerdere vdevs hebben
filesystem: een soort 'directory' met speciale eigenschappen; een pool kan meerdere filesystems hebben; er is altijd één hoofd filesystem met dezelfde naam als de pool. Bij het aanmaken van je pool heb je dus automatisch /tank als hoofd-filesystem bijvoorbeeld

dank

Nu je vraag even anders formuleren:
Kan ik het beste ZFS op root installeren naar een aparte pool en dus ook aparte disks; of kan ik naar dezelfde pool installeren als waar mijn bestanden op staan?
Antwoord: in beide gevallen installeer je naar een eigen filesystem; de vraag is of je een aparte pool wilt gebruiken. Voor de performance is dat niet echt nodig en een gigabyte meer of minder hoef je ook niet om te huilen. Je kunt dus prima naar dezelfde pool installeren en dus één pool voor zowel systeem als data te gebruiken. Echter, booten van die pool lukt niet meer zodra je de pool van meerdere vdevs voorziet; dus uitbreiden kan dan niet meer. Het kan wel, maar dan is je systeem niet meer bootable en moet je een andere boot device gebruiken. Ook willen sommige mensen hun disks laten downspinnen; in zo'n geval is het ook beter je systeem op een andere device (USB stick; SSD) te installeren.

Is gewoon een mirror en gaat niet uitgebreid worden, downspinnen ga ik ook niet aan beginnen.

Niet persé; je kunt gewoon je systeem naar een nieuw filesystem met andere naam installeren. Dat werkt overigens ook met ZFSguru. Die heeft ook een erg makkelijke Root-op-ZFS installatieprocedure wat eigenlijk alles voor je regelt. Maar zelf doen op FreeBSD leer je wellicht meer van.

De keuze FreeBSD heb ik gemaakt om het te leren/snappen. Instellen zal niet veel voorstellen, maar of je ook snapt wat je doet... vind ik ook wel belangrijk

Ja dat kun je beter altijd doen; nooit geen vieze partities aanmaken. GPT partities kun je de data partitie het beste op 1 megabyte laten beginnen; de eerste megabyte gebruik je dan voor de GPT/MBR data en een boot partitie. Volgens mij doet ZFSguru dat ook op die manier; FreeNAS weet ik niet.

Verder is het belangrijk je 4K sector disks in de juiste configuratie te gebruiken. Single disks, RAID0 en mirror werkt altijd goed; maar bij RAID-Z en RAID-Z2 kun je het beste aan deze richtlijn houden:
RAID-Z: 3, 5 of 9 disks
RAID-Z2: 6 of 10 disks

Dat is de meest ideale configuratie voor 4K sector disks als Samsung F4EG en WD EARS. Als je afwijkt van die configuratie kun je met een 'sectorsize' GNOP-truucje de pool forceren grotere sectoren te gebruiken. Dit wordt ook wel de 'ashift-tweak' genoemd. Dit kun je handmatig doen met gnop en wordt ook door ZFSguru ondersteund.

Ok, zal hier binnenkort eens testen op mn server met 4K sector disken... (EARS)


Mijn dank is groot

[Anoniem: 77995]

Verder is het belangrijk je 4K sector disks in de juiste configuratie te gebruiken. Single disks, RAID0 en mirror werkt altijd goed; maar bij RAID-Z en RAID-Z2 kun je het beste aan deze richtlijn houden:
RAID-Z: 3, 5 of 9 disks
RAID-Z2: 6 of 10 disks

Dat is de meest ideale configuratie voor 4K sector disks als Samsung F4EG en WD EARS.

Als ik 8 disks in Z2 wil gebruiken, is het dan wel prima (ik bedoel dan, geen tweakjes nodig en dus hogere stabiliteit) om Hitachi 512byte schijven in te zetten?

[Ultraman]

Anoniem: 77995 schreef op maandag 29 augustus 2011 @ 17:23:

Als ik 8 disks in Z2 wil gebruiken, is het dan wel prima (ik bedoel dan, geen tweakjes nodig en dus hogere stabiliteit) om Hitachi 512byte schijven in te zetten?

Dat kan prima voor zover ik weet. Die ideale cijfers zijn meer van belang voor 4K schijven dan 512b varianten.

Wat ik me trouwens af vraag: Kan het kwaad om 512b disken te alignen alsof het 4K schijven zouden zijn?
Want stel ik maak nu een pool van twee striped mirrors met 512b disken en ik wil daar later een setje mirrored 4K disken aan toe voegen...
Volgens mij moet dat prima kunnen toch? Omdat die 512b prima in 4K te rijmen valt.
Zolang de performance maar niet teveel af wijkt.

Ik zit trouwens ook leuk te wachten op FreeBSD9. Heb al een test server draaien met 8.2-RELEASE, dat is allemaal wel gelukt. Begint toch wel te jeuken om maar gewoon CURRENT te pakken en die om te zetten in 9-RELEASE zodra die beschikbaar komt...

[Anoniem: 6137]

Waarom gebruiken jullie niet gewoon OI? Ik snap de noodzaak van BSD niet zo. Daarnaast zijn er ook andere zaken in OI zoals commstar, crosbow en zelfs KVM =)

[Pantagruel]

Anoniem: 15758 schreef op zondag 28 augustus 2011 @ 20:20:
[...]

Ik kan er naast zitten; maar volgens mij klopt dit niet. FreeNAS is gestripped ja, maar ZFSguru niet. Ook niet de LiveCD; die gebruikt in elk geval dezelfde system image als na installatie.

Suspend-to-RAM is een APM/ACPI feature en dat zit in de kernel; als er iets in FreeNAS gestripped is zal het waarschijnlijk om de userland utilities gaan zoals acpiconf en zzz.

Zie voor meer informatie over Suspend-to-RAM in FreeBSD:
http://www.freebsd.org/doc/handbook/acpi-debug.html
En de meest makkelijke methode om te testen lijkt mij het zzz commando:
http://www.freebsd.org/cgi/man.cgi?query=zzz&sektion=8

[...]

Na de live CD van ZFS guru opgestart te hebben op de volgende test bak:

#	Product
1	Gigabyte GA-X38-DQ6
1	Corsair Q2X8G6400-C4DHX
1	Areca ARC-1221x
1	Asus EN8800GTS
1	Intel Core 2 Duo E7400

Ben ik eens gaan uitvinden of Suspend nu wilt werken, of niet.

BIOS in,controle of S3 aan is gezet bij power management, check!

Optie 1: De weboppervlakte biedt de mogelijk om een power down te doen (een ordinaire shutdown dus).
Resultaat: Een magic packet schopt de bak wakker, enkel om vanaf de live cd/hdd op te starten. Niet helemaal wat we wilden, maar wel bruikbaar.

Optie 2: In laten slapen vanuit de cli mbv zzz.
Resultaat: De bak lijkt even een stapje terug te nemen, maar gaat vervolgens uit alle macht de fans laten draaien (cpu/videokaart/RAID kaart). Dat is geen goed teken, hier gaat iets mis, snel uitgezet voordat eventuele oververhitting schade kan doen.

Optie 3: In laten slapen vanuit de cli mbv acpiconfig.
Resultaat: Vanuit de cli acpiconfig -s 3 gedaan, mmmm vinger aan de power switch, enter drukken...
De boel doet weer een stapje terug, maar weer geen ' love ' . De fans draaien op max (cpu/videokaart/RAID kaart) en een snelle controle laat zien dat er geen beeld wordt weergegeven en de netwerkverbinding plat ligt.

Prut, klaarblijkelijk is ACPI compliance toch nog moeilijk voor moederbord bakkers

Natuurlijk heb ik 't een en ander ook even onder OpenSuse getest.
Een s2ram -f laat de boel netjes in slapen, evenals een suspend -u. Een magisch pakketje verder en de boel is in de lucht. Maarrrr, de irritante maar, ook daar is niet alles koek en ei.
De Areca ARC-1221x wil niet wakker geschud worden en slaapt rustig verder. Een poging om hem alsnog wakker te schudden resulteert in een hangende bak, zeg dus maar dag met je handje en druk de reset knop maar in. Gelukkig bleek de array ge'killed' te zijn en is er geen schade opgelopen. Een hdd aan de onboard controller snort wel vrolijk op, dus klaarblijkelijk gaat er iets mis met de PCIe init of wil de Areca het simpel weg niet begrijpen .

Wellicht wil een van de ZFS binken hier het op hun machine testen. Het zou zomaar kunnen dat de array aan een HBA (kort door de bocht een veredeld doorgeefluik) zonder problemen uit zijn schoonheidsslaapje ontwaakt.

[Anoniem: 15758]

Ultraman schreef op maandag 29 augustus 2011 @ 17:48:
[...]
Dat kan prima voor zover ik weet. Die ideale cijfers zijn meer van belang voor 4K schijven dan 512b varianten

Geldt inderdaad alleen voor 4K disks.

Wat ik me trouwens af vraag: Kan het kwaad om 512b disken te alignen alsof het 4K schijven zouden zijn?
Want stel ik maak nu een pool van twee striped mirrors met 512b disken en ik wil daar later een setje mirrored 4K disken aan toe voegen...
Volgens mij moet dat prima kunnen toch? Omdat die 512b prima in 4K te rijmen valt.

Het kan in principe geen kwaad om 512B disks met 4K alignment truc (ashift=12) aan te maken; echter zul je dan wel meer ruimte verliezen aan 'slack' zeker in afwijkende RAID-Z. Dat komt omdat af en toe een sector niet volgemaakt zal worden en dat kan aardig aantikken; ik gok zo'n 4% ruimte wat toch best veel is voor een grote pool.

Maar als je nu een normale pool hebt met ashift=9 kun je daar nooit meer een native 4K sector disks aan toevoegen! Dat is een belangrijke beperking. Je kunt wel 512B disks aan 4K disk pools toevoegen maar niet andersom. Met andere woorden: je kunt wel omlaag qua sectorsize maar nooit meer omhoog. Dit is een beperking die niet iedereen kent. Alle normale ZFS pools kunnen dus niet worden uitgebreid met native 4K sector disks als die ooit uitkomen. Dit is overigens niet ZFS specifiek; dit is hoe sectorsize werkt.

Ik zit trouwens ook leuk te wachten op FreeBSD9. Heb al een test server draaien met 8.2-RELEASE, dat is allemaal wel gelukt. Begint toch wel te jeuken om maar gewoon CURRENT te pakken en die om te zetten in 9-RELEASE zodra die beschikbaar komt...

Mja eerlijk gezegd vind ik de ZFS v28 support die nu al in -STABLE zit het belangrijkst. 9-CURRENT heeft wel veel kleine verbeteringen maar echt wereldschokkend is het niet; veel van de verbeteringen zijn namelijk al eerder naar 8.x geport.

Anoniem: 6137 schreef op maandag 29 augustus 2011 @ 19:40:
Waarom gebruiken jullie niet gewoon OI? Ik snap de noodzaak van BSD niet zo. Daarnaast zijn er ook andere zaken in OI zoals commstar, crosbow en zelfs KVM =)

Solaris zuigt; althans op sommige gebieden. Wel een goede ZFS implementatie met name op het gebied van geheugenmanagement; maar op andere vlakken komt Solaris flink tekort. Het mist ook een aantal ZFS-specifieke features die FreeBSD wel heeft. En nu Oracle de scepter zwaait over het Solaris platform kun je maar beter een veilige thuishaven opzoeken die écht open source is.

FreeBSD heeft dus diverse voordelen:

• Echt open source en kan/gaat niet overgenomen worden door een commerciëel bedrijf zoals Oracle
• Hebben zeer skillvolle developers; niet veel maar wel hele goede, die weten wat ze doen en vaak voor bedrijven of overheden geavanceerde functionaliteit ontwerpen; zo ook veel DARPA projecten
• FreeBSD heeft veel innovaties naar andere producten gebracht, zoals Microsoft Windows, Linux kernel, MySQL, Firefox en vast nog meer
• Door zijn licentie kan FreeBSD ook coole technologie van andere projecten importeren, zoals ZFS, D-Trace en pf-firewall
• FreeBSD laat je booten van ZFS pools, ook met een afwijkende sectorsize en zelfs degraded; Solaris kan alleen van single disks en mirrors booten
• FreeBSD heeft een mooi GEOM framework waardoor het hele interessante dingen kan doen op het gebied van storage; en lost een hoop problemen op waar Solaris nu mee kampt.
• Betere hardware support onder BSD; scheelt niet zoveel meer met Linux die nog altijd de beste support heeft

Echter ieder zijn eigen voorkeur; Solaris heeft ook zo zijn voordelen boven FreeBSD. Toch denk ik dat Solaris het nu moeilijk heeft door de overname van Oracle; FreeBSD heeft hier geen last van en de devs hebben al aangegeven dat ZFS hoe dan ook in de standaard releases blijft wat Oracle ook doet of wilt. Als je geen bijzondere voorkeur hebt voor Solaris of BSD dan lijkt me laatstgenoemde een logischere keus. Let wel: ik ken BSD véél beter dan Solaris dus ik ben niet helemaal 'onpartijdig'.

Pantagruel schreef op maandag 29 augustus 2011 @ 22:40:
Prut, klaarblijkelijk is ACPI compliance toch nog moeilijk voor moederbord bakkers

Dat is ook mijn ervaring ja; ACPI tables zijn vaak onvolledig of onjuist; omdat ze alleen onder Windows testen en andere OS kunnen de schijt krijgen. Luie donders die moederbordfabrikanten. Zo ook de tenenkrommende spelfouten in officiële BIOS releases; zelfs van Asus. Het zijn gewoon amateurs die snel producten op de markt willen brengen; niet erg compatible met het streven naar kwaliteit van goede open source projecten. Helaas ben je nog afhankelijk van je moederbord BIOS; zelf hoop ik dat we een soort open source BIOS kunnen krijgen. Zodat Linux en andere OS niet meer afhankelijk zijn van de skills van Taiwanese moederbordfabrikanten met te weinig slaap en/of motivatie.

[onox]

CiPHER: zou je die info over ashift en ideale hoeveelheid 4K sector disks voor RAID-Z en RAID-Z2 misschien aan de startpost kunnen toevoegen? Lijkt me wel handig.

[Anoniem: 15758]

Ja je hebt helemaal gelijk; de startpost heb ik eigenlijk nooit echt afgemaakt. Wanneer ik wat tijd heb zal ik eens een goede poging wagen!

[NetXtreme]

Probeer ik vandaag bezig te gaan met m'n NAS VM... Is ZFSGuru down... heeft iemand een mirror? Heb al even gezocht, maar kan niets vinden (weet ook niet wat laatste versie is)

[Sleepie]

NetXtreme schreef op dinsdag 30 augustus 2011 @ 12:58:
Probeer ik vandaag bezig te gaan met m'n NAS VM... Is ZFSGuru down... heeft iemand een mirror? Heb al even gezocht, maar kan niets vinden (weet ook niet wat laatste versie is)

Ben hem voor je aan het uploaden, 5 minuutjes geduld svp

[NetXtreme]

Sleepie schreef op dinsdag 30 augustus 2011 @ 13:09:
[...]

Ben hem voor je aan het uploaden, 5 minuutjes geduld svp

Dank u zeer

[Sleepie]

NetXtreme schreef op dinsdag 30 augustus 2011 @ 13:10:
Dank u zeer

U heeft een DM

[Dadona]

Wel treurig dat ZFSGuru er zo vaak uit is. Of is dit de migratie van de server van een vriend naar een andere oplossing?

[Sleepie]

Dadona schreef op dinsdag 30 augustus 2011 @ 15:43:
Wel treurig dat ZFSGuru er zo vaak uit is. Of is dit de migratie van de server van een vriend naar een andere oplossing?

Jason ging een oplossing zoeken inderdaad. Ik hoop dat dit ermee te maken heeft.

[Anoniem: 6137]

Inline quoten wordt een beetje lang met sommige replies maar even terug komend op de uitspraak: Solaris zuigt en Oracle zwaait ...en dergelijke.

Nexenta heeft top spelers van SUN op de payrol staan zoals Garret Damore en Richard Elling en Bill Moore die zelfs in de board zit, deze naam is denk ik wel bekend van 3PAR en ZFS. Deze lui weten echt wel wat ze aan het doen zijn. Garret is ook de gran pumba van Illumos.

Daarnaast om te zeggen dat Solaris zuigt op basis van deze argumenten is niet heel erg sterk. Joyent in de "magic quadrant" van gartner doet hele goeie zaken met Ilumos en daar werken nu figuren als Brandon etc. uiteraard doen Nexenta (storage) en Joyent (storage client) hand in hand de ontwikkeling.

Oracle is hier dus niet zo dominerend als het gaat om ontwikkeling, Nexenta is op invite van VMware momenteel de vmware labs op vmworld naast EMC en NetApp, dit zegt heus wel wat. daarnaast is er een ZFS working group waar Nexenta, Joyent, Intel, Oracle o.a inzitten om te zorgen dat ZFS versies werkbaar blijven tussen de verschillende vendoren/versies/ontwikkelingen.

Ik wil geen BSD vs OI/illumos ware beginnen maar zeggen dat solaris zuigt... totaal niet. Ik heb zelf nog nooit zo'n volwassen Unix gezien als Solaris al was het maar op alle "adms" die ze hebben. met name de fault managment van Solaris is als je het mij vraagt erg sexy

Ook las ik ergens dat OI/Illumos/Nexenta t niet toe laat om SSD's half hier en half daar te gebruiken iets wat prima kan.

[FireDrunk]

Er was toch een probleem met flushes sturen naar partities? Of is dat al opgelost?

(weet niet meer of dat juist BSD was of Solaris?)

[Anoniem: 6137]

Solaris gebruikt slices. De device moet het flush commando ondersteunen of er voor zorgen dat het battery backed is. Dit geldt alleen voor de ZIL, als je wilt kan je op je SSD zelf een file aanmaken en deze toevoegen aan de zpool met mkfile. Maar ik denk dat de meesten hier niet veel sync IO doen dus een ZIL nodig zal me verbazen.

[FireDrunk]

Voor metadata heb je toch altijd sync writes nodig?

[Anoniem: 6137]

Alle IO die ZFS naar de disken doet is atomic tav de uberblock, na iedere tgx wordt deze ge-update. In de tgx staat alle data, file, metedata van file en metadata van ZFS.

[FireDrunk]

Dat is niet direct een antwoord op mijn vraag... Ook atomic operaties kunnen non sync zijn.
Als een disk die die atomic write vrolijk cached, en de stroom valt uit (en je hebt geen BBU) dan zit je dus met een kapotte file en een achterlopend FS. (niet dat het niet meer werkt, maar je mist data)

Om die Sync te forceren moet je OS dat opsturen naar de controller en deze moet dat ook pas accepten als het daadwerkelijk op disk/flash staat..

[Anoniem: 6137]

Klopt, maar dan snap ik je vraag niet Anyway, op het moment van schrijven van de nieuwe uberblock wordt de timestap geschreven en maakt hem daarna de active uberblock. Alle cache flushes en dergelijke worden hier voor gedaan.

[FireDrunk]

Precies, als die cache flush dus om de een of andere reden genegeerd word (de disk/controller of whatever ondersteund het niet) denkt ZFS dus dat alles op disk staat terwijl dat dus niet zo is...

Ik heb CiPHER hier ooit eens iets over horen zeggen, iets met het feit dat Solaris of BSD geen flushes op partities ondersteunden maar wel op hele disks...

[Anoniem: 6137]

De write cache wordt disabled, dus performance dropped. Dat is wat anders.

[Anoniem: 77995]

Zoals eerder gemeld ben ik bezig een ZFS (Z2) NAS te bouwen, waarbij ik zo weinig mogelijk probeer te spenderen.
Ik ben hier heel strikt in: als ik een SATA kabel nodig heb en die kost bij de lokale winkel €1,50 terwijl ik hem voor €1,- uit China kan laten komen, doe ik dat - haast is er toch niet bij, dit is voor de leuk.

Bij deze een update.

Inmiddels is het systeem aardig compleet geworden. Gedeeltelijk bestaat het uit oude spullen van mezelf, ik had genoeg liggen om er een "extra" systeem op na te houden, maar daar deed ik te weinig mee - vandaar het idee om een NAS te gaan maken.

- De oude voeding was niet goed genoeg, dus deze moest vervangen worden.

- Ook kreeg ik het systeem met geen mogelijkheid geboot met een simpele PCI grafische kaart. Ik heb daarom de kaart uit m'n dagelijkse systeem gebruikt en daar een actuelere vervanger in teruggezet.

- Anders dan ik me herinnerde, heeft het te gebruiken moederbord slechts VIER aansluitingen voor SATA. Een tegenvaller! Er zijn dus in eerste instantie twee extra SATA controllers nodig om tot 8 schijven te komen. Wellicht komt er nog één bij. Het is een gamersbord en heeft 4 stuks PCIe x16 en één PCIe x1 slot, genoeg plek dus.

- Deze week is de Chinese rommel van DealeXtreme binnengekomen. Gezien de gemangelde staat waarin veel van hun waar arriveerd, was ik bang hoe de SATA controllers er uit zouden zien, maar deze waren goed verpakt en hebben de reis overleefd.

- Deze SiI3132 controllers heb ik 1-voor-1 in een Win7 machine gezet. Win7 kon er niets mee, dus eerst de RAID driver van Silicon Image moeten inzetten. Hierna konden de kaartjes geflashed worden als HBA. Dit ging heel prettig, vanuit het Win7 apparaatbeheer.
Ook voor deze HBA "versie" van de controllers was een driver van SI zelf nodig, Windows kon er niets mee.

- Hierna de controllers gaan volhangen met oude schijven: succes! Alles wordt herkend, is benaderbaar en werkt zo snel als je kan hopen. De SMART info is niet de sterkste kant van SI, maar na wat zoeken bleek HDSentinel prima in staat alles uit te lezen. Waarom andere software hier in combinatie met de SiI3132 zo veel problemen mee heeft, weet ik niet. En of FreeBSD het kan...?

Gezien het succes tot nu toe, heb ik (nog) vertrouwen in de gang naar FreeNAS. Als ik binnenkort weer eens tijd heb, ga ik dat installeren met wat test schijven.

Dit is de config van het moment:

• Behuizing: Chieftech BigTower (oud)
• Voeding: Corsair VX550W (V&A)
• Mobo: MSI K9A2 Platinum V2 (oud)
• Proc: AMD64 X2 4200+ Brisbane (V&A)
• Geheugen: 4x2GB gemixte Kingston (oud en Marktplaats)
• Video:PCIe ATI Radeon HD2400 (gekannibaliseerd)
• SATA: 2xSilicon Image SiI3132 (DealeXtreme)
• Boot: IDE2CF controller (DealeXtreme)
• Kabeltjes, CF kaart en ander klein spul (oud en DealeXtreme)

[Sleepie]

Gezien de post hierboven en mijn RocketRaid kaartje wat hier nog steeds op een koper ligt te wachten vraag ik me opeens iets af.

Als je bijvoorbeeld zo'n RocketRaid 2320 (die ligt hier, die neem ik maar als voorbeeld) hebt, dan is dat geen HBA natuurlijk, maar je kunt hooguit de disks als JBOD configger op je raid kaart.

Gaat dat eigenlijk werken met ZFS??

[Anoniem: 6137]

Als je de write cache uitzet van de RAID kaart moet dat wel gaan werken.

[Kriss1981]

Ik heb ergens gelezen dat je dan nog steeds de kans hebt dat er schijven uit je array gegooid worden.

[Phorze]

Hierboven gaat er nog een verhaal over disk flushes etc, ik denk dat ik mijn huidige probleem hier moet zoeken. ik heb nu een ESXI server met een FreeNAS guest draaoem. daar heb ik door middel van RDM mijn disks in de VM geladen.

NAME USED AVAIL REFER MOUNTPOINT
PwnVault 151K 10.7T 47.1K /mnt/PwnVault

Als ik via WinSCP het eea probeer te kopieeren loopt de VM vast, en bij een reboot is de hele pool verdwenen, die ik vervolgens wel weer vrolijk kan aanmaken.

Het lijkt er dus op dat data ook niet daadwerkelijk geschreven wordt.

[Anoniem: 6137]

Kriss1981 schreef op dinsdag 30 augustus 2011 @ 21:40:
Ik heb ergens gelezen dat je dan nog steeds de kans hebt dat er schijven uit je array gegooid worden.

Zou bij BSD best kunnen, Nexenta iig niet. Cache flush zijn SCSI commando's en hebben niet met partities te maken.

[Anoniem: 15758]

Anoniem: 6137 schreef op dinsdag 30 augustus 2011 @ 17:36:
De write cache wordt disabled, dus performance dropped. Dat is wat anders.

En wáárom wordt die disabled? Omdat onder Solaris platform er met meerdere partities geen flush commando's kunnen worden verwerkt. Zonder flush commando's is het inschakelen van device write-back gevaarlijk en dus moet je de write-back uitschakelen met brakke performance als gevolg. Moderne schijven kunnen 1MB/s schrijven in write-through mode; niet zo tof.

Nu moet ik nog even opzoeken hoe het precies zat; maar ik meen dat het te maken had met het feit dat Solaris niet zoiets als een GEOM framework heeft. Als je dus allemaal lagen hebt zoals:

Fysieke disk -> Partitie 2 -> Label -> Encryptielaag -> ... -> ZFS

Beetje complex voorbeeld maar wel leuk in dit verband. Als ZFS nu een flush commando verstuurd moet dus verstuurd worden naar de onderliggende laag, en die stuurt het weer door, net zolang totdat het bij de fysieke disk terecht komt. Ik meen dat het probleem was dat Solaris geen flush commando's kan doorsturen naar onderliggende lagen, en om die reden de write cache uitgeschakeld wordt om dit probleem niet te laten escaleren tot corruptie bij stroomverlies.

Zal zo even wat meer opzoeken hierover; niet alles wat ik onthou is altijd up-to-date of correct.
Maar het is wel een goede uitleg waarom de device write-back uitgeschakeld zou worden; want ZFS zelf kan juist prima omgaan met HDD write-back mits de flush commando's ondersteund worden. Dat is ook de reden dat een Areca met write-back zonder BBU een gevaarlijke setup is waarbij je gemakkelijk je pool corrupt kan maken en dus alles kwijt raakt; de flush commando's worden in zo'n setup genegeerd.

[Anoniem: 6137]

Het ligt niet aan ZFS -- het is een SCSI commando. Maar oudere file systemen kennen geen cache flush dus werd deze standaar disabled, ZFS zet hem juist aan. Het ligt dus niet aan ZFS. In het begin kon er nog niet geboot worden vanaf ZFS en toen werd UFS als boot gebruikt wat toen die tijd voor problemen kon zorgen.

Nogmaals het ligt niet aan ZFS, en cache flush is een SAS/(S)ATA commando.

Nu moet ik nog even opzoeken hoe het precies zat; maar ik meen dat het te maken had met het feit dat Solaris niet zoiets als een GEOM framework heeft.

Nee, als je kijkt ook naar het type vdevs zie je in BSD een geom_vdev -- ZFS regelt zijn eigen IO via ZIO die onderdeel is van de SPA.

Fysieke disk -> Partitie 2 -> Label -> Encryptielaag -> ... -> ZFS

VFS->ZPL->DMU->SPA->VDEV->IO. (in de SPA zitten nog wat dingen maar das niet belangrijk voor de IO stack)

Ik meen dat het probleem was dat Solaris geen flush commando's kan doorsturen naar onderliggende lagen, en om die reden de write cache uitgeschakeld wordt om dit probleem niet te laten escaleren tot corruptie bij stroomverlies.

de vdev laag doet de feitelijke block request en SCSI calls, bij BSD worden deze overgeheveld naar GEOM. Dit is dus niet juist.

[CurlyMo]

Misschien ben ik niet de enige, maar ik begrijp technische uitwisselen maar deels. Voor mij is dan ook een belangrijke vraag wat de consequenties zijn in de praktijk. Kan (een op) Solaris (gebaseerd OS) nu wel of niet goed omgaan met het gebruik van partities/slices in ZFS zoals het volgens CiPHER in BSD sowieso wel werkt mbv GEOM. Het gaat dan om de inzet van dezelfde SSD voor bijv. ZIL en L2ARC?

[Anoniem: 6137]

Ja, BSD durf ik je niet te zeggen.

[ Voor 83% gewijzigd door Anoniem: 6137 op 31-08-2011 17:15 ]

[Anoniem: 15758]

Anoniem: 6137 schreef op woensdag 31 augustus 2011 @ 00:15:
Het ligt niet aan ZFS -- het is een SCSI commando.

Ook gewoon ATA hoor. Bij SCSI heet het SYNC CACHE en bij ATA heet het FLUSH CACHE.

Echter, in FreeBSD werkt het iets anders dankzij het GEOM framework:
als er een file sync wordt gegenereerd door de gebruiker of door een filesystem, dan wordt deze naar de onderste laag toegestuurd als BIO_FLUSH. Elke laag stuurt dit weer door naar de onderliggende laag, totdat de fysieke disk driver (ATA/SCSI) wordt bereikt, die zet het dan om in het SCSI of ATA equivalent.

Zo ook bijvoorbeeld met TRIM, als je allerlei compressie en RAID lagen hebt zitten tussen je filesystem en de SSDs, dan wordt dat middels een BIO_DELETE commando naar de onderste laag gestuurd die het omzet in het ATA TRIM commando of in geval van CompactFlash het equivalent hiervan.

Dat is dus een mooi framework waarin veel potentiële problemen waar andere OS mee kampen voorkomen kunnen worden. Bijvoorbeeld de beperking in Windows dat TRIM op RAID arrays niet werkt omdat een RAID array als SCSI disk is aangekoppeld; zo is het design van Windows. Dat betekent dus ook geen ATA TRIM commando.

Maar oudere file systemen kennen geen cache flush dus werd deze standaar disabled, ZFS zet hem juist aan. Het ligt dus niet aan ZFS. In het begin kon er nog niet geboot worden vanaf ZFS en toen werd UFS als boot gebruikt wat toen die tijd voor problemen kon zorgen.

UFS in Solaris ondersteunt geen flush commando's? UFS in FreeBSD in elk geval wel.

Nee, als je kijkt ook naar het type vdevs zie je in BSD een geom_vdev -- ZFS regelt zijn eigen IO via ZIO die onderdeel is van de SPA.

Het punt is niet dat ZFS het intern niet zou kunnen doorsturen, het punt is dat ZFS in Solaris de flush commando's nooit de disk kunnen laten bereiken; althans daar praten we nu over.

VFS->ZPL->DMU->SPA->VDEV->IO.

Waar zijn je partities? Enige wat je hier doet is ZFS opsplitsen; en VFS laag is niet zo relevant, we weten dat ZFS zelf de flush commando's genereert. Jij stelt dat ZFS dus direct met de disk driver communiceert, ook als daar partities tussen zitten?

Niet om je tegen te spreken, je hebt duidelijk meer verstand van Solaris dan ik. Misschien is mijn informatie verouderd, maar een beetje googlen kom ik zaken tegen als:

It's not a good idea to share an SSD between pools for reasons of data integrity and performance.

First, ZFS needs to be able to trigger the device's onboard cache to flush when a synchronous write is requested, to ensure that the write is really on stable storage before returning to the application. It can only do this if it controls the whole device. If using a slice, ZFS cannot issue the cache flush and you risk losing data during an unexpected shutdown.

Bovenstaande is volgens jou dus complete onzin?

Ik lees ook veel over de aanbeveling whole disks te gebruiken; wat zit daar achter dan? Alleen maar omdat UFS onder Solaris geen flush commando's ondersteunt en dus de disk write cache uitgeschakeld moet worden? Als dat zo zou zijn, zou bovenstaande quote dus onwaar zijn en kun je onder Solaris platforms prima een SSD gebruiken voor:
partitie1: ZFS pool
partitie2: L2ARC voor andere HDD pool
partitie3: SLOG voor andere HDD pool

Onder BSD is bovenstaande geen probleem en flush commando's kunnen de disk prima bereiken. Het stond mij bij dat dit onder Solaris geen veilige setup was, juist vanwege de flush commando's.

Echter, echt goede bronnen heb ik niet kunnen vinden met een snelle googlesessie. Is het een idee om naar een Solaris mailinglist te schrijven voor opheldering? Niet dat ik je niet wil geloven, maar ik ben gewoon erg beniewd hoe het nu precies zit en waar al die verhalen vandaan komen.

[Anoniem: 6137]

ZFS controleert zelf de disken dat is precies wat ik ook zei in de vorige mail. Dus het is ZFS die de cache flush command's stuurt niemand anders

BSD is super -- maar niet alle andere super OS-en doen per definitie wat BSD doet. Ik praat hier over Solaris en wat deze wel of niet met USF kon toen in die tijd. Als de disk ook in gebruik was door UFS, dan werden de cache flushes disabled, niet voor ZFS maar voor UFS.

Het punt is niet dat ZFS het intern niet zou kunnen doorsturen, het punt is dat ZFS in Solaris de flush commando's nooit de disk kunnen laten bereiken; althans daar praten we nu over.

Ik wil niet brutaal zijn, maar dit is dus onzin van de bovenste plank De functie die de cache flush IOCTL maakt naar de disk toe is vdev_disk_io_start(), in vdev_disk.c

Waar zijn je partities? Enige wat je hier doet is ZFS opsplitsen; en VFS laag is niet zo relevant, we weten dat ZFS zelf de flush commando's genereert. Jij stelt dat ZFS dus direct met de disk driver communiceert, ook als daar partities tussen zitten?

Partities zitten nooit in een IO path, er is verschil tussen management (partitie) en techniek (SCSI commando's) deze staan los van elkaar.

Bovenstaande is volgens jou dus complete onzin?

Als de stelling is: OI/Nexenta/Solaris ZFS krijgt data corruptie als je partities/slices gebruikt, dan ja. Als je ZFS gebruikt in general, dat heet: FUSE, Linux, BSD -- dan zeg ik zou kunnen weet ik niet dus hou ik maar me mijn mond

Onder BSD is bovenstaande geen probleem en flush commando's kunnen de disk prima bereiken. Het stond mij bij dat dit onder Solaris geen veilige setup was, juist vanwege de flush commando's.

Onder solaris is dit ook geen probleem, dit kon soms een probleem worden als je de UFS van Solaris met de ZFS van Solaris ging combineren omdat UFS dan dingen tegen de disken zei -- waarvan ZFS niet op de hoogte was. Daarnaast is het zo, dat er dus ook disken zijn die cache flush ondersteunen en zeggen: okay staat op disk terwijl het NIET zo is.

Terugkomend op je pool config, ik weet niet waarvoor je het systeem gebruikt - - maar een ZIL lijkt me niet echt nodig tenzij je er een ESX farm boven draait waarop veel sync write I/O wordt gedaan.

Mocht je er 1 willen is mijn advies de zeusram van stec te gebruiken doen we ook op VMworld, loopt als een trein:

19,455 NFSOPS, mostly read, 1,175 MB/sec @ 1.29 ms #nexenta @vmworld

[CurlyMo]

Anoniem: 6137 schreef op donderdag 01 september 2011 @ 11:39:
[...]
Als de stelling is: OI/Nexenta/Solaris ZFS krijgt data corruptie als je partities/slices gebruikt, dan ja. Als je ZFS gebruikt in general, dat heet: FUSE, Linux, BSD -- dan zeg ik zou kunnen weet ik niet dus hou ik maar me mijn mond
[...]

Wat maakt dan dat ZFS deze data corruptie krijgt, als toch de flush commando het probleem niet is? Dat zou dan betekenen dat het gebruik van partities theoretisch wel mogelijk is in Solaris maar praktisch gezien niet zoals eerder besproken.

[Anoniem: 6137]

CurlyMo schreef op donderdag 01 september 2011 @ 11:46:
[...]

Wat maakt dan dat ZFS deze data corruptie krijgt, als toch de flush commando het probleem niet is? Dat zou dan betekenen dat het gebruik van partities theoretisch wel mogelijk is in Solaris maar praktisch gezien niet zoals eerder besproken.

Brakke hardware, ik zou anders niet weten. (i.e cache flush: ja zeggen nee doen)

[ Voor 1% gewijzigd door _Dune_ op 26-03-2013 21:06 ]

[CurlyMo]

Anoniem: 6137 schreef op donderdag 01 september 2011 @ 11:57:
[...]
Brakke hardware, ik zou anders niet weten. (i.e cache flush: ja zeggen nee doen)

Dat is vrij absoluut gezegd. Kan je specifieker zijn wat dan precies de vereiste zijn qua hardware?

[FireDrunk]

En non-faking cache flush capable device... Een areca met DRAM cache zonder BBU is dat dus niet...

[Anoniem: 6137]

FireDrunk schreef op donderdag 01 september 2011 @ 12:02:
En non-faking cache flush capable device... Een areca met DRAM cache zonder BBU is dat dus niet...

Juist

[CurlyMo]

FireDrunk schreef op donderdag 01 september 2011 @ 12:02:
En non-faking cache flush capable device... Een areca met DRAM cache zonder BBU is dat dus niet...

Dus eigenlijk gewoon gebruik maken van een onboard sata controller moet geen problemen veroorzaken?

[Anoniem: 15758]

Anoniem: 6137 schreef op donderdag 01 september 2011 @ 11:39:
Partities zitten nooit in een IO path, er is verschil tussen management (partitie) en techniek (SCSI commando's) deze staan los van elkaar.

Nouja bij FreeBSD dus wel; de partities zijn onderdeel van de I/O stack, in de vorm van GEOM_PART wat alle partities waaronder MBR, GPT, PC98 en BSD verzorgt. Deze laag ligt meestal direct bovenop de fysieke disk, die door SCSI or ATA driver wordt verzorgd.

Dat het in Solaris heel anders werkt snap ik, maar toch vraag ik me af waar die verhalen over problemen met partities/slices en flush commando's vandaan komen. Jij stelt dat dat grote onzin is en dat het alleen UFS in Solaris is die problemen heeft met device write cache en om die reden bij meerdere partities de device write cache uitgeschakeld wordt omdat de andere partitie mogelijkerwijs voor UFS is bedoeld.

Het is niet dat ik je niet wil geloven; maar ik ben nu toch wel erg benieuwd naar het complete verhaal en waar al die 'do not use partitions, use whole disks' angstpolitiek vandaan komt, inclusief het bericht wat ik gequote heb. Teneinde zelf iets te leren en een eind te maken aan de onduidelijkheid heb ik hier een thread aangemaakt, op het zfs-discuss forum van OpenSolaris:
https://opensolaris.org/jive/thread.jspa?threadID=141445

Terugkomend op je pool config, ik weet niet waarvoor je het systeem gebruikt - - maar een ZIL lijkt me niet echt nodig tenzij je er een ESX farm boven draait waarop veel sync write I/O wordt gedaan.

In mijn ervaring hebben 5400rpm disks erg veel last van I/O tussendoor en schiet de performance omhoog als deze zich kunnen concentreren op waar ze goed in zijn: louter sequential I/O doen zonder random I/O tussendoor. Een SLOG in je pool helpt daarbij, en met NFS mounts, iSCSI voor systeemdisk images en VM images kan dat flink schelen de performance op pijl te houden.

Wat betreft enterprise SLOG; zelf lijkt me een leuke upgrade voor L2ARC+SLOG de Intel 720 PCI-express SSD die tegen de 1800MB/s write doet en een sloot aan IOps. Wanneer die beschikbaar komt is nog even afwachten, maar dat lijkt me heerlijk speelgoed vooral met ZFS. Nu gebruik ik nog Intel SSDs die in principe ook prima voldoen, maar een beetje overkill is altijd wel leuk.

[FireDrunk]

1800MB/s is leuk, maar echt compleet nutteloos als 10GbE (of een andere 1Gbit+ interface) niet goedkoper word... Dus het is in combinatie met ZFS leuk, maar overkill in verhouding met je andere componenten.

Hoewel dit niet eens zo heel duur is...
http://www.ebay.com/itm/Q...3f0d8ab507#ht_3328wt_1187

Voor point-to-point that is...

[ Voor 36% gewijzigd door FireDrunk op 01-09-2011 13:10 ]

[Anoniem: 15758]

Tegen die tijd hoop ik ook eens de overstap naar 10GbE te maken; iets wat ik al een jaar of twee wil maar de prijs van adapters blijft nog redelijk hoog.

Deze 10GBaseT adapter van Intel is nog een redelijk alternatief:
http://www.intel.com/cont...apters/10-gigabit-at.html

Twee van die pricewatch: Intel 10 Gigabit AT2 Server Adapter adapters kom je dan uit op 900 euro. Veel geld, had ze liever rond de 200 euro gezien.

Natuurlijk kun je ook naar InfiniBand en fiber ethernet (LX) kijken of incompatibel koper (CX4), maar ik wil 'echt' 10GBaseT ethernet, zodat het hopelijk ook een toekomstvaste investering wordt.

Maar ik twijfel wel, wellicht dat begin 2012 nieuwe adapters komen van Intel die weer zuiniger en goedkoper zijn, de huidige AT2 stamt uit 2009, alhoewel het eerste model nog wel een heatsink had en meer energie verbruikte dan het huidige model, wat helemaal passief gekoeld is. Toch vind ik de limiet van gigabit erg jammer van de potentiële performance van een mid/high-end ZFS NAS. Tegen de 1GB/s doen zou toch wel heel erg stoer zijn. Nadeel is wel dat 10GBaseT en Intel 720 SSD het idle verbruik wel iets zal doen laten stijgen.

[FireDrunk]

http://azerty.nl/0-2490-3...p-10gb-2-port-server.html

Astu, 200 euro per poort...
Staar je niet blind op die AT serie van Intel, die is best duur...

[Anoniem: 15758]

Maar dat is dus fiber (10GBase-X) en niet koper (10GBaseT). De 10GBaseT standaard is de toekomst; er wordt gesproken over LoM (LAN-on-Motherboard) in 2012/2013. Dan moet het snel gaan hoop ik, als de adapters nu nog 450 euro kosten. Maar bij gigabit ethernet ging het op een gegeven moment ook hard toen de PHY chips op een nieuwer procede werden gebakken en de kosten enorm omlaag gingen. Toch heb ik er een hard hoofd in dat we over een jaar al LoM met 10GBaseT zullen zien; misschien eerder 2013/2014?

[FireDrunk]

Je hebt gelijk, ik dacht dat er SFP->10GbE was, maar dat is er niet
Dan moet je weer met media converters aan de slag, dat is weer kak...

[Anoniem: 6137]

Wat betreft enterprise SLOG; zelf lijkt me een leuke upgrade voor L2ARC+SLOG de Intel 720 PCI-express SSD die tegen de 1800MB/s write doet en een sloot aan IOps. Wanneer die beschikbaar komt is nog even afwachten, maar dat lijkt me heerlijk speelgoed vooral met ZFS. Nu gebruik ik nog Intel SSDs die in principe ook prima voldoen, maar een beetje overkill is altijd wel leuk.

Denk dat meer RAM goedkoper zal zijn na ene korte blik op pricewatch, maar nogmaals weet niet wat voor load je hebt op je server misschien heb je idd wel die 30.000 IOPS p/s nodig

[FireDrunk]

Omdat het kan

[Anoniem: 15758]

Nodig is een groot woord; maar ik draai bijvoorbeeld meerdere workstations via iSCSI als systeemdisk op mijn ZFS server. De 720 zou 180.000 random read IOps en 56.000 random write IOps doen; dat is een hoop performance! Idle verbruik zou 8W bedragen; wat nog acceptabel is ook al doen mijn huidige SSDs 65mW met DIPM ingeschakeld.

Specs van de Intel 720 PCI-express SSD:
http://www.nordichardware...-ssd-series-detailed.html

Overigens meer RAM, ja leuk maar maar daar heb je weinig aan voor SLOG. Defeats the purpose. RAM met battery backup via SATA of PCIe doet vaak maar weinig MB/s door slechte interface of het gebruikt duur DDR2 geheugen etc. Ik was niet echt onder de indruk van de performance hiervan laatste keer dat ik er naar zocht. Maar in principe zou een reepje DDR3 met een batterij via PCI-express ook een mogelijkheid zijn.

[FireDrunk]

Ik snap ook niet dat er nog niemand een RAMDISK van DDR3 modules gemaakt heeft (behalve high-grade-superdeluxe-Enterprise stuff). Zo heel duur hoeft het toch niet te zijn?
Een simpel SoC chipje kan al gauw een paar GB/s hebben qua doorvoersnelheid en zou dus prima DDR3 kunnen vullen via een PCIe poort.

Batterijtje erop, firmware erbij, en verkopen...

[Anoniem: 15758]

Mja je moet dan dus een high-performance geheugencontroller bridgen naar ATA/SCSI/AHCI en dan weer naar PCI-express. Ik denk dat het ligt aan het niet voorhanden zijn van dit soort chips die DDR3 ondersteunen en PCI-express. Een snelle SoC zou het wellicht kunnen maar dan vergeet je dat zo'n SoC ook op firmware draait en daar een hoop werk in zit. Denk ook aan de SoCs die SSD controllers gebruiken; de firmware is daar het meest spannende onderdeel van.

Toch zou het grote markt zijn denk ik. Twee x 4GiB DDR3 kost nu 35 euro ofzo, oke ECC iets meer. Dan heb je 8GiB, een heleboel IOps en minimaal 1GB/s bandbreedte, daar kun je een leuk PCI-express product mee maken lijkt me zo.

[ Voor 20% gewijzigd door Anoniem: 15758 op 01-09-2011 15:10 ]

[FireDrunk]

Heb net een mailtje naar een SoC boer gestuurd... Ga het gewoon eens vragen

Als je voor 100 euro een PCIe kaartje zou kunnen maken met 8GB aan RAM storage met een batterij die het ding 2 weken voed ofzo.. Lijkt me toch leuk
Ik denk dat er pas echt markt voor komt als je er 32 of 64GB op kwijt kan, want dan zou je er Windows op kunnen zetten...

[ Voor 63% gewijzigd door FireDrunk op 01-09-2011 15:29 ]

[Anoniem: 6137]

http://www.ddrdrive.com/

[Femme]

Anoniem: 6137 schreef op donderdag 01 september 2011 @ 18:29:
http://www.ddrdrive.com/

Alleen zit daar een kansloze pci express x1-interface op waardoor de doorvoer beperkt wordt tot ca. 225MB/s. Hij zal alsnog wel snel zijn door de lage latency maar het is gewoon jammer om het geheugen op die manier kreupel te maken. Ik snap niet dat je de moeite neemt om zo'n product te ontwikkelen en er niet meteen op zijn minst een pci-e x4-interface op zet.

Acard heeft een sata ram-drive die slechts 180MB/s doet.

[Anoniem: 6137]

Femme schreef op donderdag 01 september 2011 @ 19:18:
[...]


Alleen zit daar een kansloze pci express x1-interface op waardoor de doorvoer beperkt wordt tot ca. 225MB/s. Hij zal alsnog wel snel zijn door de lage latency maar het is gewoon jammer om het geheugen op die manier kreupel te maken. Ik snap niet dat je de moeite neemt om zo'n product te ontwikkelen en er niet meteen op zijn minst een pci-e x4-interface op zet.

Acard heeft een sata ram-drive die slechts 180MB/s doet.

Hij is bedoeld voor ZIL. En throughput is niet zo spannend latency is waar het omgaat.

[Pantagruel]

Een huishoudelijk vraagje aan de ZFS guru's van dit topic.

Waar halen jullie je SFF-8087 -> 4x SATA (forward breakout) kabels vandaan??

Bijten jullie door de ietwat zure appel en leg €26 per kabel neer of gaan jullie voor een ebay chinees??
Of is er iets minder ver van huis voor een redelijke prijs goede waar te halen??

Alvast bedankt voor de info.

[Femme]

Normaal gesproken worden ze toch geleverd bij de sas-controller?

[Pantagruel]

Femme schreef op donderdag 01 september 2011 @ 22:19:
Normaal gesproken worden ze toch geleverd bij de sas-controller?

Niet noodzakelijk, ook de nodige webshops leveren de OEM versie (zonder kabels) van een controller (LSI SAS 9211-8i-sgl ) of bijv. de LSI SAS 9201-16i Sgl die LSI via haar eigen website enkel zonder kabels aanbiedt, natuurlijk met de hint er en aantal bij aan te schaffen als handige toevoeging.
De LSI SAS 9211-8i is ook als kit versie te krijgen, LSI wil dan graag ca €60,- extra voor de 2 kabeltjes zien .

Ook als een gebruikte/server pull adapter via internet koopt zijn deze vaak zonder kabels.

[ Voor 14% gewijzigd door Pantagruel op 01-09-2011 22:54 ]

[magistus]

Wederom een kleine update voor de Linux-gebruikers. Hoewel ik nog wel wat usability issues zijn, draait zfsonlinux (rc5) hier stabiel en naar volle tevredenheid. Dit met meerdere terabytes aan data, op meerdere diy-'servers' inclusief externe (off-line) storage.

Daarnaast ben ik gisteren toch maar weer eens met Darik Horn's PPA (zie https://launchpad.net/~dajhorn/+archive/zfs) aan de slag gegaan. De huidige versie, icm met dkms uit wheezy, is tot op heden een succes. Zowel splat als zfstest geven goede resultaten. Mocht iemand hier ook mee willen spelen, installeer eerst dkms uit wheezy, de juiste linux-headers en vervolgens het package ubuntu-zfs. Binnenkort mijn huidige systemen omzetten, eens kijken of dit vlekkeloos wil verlopen.

[zzattack]

Pantagruel schreef op donderdag 01 september 2011 @ 22:05:
Waar halen jullie je SFF-8087 -> 4x SATA (forward breakout) kabels vandaan??

ri-vier heeft ze iets goedkoper
http://cybershop.ri-vier....-breakout-cable-p-61.html