Het grote ZFS topic

[u_nix_we_all]

Skinkie schreef op dinsdag 31 mei 2011 @ 12:20:
[...]

Nee het punt is dus juist dat je een gedeeld ZFS-bestandssysteem wilt. Kijk het ophangen van iSCSI devices onder 1 systeem kan ik ook wel bedenken. Maar dat zorgt nogsteeds voor die ene single point of entry en die ene single point of failure. Ik ben juist benieuwd hoe je ZFS vanaf meerdere systemen kunt exporteren.

Maar dat doe je ook met AoE; meerdere systemen kunnen bij de disks op blockniveau. Je kunt dus over AoE mirroren, zonder de voordelen van ZFS te verliezen.
Feit blijft dat dit alleen kan als je vanaf die machines direct op blockniveau bij de disk kan als die op een of andere manier geshared zijn.
ZFS in zichzelf is niet gelijktijdig te sharen, je kunt een zpool slechts op 1 machine tegelijk actief hebben.

[Anoniem: 15758]

AoE is net als iSCSI gewoon een SAN-protocol, waarbij de server zelf geen controle heeft over het filesystem. Alleen de client heeft controle over het filesystem. Daarbij is het noodzakelijk dat ZFS alle flush acties van de client eerbiedigt, anders zou welliswaar ZFS integer blijven na een crash maar zou de client-versie van het filesystem corrupt kunnen raken. Dit betekent doorgaans wel trage performance bij veel kleine writes, tenzij je op ZFS-niveau een SLOG disk gebruikt.

In veel gevallen is een NAS-protocol beter, zoals NFS of Samba (CIFS). Dan heb je de maximale voordelen van ZFS zoals file-based checksums en shared-storage. De clients zelf hebben geen weet van het eigenlijke filesystem dat wordt gebruikt maar maken gebruik van een abstractielaag. Het nadeel hiervan is dat je problemen kunt krijgen met caching en locking; het gelijktijdig schrijven naar dezelfde file buiten de controle van de clients om kan problemen geven. En de clients hebben zoals gezegd dus geen directe ZFS controle en kunnen niet remote een zfs create doen, bijvoorbeeld.

In plaats van AoE of iSCSI kun je bij FreeBSD ook kiezen voor geom_gate, waarbij je in feite een volledige fysieke device node exporteert over TCP/IP naar een andere PC. Dankzij het GEOM-framework kun je daar leuke dingen mee doen. Bijvoorbeeld lokaal een mirror maken van één lokale disk en één geom_gate disk die op een extern systeem staat. Bij de mirror kun je dan voor kiezen om bij reads alleen van de lokale disk te lezen en dus alleen de remote mirror disk te gebruiken voor writes.

[Anoniem: 187449]

Dan maar alle fans losgekoppeld en de case open laten staan tot de nieuwe er zijn.
Dit is in bestelling:
Nexus 80mm PWM Real Silent Case Fan SP802512H-03PWM x4
Scythe mini-KAZE 60mm SY602012L x2
En zo blijven we bezig , tijd voor bier

ben erg benieuwd of dat nu veel uitmaakt .. heb ook 80mm fannetjes gezien van 6 db en fanvibratie isolators.

en omdat mijn zfs nas voor de miljoenmiljardste keer helemaal uit elkaar lag en ik onderdeel voor onderdeel ben gaan testen, gelijk even gekeken naar de verschillen tussen een disk aangesloten op een geflashte SASUC8I en direct op mobo... valt reuze mee eigenlijk.

[ Voor 54% gewijzigd door Anoniem: 187449 op 31-05-2011 20:25 ]

[CurlyMo]

Nadat een tijdje jullie hoge netwerk doorvoersnelheden heb mogen aanschouwen toch zelf maar eens geprobeerd of ik met alle tips hetzelfde kan bereiken...

Het gaat om de volgende set-up (inventaris: NAS):
Supermicro X7SPA-HF
2GB DDR2
3x Samsung EcoGreen F4EG HD204UI, 2TB

Dit alles draait Solaris 11 Express met een ZFS RAIDZ

Het moederbord bezit een dual gigabit lan maar snelheden komen nooit boven +/- 25mbps op die snelheid.

Het volgende heb ik al geprobeerd:
- Ubuntu en FreeBSD maar daarop was de performance het slechts. Solaris is ook slecht maar toch minder dan de andere distro's.
- Een gigabit router met Cat 5e kabels (Cat 6 ook geprobeerd maar gaf geen verschil).
- Verschillende Samba instellingen.

Bevindingen:
- Ik weet dat mijn netwerk wel met gigabit snelheden om kan gaan aangezien ik ook 2 windows machines aan elkaar heb gekoppeld (beide sandy brigde).
- Solaris geeft ook aan dat ik een gigabit verbinding heb.
- Mijn RAIDZ heeft een write speed van +/- 200mpbs.

Kan het zijn dat de de Atom D510 simpelweg deze netwerk snelheden niet aan kan of zit er een fout op het moederbord?

Ik heb ook gedacht aan het toevoegen van een aparte netwerk kaart zoals een intel gigabit ct maar daar zit dezelfde chip op als op mijn moederbord (82574L).

Iemand nog tips of ben ik gewoon verdoemd tot deze snelheden met deze setup?

[ Voor 3% gewijzigd door CurlyMo op 02-06-2011 10:58 ]

[Anoniem: 15758]

Netwerkperformance en I/O performance moet je apart testen, dus:
- draai dd benches om ZFS performance te testen (read+write)
- draai iperf benches om netwerk-performance te testen (dat kan crossplatform b.v. solaris -> windows of freebsd -> windows)

2GiB RAM is overigens erg weinig voor een ZFS server, dan haal je zeker niet het meeste uit je hardware. Dat geldt met name voor FreeBSD, omdat die read-ahead (prefetch) uitschakelt bij minder dan 6GiB-8GiB RAM. ZFS werkt op dat platform dus pas goed bij 8GiB RAM en meer. Atom is echter beperkt tot 4GiB dus kun je daar beter een Solaris distributie op draaien.

Wat voor NIC gebruik je op de client side? Wat voor OS?

[CurlyMo]

Cliënt side draai in Windows 7 op een Asrock H67M-GE. Deze heeft een eigen gigabit lan aansluiting.
Zoals ik aangaf is Windows 7 (desktop) --> Windows 7 (laptop) geen probleem. Beide draaien op een sandy bridge configuratie met een gigabit lan. Ik ga er dus vanuit dat mijn desktop niet de bottleneck is.

Ik ken het RAM probleem voor ZFS maar ik doe geen heftige dingen op mijn NAS zoals virtualisatie. Als enkel mijn netwerk performance omhoog gaat is het voldoende.

- De DD test heb ik gedaan daaruit bleek dat de HDD thoughput prima was.
- De iperf test zal ik nog even doen.

[Anoniem: 15758]

- dd op je mounted ZFS volume natuurlijk; je wilt end-user I/O performance testen geen raw device I/O
- iperf netwerk bandbreedte gaat over het OS, dus end-user performance geen netwerkperformance met een ander OS dat kan weet heel andere resultaten geven met name door verschillen in drivers en protocol stacks

dd op je ZFS volume doe je als volgt:

# schrijven (minimaal 8x je RAM dus 16GiB)
dd if=/dev/zero of=/pad/naar/mounted/ZFS/volume/testfile.zero bs=1M count=16384

# lezen
dd if=/pad/naar/mounted/ZFS/volume/testfile.zero of=/dev/null bs=1M

Dus nooit dd op een raw device daar heb je niks aan.

[CurlyMo]

DD Test

Write: +/- 110
Read: +/- 231

Iperf:
(Server) --> (Cliënt)
Solaris --> Windows 7:
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 125 KByte (default)
------------------------------------------------------------
[ 4] local 10.0.0.140 port 5001 connected with 10.0.0.144 port 50633
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.0 sec 345 MBytes 289 Mbits/sec

Windows 7 --> Solaris
------------------------------------------------------------
Client connecting to 10.0.0.144, TCP port 5001
TCP window size: 48.0 KByte (default)
------------------------------------------------------------
[ 3] local 10.0.0.139 port 53137 connected with 10.0.0.144 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.0 sec 906 MBytes 759 Mbits/sec

[ Voor 95% gewijzigd door CurlyMo op 02-06-2011 12:52 ]

[Skinkie]

Anoniem: 15758 schreef op dinsdag 31 mei 2011 @ 12:36:
In veel gevallen is een NAS-protocol beter, zoals NFS of Samba (CIFS). Dan heb je de maximale voordelen van ZFS zoals file-based checksums en shared-storage. De clients zelf hebben geen weet van het eigenlijke filesystem dat wordt gebruikt maar maken gebruik van een abstractielaag. Het nadeel hiervan is dat je problemen kunt krijgen met caching en locking; het gelijktijdig schrijven naar dezelfde file buiten de controle van de clients om kan problemen geven. En de clients hebben zoals gezegd dus geen directe ZFS controle en kunnen niet remote een zfs create doen, bijvoorbeeld.

Een remote zfs create is dus 'eigenlijk' wat ik interessant zou vinden. Create niet zo zeer, snapshot wel. Verder is eigenlijk de enige 'logische' oplossing nu om meerdere nodes toe te voegen glusterfs/lustre draaien of richting pNFS.

Maar ze doen eigenlijk allemaal niet wat je in ZFS-gedachte zou willen: een manier om vanaf verschillende systemen 1 ZFS pool te vormen, en dat verschillende systemen dus ook getrunkt data kunnen uitvoeren. Denk hierbij aan een pool die leeft op een aantal systemen en op basis van een data aanvraag vanaf de verschillende systemen data kan uitvoeren.

Dus ZFS met z'n hele management omgeving niet geforceerd uit 1 netwerk poortje laten komen, maar de mogelijkheid geven om juist dat gedeelte schaalbaar te maken.

[vargo]

Al paar avonden bezig mijn backup NAS in te richten:
* OpenIndiana
* NexentaStor
Niets werkt helaas; installatie wordt niet afgerond of er ontstaan opstart problemen .
Vreemde is dat ik 'vroeger' openSolaris en ook NexentaStor met dezelfde hardware (asus K8n4-e deluxe) draaiende heb gehad. Nog maar wat verder aanklooien en anders toch terug naar FreeBSD.

Anyway - was aan het rondkijken naar de status van ZFS & Lustre en kwam de volgende presentatie tegen:
http://zfsonlinux.org/doc...S_on_Linux_for_Lustre.pdf
Ik had er een hard hoofd in of het er ooit zou komen maar dit klinkt toch wel veelbelovend.

[leuk_he]

Anoniem: 15758 schreef op donderdag 02 juni 2011 @ 11:20:
# schrijven (minimaal 8x je RAM dus 16GiB)
dd if=/dev/zero of=/pad/naar/mounted/ZFS/volume/testfile.zero bs=1M count=16384

Al eerder over gehad, nullen schrijven kan de boel vervormen (compressie, zeker met SSD's firmwares die "cheaten" ). Wellicht werkt /dev/urandom beter.

[CurlyMo]

leuk_he schreef op vrijdag 03 juni 2011 @ 00:14:
[...]


Al eerder over gehad, nullen schrijven kan de boel vervormen (compressie, zeker met SSD's firmwares die "cheaten" ). Wellicht werkt /dev/urandom beter.

Ik heb alleen geen SSD's en andere 'bijzondere' opties aanstaan, dus nullen zullen in mijn geval wel redelijk representatief zijn...

Nu nog de duiding van de cijfers en de oplossing van mijn probleem (als die er dan al is).

[Anoniem: 15758]

leuk_he schreef op vrijdag 03 juni 2011 @ 00:14:
[...]


Al eerder over gehad, nullen schrijven kan de boel vervormen (compressie, zeker met SSD's firmwares die "cheaten" ). Wellicht werkt /dev/urandom beter.

Volgens mij al een stuk of drie keer gezegd in dit topic:

• /dev/urandom is op BSD platform hetzelfde als /dev/random; op Linux platform zit er wel verschil tussen, op Solaris platform weet ik niet.
• /dev/zero is prima voor een normale HDD pool waarbij compressie is uitgeschakeld, voorwaarde is wel dat je naar een normale file schrijft en niet naar een ZVOL; daarbij is het schrijven van nullen wel anders dan random-data - het worden als 'gaten' in de volume gezien ipv als echte data.
• Het lezen van /dev/urandom maakt de benchmark een CPU-benchmark ipv een I/O-benchmark. De CPU zal hierbij een bottleneck vormen en dus wordt dat per definitie geen I/O benchmark meer. Hetzelfde geldt voor compressie inschakelen dan test je de CPU-performance niet (louter) de I/O performance.

Kortom: gewoon /dev/zero gebruiken. Onafhankelijk hiervan moet je zorgen dat de hoeveelheid data die je leest en schrijft niet zomaar in je RAM past, en daarom dat je minimaal 8x je RAM moet aanhouden, anders komt de data gedeeltelijk uit je RAM en krijgt je hogere snelheden dan je disks überhaupt kunnen leveren. Een aantal MB lezen of schrijven gebeurt tegen iets van 4 gigabyte per seconde.

Nu nog de duiding van de cijfers en de oplossing van mijn probleem (als die er dan al is).

Ik merk twee dingen op:
- Je IP adressen zijn veranderd; dat kan door dynamic IP komen maar weet je zeker dat je exact dezelfde OS + configuratie gebruikt bij beide benchmarks?
- Je TCP Receive Window is veranderd, waarom? Probeer met dezelfde instellingen te testen; liefst default zonder enige tweaks zowel aan iPerf als aan je OS.

Als je met iPerf niet rond de 950 megabit haalt dan gaat het daar dus al mis; dat lijkt bij jou het geval te zijn. Je kunt tjidens de benchmark ook kijken naar je CPU performance. Merk hierbij op dat de driver waarschijnlijk single threaded is. Een quadcore met hyperthreading betekent dus 12,5% = CPU bottlenecked. Bij een Atom met 4 threads (HyperThreading) is dat dus 25%. Kijk ook goed naar het percentage interrupt CPU usage; dat mag niet te hoog zijn. Eventueel kun je met polling de interrupts uitschakelen dat kan veel CPU cycles schelen mocht dat je botteneck wezen. Verder is 100MB/s+ max schrijven op ZFS een slechte prestatie, een 3-disk RAID-Z array hoort tot max 280MB/s te kunnen doen, zeg 250MB/s optimaal in de praktijk. Jij haalt dus nog niet de helft, wat mogelijk door te weinig RAM komt. Met die configuratie werkt een traditionele mdraid + XFS of Ext4 setup waarschijnlijk sneller, ZFS heeft duidelijk baat bij meer geheugen. Ook kan je lage netwerkperformance komen door de client side (Windows) door foute drivers. Voor Windows gebruik je het beste Intel NIC + drivers, bij Solaris/FreeBSD kunnen eventueel realtek en consorten ook prima werken, is mijn eigen ervaring.

[ Voor 48% gewijzigd door Anoniem: 15758 op 03-06-2011 02:05 ]

[CurlyMo]

Ik merk twee dingen op:
- Je IP adressen zijn veranderd; dat kan door dynamic IP komen maar weet je zeker dat je exact dezelfde OS + configuratie gebruikt bij beide benchmarks?
- Je TCP Receive Window is veranderd, waarom? Probeer met dezelfde instellingen te testen; liefst default zonder enige tweaks zowel aan iPerf als aan je OS.

Iperf test zijn als volgt uitgevoerd:
- Windows 7: iperf -c 10.0.0.140
- Solaris: iperf -s

&

- Windows 7: iperf -s
- Solaris: iperf -c 10.0.0.144

De default settings (TCP Recieve Window) veranderde automatisch...

Als je met iPerf niet rond de 950 megabit haalt dan gaat het daar dus al mis; dat lijkt bij jou het geval te zijn. Je kunt tjidens de benchmark ook kijken naar je CPU performance. Merk hierbij op dat de driver waarschijnlijk single threaded is. Een quadcore met hyperthreading betekent dus 12,5% = CPU bottlenecked. Bij een Atom met 4 threads (HyperThreading) is dat dus 25%. Kijk ook goed naar het percentage interrupt CPU usage; dat mag niet te hoog zijn. Eventueel kun je met polling de interrupts uitschakelen dat kan veel CPU cycles schelen mocht dat je botteneck wezen.

Kun je ook uitleggen hoe ik dat zou moeten doen / testen?

Verder is 100MB/s+ max schrijven op ZFS een slechte prestatie, een 3-disk RAID-Z array hoort tot max 280MB/s te kunnen doen, zeg 250MB/s optimaal in de praktijk. Jij haalt dus nog niet de helft, wat mogelijk door te weinig RAM komt. Met die configuratie werkt een traditionele mdraid + XFS of Ext4 setup waarschijnlijk sneller, ZFS heeft duidelijk baat bij meer geheugen.

Het DD commando geeft onder Solaris niet de uitgebreide informatie terug na het testen. Daarom gebruik ik dit commando:

time sh -c "dd if=/dev/zero of=/mountpoint/testfile.bin bs=1024k && sync"

Kan het uitmaken dat ik de schijven niet op een 4k sector instelling heb geconfigureerd?

Ondanks dat zou het toch voor mijn netwerk performance niet uit moeten maken of ik nu wel of niet op de 250 MB/s kom. Dat trekt een gigabit lijn toch niet vol. Ondanks dat ik snap dat deze situatie niet ideaal is heeft het naar mijn idee weinig te maken met mijn netwerk probleem.

Ook kan je lage netwerkperformance komen door de client side (Windows) door foute drivers. Voor Windows gebruik je het beste Intel NIC + drivers, bij Solaris/FreeBSD kunnen eventueel realtek en consorten ook prima werken, is mijn eigen ervaring.

Zoals eerder aangegeven haalt een Windows --> Windows setup wél hoge snelheden...

[raymonvdm]

Hoe zit het eigenlijk met Jumbo frames en *nix systemen. Want ook ik kom niet verder en 25mb/s / 30mb/s

Dit is getest op een P4 3.0 met 2GB geheugen en 6 x 2TB F4 disken (raidz2)
Dit is getest op een Xeon 3.0 met 4GB geheugen en 2 x 2TB F4 disken (raidz)

Als os heb ik gebruikt openindiana/freenas en probeer nu nexenta maar ook die zit op 30mb/sec

[Anoniem: 15758]

CurlyMo schreef op vrijdag 03 juni 2011 @ 09:28:
Kun je ook uitleggen hoe ik dat zou moeten doen / testen?

CPU performance tijdens de tests kun je bekijken met 'top' commando. Geen idee of die onder Solaris ook interrupt usage laat zien; onder FreeBSD in elk geval wel dan kun je mooi zien of je (netwerk/disk-) drivers inefficient zijn of niet.

Kan het uitmaken dat ik de schijven niet op een 4k sector instelling heb geconfigureerd?

Ja en nee. Voor optimale configuraties (RAID-Z: 2,3,5,9 disks; RAID-Z2: 6 en 10 disks) hoef je dat niet te doen, al kan het nog wel iets verbetering geven. Meer benchmarks hierover vind je op Hardforum.

Ondanks dat zou het toch voor mijn netwerk performance niet uit moeten maken of ik nu wel of niet op de 250 MB/s kom. Dat trekt een gigabit lijn toch niet vol. Ondanks dat ik snap dat deze situatie niet ideaal is heeft het naar mijn idee weinig te maken met mijn netwerk probleem.

Dat is dus een verkeerde aanname. Als je ZFS pool max 110MB/s doet bij een dd-write, krijg je dat nooit via een netwerk write. Althans dat is mijn ervaring. Om 100MB/s netwerk write bij te houden wil je minstens het dubbele hebben wat ZFS lokaal kan doen. Tevens moet je rekening houden met degradatie van de I/O performance doordat je schijven gevuld raken en dus op tragere gebieden gaan schrijven en door fragmentatie. Factor 0.5 * 0.5 = 0.25. Voor 100MB/s netwerk write heb je dus minimaal 400MB/s local write nodig om dat enigszins te kunnen afdekken, als ruwe maatstaf. Als je met een brandschone pool al geen goede performance krijgt gaat dat alleen maar dalen zodra je pool daadwerkelijk gevuld is.

Zoals eerder aangegeven haalt een Windows --> Windows setup wél hoge snelheden...

Wat volkomen logisch is, immers er worden andere drivers gebruikt, met name de drivers van de netwerkkaart. Daarnaast heb je geen zwaar filesystem maar een licht journaling filesystem wat natuurlijk veel minder overhead geeft, en je hebt twee dezelfde protocol stacks die op elkaar zijn ingespeeld. Cross-platform is het moeilijker om het laatste restje performance uit je netwerk te halen, is mijn ervaring.

Je hoort bij zowel file I/O performance als netwerk performance dus afzonderlijk goede performance te krijgen, pas als beide goed zijn kun je echte tests doen die zowel ZFS als netwerk gebruiken. In jouw geval lijken beide dus niet in orde te zijn, en kun je dus ook nooit goede 'netto' performance verwachten. In veel gevallen is het testen en nog eens testen, totdat je diverse zaken hebt uitgesloten en zo min mogelijk factoren je performance kan bederven. In mijn ervaring zijn het bijna altijd meerdere oorzaken die allemaal een beetje effect hebben, maar gezamenlijk dus voor flink lagere performance kunnen zorgen.

raymonvdm schreef op vrijdag 03 juni 2011 @ 09:39:
Hoe zit het eigenlijk met Jumbo frames en *nix systemen. Want ook ik kom niet verder en 25mb/s / 30mb/s

Zelfde verhaal als hierboven: test file I/O en netwerk apart. Ik zelf gebruik geen Jumbo frames en haal 110MB/s write en 80MB/s read naar ZFS, in elk geval naar mijn SSD pool.

Pentium 4 en andere 32-bit CPUs zijn in principe ongeschikt voor ZFS, evenals PCI. Zeker als je I/O én gigabit netwerk over PCI lopen mag je verwachten dat de performance knudde is. Voor een Xeon met 4GB RAM + Solaris zou ik betere performance verwachten. Maar 2 disks in RAID-Z, heb je dat echt zo geconfigt? Niet dat het niet kan, maar dat is in principe wel inferieur aan een mirror. Een mirror biedt je betere performance tegen dezelfde overhead bij slechts 2 disks.

[Skinkie]

Anoniem: 15758 schreef op zaterdag 04 juni 2011 @ 10:17:
Een mirror biedt je betere performance tegen dezelfde overhead bij slechts 2 disks.

Help me even, maar een mirror bij ZFS doet toch ook geen onafhankelijk iolookup? Dus dat het begin van het bestand van disk 1 komt, en het volgende blok van disk 2? Het is toch altijd een paralelle lookup waarbij inhoud wordt vergeleken? (Ook al zou dat niet hoeven met ZFS)

[Anoniem: 15758]

iolookup? Je bedoelt of er striping wordt toegepast op de mirror en dus een performancevoordeel kent? Het antwoord daarop is: ja.

Bij de meeste RAID1 ofwel mirrors is er vrijwel geen performancevoordeel, bij ZFS is dat wel zo en bij leesacties komt het heel dicht in de buurt van een RAID0 (striping), nooit 100% omdat bij hardeschijven er blocks worden overgeslagen door de striping en dus de hardeschijven niet zo optimaal kunnen lezen als een RAID0 dat kan, waarbij de hardeschijven 100% nuttig werk kunnen doen en dus in principe geldt 2 HDDs = 2x de performance. Bij een mirror is dat iets van 1,75x; nog steeds erg goed!

ZFS biedt dus de beste performance bij mirrors die ik ooit heb gezien. Voor schrijfacties geldt dat een mirror (vrijwel) altijd de performance heeft van een enkele disk, dus daar heb je geen voordelen bij.

In jouw vraag leid ik af dat je denkt dat ZFS dezelfde blocks leest en dan vergelijkt of ze overeenkomen; dat is niet zo! ZFS weet aan de hand van de checksum of de data klopt ja of nee, pas als de checksum niet overeenkomt wordt de redundante kopie aangesproken. In normale gevallen lezen beide mirror disks dus andere blocks, bijna zoals RAID0/striping dat doet.

Dat heeft één klein nadeel: ZFS zal bij normaal gebruik mogelijk niet alle inconsistenties opmerken. Stel dat een deel data corrupt is op één van de disks die door de 'mirror-striping' niet wordt aangesproken (overgeslagen) dan blijft dat onopgemerkt, totdat je een keer een scrub doet. Dat is echter ook zo bij RAID-Z waarbij de parity wordt overgeslagen. Dat laatste is wel theoretisch, want heb ik niet zelf gecontroleerd met d-trace. Maar het zou me sterk verbazen als het niet zo werkt.

[leuk_he]

Skinkie schreef op zaterdag 04 juni 2011 @ 11:45:
[...]

Help me even, maar een mirror bij ZFS doet toch ook geen onafhankelijk iolookup? Dus dat het begin van het bestand van disk 1 komt, en het volgende blok van disk 2? Het is toch altijd een paralelle lookup waarbij inhoud wordt vergeleken? (Ook al zou dat niet hoeven met ZFS)

Waarom vergelijken ? Alleen als de checksum niet klopt zou van de andere disk een block gelezen moeten worden om te repareren. Dus bij lezen kan hij stripen. (ene blok van ene disk, volgende blok van andere).

Toch is het verschil met een zraid bestaande uit 2 disken (onlogisch, maar werkt wel) niet zo heel groot. een stukje terug heeft iemand in dit topic daar ook een benchmark over gedraaid.

[DutchKel]

CurlyMo schreef op vrijdag 03 juni 2011 @ 09:28:
[...]


Iperf test zijn als volgt uitgevoerd:
- Windows 7: iperf -c 10.0.0.140
- Solaris: iperf -s

&

- Windows 7: iperf -s
- Solaris: iperf -c 10.0.0.144

De default settings (TCP Recieve Window) veranderde automatisch...


[...]


Kun je ook uitleggen hoe ik dat zou moeten doen / testen?


[...]


Het DD commando geeft onder Solaris niet de uitgebreide informatie terug na het testen. Daarom gebruik ik dit commando:

time sh -c "dd if=/dev/zero of=/mountpoint/testfile.bin bs=1024k && sync"

Kan het uitmaken dat ik de schijven niet op een 4k sector instelling heb geconfigureerd?

Ondanks dat zou het toch voor mijn netwerk performance niet uit moeten maken of ik nu wel of niet op de 250 MB/s kom. Dat trekt een gigabit lijn toch niet vol. Ondanks dat ik snap dat deze situatie niet ideaal is heeft het naar mijn idee weinig te maken met mijn netwerk probleem.


[...]


Zoals eerder aangegeven haalt een Windows --> Windows setup wél hoge snelheden...

De Atom is redelijk traag als het gaat om SMBD in linux (ik heb alleen ervaring met ubuntu). Zelfs met een single disk haalde ik maar 25MB/s en sloeg smbd met 1 thread op bijna 100%.

Als je iets aan het kopieeren bent moet je eens "top" (ik ga er vanuit dat dit ook in solaris werkt) intikken in de console... dan zie je wat er allemaal op "tilt" slaat.

[Anoniem: 9449]

vargo schreef op donderdag 02 juni 2011 @ 23:16:
Anyway - was aan het rondkijken naar de status van ZFS & Lustre en kwam de volgende presentatie tegen:
http://zfsonlinux.org/doc...S_on_Linux_for_Lustre.pdf
Ik had er een hard hoofd in of het er ooit zou komen maar dit klinkt toch wel veelbelovend.

Zeer interessante presentatie, binnenkort misschien dus "echt" ZFS op Linux (als LLNL dit vrij gaat geven). Maar hoe zit het nou met die licentie (zie plaatje pagina 7), kan dat zomaar?

[Ultraman]

kfaessen schreef op zaterdag 04 juni 2011 @ 13:06:
[...]

De Atom is redelijk traag als het gaat om SMBD in linux (ik heb alleen ervaring met ubuntu). Zelfs met een single disk haalde ik maar 25MB/s en sloeg smbd met 1 thread op bijna 100%.

Als je iets aan het kopieeren bent moet je eens "top" (ik ga er vanuit dat dit ook in solaris werkt) intikken in de console... dan zie je wat er allemaal op "tilt" slaat.

Een Atom maar 25MB/s? Dat vind ik wel karig.
Toen ik nog een zuinige Pentium3 Coppermine 500MHz gebruikte wist ik daarmee gemiddeld 45MB/s over Samba te halen binnen het Gigabit netwerk, zonder Jumbo Frames. Pieken lagen tegen de 60MB/s.
Gebruikte netwerkkaart was een Intel 1000/MT Server Adapter PCI-X in een PCI slot.

Als je met de Atom maar 25MB/s haalt dan heb je Samba waarschijnlijk niet optimaal geconfigureerd of je hebt ergens een hardware bottleneck, of brakke netwerkkaart. TCP_NODELAY in je Samba configuratie opgenomen? Dat scheelt een berg.

[Anoniem: 15758]

Ik denk eerder aan een netwerkdriver die veel CPU cycles opslurpt door interrupts of zoiets; ik heb zelf een Atom draaien met redelijke ZFS performance; 65MB/s uit mijn hoofd. Wel een simpele mirror array en geen rare fratsen. Onboard realtek NIC met FreeBSD overigens, maar de ene realtek is de andere niet. Dat ligt niet aan realtek maar aan de PHY, en daar zijn er aardig wat van.

[DutchKel]

Ultraman schreef op zaterdag 04 juni 2011 @ 15:24:
[...]

Een Atom maar 25MB/s? Dat vind ik wel karig.
Toen ik nog een zuinige Pentium3 Coppermine 500MHz gebruikte wist ik daarmee gemiddeld 45MB/s over Samba te halen binnen het Gigabit netwerk, zonder Jumbo Frames. Pieken lagen tegen de 60MB/s.
Gebruikte netwerkkaart was een Intel 1000/MT Server Adapter PCI-X in een PCI slot.

Als je met de Atom maar 25MB/s haalt dan heb je Samba waarschijnlijk niet optimaal geconfigureerd of je hebt ergens een hardware bottleneck, of brakke netwerkkaart. TCP_NODELAY in je Samba configuratie opgenomen? Dat scheelt een berg.

Goeie tip, ik had idd samba een beetje standaard geconfigureerd (en nu nog steeds, maar met een i3 SB haal ik de maximale snelheid van het netwerk: 110-120MB/s). Ik zal het direct in de config zetten, dat ontlast de machine vast wel.

Overigens was de atom die ik had gebruikt erbij een 330 (dus de eerste versie, 1.6GHz, dual core, 4 threads), de atoms van nu zijn ook weer een stuk sneller.

[Pantagruel]

kfaessen schreef op zaterdag 04 juni 2011 @ 16:24:
[...]

Goeie tip, ik had idd samba een beetje standaard geconfigureerd (en nu nog steeds, maar met een i3 SB haal ik de maximale snelheid van het netwerk: 110-120MB/s). Ik zal het direct in de config zetten, dat ontlast de machine vast wel.

Overigens was de atom die ik had gebruikt erbij een 330 (dus de eerste versie, 1.6GHz, dual core, 4 threads), de atoms van nu zijn ook weer een stuk sneller.

Ook de eerste serie Atoms kunnen meer dan 25MB/ aan data aan te leveren (Thuis servertje alhier: Atom N230,2GB RAM, Samsung 320 GB tbv OS ,Samsung 1TB tbv data, Intel GT1000 nic, OpenSuse 11.x, Samba/NFS shares, ftp actief.

Rauwe performance van disk:
hdparm -Tt /dev/sdb:
Timing cached reads: 1206 MB in 2.00 seconds = 603.16 MB/sec
Timing buffered disk reads: 320 MB in 3.00 seconds = 106.62 MB/sec

dd iflag=direct if=/dev/sdb1 of=/dev/null bs=64k count=100000
100000+0 records in
100000+0 records out
6553600000 bytes (6.6 GB) copied, 63.5724 s, 103 MB/s

Netwerk:
kopieer actie van een ca. 6 GB mkv:
SMB tussen de 45 en 60 MB/s. NFS en FTP doen het beter (minimaal 65 MB/s en max. pieken van rondom de 80 MB/s).

Dus een nieuwere atom is niet noodzaak voor redelijke doorvoersnelheden.

[DutchKel]

Pantagruel schreef op zondag 05 juni 2011 @ 10:14:
[...]


Ook de eerste serie Atoms kunnen meer dan 25MB/ aan data aan te leveren (Thuis servertje alhier: Atom N230,2GB RAM, Samsung 320 GB tbv OS ,Samsung 1TB tbv data, Intel GT1000 nic, OpenSuse 11.x, Samba/NFS shares, ftp actief.

Rauwe performance van disk:
hdparm -Tt /dev/sdb:
Timing cached reads: 1206 MB in 2.00 seconds = 603.16 MB/sec
Timing buffered disk reads: 320 MB in 3.00 seconds = 106.62 MB/sec

dd iflag=direct if=/dev/sdb1 of=/dev/null bs=64k count=100000
100000+0 records in
100000+0 records out
6553600000 bytes (6.6 GB) copied, 63.5724 s, 103 MB/s

Netwerk:
kopieer actie van een ca. 6 GB mkv:
SMB tussen de 45 en 60 MB/s. NFS en FTP doen het beter (minimaal 65 MB/s en max. pieken van rondom de 80 MB/s).

Dus een nieuwere atom is niet noodzaak voor redelijke doorvoersnelheden.

Intussen heb ik al een i3 2100T setje ervoor. Nu is de speed via smb 110-120MB/s lezen en schrijven (alleen als de andere kant die snelheid ook aan kan). Maar het was volgens mij toen met die 25MB/s zonder die TCP_NODELAY in de config aangezet.

Maar het ging mij er eigenlijk om dat het trage van CurlyMo aan smb kon liggen en dat is nog steeds van toepassing. Voor mij is dit verder dus minder van belang.

[Anoniem: 187449]

txt versie OI 151 is beschikbaar




* zoals te zien had/heb ik een IRQ probleem op 16

[ Voor 19% gewijzigd door Anoniem: 187449 op 06-06-2011 11:26 ]

[vargo]

Anoniem: 9449 schreef op zaterdag 04 juni 2011 @ 13:58:
[...]

Zeer interessante presentatie, binnenkort misschien dus "echt" ZFS op Linux (als LLNL dit vrij gaat geven). Maar hoe zit het nou met die licentie (zie plaatje pagina 7), kan dat zomaar?

Volgens http://zfsonlinux.org/faq.html kan ZFS wel als 'kernel module' (dus geen user land!) onder CDDL licentie worden geimplementeerd, maar kan het geen onderdeel uitmaken van de linux kernel:

1.1 What about the licensing issue?

In a nutshell, the issue is that the Linux kernel which is licensed under the GNU General Public License is incompatible with ZFS which is licensed under the Sun CDDL. While both the GPL and CDDL are open source licenses their terms are such that it is impossible to simultaneously satisfy both licenses. This means that a single derived work of the Linux kernel and ZFS cannot be legally distributed.

One way to resolve this issue is to implement ZFS in user space with FUSE where it is not considered a derived work of the kernel. This approach resolves the licensing issues but it has some technical drawbacks. There is another option though. The CDDL does not restrict modification and release of the ZFS source code which is publicly available as part of OpenSolaris. The ZFS code can be modified to build as a CDDL licensed kernel module which is not distributed as part of the Linux kernel. This makes a Native ZFS on Linux implementation possible if you are willing to download and build it yourself.

Wat ik me af vraag is hoe dit in de praktijk gaat uitpakken voor bijv een Ubuntu installatie. Kan die kernel module onderdeel zijn van je installatie en is installeren onder ZFS dan gewoon 1 van de file systeem keuzes?

/edit: er is trouwens ook een indiaas bedrijf (KQ Infotech) dat op basis van het werk van LLNL een kernel module aan het bouwen is. Phonorix heeft een preview gebenchmarkt: http://www.phoronix.com/s...ux_kqzfs_benchmarks&num=5.

[ Voor 6% gewijzigd door vargo op 05-06-2011 18:31 ]

[CurlyMo]

kfaessen schreef op zondag 05 juni 2011 @ 14:13:
[...]

Intussen heb ik al een i3 2100T setje ervoor. Nu is de speed via smb 110-120MB/s lezen en schrijven (alleen als de andere kant die snelheid ook aan kan). Maar het was volgens mij toen met die 25MB/s zonder die TCP_NODELAY in de config aangezet.

Maar het ging mij er eigenlijk om dat het trage van CurlyMo aan smb kon liggen en dat is nog steeds van toepassing. Voor mij is dit verder dus minder van belang.

De TCP_NODELAY optie had ik ook al eens geprobeerd net als de andere veel voorkomende opties die worden aangeraden op internet. Dat zorgde ook niet voor verbetering.

Jumbo frames doen ook niks merkbaars.

Ik ga binnenkort eens een ubuntu / windows install doen op een andere harde schijf om eens te kijken of de lage zfs write speed de bottleneck zou kunnen zijn.

[Ravefiend]

FreeNAS 8.0 heeft de eerste dagen goed gewerkt op mijn nieuwe NAS en heb er een hele zooi data naartoe kunnen copieren. Sindsdien gaat het minder goed want de huidige system state is dat bij de minste activiteit op het systeem de processen beëindigd worden met ofwel signal 11 dan wel signal 6. Hiervoor heb ik een thread open op het nieuwe FreeNAS forum maar ben er vooralsnog niet uit wat de oorzaak is. Die zou ik graag eerst vinden vooraleer ik het systeem reboot. Iemand al eens hetzelfde ervaren?

[Ultraman]

CurlyMo schreef op zondag 05 juni 2011 @ 19:51:
[...]


De TCP_NODELAY optie had ik ook al eens geprobeerd net als de andere veel voorkomende opties die worden aangeraden op internet. Dat zorgde ook niet voor verbetering.

Jumbo frames doen ook niks merkbaars.

Ik ga binnenkort eens een ubuntu / windows install doen op een andere harde schijf om eens te kijken of de lage zfs write speed de bottleneck zou kunnen zijn.

Is het dan niet makkelijker om eerst een efficiënt protocol te testen ipv Samba?
Zet bijvoorbeeld eens een simpele FTP server op en test daar eens mee. vsftpd is daar op zich een goede kandidaat voor. Benieuwd of je performance dan nog steeds slecht is.

[ Voor 1% gewijzigd door Ultraman op 01-03-2013 18:09 . Reden: nickchange ]

[leuk_he]

Ravefiend schreef op maandag 06 juni 2011 @ 09:52:
bij de minste activiteit op het systeem de processen beëindigd worden met ofwel signal 11 dan wel signal 6.

In de freebsd faq wordt verwezen naar dit linux verhaal:

http://www.bitwizard.nl/sig11/

Met andere woorden, het zou aan je hardware kunnen liggen. memtest enzo gaan draaien?

[Pantagruel]

Ultraman schreef op maandag 06 juni 2011 @ 10:38:
[...]

Is het dan niet makkelijker om eerst een efficiënt protocol te testen ipv Samba?
Zet bijvoorbeeld eens een simpele FTP server op en test daar eens mee. vsftpd is daar op zich een goede kandidaat voor. Benieuwd of je performance dan nog steeds slecht is.

SMB is in verhouding tot ftp en NFS inderdaad behoorlijk ineffeciënt .

Bloody raw netwerk bandbreedte test draaien mbv Iperf, how-to-tje, sluit je evt. harddisk beperkingen of een brak kabeltje uit als iperf echt slechte getallen laat zien

[smesjz]

leuk_he schreef op maandag 06 juni 2011 @ 10:46:
[...]


In de freebsd faq wordt verwezen naar dit linux verhaal:

http://www.bitwizard.nl/sig11/

Met andere woorden, het zou aan je hardware kunnen liggen. memtest enzo gaan draaien?

Dit is wel heel selectief gequote uit die FAQ en die site zelf. De FreeBSD FAQ (http://www.freebsd.org/do...roubleshoot.html#SIGNAL11) geeft zelf goede tips om dit te troubleshooten. Het meest waarschijnlijke in dit geval is een bug in het programma, memtest draaien kan nooit kwaad. Maar ik zou hardware problemen zeker niet als eerste verdachte zien...

[CurlyMo]

Pantagruel schreef op maandag 06 juni 2011 @ 10:52:
[...]


SMB is in verhouding tot ftp en NFS inderdaad behoorlijk ineffeciënt .

Bloody raw netwerk bandbreedte test draaien mbv Iperf, how-to-tje, sluit je evt. harddisk beperkingen of een brak kabeltje uit als iperf echt slechte getallen laat zien

Die tests had ik dus al gedaan. Ftp server draait maar geeft maar een marginale verbetering...

[Pantagruel]

CurlyMo schreef op maandag 06 juni 2011 @ 10:58:
[...]


Die tests had ik dus al gedaan. Ftp server draait maar geeft maar een marginale verbetering...

Klopt, had ik overheen gelezen.

Puur om het weten en dus niet echt functioneel omdat je al op een i3 bent overgestapt.

Welke LAN interface gebruikte je eigenlijk??
Het is maar een wilde gok, maar wellicht dat de IPMI die over LAN1 meehobbelt wellicht in de weg. In t BIOS kun je tevens PCIe error logging aan zetten, misschien levert dat wat op.

[raymonvdm]

Volgens mij maakt het niet veel uit wat voor merk netwerkkaart je hebt. Het is meer een kwestie van geluk dan wijsheid denk ik.

Ik heb nu getest met 2 systemen eentje met een onboard Intel E1000 en eentje met onboard broadcom en de snelheid maakt niet uit. Ik heb nog ergens een pci-x Intel 1000 en die wil ik nog wel eens testen maar ik gok dat mn sata aansluitingen het probleem zijn. ( 4 x pci-e en 2 x onboard)

Een i3 processor gaat dus zeker een oplossing zijn, maar ik wil meer dus een i5 2400S en vt-d maar dat laat nog even op zich wachten. Al moet het niet te lang duren want beest stookt nu 160watt

[leuk_he]

smesjz schreef op maandag 06 juni 2011 @ 10:56:
[...]


Dit is wel heel selectief gequote uit die FAQ en die site zelf. De FreeBSD FAQ (http://www.freebsd.org/do...roubleshoot.html#SIGNAL11) geeft zelf goede tips om dit te troubleshooten. Het meest waarschijnlijke in dit geval is een bug in het programma, memtest draaien kan nooit kwaad. Maar ik zou hardware problemen zeker niet als eerste verdachte zien...

In het andere topic waar hij naar verwijst valt op dat meerder applicaties crashen, niet enkel smbd, maar ook zelfs "csh" (en als iets stabiel is is het toch wel de shell? toch?). Daarom denk ik toch aan systeem problemen, en niet aan 1 programma.

[Pantagruel]

raymonvdm schreef op maandag 06 juni 2011 @ 13:42:
Volgens mij maakt het niet veel uit wat voor merk netwerkkaart je hebt. Het is meer een kwestie van geluk dan wijsheid denk ik.

Intel/Broadcom nic chips hebben doorgaans betere driver ondersteuning als het gaat om niet windows OS-en als *nix en BSD, Realtek is/was berucht om haar brakke ondersteuning

Ik heb nu getest met 2 systemen eentje met een onboard Intel E1000 en eentje met onboard broadcom en de snelheid maakt niet uit. Ik heb nog ergens een pci-x Intel 1000 en die wil ik nog wel eens testen maar ik gok dat mn sata aansluitingen het probleem zijn. ( 4 x pci-e en 2 x onboard)

Een i3 processor gaat dus zeker een oplossing zijn, maar ik wil meer dus een i5 2400S en vt-d maar dat laad nog even opzich wachten. Al moet het niet te lang duren want beest stookt nu 160watt

De ICH7R van je moederbordje zou toch wel een 80 MB/sec moeten trekken (oude tweakers bench met een SSD laat ca 80 MB/sec zien), de vraag blijft dan wel in hoeverre andere insteekkaarten van dezelfde bandbreedte gebruik maken (PCI/PCIe bus) en elkaar dus mogelijk in de weg zitten.

[ Voor 15% gewijzigd door Pantagruel op 06-06-2011 15:38 ]

[TMon]

raymonvdm schreef op maandag 06 juni 2011 @ 13:42:

Een i3 processor gaat dus zeker een oplossing zijn, maar ik wil meer dus een i5 2400S en vt-d maar dat laad nog even opzich wachten. Al moet het niet te lang duren want beest stookt nu 160watt

Een i5 2400s is zonde van je geld. Is in Idle niks zuiniger en in load enkel zuiniger omdat hij op veel lagere clocksnelheid draait dan de normale 2400 en dus ook echt trager is. tomshardware had hier dacht ik een artikel over een tijdje terug.

[Ravefiend]

leuk_he schreef op maandag 06 juni 2011 @ 14:29:
[...]

In het andere topic waar hij naar verwijst valt op dat meerder applicaties crashen, niet enkel smbd, maar ook zelfs "csh" (en als iets stabiel is is het toch wel de shell? toch?). Daarom denk ik toch aan systeem problemen, en niet aan 1 programma.

Hardware probleem lijkt me zelf minder aannemelijk net omdat ik csh telkens weer kan laten crashen door deze actie:

1. Open up an SSH session as root
2. Type cd /var/log[tab]
--> connection closed and on the console I get "Jun 3 02:43:29 freenas kernel: pid 43194 (csh), uid 0: exited on signal 11"

Vooralsnog heb ik het systeem niet herstart ...

[Ultraman]

raymonvdm schreef op maandag 06 juni 2011 @ 13:42:
Volgens mij maakt het niet veel uit wat voor merk netwerkkaart je hebt. Het is meer een kwestie van geluk dan wijsheid denk ik.

Jazeker wel.
Op hedendaagse snelle CPUs een stuk minder, maar zodra je bij de minder sterke modellen komt wordt het wel van belang. Een Atom heeft weinig power en zal profijt hebben bij een goede netwerkchip met goede drivers. Op Linux en BSD platformen is Intel ontzettend goed ondersteunt, aan de e1000 serie heb je een goede wat dat betreft. Realtek is trouwens ook best goed ondersteunt, maar de chips zijn minder krachtig dan die van Intel.
Mijn ervaring is wel dat het tegenwoordig met de Gigabit standaard en de eisen die het stelt qua offloading het verschil wel een stuk minder extreem is geworden.

Het is echter ook geen heilige graal. Je netwerkperformance zal niet magisch verbeteren als je ff een Intel NICje inprikt. De andere factoren moeten ook kloppen, configuratie van software en de andere hardware van het netwerk zoals bekabeling en switches.
Zeker die bekabeling is daar belangrijk voor Gigabit. Goede CAT5E of nog beter CAT6 is wat je wilt hebben.
En als het linked op Gigabit snelheid is dat geen garantie dat het gehaald kan worden.
Ik heb er een kabel bijzitten die keurig linked op Gbit, maar de ene richting wordt 80MB/s gehaald en de andere kant op amper 20MB/s. Omdat die kabel ergens slecht is dus.

[TMon]

misschien handig voor de beginnende zfs-er (zoals ik) om te vermelden welke schijven jullie gebruiken. Dus met type nr. erbij. Dit omdat je met advanced format schijven eerst de boel recht moet trekken en dit in geval van vervanging later, weer moet doen. Als ik het goed heb, toch?

En als je dan advanced format schijven gebruikt, vertel dan hoe je een fysieke swap aanpakt en wat je moest doen om te allignen.

[Anoniem: 15758]

Samsung F4 schijven zijn het meest populair, dit zijn inderdaad 'advanced format' ofwel 4K sector schijven. Maar je hoeft niet veel te doen, alleen is het wel handig je te beperken tot de optimale disk configuratie:
RAID-Z: 3, 5 of 9 disks
RAID-Z2: 6 of 10 disks

Voor mirror (RAID0+1) gelden deze beperkingen niet. Voor alle situaties geldt dat je geen vieze/foute partities moet gebruiken; het liefst helemaal geen partities of anders goed alignde partities. Een goede partitie is een die begint op een 4K boundary, vaak sector 2048 offset (1MiB offset).

Daarnaast bestaat er een ashift=12 methode die ZFS anders data laat alloceren. Echter is dat niet/minder nodig als je je houdt aan bovenstaande disk configuratie (3/5/9 of 4/10 disks). Als je dat hebt gedaan en je moet een disk vervangen, hoef je dat niet opnieuw te doen. Die instelling gaat per pool dus eenmaal op ashift=12 blijft het altijd zo.

Beantwoordt dit je vragen?

[TMon]

zuiver. Maar zou je een link kunnen geven waar uitgelegd wordt waarom 3,5,9 dan de magische getallen zijn? Gezien je kennis door de posts heen geloof ik je meteen, maar ik wil het gewoon graag duidelijk hebben voor mezelf.

En je hebt m'n vraag kort en bondig beantwoord, ik verwachtte een veel groter en omvangrijker antwoord gezien alle ophef over die 4k disks. Maar dit is natuurlijk beter

[Anoniem: 15758]

Die info heb ik ook maar van HardForum, maar duikt op wel meer plaatsen op. En zelf ook geverifiëerd. De theorie erachter is ook begrijpelijk, als je weet hoe RAID-Z werkt.

Met 5 disks in RAID-Z kom je uit op 4 data disks (5 minus 1 parity disk) en dat levert met 128K / 4 een getal op wat deelbaar is door 4 kilobyte sectors. De truc is dus om altijd een 'power-of-two' getal te krijgen voor het aantal data disks. Met data disks bedoel ik dus het aantal disks minus de parity disks. Bij 6-disk RAID-Z2 kom je dus uit op 4 data disks. 128 gedeeld door 4 is dus goed, evenals 128 / 2 of 128 / 1 of 128 / 8.

Maar stel je neemt 4 disks in RAID-Z dan krijg je 128K / 3 en dat levert dan 42.67KiB op; wat soms 42.5K en soms 43K betekent voor je hardeschijven. Dat betekent dat bij alle I/O die ZFS dan doet een 4K sector hardeschijf het laatste deel (40-44K) op een omslachtige/langzame manier moet schrijven. Eerst een 4K block lezen en daarna de hele 4K block opnieuw schrijven. Dat lezen+schrijven kan niet tegelijk gebeuren dus staat dit gelijk aan een seek. Dat maakt dat zulke arrays een stuk langzamer zijn.

De ashift=12 methode houdt in dat ZFS de disks beschouwt als native 4K sector disks. Daarmee voorkom je het bovenstaande probleem maar schrijf je soms onnodig meer data, en verlies je ruimte door meer 'slack'.

De echte magische getallen zijn dus: 1, 2, 4, 8, 16, 32, 64, 128, 256, etcetera. Alleen door de parity disks worden dat 'rare' getallen zoals 3, 5 en 9 in RAID-Z en 4, 6, 10, 18 in RAID-Z2 en 5, 7, 11, 19 in RAID-Z3.

[leuk_he]

Anoniem: 15758 schreef op woensdag 08 juni 2011 @ 16:52:
Met 5 disks in RAID-Z kom je uit op 4 data disks (5 minus 1 parity disk) en dat levert met 128K / 4 een getal op wat deelbaar is door 4 kilobyte sectors.

http://blowfi.sh/2010/12/26/good-things-take-time/

inderdaad, echter dat heleverhaal werkt alleen als je de ashift goed zet denk ik. Want als je dat niet doet dan zal door de variable blocksize een block van 4 kb gedeeld worden. (niks aan de hand), maar alle blokken erna zullen niet meer aligned zijn in de metaslab? want een minblocksize kun je niet zetten ... tohc...?

[FireDrunk]

Anoniem: 15758 schreef op woensdag 08 juni 2011 @ 16:52:
Die info heb ik ook maar van HardForum, maar duikt op wel meer plaatsen op. En zelf ook geverifiëerd. De theorie erachter is ook begrijpelijk, als je weet hoe RAID-Z werkt.

Met 5 disks in RAID-Z kom je uit op 4 data disks (5 minus 1 parity disk) en dat levert met 128K / 4 een getal op wat deelbaar is door 4 kilobyte sectors. De truc is dus om altijd een 'power-of-two' getal te krijgen voor het aantal data disks. Met data disks bedoel ik dus het aantal disks minus de parity disks. Bij 6-disk RAID-Z2 kom je dus uit op 4 data disks. 128 gedeeld door 4 is dus goed, evenals 128 / 2 of 128 / 1 of 128 / 8.

Maar stel je neemt 4 disks in RAID-Z dan krijg je 128K / 3 en dat levert dan 42.67KiB op; wat soms 42.5K en soms 43K betekent voor je hardeschijven. Dat betekent dat bij alle I/O die ZFS dan doet een 4K sector hardeschijf het laatste deel (40-44K) op een omslachtige/langzame manier moet schrijven. Eerst een 4K block lezen en daarna de hele 4K block opnieuw schrijven. Dat lezen+schrijven kan niet tegelijk gebeuren dus staat dit gelijk aan een seek. Dat maakt dat zulke arrays een stuk langzamer zijn.

De ashift=12 methode houdt in dat ZFS de disks beschouwt als native 4K sector disks. Daarmee voorkom je het bovenstaande probleem maar schrijf je soms onnodig meer data, en verlies je ruimte door meer 'slack'.

De echte magische getallen zijn dus: 1, 2, 4, 8, 16, 32, 64, 128, 256, etcetera. Alleen door de parity disks worden dat 'rare' getallen zoals 3, 5 en 9 in RAID-Z en 4, 6, 10, 18 in RAID-Z2 en 5, 7, 11, 19 in RAID-Z3.

Daarom lees je ook wel dat mirroring bij zo'n raar aantal schijven beter is... Dus veel setjes van 2 maken

4 x een mirror performt schijnbaar beter dan een RAIDZ2 van 8 disks. Dat moet ik zelf nog een keer testen

[Anoniem: 15758]

leuk_he schreef op woensdag 08 juni 2011 @ 16:57:
inderdaad, echter dat heleverhaal werkt alleen als je de ashift goed zet denk ik.

Nee juist bij de normale ashift=9 (default) gelden die optimale disk nummers. Als je een niet-optimale hoeveelheid disks hebt dan heb je juist het meest baat bij ashift=12 tuning.

Ashift=9 betekent dat ZFS de disks als 512-byte sectors beschouwt (2^9 = 512).
Ashift=12 betekent dat ZFS de disks als 4K sectors beschouwt (2^12 = 4096).

Dus stel je hebt 4 disks in RAID-Z dan kom je uit op 128K / 3 wat je 42.67 geeft. Met ashift=9 wordt dat soms 42.5K en soms 43.0K welke beide niet-optimaal zijn voor 4K sector schijven. Met ashift=12 wordt dat automatisch 44K waarbij er dus 1.5K of 1.0K verloren gaat per block. De 128K komt van de recordsize; die bijna altijd 128K is en niet groter is te maken, helaas.

FireDrunk schreef op woensdag 08 juni 2011 @ 17:25:
[...]
Daarom lees je ook wel dat mirroring bij zo'n raar aantal schijven beter is... Dus veel setjes van 2 maken
4 x een mirror performt schijnbaar beter dan een RAIDZ2 van 8 disks. Dat moet ik zelf nog een keer testen

Mirrorring heeft geen last van bovenstaande problemen, omdat het 128K gebruikt per stripe en dus nooit iets 'deelt' aan de hand van het aantal schijven. 6 disks in 3 mirrors betekent 3 keer 128K met striping, en dat gaat altijd goed ook gebruik je 8K of 16K sector schijven. Nieuwere SSDs gebruiken bijvoorbeeld 8K pages wat betekent dat ze het liefst in veelvouden van 8K schrijven om fragmentatie en write amplification te voorkomen.

Ongeacht de sectorsize, een of meer mirrors doen altijd meer IOps dan een enkele RAID-Z. Een RAID-Z (1/2/3) doet evenveel IOps als een enkele disk. Een mirror kan met leesacties daar overheen. Meerdere mirrors is dus voor IOps veel beter dan één grote RAID-Z. IOps schaalt met het aantal vdevs, die door ZFS worden gestriped. Echter, dit is misschien niet zo heel spannend als je vooral grote bestanden opslaat, of als je wel IOps nodig hebt maar een SSD gebruikt voor L2ARC+SLOG, dan kun je ook prima RAID-Z gebruiken.

[FiXeL]

Even een noob vraagje tussendoor...

Ik zit tegen een upgrade van mijn main pc aan, en wou de oude hergebruiken als fileserver. Het ZFS format spreekt me erg aan, en ik wou er eerst maar eens freenas op gaan draaien gezien ik niet zoveel ervaring heb met Linux/Unix systemen.

Specs:

- Asus P5Q Pro
- Intel Core 2 Duo E8400
- 4 Gb Ram
- 600W PSU
- Cheapo videokaart (zit nu een Radeon HD4850 in, maar die gaat eruit voor een passief gekoelde kaart)
- 4/8 2Tb WD Eco green schijven (eerst 4, en indien nodig een upgrade naar nog 4=8)

WD Eco green schijven... krijg ik daar problemen mee met freenas? Ik lees dat de 4Kb blocksize soms problemen oplevert. Ook moet het OS op een aparte USB drive geplaatst worden zonder SATA sloten in te leveren. Er zit een hoop verschil in USB Drives, Wat voor drive met wat voor soort geheugen is het beste geschikt voor deze toepassing? Ik kan natuurlijk een cheapo flash drive gaan halen, maar wat als ie stuk gaat of bad blocks begint te bevatten? Hoe zit het met drivers voor southbridge controller van het mobo? Gezien die 6 SATA poorten heeft lijkt het me wel fijn dat die werkt met freenas. (8 in totaal)

Ik heb al een Netgear Readynas Duo, maar die 2TB in X-Raid Begint langzaam aan vol te raken. Zelf denk ik, dat 4x 2TB in Raid-Z eerst wel voldoende zal zijn voor mijn fileserving behoeftes, maar later kunnen er altijd nog 4 schijven bij, mocht dat nodig zijn.

Alvast bedankt voor alle tips en advies!

[Anoniem: 15758]

E8400 is vette overkill voor een simpele ZFS server, maar 4GiB RAM is dan weer aan de krappe kant. Een videokaart heb je strict genomen niet nodig; je kunt gewoon zonder enige videokaart draaien nadat je FreeNAS hebt geïnstalleerd. Nadeel is dat je dan moeilijker troubleshooting kan doen als er iets mis gaat, maar dan kun je natuurlijk weer een videokaart plaatsen mocht dat nodig zijn. Dat scheelt weer een watt of 20, die videokaarten trekken meer stroom dan een basis computersysteem; erg jammer!

Zoals je hierboven kunt lezen is 4 of 8 schijven geen optimale configuratie voor nieuwere 4K sector schijven zoals WD EARS en Samsung F4. Als je nog geen schijven hebt gekocht kun je ook kiezen voor Hitachi 5K3000 2TB schijven die zijn 512-byte sector en heb je dus geen problemen met 4 of 8 disks.

Drivers is iets van windows; bij Linux en BSD zitten alle drivers in de kernel zelf en is dus niet iets wat je kunt of wilt installeren. Je chipset SATA hoort altijd te werken, bij auxillary SATA hangt het af van de controller. Jouw moederbord heeft ICH10R southbridge met 6 SATA in AHCI wat de beste poorten zijn die je kunt hebben. Daarnaast 2 SATA via Marvell 88SE6111 die een apart kleurtje hebben, die zijn van mindere kwaliteit. Marvell is een chip die onder Linux/BSD/Solaris een zeer wisselende driverkwaliteit kent. Kwestie van uitproberen.

Persoonlijk zou ik zeggen: kies 6x Samsung F4 schijven in RAID-Z2 dan houd je 8TB effectief over en zit je goed qua 4K sectors. Dan hoef je de Marvell poorten niet te gebruiken. Wil je persé 8 disks dan kun je of mindere performance verwachten als je die WD EARS schijven al hebt, of je koopt Hitachi schijven zodat je geen problemen hebt met 4K sectors. Er is een kleine kans dat die Marvell poorten problemen gaan geven.

FreeNAS gaat prima op een USB stick; kwaliteit maakt niet uit is allemaal knudde omdat er geen intelligente controller in zit zoals bij SSDs het geval is. Omdat FreeNAS niet of minimaal schrijft naar de flash maakt dat verder ook weinig uit.

[FiXeL]

E8400 is ook vette overkill, ik weet het... Normaal gesproken gingen mijn outdated systeempjes richting familie die nog oudere hardware draaien, maar die zijn voorzien en ik heb geen zin om dit systeem door te verkopen en iets zuinigers te halen. Het systeem zal toch niet 24/7 draaien, voor af en toe een filmpje serveren kan ik ook terugvallen op de Netgear NAS. 4Gb ram is wat ik lees idd aan de krappe kant, maar echt veel performance hoeft ook niet perse. Het wordt een opslagbak, maar gezien de prijzen van geheugen zou een upgrade misschien geen kwaad kunnen.... Is 8 GB voldoende?

Wat betreft de videokaart... Hmja, die zou er uit kunnen idd, goeie tip! Ik wou er eigenlijk een cheapo videokaart inzetten voor het geval dat, maar ik kan natuurlijk ook gewoon de oude blijven gebruiken... Ik heb nog geen schijven gekocht, dus die optie staat nog open.... Hitachi it is.

Goed dat ik weet dat de Marvell poorten lastig kunnen zijn, ik zat te twijfelen of ik er meteen 4 of meteen 6 schijven in zou drukken, omdat ik nu maar 2TB opslag heb op de NAS, en 1TB opslag op de PC, dus eigenlijk leek 6TB me eerst wel voldoende. Als de server draait wou ik de NAS opnieuw inrichten zodat deze inplaats van Raid-1 Jbod draaide zodat deze voldoende capaciteit had voor backups (naja films en series is niet zo belangrijk) en er nog een extra externe HD bij voor just in case.

Marvel poorten kan ik altijd nog eens een paar schijfjes in jbod aan hangen, en kijken hoe dat gaat.

Bedankt voor je advies, dat wordt ff 6 schijfjes halen!

[Anoniem: 15758]

Dus je wilt geen RAID-Z of RAID-Z2 draaien maar RAID1 of RAID0? Een JBOD bestaat niet bij ZFS, wel een RAID0.

Voordeel van RAID1 en RAID0 configuraties zijn dat je flexibeler met je schijven kunt omgaan:

• Je kunt een RAID0 naar RAID1 converten, én weer terug (een mirror een stripe maken).
• Je kunt eenvoudig disks toevoegen en direct extra capaciteit krijgen; hiervoor is geen rebuild nodig.
• Stel je hebt RAID1 maar je wilt even één disk toevoegen dan kan dat ook, om er pas later een mirror van te maken.
• Stel je hebt even een disk nodig voor iets anders kun je die even 'stelen' van een RAID1 die dan een RAID0 wordt en later weer terug plaatsen.

ZFS werkt met vdevs, elke 'array' is een vdev. Dat kan een single disk zijn, een mirror of een RAID-Z. Meerdere vdevs worden in RAID0 geplaatst. Dus een RAID0 array ziet er zo uit:
vdev1: Hitachi 2TB
vdev2: Hitachi 2TB

Een RAID1 ziet er zo uit:
vdev1: mirror (Hitachi 2TB + Hitachi 2TB)
vdev2: mirror (Hitachi 2TB + Hitachi 2TB)
(eigenlijk is dit een RAID1+0 omdat je twee mirrors in een stripe hebt.

Voordeel van ZFS is dat je kunt wisselen met disk groottes. Je kunt later gewoon een 3TB disk toevoegen aan je pool met 2TB schijven, zonder die extra terabyte te verliezen.

Dit alles is erg makkelijk, zelfs met command line:
RAID0 disk toevoegen: zpool add tank /dev/label/nieuwedisk
RAID1 disks toevoegen: zpool add tank mirror /dev/label/nieuwedisk1 /dev/label/nieuwedisk2
Van een RAID0 een RAID1 maken: zpool attach tank /dev/label/bestaandedisk /dev/label/nieuwedisk3

Ik gebruik /dev/label omdat je dan eigen namen kunt geven. Je kunt ook GPT partities gebruiken of gewoon device nodes (/dev/ada4). Wat FreeNAS 8 doet weet ik niet meer uit mijn hoofd, maar wat ik hierboven zeg zou ook via de GUI moeten lukken.

[FiXeL]

Wou voor de main Pool gewoon Raid-Z/Z2 gebruiken, en als er zonder probs nog een paar schijven bij kunnen (op de marvell poort) dan is dat leuk in raid-0 of -1, maar da's geen prioriteit.

[smokalot]

Anoniem: 15758 schreef op woensdag 08 juni 2011 @ 20:39:
Een JBOD bestaat niet bij ZFS, wel een RAID0.

nou ja, een zfs stripe is niet helemaal hetzelfde als een raid0, ze kunnen verschillende grootte zijn (zonder verlies van capaciteit), en als je een snelle en een langzame disk in een stripe zet wordt je snelle disk sneller gevuld dan de langzame. Het zit er dus een beetje tussenin.

Je kunt ook nog overwegen een stripe te gebruiken, en dan copies=2 op het filesystem (zfs, dus niet op de zpool) zetten om iets meer veiligheid van je data te hebben. Zfs zal dan zoveel mogelijk proberen twee kopieen van ieder block op te slaan op verschillende devices, dus als je datacorruptie hebt kan ie het repareren, maar als het hele device wegvalt ben je alsnog alles kwijt.

[Anoniem: 15758]

smokalot schreef op woensdag 08 juni 2011 @ 22:04:
[...]

nou ja, een zfs stripe is niet helemaal hetzelfde als een raid0

Klopt helemaal.

Maar ZFS is per definitie incompatible met welk RAID level dan ook, vandaar dat het ook een 'layering violation' wordt genoemd; geen enkele RAID-engine kan nadoen wat ZFS doet, omdat filesystem en RAID engine met elkaar zijn verweven en niet los te koppelen zijn van elkaar.

Echter, als je een RAID0 beschouwt als interleaving waarbij één bestand op meerdere devices komt te staan voor extra snelheid, en een JBOD/concat als een techniek waarbij een bestand slechts op één device komt te staan zonder extra snelheidwinst, dan kun je wel stellen dat wat ZFS doet veel eerder met RAID0 overeenkomt dan met JBOD.

ZFS is een rare eend en slecht vergelijkbaar omdat er bijna geen echt alternatief is waarmee het goed te vergelijken is. Btrfs komt op sommige punten aardig in de buurt, maar dat is vaak nog onbekender. Het gevaar van de leuke features van ZFS is en de 'eigenwijze' manier van sommige design choices is dat het veel ingewikkelder klinkt dan het in werkelijkheid is. Dat doet sommige mensen afschrikken waarvoor ZFS wel geschikt zou zijn maar ze denken dat het te ingewikkeld voor hen is.

[FiXeL]

Nog 1 vraagje.. Een E8400 CPU is zwaar overkill volgens jou, maar wat voor socket 775 processor zou voor voor deze toepassing het best geschikt zijn? Een single core celeron kost maar 30 euro, maar trekt die dat wel? Stroomconsumptie is natuurlijk ook iets om rekening mee te houden, dus een single core is denk ik beter voor mn stroomrekening. Maar ik wil niet er een CPU inprikken om er later achter te komen dat ie teveel werk moet verstouwen. Alvast bedankt!

[Anoniem: 15758]

Het is niet zo dat een krachtigere CPU automatisch meer stroom verbuikt; juist eerder andersom gek genoeg; de goedkopere maar oudere CPUs verbruiken meer stroom wanneer ze niks doen (idle) dan nieuwe processors met de nieuwste productietechnieken (highK-metalgate). De E8400 valt hier ook onder en verbruikt dus in principe maar weinig stroom. Maar de chipsets op socket 775 zijn weer niet zuinig en daar komt je hogere energieverbruik vandaan. Bij nieuwe socket 1115 CPUs is de northbridge van de chipset en GPU in de CPU geïntegreerd, wat flink scheelt qua energieverbruik.

Een E8400 CPU zou het best overeenkomen met 16GiB RAM en 30 tot 40 schijven in meerdere RAID-Z2's. Dat kan die CPU aan. Ik zie het ongeveer zo:

4GiB RAM -> Intel Atom CPU
8GiB RAM -> AMD Zacate of simpele dualcore
16GiB RAM -> krachtige dualcore of quadcore

Als je zaken als compressie en encryptie gebruikt kan dat flink verschuiven; dan heb je mogelijk wel baat bij een krachtigere CPU. Echter gzip compressie is eigenlijk altijd langzaam; dat dien je alleen te gebruiken voor data die uit tekstbestanden bestaat, bijvoorbeeld waar je logs worden geschreven dat zorgt ook niet/nauwelijks voor overhead.

Voor een laag energieverbruik geldt dat je een modern platform (moederbord/chipset) wilt, een zuinige voeding (PicoPSU indien mogelijk) en zuinige 'green' hardeschijven. En geen onnodige dingen. Alles met een heatsink verbruikt in principe veel stroom.

In jouw geval kun je die E8400 gewoon gebruiken, anders zou ik voor een Zacate setup gaan dan scheelt het nog wat qua energieverbruik, maar je grootste verbruiker zal je moederbord zijn en je voeding.

[FiXeL]

Bedankt voor je reply!

Wat ik uit dit verhaal opmaak is dat het mobo wat ik voor dit doeleinde wil gebruiken niet ideaal is, en de CPU zwaar overkill. (maar dat was al duidelijk) Tis voor mij alleen een beetje een afweging dan... Is de oude hardware het nog waard om in te ruilen voor iets zuinigers, of laat ik het zo? Let wel, het systeem zal niet 24/7 gaan draaien, maar hooguit in de weekenden om backups te draaien van mijn NAS en PC. Dus vanuit dat opzicht ben ik een beetje huiverig voor deze hardware verpatsen en nieuwe halen. (met het risico dat ik veel duurder uitben)

Ik ben inmiddels ook aan het kijken naar een geheugen upgrade, maar het mobo gooit roet in het eten. De Dimms mogen max. 4GB per stuk zijn, met een max. van 16GB totaal en de geheugenchips op de dimm niet groter dan 128MB. Ik heb destijds 2 identieke systemen samengesteld, (1 voor mij, ander voor collega) dus ik kan aan een identiek setje dimms komen, maar dat betekend wel dat ik een werkend setje dimms voor de andere pc moet komen, wat eigenlijk een beetje verplaatsen van het probleem is, en dan nog zit je op 8GB totaal.

Moeilijk, moeilijk... Ik hoef geen killer performance though... Als de server maar een beetje leuk data kan wegschrijven/serveren vindt ik het prima. Maar het moet natuurlijk niet 4MB/Sec worden over Gbit lan.

[Anoniem: 15758]

het systeem zal niet 24/7 gaan draaien, maar hooguit in de weekenden om backups te draaien van mijn NAS en PC.

Dan heeft het weinig zin om zoveel moeite te doen om voor een laag verbruik te optimaliseren. Houd het gewoon lekker bij je E8400; een beetje overkill is niet erg en veel geld aan een hoger stroomverbruik ben je ook niet kwijt. Nieuwe hardware kopen is ook niet gratis.

Geheugen voor DDR2 is wel duurder dan voor DDR3; dus ik zou het bij 8GiB houden dat is opzich al erg mooi. Verder is een kleine SSD wel aan te bevelen, dat kan je snelheid flink boosten. Liefst een Intel 320 SSD zodat je hem als zowel SLOG als L2ARC kan gebruiken; 80GiB zou ideaal zijn, de 120GiB versie is nog iets sneller maar de capaciteit heb je niet nodig. Eigenlijk zou 40GiB al heel mooi zijn, maar die is weer een stuk langzamer qua writes.

[FiXeL]

In pricipe heb ik een intel postville 160GB schijf beschikbaar... Daar draait nu mijn windows op en ik zit nu dus nog lekker te tikken op de toekomstige server. Ik schrok idd van de prijzen voor DDR2 geheugen, het is in vergelijking met DDR3 een stuk duurder idd. Ik bestel er gewoon 2 dimmetjes bij, mocht het ruzie krijgen met mn huidige dimms, dan probeer ik omruilen met de andere pc die mijn collega heeft, mocht het daar ook niet werken dan stuur ik het weer terug.

Morgen komt mn salaris weer binnen + vakantiegeld, en ik krijg binnenkort ook een hoop knaken terug van de belastingdienst.

[Anoniem: 15758]

Intel X25-M 160GB is wel geschikt als L2ARC, maar eigenlijk veels te groot en ontbeert supercapacitors waardoor je hem beter niet als SLOG kunt gebruiken. Ik zou zelf die Intel 160GB SSD in je desktop gebruiken en of nu of later een Intel 320 SSD erbij kopen speciaal voor ZFS. Die nieuwe serie heeft supercaps en is daarom ook voor SLOG geschikt, wat een must is zeker als je met ZFS versie van lager dan 19 werkt.

Verder zou ik rustig aan doen met te dure uitgaven; probeer het te doen met de spullen die je al hebt, een beetje geheugen erbij is prima natuurlijk.

[Anoniem: 187449]

vers : open indiana 151 live desktop iso

Fixes and improvements since oi_148:

* More bug and security fix backports
* Unicode 6.0.0 compatibility
* More bug fixes to JDS GNOME 2.30.2
* Perl 5.10.0 update
* GCC 4.6.0 (SFEgcc-46) & GDB 6.8
* Java 1.6_25
* Brasero 2.30.3
* Areca 18xx SAS/SATA controller support
* Nvidia 275.09.04 driver
* More bug fixes to ZFS pool 28 and ON_147 from Illumos project.
* Over 6634 software packages available from NetBSD pkgsrc 2011Q1 project

> http://wiki.openindiana.org/oi/oi_151

[ Voor 3% gewijzigd door Anoniem: 187449 op 10-06-2011 22:07 ]

[Splendid]

Anoniem: 187449 schreef op vrijdag 10 juni 2011 @ 21:54:
vers : open indiana 151 live desktop iso

Fixes and improvements since oi_148:

* More bug and security fix backports
* Unicode 6.0.0 compatibility
* More bug fixes to JDS GNOME 2.30.2
* Perl 5.10.0 update
* GCC 4.6.0 (SFEgcc-46) & GDB 6.8
* Java 1.6_25
* Brasero 2.30.3
* Areca 18xx SAS/SATA controller support
* Nvidia 275.09.04 driver
* More bug fixes to ZFS pool 28 and ON_147 from Illumos project.
* Over 6634 software packages available from NetBSD pkgsrc 2011Q1 project

> http://wiki.openindiana.org/oi/oi_151

Dit is nog niet de stable he, maar wel een goeie release om mee te gaan testen

[Anoniem: 187449]

dit is nog niet veranderd

he ..
Name : driver/storage/mpt_sas
Summary : LSI MPT SAS 2.0 Controller HBA Driver
Publisher: openindiana.org
Version: 0.5.11
Build Release: 5.11
Branch: 0.151
Packaging Date: Mon May 23 15:30:06 2011
Size: 684.21 kB
FMRI: pkg://openindiana.org/driver/storage/mpt_sas@0.5.11,5.11-0.151:20110523T153006Z

[ Voor 64% gewijzigd door Anoniem: 187449 op 10-06-2011 23:40 ]

[Oid]

Na het lezen van dit topic is mijn idee om 2x een RAIDZ van 3x2TB te maken en deze dan in RAID0 te zetten waardoor ik effectief 8 TB heb. Ik wil liever 1x een RAIDZ2 van 6x2TB maar mijn probleem is dat er 2 schijven nu de data bevatten die in deze opstelling moet komen te staan. (en ik moet dus eerst iets hebben voordat ik de data kan overkopieren)

Ultraman in "Het grote ZFS topic" ik las hier over een "loopback device" maar kan dit nergens terug vinden of dit voor freenas ook kan gelden, en hoe dit eventueel zou werken.

Is dit dan voor mij de handigste keuze? ICM freenas?

[raymonvdm]

Oid schreef op zaterdag 11 juni 2011 @ 15:45:
Na het lezen van dit topic is mijn idee om 2x een RAIDZ van 3x2TB te maken en deze dan in RAID0 te zetten waardoor ik effectief 8 TB heb. Ik wil liever 1x een RAIDZ2 van 6x2TB maar mijn probleem is dat er 2 schijven nu de data bevatten die in deze opstelling moet komen te staan. (en ik moet dus eerst iets hebben voordat ik de data kan overkopieren)

Ultraman in "Het grote ZFS topic" ik las hier over een "loopback device" maar kan dit nergens terug vinden of dit voor freenas ook kan gelden, en hoe dit eventueel zou werken.

Is dit dan voor mij de handigste keuze? ICM freenas?

Voor het datakopieren kun je proberen om een extra 2TB te kopen en daar alles heen kopieren. Ik wilde eerst ook beginnen met 4 x 2TB maar op advies van hier toch maar gelijk voor 6x2TB gegaan omdat array expansion geen optie is. Kost je 120 euro meer maar ben wel bijna gelijk klaar.

Ik heb een kast zoals deze kast: V&A aangeboden: Sharkoon Rebel9 Aluminium

[Anoniem: 187449]

raymonvdm schreef op zaterdag 11 juni 2011 @ 21:15:
[...]


Voor het datakopieren kun je proberen om een extra 2TB te kopen en daar alles heen kopieren. Ik wilde eerst ook beginnen met 4 x 2TB maar op advies van hier toch maar gelijk voor 6x2TB gegaan omdat array expansion geen optie is. Kost je 120 euro meer maar ben wel bijna gelijk klaar.

Ik heb een kast zoals deze kast: V&A aangeboden: Sharkoon Rebel9 Aluminium

he tnx .. en die behuizing is uitermate ZFS friendly

[raymonvdm]

De behuizing is ook lekker stil. Hij maakt nu met twee aangesloten 4 in 3 bays weinig geluid. In ieder geval minder dan mn ESXi machine op basis van een intel kast. Helaas wil hij nog wel 110 watt hebben.

Met een E2180 processor en 2GB komt ik trouwens nog steeds niet verder dan 35MB/Sec via CIFS

[Ultraman]

Oid schreef op zaterdag 11 juni 2011 @ 15:45:
Ultraman in "Het grote ZFS topic" ik las hier over een "loopback device" maar kan dit nergens terug vinden of dit voor freenas ook kan gelden, en hoe dit eventueel zou werken.

Is dit dan voor mij de handigste keuze? ICM freenas?

Ik heb geen ervaring met FreeNAS, anders dan dat ik weet dat het een soort uitgeklede FreeBSD is. In FreeBSD is het echter mogelijk om een 6 disk RAID-Z2 te maken met maar 4 echte harddisken door gebruik te maken van twee "virtuele" schijven. Dat kan middels het geom framework. Maak een loop block device aan en gebruik er daar twee van samen met de de 4 echte schijven om een 6 disk RAID-Z2 te maken. Zo houdt je ZFS eventjes voor de gek alsof er 6 daadwerkelijke disken zijn.
Kopieer de data en vervang vervolgende de virtuele disken voor echte schijven. Klaar.

Ik stel voor om deze procedure eerst voor jezelf even te proberen in een virtuele machine. Ik heb het hier onder Virtualbox gedaan. Guides zijn te vinden op internet, mogelijk wel voor (Open)Solaris, dus je zult even moeten uitzoeken hoe je onder FreeBSD een loopback maakt, maar dat is prima te vinden.
Alleen of dit onder FreeNAS kan... hangt er van af wat ze er allemaal uitgestripped hebben.

[ Voor 3% gewijzigd door Ultraman op 11-06-2011 22:51 ]

[leuk_he]

Klein vraagje tussendoor wat ik niet gegoogled krijg

(openinidiana 148 )

code:

bash-4.0$ ls -la
total 17
drwxr-xr-x   5 root     root           5 Jun 10 05:12 .
drwxr-xr-x  26 root     staff         28 Jun 11 23:00 ..
drwxr-xr-x  22 leukhe   staff         38 Jun 10 09:22 home
drwxr-xr-x   2 root     root           2 Jun 10 10:00 opt
drwxr-xr-x   2 root     root           2 Jun  4 11:20 opt1
bash-4.0$ ls -lad .zfs
dr-xr-xr-x   4 root     root           4 Jun  3 19:03 .zfs

waarom zie file/directory beginnend met een . niet met "ls -a" niet?
/edit:
@icyx hieronder... zo simpel was het inderdaad.

[ Voor 5% gewijzigd door leuk_he op 12-06-2011 17:25 ]

[Anoniem: 187449]

raymonvdm schreef op zaterdag 11 juni 2011 @ 22:46:
De behuizing is ook lekker stil. Hij maakt nu met twee aangesloten 4 in 3 bays weinig geluid. In ieder geval minder dan mn ESXi machine op basis van een intel kast. Helaas wil hij nog wel 110 watt hebben.

Met een E2180 processor en 2GB komt ik trouwens nog steeds niet verder dan 35MB/Sec via CIFS

er komt een nieuwe samba aan.. dus wie weet


http://www.h-online.com/o...ow-available-1258843.html
http://holger123.wordpress.com/smb-traffic-analyzer/

[icyx]

leuk_he schreef op zaterdag 11 juni 2011 @ 23:29:
Klein vraagje tussendoor wat ik niet gegoogled krijg

(openinidiana 148 )

code:

bash-4.0$ ls -la
total 17
drwxr-xr-x   5 root     root           5 Jun 10 05:12 .
drwxr-xr-x  26 root     staff         28 Jun 11 23:00 ..
drwxr-xr-x  22 leukhe   staff         38 Jun 10 09:22 home
drwxr-xr-x   2 root     root           2 Jun 10 10:00 opt
drwxr-xr-x   2 root     root           2 Jun  4 11:20 opt1
bash-4.0$ ls -lad .zfs
dr-xr-xr-x   4 root     root           4 Jun  3 19:03 .zfs

waarom zie file/directory beginnend met een . niet met "ls -a" niet?

code:

v|581M|[kevin@iusaaset ~]$ man zfs
[...]
Native Properties
[...]
     snapdir=hidden | visible

         Controls whether the .zfs directory is hidden or visible
         in  the  root  of  the  file  system as discussed in the
         "Snapshots" section. The default value is hidden.

De snapdir is een speciale map die tijdens normaal gebruik standaard onzichtbaar is. Dit is handig, omdat je anders hele vreemde situaties kan krijgen. Denk eens aan een find, of een ls -R op een filesystem met een stuk of wat snapshots...

Wanneer hij expliciet wordt aangeroepen (lees: stat()'d) zal hij echter wel te zien zijn. Je kan hem dan zonder problemen gebruiken, terwijl hij toch voor bovengenoemde situaties beschermd is.

[Anoniem: 221236]

iemand met benchmarks qua nfs (met ZIL aan en uit )?
ikzelf haal volgens ATTO van 1k t/m 8k ~85MB read en ~55MB write, 3 mirrors van elk 2, ZIL aan zonder NFS tuning.
iemand ervaring/aanvaringen met NFS tuning? ik heb gewoon 'zfs share...' gedaan met de nodige opties en dat werkt prima maar enig sleutel werk ben ik niet echt vies van. kan echter niets vinden waar ik kan sleutelen, als een nfsd.conf. ken alleen nfs_server_flags maar daar word ik niet echt opgewonden door.

[ Voor 8% gewijzigd door Anoniem: 221236 op 12-06-2011 02:39 ]

[Oid]

raymonvdm schreef op zaterdag 11 juni 2011 @ 21:15:
[...]


Voor het datakopieren kun je proberen om een extra 2TB te kopen en daar alles heen kopieren. Ik wilde eerst ook beginnen met 4 x 2TB maar op advies van hier toch maar gelijk voor 6x2TB gegaan omdat array expansion geen optie is. Kost je 120 euro meer maar ben wel bijna gelijk klaar.

Ik heb een kast zoals deze kast: V&A aangeboden: Sharkoon Rebel9 Aluminium

Het probleem daaraan is mijn data heb ik nu in RAID0 staan zo'n 3.5 TB op 4 TB (2x2TB RAID0)

Bedankt voor het advies, ga eens kijken of dat haalbaar is, maar ook ga ik kijken naar de oplossing van ultraman

Ik heb zelf de Rebel 12 gekocht, super mooie kast en echt heel degelijk. Voorbereid op de toekomst (Kunnen 18 schijven in)

@ Ultraman: Super bedankt ik ga het hiermee aan de slag, heb freenas al in VMWare workstation draaien dus ik ga het gewoon ff testen en anders geen freenas maar freebsd.

[ Voor 5% gewijzigd door Oid op 12-06-2011 13:14 ]

[Anoniem: 187449]

mocht het gaan regenen :



leesvoer

[raymonvdm]

Pffff, het zit me niet echt mee.

Eerst begonnen met een Intel moederbord waarbij ESXi niet meer start omdat hij blijft hangen op de LSI controllers ben ik verder gegaan met een E2180 processor op een P5LD2 maar deze heeft geen VT support dus kan ik geen 64Bit NexentaStor draaien onder ESXi. Resultaat disken worden wel gezien maar niet beschikbaar door foutmelding. Poging 3 P5MT met een P4 processor waarbij het bord VT ondersteuning heeft maar de processor niet.

Ik ben er klaar mee.... Ik wil NexentaSTOR in ESXi maar zo kom ik er niet he !

Even een ZFS systeempje bouwen en ben al een maand bezig. Had ik maar geld voor een i5 setup

[Anoniem: 187449]

ik ben al 2 maanden bezig .. niet piepen

[FireDrunk]

Waarom niet gewoon baremetal draaien?

[FiXeL]

Beetje bezig geweest met de toekomstige Freenas server:



Dit kaartje had ik nog liggen, een 2GB USB stick op bankpas formaat, met dank aan Mokveld

Eenmaal uitelkaar gesloopt (hey, het kaartje heeft de afgelopen paar jaar flink wat beschadigingen opgelopen aan de buitenkant, en was gratis gezien het een relatiegeschenk was)



Het PCB-tje op een stukje printplaat geplakt, en een interne USB header eraan gesoldeerd....



Aan de onderkant nog wat verlichting plakken....



En voila... Inpluggen en intern een 2GB drive + verlichting voor de aanstaande installatie van Freenas 8.0. Er komt naast de hardware voor mijn nieuwe systeem ook 4x 2GB DDR2 geheugen aan, en 6x 2TB hitachi HDD's.

[raymonvdm]

Ik ben omdat alles tegenzit aan het spelen met FreeNAS 8 en probeer nu mn disken te down spinnen maar dit werkt niet (bekend probleem blijkbaar)

Nu lukt het handmatig wel als ik het volgende doe op de FreeNAS console

ataidle -S 5 /dev/ada0
ataidle -S 5 /dev/ada1

Maar dan kom ik bij de disken die op mn lsi controller zitten

ataidle -S 5 /dev/da1 (the device does not support power management

Gebruik ik ataidle /dev/ada0 dan kan ik de disken ook lezen qua settings dit is anders met de disken op de lsi controller

Het downspinnen van de disken heeft wel effect. Ik gebruik nu 85 Watt, op het moment dat ik 2 disken down-spin dan is het gebruik nog 75 Watt. Elke disk gebruik dus 5 Watt dat betekend dat we 6 x 5 = 30 Watt kunnen besparen door door power management

[ Voor 40% gewijzigd door raymonvdm op 12-06-2011 20:34 ]

[Anoniem: 15758]

ataidle is verouderd; je dient camcontrol (SCSI) en atacontrol (ATA) te gebruiken. Als door passthrough de spindown niet werkt kun je APM overwegen - dan spint de schijf zichzelf down, maar moet wel ondersteund worden door de schijf. Met camcontrol identify kun je zien of dit wordt ondersteund. Mogelijk moet je hiervoor de schijf eerst op een ATA controller aansluiten.

[raymonvdm]

Ik heb op dit moment nog geen pass-through maar alleen FreeNAS op een USB stick in de machine. FreeNAS kan dus rechtstreeks bij alle hardware

atacontrol kent hij wel als commando, alleen /dev/da1 kent hij dan weer niet. camcontrol kent hij ook.


camcontrol standby ada0 -t 500 werkt wel (onboard)
camcontrol standby da0 -t 500 werkt niet (lsi controller) Ik krijg dan de meldingen CAM status function not available

Linkje gevonden http://forums.freebsd.org/archive/index.php/t-22152.html

Ik heb nu met camcontrol stop ad0 tot ad3 de disken kunnen stoppen. De kwh meter vind nu dat we 64watt gebruiken en ze klinken ook echt down te gaan.

met een ls /mnt/tank/test2/ hoor ik ook weer een aantal schijven starten. Ik kan niet horen of ze het allemaal zijn maar de kwh meter zit op 85Watt dus het lijkt er wel op


Ben ik de eerste die ook de disken stil wil hebben als ze niet gebruikt worden (90% van de tijd) want er zijn niet veel meldingen over te vinden...

En hoe krijg ik ataidle -S 5 /dev/ada0 weer uit als ik niet meer wil dat ze down spinnen ....

[ Voor 74% gewijzigd door raymonvdm op 13-06-2011 00:50 ]

[FireDrunk]

Ik heb dat ook zeker geprobeerd (maar dan onder Linux) en die LSI controller wil gewoon niet (ervan uitgaande dat je dezelfde hebt als ik, namelijk een 1068e). Die controller negeert gewoon spindown commando's... niet meer en niet minder...

LSI heeft (dacht ik, weet het niet meer zeker) aangegeven dat ze die functie ook niet in willen bouwen, maar dat die functie voorbehouden is aan de nieuwe(re) controllers, bijvoorbeeld de LSI2008, hun meestgebruikte 6Gbps chipset.

[Anoniem: 15758]

Net even geprobeerd op mijn USAS-L8i en daar werkt het inderdaad ook niet op. Blijft over dat je APM gebruikt voor automatische spindown; wat onafhankelijk gebeurt van de controller of het OS. Dus even op je onboard SATA aankoppelen, APM inschakelen en weer terugzetten. Dat zou moeten werken, op voorwaarde dat je schijven APM ondersteunen.

Persoonlijk vind ik de winst voor green schijven minimaal, en de last om elke keer 15 seconden te wachten voordat er wat gebeurt als je wat aanklikt te groot. Maar ieder zijn eigen afweging natuurlijk; wel jammer dat spindown dus kennelijk niet werkt met LSI 1068E; dat wist ik nog niet.

[FireDrunk]

Dat was al wel langer bekend, is ook meermalen langsgekomen, maar ja, helaas pindakaas... Dat is voor mij ook wel balen... Ik hoop dat mijn onboard sas controller het wel kan, binnenkort maar eens gaan testen.

[Kriss1981]

Heb ergens gelezen dat ZFS v28 nu ook voor FreeBSD 8.2 beschikbaar is. Ik heb alle ports op mijn systeem geupdate, maar krijg nog steeds te zien dat ZFS v15 het hoogst beschikbare versienummer is.

Nu komt ik met google op een patch uit, maar heb geen idee hoe ik dit moet installeren.
Kan iemand mij vertellen hoe ik dit doe of misschien is er ergens een HOWTO die ik nog niet gevonden heb.

[Anoniem: 15758]

FreeBSD 8.2 is een release; daar wordt niets meer aan veranderd. Wel zijn er patches die op 8.2 of 8-STABLE kunnen worden uitgevoerd, en daarbij ZFS v28 support toevoegen. Dat zijn experimentele patches die al een tijdje beschikbaar zijn. Daarvoor moet je weten hoe je een kernel en world kunt compileren en installeren.

Dat is dus geen taak voor een beginnende FreeBSD gebruiker en mag als experimenteel worden aangemerkt. Eindgebruikers moeten gewoon wachten tot ZFS v28 beschikbaar is in een release; 8.3 of 9.0. Dan weet je zeker dat ZFS voldoende getest is en je veilig over kunt.

De portstree is er voor add-on software; niet om het besturingssysteem te updaten. Als je persé ZFS v28 op FreeBSD wilt draaien, kun je een FreeBSD 9-CURRENT snapshot proberen. Die zijn uiteraard ook experimenteel. Alhoewel ZFS v28 al aardig draait bij mij, zal ik het zeker weten nog niet gebruiken voor mijn echte data.

Veel mensen willen die hogere versie vanwege deduplication, om vervolgens achter te komen dat de resource-vretende dedup functionaliteit niets voor hen is maar vooral voor enterprise users met heel veel identieke data (300 Linux workstations levert aardig wat identieke datablokken op). ZFS v15 is een prima versie; het enige wat er in mist is ZFS log removal en forced imports met transaction group rollback, indien je pool beschadigd is of je SLOG device corrupt of afwezig is. Voor de rest zijn de veranderingen vrij subtiel, zeker voor 'casual users'. ZFS is van zichzelf al erg goed; geen reden om een experimentele alpha-versie te draaien IMO.

[raymonvdm]

Ik ben gisteren nog even bezig geweest en heb nu een volgende setup maar ik weet nog steeds niet of dit het is.

#	Product	Prijs	Subtotaal
1	LSI LSI SAS3081E-R-KIT	€ 0,-	€ 0,-
6	Samsung EcoGreen F4EG HD204UI, 2TB	€ 59,90	€ 359,40
1	Sharkoon Rebel9 Aluminium	€ 47,70	€ 47,70
1	Asus P5LD2-VM DH	€ 0,-	€ 0,-
1	S3 PCI VGA	--	--
2	1GB PC5300 DDR2 So-DIMM (Corsair, CMSS1GB-667SOD)	€ 0,-	€ 0,-
1	intel core2duo E2180	--	--
3	Cooler Master 4 in 3	--	--
1	Hitachi Deskstar 80gb	--	--
Bekijk collectie Importeer producten		Totaal	€ 407,10

Ik draai nu ESXi vanaf de 80GB ide disk. Met binnen ESXi een FreeBSD 32Bit FreeNAS vm. De disken heb ik via RDM doorgezet naar de FreeNAS machine. Dit werkt allemaal maar met het nadeel dat de disken niet kunnen downspinnen. De machine gebruikt op dit moment 100Watt

Ik ben nog aan het brainstromen (wellus,nietus enz) over wat nu de ultieme oplossing is

De alternatieve:

- Misschien toch maar een simpele AMD kopen en een losse NAS maken met de disken op het moederbord zodat deze disken kunnen downspinnen na 1H zodat dit 6 x 5 = 30 Watt verbruik scheelt. Daarnaast zal een nieuw moederbord/proc/mem ook zuiniger zijn maar zitten we met de aanschaf waarde.

- Voor dit systeem een los 775 moederbord kopen met 6+ SATA poorten en OpenSuse of OpenIndiana installeren en dan tochiets als VMware server op een 7e disk zodat de ZFS array kan downspinnen en de rest werkt vanaf een SSD/2.5" SATA disk/80GB ide disk

- Losse NAS kopen, nee dit wordt hem niet

[ Voor 14% gewijzigd door raymonvdm op 14-06-2011 09:22 ]

[Anoniem: 187449]

- of je niet zo druk maken om 30 watt (levensduur van je disk bij veelvuldig up/downspinnen)

[Kriss1981]

Anoniem: 15758 schreef op maandag 13 juni 2011 @ 21:42:

Dat is dus geen taak voor een beginnende FreeBSD gebruiker en mag als experimenteel worden aangemerkt. Eindgebruikers moeten gewoon wachten tot ZFS v28 beschikbaar is in een release; 8.3 of 9.0. Dan weet je zeker dat ZFS voldoende getest is en je veilig over kunt.

Bedankt weer voor deze heldere uitleg.
Dan wacht ik toch maar op een volgende release. Ik heb die extra features toch niet nodig.

Mijn configuratie draait nu een paar weken stabiel op ZFSguru, maar ik ga bij een volgende release van FreeBSD toch overstappen op FreeBSD en dan een root-on-ZFS installatie creëren met mfsBSD.
Dan ga ik alsnog een Intel SASUC8I bestellen. Ik kom nu een SATA poort te kort, omdat mijn Highpoint Rocket 620 toch echt niet werkt onder FreeBSD.

[Ultraman]

Zoals CiPHER al aangeeft is ZFS in FreeBSD 8.2-RELEASE op v15.
v28 zit in 9-CURRENT en is volgens mij ook geimporteerd in 8-STABLE. Op zich zou je dus naast 9-CURRENT ook kunnen kijken of het interessant is om je 8.2-RELEASE om te zetten naar 8-STABLE en te upgraden. Maar alleen als je het echt nodig hebt of om te experimenteren is het denk ik interessant. Dedup heeft een paar hoge eisen. Ik ben zelf nog aan het overwegen om het enkel voor jails te gebruiken, maar dmv nullfs mounts moet ik bijna hetzelfde kunnen bereiken volgens mij...

Kriss27 schreef op dinsdag 14 juni 2011 @ 10:55:
Ik kom nu een SATA poort te kort, omdat mijn Highpoint Rocket 620 toch echt niet werkt onder FreeBSD.

* Ultraman streepje zetten doet op zijn lijstje met mogelijk interessante hardware...

Ik ben hier bijna zo ver dat ik FreeBSD met ZFS daadwerkeljk ga inzetten. Moet het concept van jails nog even zien te masteren. Opzetten gaat OK, volgende stap is hoe je die op een efficiënte manier up-to-date houdt. Ik ga eens kijken of ezjail zo handig is als ik her en der lees.
Als mensen hier nog interessante/nuttige links of gewoon tips er over hebben hoor ik dat graag (over DM om de thread niet te vervuilen?).

[ Voor 25% gewijzigd door Ultraman op 14-06-2011 11:05 ]

[raymonvdm]

Ultraman schreef op dinsdag 14 juni 2011 @ 11:02:
Zoals CiPHER al aangeeft is ZFS in FreeBSD 8.2-RELEASE op v15.
v28 zit in 9-CURRENT en is volgens mij ook geimporteerd in 8-STABLE. Op zich zou je dus naast 9-CURRENT ook kunnen kijken of het interessant is om je 8.2-RELEASE om te zetten naar 8-STABLE en te upgraden. Maar alleen als je het echt nodig hebt of om te experimenteren is het denk ik interessant. Dedup heeft een paar hoge eisen. Ik ben zelf nog aan het overwegen om het enkel voor jails te gebruiken, maar dmv nullfs mounts moet ik bijna hetzelfde kunnen bereiken volgens mij...


[...]

* Ultraman streepje zetten doet op zijn lijstje met mogelijk interessante hardware...

Ik ben hier bijna zo ver dat ik FreeBSD met ZFS daadwerkeljk ga inzetten. Moet het concept van jails nog even zien te masteren. Opzetten gaat OK, volgende stap is hoe je die op een efficiënte manier up-to-date houdt. Ik ga eens kijken of ezjail zo handig is als ik her en der lees.
Als mensen hier nog interessante/nuttige links of gewoon tips er over hebben hoor ik dat graag (over DM om de thread niet te vervuilen?).

Ook ik kan vertellen dat zo`n Highpoint Rocket 620 kaartje niet werkt Gelukkig heb ik al een 8 poorts LSI op de kop weten te tikken

psst 620 je kopen ?

[ Voor 3% gewijzigd door raymonvdm op 15-06-2011 13:46 ]

[Ultraman]

Kansen genoeg gehad om er ook een te halen.
Maar dan moet ik er ook nog schijven halen om er eigenlijk gebruik van te maken, want mijn huidige zes schijven kunnen nog aan het moederbord.

Met andere woorden: het is me de investering nog niet waard. En ik wil naar 2+6 disken. 2 voor het OS en 6 voor datatank. Voorlopig nog 2+4 dus.
Ik heb nog genoeg ruimte voorlopig gelukkig

[Anoniem: 187449]

wat stil..word er niet meer geZFS 't

[Splendid]

Anoniem: 187449 schreef op zondag 19 juni 2011 @ 15:02:
wat stil..word er niet meer geZFS 't

Jawel, maar het ligt even stil. Ze schieten niet op met OI 151

[Anoniem: 187449]

Splendid schreef op maandag 20 juni 2011 @ 10:23:
[...]

Jawel, maar het ligt even stil. Ze schieten niet op met OI 151

uhh .. die draait hier al een paar weken

[ Voor 14% gewijzigd door Anoniem: 187449 op 20-06-2011 11:07 ]

[Splendid]

Anoniem: 187449 schreef op maandag 20 juni 2011 @ 11:06:
[...]


uhh .. die draait hier al een paar weken

Ja de BETA, STABLE is nog niet uit En als ik over ga van nexenta naar OI dan wil ik wel graag de stable gebruiken

[Anoniem: 187449]

Splendid schreef op maandag 20 juni 2011 @ 11:09:
[...]

Ja de BETA, STABLE is nog niet uit En als ik over ga van nexenta naar OI dan wil ik wel graag de stable gebruiken

enig idee wanneer die verwacht word ?

[Splendid]

Anoniem: 187449 schreef op maandag 20 juni 2011 @ 11:36:
[...]


enig idee wanneer die verwacht word ?

Ik verwacht hem toch wel deze week, maar goed dat dacht ik 2 weken geleden ook als je de lijst bekijkt van gedane zaken: http://wiki.openindiana.org/oi/oi_151