Het grote ZFS topic

[matty___]

Trishul schreef op donderdag 20 juni 2013 @ 23:20:
Waarschijnlijk een beetje offtopic, maar ik ben er zeer benieuwd naar:

http://www.vgleaks.com/so...station-4-os-development/

Het schijnt dus dat het PS4 OS FreeBSD 9.0 gebaseerd is. Betekend dit dan dat Sony bv. UFS of ZFS kan gebruiken? Ik weet dat het gaat om slechts 1 HDD, maar was benieuwd of het licentie-technisch mogelijk is, omdat er geloof ik ook een NAS fabrikant is dat ZFS als optie aanbiedt op haar systemen.

De reden dat ze Freebsd gebruiken is vanwege de licentie vermoed ik. Met Linux zou je je aanpassingen moeten delen wat een concurrentieverlies zou kunnen betekenen.

Wel raar dat ze grub gebruiken als bootloader. Als ze nu ook even 100k doneren aan de foundation en een deel van hun aanpassingen up stream geven dan zou dat wel een mooie boost zijn voor freebsd.

[webfreakz.nl]

FireDrunk schreef op vrijdag 21 juni 2013 @ 08:58:
Ze kunnen natuurlijk ook lui zijn en FAT32 gebruiken...

Dat is gelimiteerd tot een bestandsgrootte van 4GB. En ik dacht dat Microsoft wat gedoe met patenten had met FAT16/32 ? En FAT ondersteunt geen journaling.

[ Voor 5% gewijzigd door webfreakz.nl op 21-06-2013 10:48 ]

[FireDrunk]

Tja, het is waarschijnlijk goedkoper om frameworks te schrijven die de bestanden in stukjes knippen dan om licentie kosten af te gaan dragen

[Trishul]

Bedankt voor de antwoorden. Ik kwam er net achter dat de PS3 UFS met stevige encryptie eroverheen gebruikt (alleen te decrypten door de cell-hypervisor, is sha-1 4096b geloof ik). Best aannemelijk dat ze dan weer UFS gaan gebruiken i.p.v ZFS. ZFS lijkt me wel ideaal eigenlijk voor een PS4; vooral tegen bad sectors, recovery etc.

[FireDrunk]

Maar performance technisch niet handig, en 8GB RAM in je box hebben waarvan 4 alleen voor je filesystem is natuurlijk inefficient...

[Trishul]

Maar die 4GB is toch alleen noodzakelijk als je alle voordelen van ZFS wil hebben, toch (pre-fetch etc.)?
In ieder geval een interessante ontwikkeling. Heb vorig jaar naar tevredenheid ook ZFS gebruikt om m'n BSc scriptie veilig te stellen. Helaas heeft dat servertje momenteel moederbordproblemen, waardoor ik m'n MSc scriptie niet makkelijk kan veiligstellen. Anyways, binnenkort komt er weer een gloednieuwe servertje, ben er alleen nog niet uit of het freeNAS of ZFSguru wordt. Was wel tevreden over FreeNAS, liep even stabiel als m'n Qnap.

[jacovn]

jacovn schreef op dinsdag 07 mei 2013 @ 15:41:
Intel X520-DA2 werkt zonder issues direct in ZFSGuru
Simpele direct attach kabel van 60 euro ertussen en 10GE werkt als een speer.
Ik heb nu copy speed van mijn win 7 PC van 235 Mbyte/sec via samba. De windows PC is niet al te snel qua i/o met een HW raid-5 van 5x1 TB.

Ik had toch wel wat issues met de 10ge kaarten aan de praat te houden.
Op 1 server liep 1 interface goed, de amdere miet.

Na wat spitwerk in de log bleek dat er niet genoeg buffers warem om 10ge te kunnen gebruiken.

kern.ipc.nmbclusters=262144
kern.ipc.nmbjumbop=262144
Kern.ipc.nmbjumbo16=32000
Kern.ipc.nmbjumbo9=64000

Aangepast en alles loopt nu goed.


Wellicht handig voor iemand anders die met 10ge aan de slag wil.

[FireDrunk]

Misschien heeft dat ook wel zin voor mensen die ESXi draaien en gebruik maken van VMXNET3

[Neptunus]

Trishul schreef op vrijdag 21 juni 2013 @ 12:20:
Anyways, binnenkort komt er weer een gloednieuwe servertje, ben er alleen nog niet uit of het freeNAS of ZFSguru wordt. Was wel tevreden over FreeNAS, liep even stabiel als m'n Qnap.

Ook al eens naar nas4free gekeken?

[Pantagruel]

jacovn schreef op vrijdag 21 juni 2013 @ 15:03:
[...]

Ik had toch wel wat issues met de 10ge kaarten aan de praat te houden.
Op 1 server liep 1 interface goed, de amdere miet.

Na wat spitwerk in de log bleek dat er niet genoeg buffers warem om 10ge te kunnen gebruiken.

kern.ipc.nmbclusters=262144
kern.ipc.nmbjumbop=262144
Kern.ipc.nmbjumbo16=32000
Kern.ipc.nmbjumbo9=64000

Aangepast en alles loopt nu goed.


Wellicht handig voor iemand anders die met 10ge aan de slag wil.

Nice!

Alleen de kosten van een setje Intel X520-DA2 controllers. Zelfs op ebay altijd nog zo'n $300 't stuk, auw .

[jacovn]

Ja helaas, iets van 285 euro per stuk, en dan kabels van 60 euro ertussen.
Wel sneller, al hangt dat ook erg van de source af. Vanuit de ramdisk van mijn download pc gaat het wel lekker snel met iets van 450 MByte/sec

Ik moet ook nog de 2 servers testen met copy tussen hun. Dan moet ik maar kijken wat voor protocol ik ga gebruiken.

[analog_]

Trishul schreef op vrijdag 21 juni 2013 @ 11:55:
Bedankt voor de antwoorden. Ik kwam er net achter dat de PS3 UFS met stevige encryptie eroverheen gebruikt (alleen te decrypten door de cell-hypervisor, is sha-1 4096b geloof ik). Best aannemelijk dat ze dan weer UFS gaan gebruiken i.p.v ZFS. ZFS lijkt me wel ideaal eigenlijk voor een PS4; vooral tegen bad sectors, recovery etc.

sha-1 is een hashing algoritme, lijkt me dus sterk, alleen te decrypten door is nogal egostreling vanuit sony pr. Na 6 jaar is er nog steeds geen enkele ps3 (cell) titel die er beter uitzag dan de xbox360. Moraal v/h verhaal? Cell is veel praat weinig actie.

[Trishul]

analog_ schreef op vrijdag 21 juni 2013 @ 19:54:
[...]

sha-1 is een hashing algoritme, lijkt me dus sterk, alleen te decrypten door is nogal egostreling vanuit sony pr. Na 6 jaar is er nog steeds geen enkele ps3 (cell) titel die er beter uitzag dan de xbox360. Moraal v/h verhaal? Cell is veel praat weinig actie.

Offtopic, maar: Beyond: Two Souls, The Last of Us etc. zien er toch duidelijk beter uit dan de X360 games. Wordt ook bevestigd door de media en de gamers zelf... Maar je hebt voor de rest gelijk hoor, de X360 heeft de betere gpu. Maar de PS3 de betere cpu. Kijk maar eens naar de animaties en gezichtbewegingen in Heavy Rain, en de physics in Little Big Planet. Of de audio engine van Killzone 3 die op een dedicated SPE draait...

Neptunus schreef op vrijdag 21 juni 2013 @ 15:27:
[...]

Ook al eens naar nas4free gekeken?

Die kwam ik ook laatst tegen ja. Maar denk dat ik bij FreeNAS blijf, aangezien ik daar toch al goeie ervaringen mee heb na iets meer dan een jaar het gebruikt te hebben.

[Xudonax]

Ik heb nog even zitten spelen met mijn ZFS on Linux systeempje, en was benieuwd of de module onderhand automatisch de ARC een fatsoenlijke hoeveelheid geheugen gaf. Helaas is het antwoord zo te zien nee... Op mijn bak met 16GB RAM is er iets meer dan 2GB (2213281792 bytes) toegewezen aan de ARC als ik het goed lees. Aangezien de machine verder vrij weinig doet (ok, wat GUI werk en downloadbak) vind ik dit bijzonder weinig. Ik had "vroegâh" ~3.5GB ingesteld staan voor ARC, maar misschien is meer handiger gezien mijn idee om L2ARC te gaan gebruiken?

Wel ben ik van plan om twee 32GB SSDs* toe te voegen als L2ARC devices. Grofweg 16GB van beide SSDs wil ik gebruiken als caching voor mijn (nu nog) RAIDZ array van 500GB schijven welke als iSCSI het netwerk op gaan, en 8GB wil ik gaan gebruiken voor mijn algemene ZFS pool waar van alles en nog wat op gebeurd. Dit is een RAID-Z2 array op 1TB notebook schijven.

arcstats:

code:

$ cat /proc/spl/kstat/zfs/arcstats
4 1 0x01 80 3840 13306171878 2239903392262
name                            type data
hits                            4    2208179
misses                          4    150141
demand_data_hits                4    1831213
demand_data_misses              4    25616
demand_metadata_hits            4    210280
demand_metadata_misses          4    7113
prefetch_data_hits              4    166436
prefetch_data_misses            4    117127
prefetch_metadata_hits          4    250
prefetch_metadata_misses        4    285
mru_hits                        4    404322
mru_ghost_hits                  4    5938
mfu_hits                        4    1637265
mfu_ghost_hits                  4    2709
deleted                         4    51039
recycle_miss                    4    41
mutex_miss                      4    1
evict_skip                      4    1994
evict_l2_cached                 4    0
evict_l2_eligible               4    8418048000
evict_l2_ineligible             4    5850428416
hash_elements                   4    122949
hash_elements_max               4    123012
hash_collisions                 4    28020
hash_chains                     4    12676
hash_chain_max                  4    4
p                               4    6791958528
c                               4    8853127168
c_min                           4    1106640896
c_max                           4    8853127168
size                            4    8853229224
hdr_size                        4    41931968
data_size                       4    8769285120
other_size                      4    42012136
anon_size                       4    71467008
anon_evict_data                 4    0
anon_evict_metadata             4    0
mru_size                        4    6720446464
mru_evict_data                  4    6650462208
mru_evict_metadata              4    36741120
mru_ghost_size                  4    2131625472
mru_ghost_evict_data            4    2117730304
mru_ghost_evict_metadata        4    13895168
mfu_size                        4    1977371648
mfu_evict_data                  4    1967792128
mfu_evict_metadata              4    771072
mfu_ghost_size                  4    4393825792
mfu_ghost_evict_data            4    4386349056
mfu_ghost_evict_metadata        4    7476736
l2_hits                         4    0
l2_misses                       4    0
l2_feeds                        4    0
l2_rw_clash                     4    0
l2_read_bytes                   4    0
l2_write_bytes                  4    0
l2_writes_sent                  4    0
l2_writes_done                  4    0
l2_writes_error                 4    0
l2_writes_hdr_miss              4    0
l2_evict_lock_retry             4    0
l2_evict_reading                4    0
l2_free_on_write                4    0
l2_abort_lowmem                 4    0
l2_cksum_bad                    4    0
l2_io_error                     4    0
l2_size                         4    0
l2_hdr_size                     4    0
memory_throttle_count           4    0
duplicate_buffers               4    0
duplicate_buffers_size          4    0
duplicate_reads                 4    0
memory_direct_count             4    0
memory_indirect_count           4    0
arc_no_grow                     4    0
arc_tempreserve                 4    0
arc_loaned_bytes                4    0
arc_prune                       4    0
arc_meta_used                   4    163540648
arc_meta_limit                  4    2213281792
arc_meta_max                    4    163618768

* = Dit zijn inderdaad niet de beste SSDs, maar ze zijn relatief snel met lezen (~300MByte/s in benchmarks) en ze zijn goedkoop. Daarnaast zijn ze bedoeld voor caching, en dat is wat ik ermee doe, toch? Ook kan ik me niet voorstellen dat ze niet als gewone SATA devices gaan verschijnen, en zo wel dan heb ik een ander mooi doel voor ze en bestel ik andere SSDs.

[Mafketel]

ehm ... €74 voor die twee sandisks a 64Gb?

Zou je niet beter een 64Gb m4 of de laatste 830 voor €65 kopen.

[Neptunus]

Waarom is mijn benchmark trager met ZIL & L2ARC dan zonder. Voor mij is het een totaal raadsel!

Gebruikte disks:
- 10x Hitachi US7K3000 (SATA 600)
- 2x intel 320 (SATA 300)

Configuratie: 2x M1015 in IT met disks aangesloten als volgt:
- 5x Hitachi US7K3000 en 1x intel 320 verbonden met 1x M1015

Zonder ZIL & L2ARC
WRITE

code:

sideswipe:/mnt# dd if=/dev/zero of=zero.file bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 55.288349 secs (776830447 bytes/sec)

READ

code:

sideswipe:/mnt# dd if=zero.file of=/dev/null bs=1m
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 50.604693 secs (848729046 bytes/sec)

Met ZIL & L2ARC
WRITE

code:

sideswipe:/mnt# dd if=/dev/zero of=zero.file bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 75.277081 secs (570554442 bytes/sec)

READ

code:

READ
sideswipe:/mnt# dd if=zero.file of=/dev/null bs=1m
40960+0 records in
40960+0 records out
42949672960 bytes transferred in 61.050132 secs (703514828 bytes/sec)

[matty___]

Komt dat niet door het exclusieve gebruik van je RAM, wat natuurlijk sneller is dan een SSD.

[Compizfox]

Nee, L2ARC heet niet voor niets L2ARC. Het is de Level 2 Adaptive Replacement Cache. De L1ARC is je RAM en die blijft gewoon in gebruik bij een L2ARC. Je gooit er enkel een extra level achter, zodat je totale cache groter is. Maar de snellere L1ARC blijft natuurlijk een hogere prio hebben dan de L2ARC.

[Neptunus]

Compizfox schreef op zondag 23 juni 2013 @ 23:34:
Nee, L2ARC heet niet voor niets L2ARC. Het is de level 2 Adaptive Replacement Cache. De L1ARC is je RAM en die blijft gewoon in gebruik bij een L2ARC. Je gooit er enkel een extra level achter, zodat je totale cache groter is. Maar de snellere L1ARC blijft natuurlijk een hogere prio hebben dan de L2ARC.

Ja zo had ik het ook begrepen. Daarom snap ik er ook niets van. Heb ik ergens in mijn onschuld ergens door een configuratie fout een snelheids bottelnek gemaakt?

[FireDrunk]

Nee je snapt het principe niet. Sequentiele snelheden worden helemaal niet sneller door het gebruik van L2ARC en ZIL, eerder langzamer. De sequentiele schrijfsnelheid van je pool word waarschijnlijk afgeremd door de snelheid van je L2ARC. Je systeem wil de L2ARC vullen maar moet wachten totdat de SSD die data daadwerkelijk gecached heeft voordat hij verder kan gaan, dat gaat niet 100% asynchroon.

En qua ZIL, je Random writes worden sneller, niet je Sequentiele.
Test maar eens met een windows machine op een iSCSI ZVOL. Daar merk je pas het verschil.

[Neptunus]

FireDrunk schreef op maandag 24 juni 2013 @ 09:09:
Nee je snapt het principe niet. Sequentiele snelheden worden helemaal niet sneller door het gebruik van L2ARC en ZIL, eerder langzamer. De sequentiele schrijfsnelheid van je pool word waarschijnlijk afgeremd door de snelheid van je L2ARC. Je systeem wil de L2ARC vullen maar moet wachten totdat de SSD die data daadwerkelijk gecached heeft voordat hij verder kan gaan, dat gaat niet 100% asynchroon.

En qua ZIL, je Random writes worden sneller, niet je Sequentiele.
Test maar eens met een windows machine op een iSCSI ZVOL. Daar merk je pas het verschil.

Thanks voor je uitleg. Gisteren avond verder gelezen in documentatie over ZFS. Zelf vermoede ik misschien wel dat ik een bandbreedte beperking zou hebben op mijn sata poorten. Aan de andere kant kon ik me dat weer niet voorstellen.

Kwam ook nog een opmerking tegen: probeer een benchmark te doen met meer random karakter. Gebruik bv. iozone. Verder moet je zorgen dat sync=always on op de dataset actief is.

Ik vraag me nu alleen een beetje af of ZIL en L2ARC wel zin hebben in mijn configuratie en mijn manier van gebruiken. Ik ga de ZFS pool alleen gebruiken om documenten/movies/mp3 te sharen met NFS en CIFS. Natuurlijk wordt er ook data naar de pool geschreven door verschillende gebruikers.

[FireDrunk]

sync=always is klets, dat is helemaal niet nodig. Dat zorgt er voor dat write opdrachten die async zijn geforceerd synchroon weggeschreven worden. Applicaties kunnen prima zelf bepalen wanneer ze synchrone of asynchrone opdrachten gebruiken, daar moet je zelf niet aan sleutelen.

Wat je sowieso kan doen is je logbias veranderen (zpool set logbias=throughput [poolnaam]).
Daarmee vertel je ZFS dat als het synchrone transfers doet, het de disk moet gebruiken en niet je ZIL, dat versnelt de sequentiele transfers. Wel word je random IO iets trager omdat het in eerste begint op je disks, en pas naar je ZIL switcht als het merkt dat het om Random IO gaat dacht ik.

Exacte waarheden moet je even opzoeken op internet, maar iig kan je de logbias setting veranderen, dat zou al moeten schelen.

ZIL is voor een gewone NAS functie inderdaad overbodig, L2ARC is op zich leuk icm spindown, je data kan dan van SSD af komen terwijl je disks gewoon idle blijven. (Mits de data die je opvraagt op L2ARC staat uiteraard)

[Phuncz]

Nu eens een niveau'tje of 3 lager:

Binnenkort begin ik ook eens met mijn eigen ZFS NAS, heb wel al geprutst met ander materiaal maar nu is het voor thuis

Momenteel heb ik het volgende in mijn PC:
2x 1TB HDD's (WD EAVS)
2x 2TB HDD's (WD EARS)

De bedoeling is die schijven te verhuizen naar de NAS en er een paar 3TB HDD's (WD EZRX) bij te kopen. Is het verstandig om gebruik te maken van mirroring in die situatie ?

Ik wil de 1TB en 2TB disks in de toekomst wel vervangen als ze defect zijn, maar heb weinig interesse om nu perfect werkende disks weg te gooien want veel zijn ze niet waard buiten garantie.

De bedoeling is max. 6 disks want meer laat mijn behuizing momenteel niet toe, evenals het moederbord.

[Xudonax]

Je kunt een aantal dingen doen, afhankelijk van welk OS je wilt gebruiken:

Een 1TB mirror, een 2TB mirror en een 3TB mirror in één pool
Lekker simpel en veilig, maar een beetje weggooien van schijfruimte IMO

Een 1TB mirror en een RAID-Z setup op je 2TB en 3TB disks
Vervang later je 2TB disks door 3TB disks om te zorgen voor een totaal van 9TB vrije ruimte ipv 6TB. Als je 1TB schijven kapot gaan dan kun je de vervanging hiervoor blijven gebruiken als een mirror.

Op FreeBSD: Gebruik het GEOM framework. Op Linux: Gebruik MD
Maak met het GEOM framework van FreeBSD (en FreeNAS, ZFSGuru, ...) van steeds één 1TB en 2TB disk een 3TB volume, en voeg deze samen met je nieuwe 3TB schijven toe in een RAIDZ setup. Eenzelfde iets kan met Linux en md verwacht ik.

Dat zijn in mijn ogen de 3 meest bruikbare situaties

[Phuncz]

Sowieso ga ik BSD gebruiken, ik heb al ervaring met FreeNAS maar ik ben bereid NAS4Free en ZFSguru te proberen, maar nog geen idee welke beter is voor mijn doel. Ik ga het systeem énkel gebruiken als NAS, mogelijk in de toekomst wil ik er een linux VM onder gaan draaien maar dat is momenteel niet nodig (heb daar een simpel servertje voor).

Als ik alles mirror ben ik idd. 50% storage space kwijt, maar dat heb ik nu ook dus ik vind het niet zo erg.

De tweede oplossing lijkt me ongewoon, ik dacht dat dit niet zomaar ging, de zpool expanden ?

De derde oplossing lijkt me minder omdat de kans op falen hoger ligt dankzij de dubbele failure rates voor de 1+2TB vdevs.

Ik geloof wel dat 6 disks optimaal is voor RAID-Z2, niet ?

[Remcor2000]

Phuncz schreef op maandag 24 juni 2013 @ 19:36:
Nu eens een niveau'tje of 3 lager:

Binnenkort begin ik ook eens met mijn eigen ZFS NAS, heb wel al geprutst met ander materiaal maar nu is het voor thuis

Momenteel heb ik het volgende in mijn PC:
2x 1TB HDD's (WD EAVS)
2x 2TB HDD's (WD EARS)

De bedoeling is die schijven te verhuizen naar de NAS en er een paar 3TB HDD's (WD EZRX) bij te kopen. Is het verstandig om gebruik te maken van mirroring in die situatie ?

Ik wil de 1TB en 2TB disks in de toekomst wel vervangen als ze defect zijn, maar heb weinig interesse om nu perfect werkende disks weg te gooien want veel zijn ze niet waard buiten garantie.

De bedoeling is max. 6 disks want meer laat mijn behuizing momenteel niet toe, evenals het moederbord.

Beide 1tb schijven met Raid0 tot 1 2tb schijf maken. Daarna heb je dus 3x 2tb schijven en deze in een Raid Z1 zetten. Daarna kan je de schijven vervangen met de 3x 3tb schijven.

Heb t zelfde gedaan met 2x 250gb in raid 0, en 2x gb. Een tijd later heb ik de 2x 250gb vervangen voor 1 500gb schijf. En vorige week de 500gb schijven weer vervangen voor 2tb schijven.

Werkte voor mij als een prima oplossing.

[Xudonax]

De tweede oplossing is niet zo ongewoon Pool expanden kan wel, maar heeft wat mitsen en maren.

Je kunt de beschikbare ruimte vergroten door al je disks te vervangen door grotere exemplaren, of door een extra volume aan je pool toe te voegen. Je kunt alleen geen devices aan een volume toevoegen, dus als je een RAIDZ van 4 disks hebt, kun je daar geen 5e aan toevoegen. Als je een pool hebt met daarin een RAIDZ volume, kun je daar best nog een RAIDZ volume (of een andere manier van opslag) aan toe voegen, en je pool word hierdoor groter.

EDIT: Mijn twee caching SSDs toegevoegd, 2x 16GB voor de pool fcpx en 2x 8GB voor de pool tank. Zo te zien is ZFS ze al vrolijk aan het volschrijven met wat gemiddeld gebruik Nu moet ik wel zeggen dat op fcpx op dit moment primair een scrub draait omdat een disk wat issues geeft waardoor de cache niet héél erg gebruikt word.

In performance merk ik er vrij weinig van, maar het is iig sneller dan mijn L2ARC op basis van 4 el-cheapo USB sticks Ook word de cache nu een stuk meer gebruikt dan toen, maar dat zal wel met de snelheid/latency te maken hebben

code:

$ sudo zpool iostat -v 
                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
fcpx                                           494G   898G  2.18K     11  17.3M  32.7K
  raidz1                                       494G   898G  2.18K     11  17.3M  32.7K
    ata-SAMSUNG_HD501LJ_S0MUJ1MP850217            -      -  1.37K      6  9.63M  18.2K
    ata-ST3500820AS_5QM2E5LN                      -      -    713      6  10.3M  18.2K
    ata-ST3500820AS_5QM2GSKG                      -      -    722      6  10.3M  18.2K
cache                                             -      -      -      -      -      -
  ata-SanDisk_SDSSDRC032G_131172400266-part1  4.78M  16.0G      0      0    651  1.49K
  ata-SanDisk_SDSSDRC032G_131172400708-part1  10.6M  16.0G      0      0  1.25K  3.29K
--------------------------------------------  -----  -----  -----  -----  -----  -----
tank                                          2.53T  2.91T     87     42  10.5M  2.01M
  raidz2                                      2.53T  2.91T     87     42  10.5M  2.01M
    ata-HGST_HTS541010A9E680_JB100013J2RP1A       -      -     34     13  1.91M   558K
    ata-HGST_HTS541010A9E680_JB100013J3ST5B       -      -     30     13  1.83M   555K
    ata-HGST_HTS541010A9E680_JB100013J3TXGB       -      -     29     14  1.58M   559K
    ata-HGST_HTS541010A9E680_JB100013J422JB       -      -     32     13  1.68M   558K
    ata-HGST_HTS541010A9E680_JB100013J4HGNB       -      -     31     13  1.91M   556K
    ata-HGST_HTS541010A9E680_JB100013J4J15B       -      -     33     13  1.88M   559K
cache                                             -      -      -      -      -      -
  ata-SanDisk_SDSSDRC032G_131172400266-part2  3.21G  4.79G      0      8  57.1K  1017K
  ata-SanDisk_SDSSDRC032G_131172400708-part2  5.60G  2.39G      1     14  90.2K  1.73M
--------------------------------------------  -----  -----  -----  -----  -----  -----

[ Voor 71% gewijzigd door Xudonax op 24-06-2013 23:41 ]

[Extera]

jacovn schreef op maandag 04 februari 2013 @ 13:56:
nou dit performed tenminste normaal. 6 x 3 TiB HDD;

ZFSguru 0.2.0-beta8 (9.1-004) pool benchmark
Pool : movietanl (16.3T, 1% full)
Test size : 64 GiB
normal read : 1 GB/s
normal write : 619 MB/s
I/O bandwidth : 24 GB/s


Transfer rate naar de server tot 105 Mbyte/sec met windows slepen van de PC naar de shared drive.

Ik ben er ook achter gekomen waarom 1 hdd zoveel errors had, defecte poort op de M1015, want 3 verschillende kabels, en zelfde probleem. Weer iets wat RMA mag..

Ik denk dat ik het zelfde probleem heb...
Ik krijg ook deze error:

(Probe258:mps1:0:3:0): INQUIRY. CDB: 12 0 0 0 24 0 lenght 36 SMID <oplopend nummer> terminated ioc 804b scsi 0 state c xfer 0

Heb 1 disk RMA gestuurd, maar met de nieuwe disk heb ook problemen.

Zijn jou problemen opgelost na het vervangen van de controller?

Ik ga van de week uitgebreider testen, ik ga de controller nog even in een ander systeem testen, en ga de disks even testen aan een andere controller (Highpoint RR 2340 )

[jacovn]

Het was de M1015 inderdaad. 1 sata poort defect. RMA gestuurd en een andere gekregen.

Later nog een brakke backplane in mijn norco, en nog 2 hdds met cable errors.
Ze doen het echter prima, maar ze vallen op in het overzicht van zfsguru met rode cijfers.

[Midas.e]

Management wil graag (wij ook ) nieuwe storage voor een aantal vm machines, nu wil ik eigelijk wel dit op ZFS gaan draaien. Als base system zal een 4U systeem met 24 hotswap disks worden gekozen.

qua hardware maakt het nu even niet uit, maar wel hoe de raidsets worden gemaakt, ik zat zelf te denken aan een vdev per 6 schijven (1 cluster gezien vanaf de voorkant) en deze weer in een raidz1, dat lijkt mij het meest efficient qua snelheid met natuurlijk losse l2arc en zil ssds.
Is dat zo aan te raden of juist niet?

[FireDrunk]

Je kan niet kiezen op welke manier vdev's aan elkaar geknoopt worden, meerdere VDEV's in 1 pool zijn altijd RAID0.

Je moet dus 4 vdev's maken die zelf in RAIDZ staan.

[Midas.e]

Zou dit qua performance een beetje meekomen in dat geval? (ja ik ben dus echt een ZFS newbie nog)

#	Product	Prijs	Subtotaal
1	Intel Core i5 3570K Boxed	€ 189,90	€ 189,90
1	ASRock B75 Pro3-M	€ 56,-	€ 56,-
24	Western Digital Green WD20EARX, 2TB	€ 84,85	€ 2.036,40
1	Norcotek RPC-4224	€ 487,03	€ 487,03
1	GeIL Evo Leggera GEL332GB1866C10QC	€ 204,90	€ 204,90
1	HP SAS Expander Card	€ 209,33	€ 209,33
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 118,58	€ 118,58
1	Intel 320 120GB	€ 0,-	€ 0,-
Bekijk collectie Importeer producten		Totaal	€ 3.302,14

Schijven zouden nog naar 3TB's kunnen gaan mocht dit qua performance beter kunnen, heeft ZFSGuru nog iets van HA mogelijkheden?

Als eerste zou dit als demo/test model komen zodat we kunnen zien wat we kunnen verwachten van ZFS icm VMware ESXi via iscsi/NFS

[ Voor 2% gewijzigd door Midas.e op 01-07-2013 14:27 . Reden: uitleg ]

[Nism0]

weet iemand wat het verschil is van het recoveren van een disk in een mirror root pool met:

# zpool offline rpool c1t0d0s0
# cfgadm -c unconfigure c1::dsk/c1t0d0
<Physically remove failed disk c1t0d0>
<Physically insert replacement disk c1t0d0>
# cfgadm -c configure c1::dsk/c1t0d0
<Confirm that the new disk has an SMI label and a slice 0>
# zpool replace rpool c1t0d0s0
# zpool online rpool c1t0d0s0
# zpool status rpool
<Let disk resilver before installing the boot blocks>
SPARC# installboot -F zfs /usr/platform/`uname -i`/lib/fs/zfs/bootblk /dev/rdsk/c1t0d0s0
x86# installgrub /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c1t9d0s0

Of gewoon zpool rpool detach en attach?

Het laatste lukt mij namelijk veel makkelijker en de uitkomst lijkt me hetzelfde?

[Extera]

jacovn schreef op maandag 01 juli 2013 @ 13:01:
Het was de M1015 inderdaad. 1 sata poort defect. RMA gestuurd en een andere gekregen.

Later nog een brakke backplane in mijn norco, en nog 2 hdds met cable errors.
Ze doen het echter prima, maar ze vallen op in het overzicht van zfsguru met rode cijfers.

Dank voor je antwoord zo te lezen heb jij ook best wat opstartprobleempjes gehad
Zojuist weer wat aan het testen geweest (kan helaas alleen remote bij mijn setup op dit moment).
Ik heb de IBM aan een Windows bak gehangen, en daar worden van de disks slechts 4 gezien in schijfbeheer, erg vreemd, ik heb 3 schijven aan port 1, en 2 schijven aan port 2 gehangen.

Anyway, ik zie 3888 bad sectors op 1 van de schijven, en 13816 bad sectors op de andere.
De schijf welke ik in deze VM niet herken heeft denk ik ook problemen (deze is notabene al omgeruild).

Even een domme vraag misschien: Maar bad sectors kunnen toch nooit komen door een defecte controller, of daardoor worden veroorzaakt?

[ Voor 3% gewijzigd door Extera op 01-07-2013 17:04 ]

[syl765]

@nism0

De uitkomst is inderdaad hetzelfde.
Ik weet alleen niet of je een defecte schijf kunt detachen?
Misschien zit daar het verschil.
Ik heb laatst de schijven van 1 TB vervangen door 2 TB schijven en heb hiervoor gewoon de detach en attach optie gebruikt.
Alles werkt gewoon en heb de mirrors gewoon weer terug.

gr
Johan

[Nielson]

Midas.e schreef op maandag 01 juli 2013 @ 14:26:
Zou dit qua performance een beetje meekomen in dat geval? (ja ik ben dus echt een ZFS newbie nog)
[knip]

Ervanuit gaande dat je niet gaat overklokken heeft een K-cpu niet zoveel nut, de normale is iets goedkoper en je krijgt er als bonus nog VT-d bij. Geheugen zou ik gewoon DDR3-1600 doen, bv tweemaal deze. Waarom geen S1150/Haswell trouwens?

[jacovn]

Ik heb nog een algemene vraag, wellicht verkeerde topic, maar hoe copieer ik het snelste/beste tussen 2 zfsguru severs ?
Er zit een 10 ge verbinding tussen. Is gewoon het mappen van de samba/cifs share goed genoeg, of kan ik beter met ftp of zo proberen ?

[Midas.e]

rsync of NFS met mv zou ik denk ik zelf eerder kiezen?

[Nism0]

syl765 schreef op maandag 01 juli 2013 @ 17:05:
@nism0

De uitkomst is inderdaad hetzelfde.
Ik weet alleen niet of je een defecte schijf kunt detachen?
Misschien zit daar het verschil.
Ik heb laatst de schijven van 1 TB vervangen door 2 TB schijven en heb hiervoor gewoon de detach en attach optie gebruikt.
Alles werkt gewoon en heb de mirrors gewoon weer terug.

gr
Johan

Hee Johan,
Goed om te horen dat het bij jou ook werkt.
Als niemand anders dit kan tegenspreken dan is deze methode vele malen makkelijker om schijven in zijn geheel te vervangen..
Ik had trouwens de schijf verwijderd in een vmware omgeving en toen een nieuwe schijf aangemaakt en die toegevoegd.

[Nism0]

jacovn schreef op maandag 01 juli 2013 @ 19:22:
Ik heb nog een algemene vraag, wellicht verkeerde topic, maar hoe copieer ik het snelste/beste tussen 2 zfsguru severs ?
Er zit een 10 ge verbinding tussen. Is gewoon het mappen van de samba/cifs share goed genoeg, of kan ik beter met ftp of zo proberen ?

ZFS send and receive

[FireDrunk]

Idd, de enige valide manier om remote zfs te gebruiken.

[sphere]

Is er hier iemand met een werkende setup met ESXi of Xen, en dan FreeBSD of wat dan ook in een guest? Ik wil graag ZFS, maar ik wil ook graag Linux houden voor xbmc. Maar uiteindelijk zit ik niet te wachten op corruptie via de achterdeur omdat ik via een hypervisor ga kloten

[FireDrunk]

HyperBart heeft het momenteel draaien, en ik heb het ook vaak (en lang) genoeg gehad.
ESXi werkt prima als hypervisor voor ZFS, zolang je maar VT-d gebruikt om je controller met schijven door te geven. Je moet dus geen VMFS gebruiken.

[sphere]

Ah ok. Nog maar even wat geld bij elkaar harken voor hitachi's en hopen dat vaapi dan ook ondersteund wordt.

[FireDrunk]

Uh? Wat wil je met VAAPI?

[jacovn]

FireDrunk schreef op maandag 01 juli 2013 @ 23:24:
Idd, de enige valide manier om remote zfs te gebruiken.

Het gaat om film directorys, dus geen hele volumes. Het is niet voor backup bedoeld.

Ik wil alle films zonder nl ondertitels van een server op de andere zetten.

Eerst maar een test met een samba share:

mount_smbfs -I 192.168.4.1 //192.168.4.1/share /unraid
Dat lukt goed, maar de overdracht is 17,25 MB/sec (unraid was een mountpoint/folder uit de tijd dat ik van dat waardeloze product overstapte naar zfs)


Met een NFS mount moet ik data naar de server copieren, want zenden mag blijkbaar niet wegens de standaard rechten.

[root@zfsguru /]# mount -t nfs 192.168.4.1:/Movietank3/share /unraid
Overdracht 138 MB/sec


Als ik op mijn PC op de 2 servers een share open en de file overcopieer haal ik ook 132 MB/sec.

[ Voor 51% gewijzigd door jacovn op 02-07-2013 11:12 ]

[sphere]

FireDrunk schreef op dinsdag 02 juli 2013 @ 01:20:
Uh? Wat wil je met VAAPI?

offtopic:
XBMC.

[ Voor 8% gewijzigd door sphere op 02-07-2013 08:29 ]

[FireDrunk]

sphere schreef op dinsdag 02 juli 2013 @ 08:28:
[...]

offtopic:
XBMC.

Oh sorry, ik zit te slapen, ik dacht dat het om de VMWare API's ging

[WaRSTeaM]

Nou ik was al aan het twijfelen om over te gaan op een ZFS systeem en na gisteren heb ik besloten om de stap te nemen.
Ik had een windows server machine met een Areca ARC-1680iX-24 met 20 2TB disks in 2 array's.
- Array 1 RAID 6 12x 2TB
- Array 2 RAID 5 8X 2TB

Alle disken zijn WD Green schijven waarvan de firmware met Widdle is aangepast en TLER nog gefixed kon worden.

Na een verhuizing alles weer opgebouwd en om de een of andere reden een aantal disk dropouts gehad. paar weken aan recovery moeten doen en alles is weer up and running. Was helemaal gelukkig dat mijn volledige omgeving weer online was zonder verlies van DATA.

En toen dacht ik gisteren even lekker een episode in MKV format te kijken..... dubbel klik, file open, groen korrelig scherm, geen sound, geen playback.... Uhmm oke. nouja zal wel aan die ene episode liggen. Ep 2 dan maar openen.. same story...
Random wat verschillende MKV bestanden geopent en ja hoor. 90% van alles wat ik aan MKV heb (bijna 16TB) is corrupt
En dit heb ik al eens eerder gehad met een 4 TB array.. Denk je een dure Areca kaart met RAID 6 te hebben heb je er in het eind nog geen drol aan. MKV repair is er eigenlijk niet dus zeg maar bye bye collectie!!!

ZFS it will be for me. Ben zo klaar met de huidige brakke RAID oplossingen. Dan maar een paar honderd investeren in een nieuw systeem voor ZFS en maar weer opnieuw beginnen. Spare time, Not anymore I guess.

Enige waar ik nog een beetje mee zit is het bare systeem zelf (Mobo- proc- mem) Ik heb nog 24 disken liggen om verder uit te breiden dus kom ik in totaal op 44 disken uit in 1 systeem. Denk dat ik met ZFS niet meer wegkom met een simpel ASUS mobotje met ingebakken CPU en 4GB mem. (Voor Windows had ik hier o.a. die dikke Areca kaart voor)

Suggesties voor een (liefst zo energie zuinig mogelijk) bare system?
(Ja ik hoor jullie denken, Energie zuinig bare system maar er vervolgens wel 44 disken aan hangen.... Ja klopt! Alle kleine beetjes helpen! )

[FireDrunk]

Nou, dat valt wel mee, je kan prima een budget systeem met ZFS draaien hoor. Enige wat je dan krijgt is dat je server het wat druk heeft op het moment dat je veel doet met je array, en dat relatieve CPU belasting om GBit vol te krijgen wat hoog ligt, maar werken doet het wel hoor.

Met een G1610, de meest budget CPU vandaag de dag, en (in mijn ogen) veel bang voor buck, kan je prima ZFS draaien.

Enige nadeel is dat je veel controllers moet kopen om al die 44 disks aan te sluiten.

Bedenk goed voor je zelf hoeveel disks je daadwerkelijk aan wil sluiten, dan kunnen we hier een beter beeld vormen over wat er precies nodig is.

Soms is het zelfs goedkoper om wat disken te verkopen, en grotere disken terug te kopen.
Die disken hoeven an sich neit goedkoper te zijn, maar als je daarmee controllers uitspaart ben je in the long run wel goedkoper uit.

[jacovn]

+1 voor FireDrunk.
Ik ben van allemaal losse hdds overgegaan naar een kleiner aantal 3 en 4 TB.

Van de laatste serie (500, 1TB, 1.5TB en 2 TB) heb ik 38 TB aan hdd's verkocht en 30 TB (10x3) teruggekocht en moest er 150 euro bij leggen. (dat waren samen denk ik 35-40 hdds)
Ooit het idee gehad al die oude hdds in unraid servers te zetten voor zo min mogelijk kosten, maar door frustatie nu uitgekomen op zfsguru machines met IBM M1015 kaarten en een stuk minder hdd's

[WaRSTeaM]

Nou ik behoud mijn ARECA kaart wel (en heb een Chenbro CK12804 24x SAS-/SATA-Expander) waardoor ik nu al door kan gaan tot 48 disks zonder de SATA poorten van m'n mobo te gebruiken.
Er zit het volgende in:

Dus ik kan wel even vooruit als ik dat zo zie. Denk dat als ik m'n geheugen vergroot dat ik er aan heet eind kom.
Voorlopig heb ik nu alleen nog GB ethernet liggen dus de CPU zal voldoende kracht hebben.

Verder wil ik de huidige config zeker weer online hebben in ZFS (minimaal 2 pools waarvan er 1 RAIDZ2 zal zijn met 12 disks.) Daar kan ik voorlopig mee vooruit. De andere disk zal ik opdelen in andere pools. Zit te denken aan 2 RAID-Z2 pools van 12 disks. Wil eigenlijk neit meer disks in 1 pool hebben. 2x uitval met 12 disks vind ik echt op het randje eigenlijk.

Edit;
Advies om naar minder maar grotere disks te gaan had ik ook overwogen maar gezien de prijs die ik betaal voor 2TB disks zit dat er nog even niet in.

[ Voor 8% gewijzigd door WaRSTeaM op 02-07-2013 11:57 ]

[FireDrunk]

Die Areca kaart is niet geschikt voor ZFS, daar ga je ook problemen mee krijgen.

De Expander is eventueel wel te hergebruiken, maar dan moet je er een andere basiscontroller voor hangen. Een M1015 kan prima met SAS Expanders om gaan.

Overigens kan je zelfs met 4GB prima ZFS gebruiken, alleen heb je geen prefetchen (data alvast vanaf disk laden in geheugen om te anticiperen op wat er gevraagd gaat worden door users).

Maar daar merk je met 1 user niet super veel van. Je write performance zal wel iets lager zijn, omdat ZFS minder in RAM kan cachen voordat het verplicht naar disk moet schrijven.

[ Voor 44% gewijzigd door FireDrunk op 02-07-2013 12:24 ]

[Extera]

Je kan meerdere vdev aanmaken onder 1 pool.

Je krijg dan je pool, met daar onder:
vdev 12x 2TB zraid2 20TB netto
vdev 12x 2TB zraid2 20TB netto
vdev 12x 2TB zraid2 20TB netto

Je pool is dan 60TB netto (minus overhead)
die kan je dan weer opdelen in datasets om overzicht te behouden.

Enige nadeel is dat je schijf aantallen niet optimaal zijn, uit de startpost:

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

[jacovn]

ZFSGuru (FreeBSD) gebruikt veel geheugen als je met data aan de slag gaat.
Ik copieer nu een paar TB over en dan zitten beide systemen op 70+ % van het geheugen voor de kernel. (18 en 23 GB)

[WaRSTeaM]

FireDrunk schreef op dinsdag 02 juli 2013 @ 12:23:
Die Areca kaart is niet geschikt voor ZFS, daar ga je ook problemen mee krijgen.

.........

Waarom zou ik problemen met deze Areca kaart krijgen? Ik kan de schijven namelijk gewoon als Pass-Through Disk configureren dus geen Hardware raid via de areca kaart. Het OS ziet ze dan allemaal als losse disks en kan daar (In het geval van ZFS) pools van maken. Ik gebruik de areca kaart dan alleen voor Pass-Through en niet voor RAID. (Ja oke je hebt volkomen gelijk als je zegt dat de kaart daar VEELS te duur voor is!)
Maarja het lieft wil ik dan weer een kaart terug met +20 SAS/SATA poorten. Als ik dan b.v. kijk naar een Highpoint (Waar ik eigenlijk al niet kapot van ben) kaart met 20+ poorten dan praten we ook al gauw over €700,--/€800,-- per stuk
Dan is me dat allemaal niet waard (Lees Areca verkopen, goede nieuwe kaart zoeken en kopen)
Heb nog 2 andere Areca kaarten liggen (1x 12 ports SATA & 1x 8 Poorts SATA ) die ik evt ook nog kan inzetten. Ook zonder RAID en puur als Pass-Through.

Zoals je eht nu schets zou ik dus beter af zijn door de 3 kaarten te verkopen en een aantal M1015 kaarten te kopen (Als dan niet i.c.m. de SAS expanders)

[FireDrunk]

jacovn schreef op dinsdag 02 juli 2013 @ 12:58:
ZFSGuru (FreeBSD) gebruikt veel geheugen als je met data aan de slag gaat.
Ik copieer nu een paar TB over en dan zitten beide systemen op 70+ % van het geheugen voor de kernel. (18 en 23 GB)

Dat is logisch, dat heet caching, dat doet elk modern Operating System.

Zelfs al zou je een Windows 2012 Server met 512GB geheugen aan het werk zetten, kan je zien dat er als je 1TB aan data verplaatst je ook gewoon 500GB aan geheugen in gebruik hebt.

WaRSTeaM schreef op dinsdag 02 juli 2013 @ 13:04:
[...]

Waarom zou ik problemen met deze Areca kaart krijgen? Ik kan de schijven namelijk gewoon als Pass-Through Disk configureren dus geen Hardware raid via de areca kaart. Het OS ziet ze dan allemaal als losse disks en kan daar (In het geval van ZFS) pools van maken. Ik gebruik de areca kaart dan alleen voor Pass-Through en niet voor RAID. (Ja oke je hebt volkomen gelijk als je zegt dat de kaart daar VEELS te duur voor is!)
Maarja het lieft wil ik dan weer een kaart terug met +20 SAS/SATA poorten. Als ik dan b.v. kijk naar een Highpoint (Waar ik eigenlijk al niet kapot van ben) kaart met 20+ poorten dan praten we ook al gauw over €700,--/€800,-- per stuk
Dan is me dat allemaal niet waard (Lees Areca verkopen, goede nieuwe kaart zoeken en kopen)
Heb nog 2 andere Areca kaarten liggen (1x 12 ports SATA & 1x 8 Poorts SATA ) die ik evt ook nog kan inzetten. Ook zonder RAID en puur als Pass-Through.

Zoals je eht nu schets zou ik dus beter af zijn door de 3 kaarten te verkopen en een aantal M1015 kaarten te kopen (Als dan niet i.c.m. de SAS expanders)

De Areca gooit schijven met bad sectors offline, dat is helemaal niet nodig, want ZFS kan dat prima zelf oplossen. Je moet ook niet naar Highpoint kijken. Bovendien moet je maar hopen dat de kaart SMART waardes doorgeeft, want ook die heb je nodig.

De enige goede kaarten zijn kaarten gebaseerd op LSI chipsets met SAS1068, SAS2008, of SAS2308 chipsets. Er zijn nog een paar andere budget alternatieven (ASMedia 1061 bijvoorbeeld) maar die leveren niet genoeg poorten.

[jacovn]

Je hebt voor een M1015 minimaal een PCI-E 2.0 x4 (electrisch) en x8 mechanisch nodig.
Als je er 3 wilt plaatsen moet je wel deze sloten vrij hebben..

Je AMD chipset lijkt 22 PCI-E lanes te hebben, maar op de Asus site staat:
2 x PCIe 2.0 x16 (blue @ x16 mode,gray @ x4 mode)
1 x PCIe x1
3 x PCI

Daar gaan dan maar 2 stuks M1015 in.

[ Voor 39% gewijzigd door jacovn op 02-07-2013 13:35 ]

[FireDrunk]

Hij kan ook een tweede SAS expander kopen...

[WaRSTeaM]

FireDrunk schreef op dinsdag 02 juli 2013 @ 13:27:
[...]

De Areca gooit schijven met bad sectors offline, dat is helemaal niet nodig, want ZFS kan dat prima zelf oplossen.

Ik kan de ARECA ook op JBOD modus zetten en had ook al gelezen dat SMART doorgeven geen probleem is i.c.m. FreeBSD.

BUT:

Ik zei al dat ik er helemaal klaar mee was dus ben meteen met de stoute schoenen het internet op gegaan. Resultaat:
Gekocht: 2X IBM M1015
Gekocht: 1X Chenbro CK12804
Gekocht: 1X Norco RPC-4224

Al in bezit:
1X RPC-4220
1X Chenbro CK12804

(Kon het niet laten)

Even voor de goede orde, dit is wat ik van plan ben:
- Mobo SATA wordt gebruikt voor 1x 80GB SSD voor OS en 1X DVD drive
- PCI-E slots worden gevuld met de IBM M1015
- 1 IBM 1015 wordt voorzien van 2x Chenbro CK12804 voor HDD connecties

Ik zet mijn "Oude" Areca kaart voorlopig in mijn Game pc en connect daar de bestaande RAID array's op. De nieuwe server wordt voorzien van de laatste ZFSguru build en bouw daar een RAIDZ2 config met 10x 2TB disk op. Daar zet ik alles wat ik nog heb op de bestaande 12x 2TB array op en faseer deze areca array uit. De HD's die vrij komen worden gebruikt om een 2de RAIDZ2 config te maken met 10x 2TB disken.
De 2de array op de Areca kaart die vol staat met goede DATA (Niet corrupt) zet ik dan over. Dan heb ik weer 8 disken vrij en bouw een 3de RAIDZ2 10x 2TB config.
Alles wat ik dan nog over heb ga ik pas inzetten als ik storage nodig heb en "geld over" heb voor nog 2x een Chenbro CK12804 om de 2de IBM M1015 mee te vullen. Ook zal ik dan weer in de buidel moeten tasten om nieuwe Norco cases te halen.

De 20Bay norco case dient voor de main 2 array's, SSD en DVD drive en mobo + voeding. Deze gaat in mijn 22U HP rackcabinet. De overige Norco cases worden direct achter de fans, welke weer achter het PCB van de HDD zitten, afgezaagd. (Een plaatje zegt zo veel meer als woorden:)


Deze gaan dan in een 19 patchkast (Je al gemeten en past perfect qua diepte, en in de hoogte kan ik er 3 kwijt en nog iets ruimte over houden, zeg 2U over) welke weer middels externe SAS kabels aan m'n host komen te hangen.

Denk dat ik voorlopig nog wel even onder de pannen ben

(heb overigens nog 2X een 80Gb Intel SSD liggen die ik evt voor caching kan usen middels de poorten op het MB of zie ik dat verkeerd?)

Edit:
Nog even een side note @ FireDrunk; Ik zag bij je laatste post pas je Handtekening en was blij dat ik al naar de WC was geweest anders had ik in m'n box geplast van het lachen! Valt onder het kopje; It's funny cause... IT's TRUE! )

[FireDrunk]

Ik denk dat je even met CiPHER moet praten, die heeft vroegah veel met Areca's gewerkt, en die dingen vervloekt...

Ze zijn veel te agressief in het het offline gooien van disks, en dat is icm met ZFS niet handig. Maar goed, je bent vrij om het te proberen...

Verder:

Kan je die cases niet gewoon zo kopen ipv afzagen?

http://www.norcotek.com/category.php?id=8

[ Voor 6% gewijzigd door FireDrunk op 02-07-2013 21:31 ]

[jacovn]

Hmm dan vraag ik me af waar de voeding dan moet komen?

[WaRSTeaM]

Zal het in mijn achterhoofd houden! Tnx for the direction. Maar voor nu even niet meer nodig. Inmiddels toch al besloten om voor een IBM 1015 oplossing te gaan. Spullen immers al gekocht Areca kaarten verkoop ik wel weer door. Hecht meer waarde aan mijn data en de betrouwbaarheid ervan dan aan mijn areca kaarten

Ik had idd bij Norco (En hun duitse variant Inter-Tech) gekeken naar oplossingen waarbij ik niet hoef te modden. Hebben ze wel maar betaal dan ook meteen 2 tot 3x zo veel. Meeste van die cases zitten al expanders in (en niet de gene die ik wil hebben of met te veel externe aansluitingen (1 per 4 drives) waar ik alsnog om heen moet werken). Ja oke je hebt gelijk 24 disken over 1 kabel; sounds like single point of failure.... maar het is voor thuis gebruik (Oke oke extreem uit de hand gelopen hobby) dus dat zit voor mij wel goed.

En anders kom je uit op een halve case met 3x 5in3 bay drives. 15 disks per case... humm 15... waarom kom ik dat getal toch zo weinig tegen in de IT...
Ik wil perse een veelvoud van 4 hebben. Mss af en toe een beetje old school gedachte maar goed.

@Javovn;
Voeding komt gewoon in de main case. Zeer zware versie en per case gebruik ik 1 12V rail welke ik middels Molex buiten de main case breng. Zit nog te denken om evt een losse voeding aan te schaffen en deze afzonderlijk aan te sluiten. Heb eigenlijk alleen de 12V rails nodig dus vond het eigenlijk overbodig. Maar daar moet ik zeker nog even een aantal keer een rekensom op los laten en even de pros en cons vergelijken. En als je gaat rekenen valt het allemaal best mee: niet al te zware MB en Proc, geen extra Videokaart, de PCI-E kaartjes en Expanders vragen ook niet zo heel veel. HD's vragen alleen tijdens spin-up hun piek (Meer als tijdens full load (Piek vermogen)) en ik wil de fans van alle cases behalve de main case apart aansluiten. Deze laat ik gelijk met de koeling van de patchkast lopen welke apart gevoed wordt. Dat stelt niet zo heel veel voor maar haalt wel weer load weg van de Main PSU.

Ik zal zeker in het grote RAID show-off topic e.e.a. gaan posten als ik dit project een keer af krijg dus dan zul je misschien beter begrijpen hoe of wat. Zal echter in het begin met 2 Norco cases minder worden.. Vaste lasten worden er tegenwoordig ook niet minder op helaas en er staat ook nog een koopwoning in het verschiet.. (Altijd leuk z'n hobby)

Tot op heden in ieder geval top voor het advies. Heeft me zeker wel op een aantal zaken gewezen en advies van andere bronnen naast me neer doen leggen. Helemaal m.b.t. het type HBA!!!

[jacovn]

Die norco 19" kasten 422x kasten zijn best wel lang/diep inderdaad.
Ik heb 2 stuks in een norco 19" open rack hangen, (ze staan op een soort bord wat voor en achter vast zit) en dat past allemaal maar net in mijn home cinema ruimte achter de bank.

Dat afzagen is wellicht niet eens zo'n slecht idee.. Alleen heb ik 2 complete servers, en dan heb je al 4x 4U hoogte gelijk:)

[Nism0]

Weet iemand of ik verschil ga merken tussen registered of unbufferend geheugen? (80TB Enterprise ZFS doos)

*edit

Xeon E5-1620 CPU

[ Voor 12% gewijzigd door Nism0 op 04-07-2013 21:56 ]

[FireDrunk]

Nism0 schreef op donderdag 04 juli 2013 @ 21:52:
Weet iemand of ik verschil ga merken tussen registered of unbufferend geheugen? (80TB Enterprise ZFS doos)

*edit

Xeon E5-1620 CPU

Ja dat weet ik en nee dat merk je niet.
Unbuffered gaat alleen minder ver. En voor registered geheugen zit je vast aan Sockets C32, G34, 1366 of 2011.

Qua performance scheelt het niet behalve als je veel quad ranked geheugen gebruikt.

[Nism0]

FireDrunk schreef op donderdag 04 juli 2013 @ 22:13:
[...]

Ja dat weet ik en nee dat merk je niet.
Unbuffered gaat alleen minder ver. En voor registered geheugen zit je vast aan Sockets C32, G34, 1366 of 2011.

Qua performance scheelt het niet behalve als je veel quad ranked geheugen gebruikt.

Ok mooi, dan kunnen we 16GB repen nemen

[Kridri]

Weet iemand of er een bsd distro is de zfs ondersteunt op de arm instructieset.

[FireDrunk]

Zfs is eigenlijk 64bit only, en alleen bij gods gratie werkbaar te krijgen onder 32 bit. ARM kan je daarom denk ik vergeten...

[StygMa]

Heeft de hoeveelheid werkgeheugen drastisch invloed op de transfer rates van en naar een windows bak?

Ik heb nu raidz1 met 3x 3TB green WD schrijven met Freenas draaiend op een Intel Pentium G620 met 4 gig werkgeheugen. Ik verwacht niet dat hij mijn gigabit compleet vol trekt, maar ik zit nu rond de 30-35 MB/s en ik hoop toch wel het dubbele zeker te halen. Kan dit aan de hoeveelheid geheugen liggen of zit er ergens anders dus een probleem. (16 staat wel op de planning)

[ Voor 3% gewijzigd door StygMa op 06-07-2013 20:12 ]

[Snow_King]

FireDrunk schreef op vrijdag 05 juli 2013 @ 15:14:
Zfs is eigenlijk 64bit only, en alleen bij gods gratie werkbaar te krijgen onder 32 bit. ARM kan je daarom denk ik vergeten...

Ofwel, afwachten tot ARMv8 eindelijk komt met dus 64-bit support. Hopelijk zien we die hardware in 2014.

[FireDrunk]

StygMa schreef op zaterdag 06 juli 2013 @ 20:10:
Heeft de hoeveelheid werkgeheugen drastisch invloed op de transfer rates van en naar een windows bak?

Ik heb nu raidz1 met 3x 3TB green WD schrijven met Freenas draaiend op een Intel Pentium G620 met 4 gig werkgeheugen. Ik verwacht niet dat hij mijn gigabit compleet vol trekt, maar ik zit nu rond de 30-35 MB/s en ik hoop toch wel het dubbele zeker te halen. Kan dit aan de hoeveelheid geheugen liggen of zit er ergens anders dus een probleem. (16 staat wel op de planning)

Ja, bij 4GB of minder staat prefetching uit. Bij > 4GB krijg je prefetching, wat een hoop scheelt qua performance.

---

Vandaag mijn Opteron omgebouwd in een andere kast en voorzien van zo ongeveer alle meuk die ik nog had liggen.

Config:

Opteron 4164EE (1.8Ghz 6-core)
4*16GB DDR3 ECC Registered geheugen.
Intel 1000 VT Quad port NIC
LSI 1068E Controller met:
2*73GB 10K SAS disks
2*73GB 15K SAS disks

IBM M1015 Controller met:
4* Intel G2 80GB SSD

(onboard):
1 * 256GB Samsung 830 SSD
1 * 128GB Samsung 840 Pro SSD

Vandaag ESXi geinstalleerd, en een ZFSguru VM gemaakt met 3 pools.
1 RAID0 pool van de 80GB SSDs
1 Mirror Pool van de 10k schijven
1 Mirror Pool van de 15k schrijven

ZFSguru VM heeft VMXNET3 en toch is de performance om te janken...


Van boven naar beneden:

SSD Pool
10k pool
15k pool

De 4 SSD's zouden sequentieel meer dan 300MB/s moeten schrijven. De SAS disks doen ook ruim 125MB/s Schrijven per stuk sequentieel.

Ik vind het maar raar dat ZFS zo'n ongelofelijke write penalty heeft...

[ Voor 41% gewijzigd door FireDrunk op 07-07-2013 00:26 ]

[Verwijderd]

Wat zie je met gstat, doen je schijven ook sequentiëel of zitten ze te seeken? Heb je ook getest of het inderdaad aan ZFS ligt, door hetzelfde te doen op een tmpfs share? Misschien ligt het wel iets met interrupts en ESXi. Veel performance issues zie ik in combinatie met ESXi-virtualisatie. Genoeg dingen die mis kunnen gaan die funest zijn voor de prestaties.

Verder: gebruik je iSCSI of NFS of SMB/CIFS?

[matty___]

bijzonder. Ik doe moet huis tuin en keuken servertje met 4x1TB in raid10 en 8GB en intel nic, rond de 100 read/write op een iscsi share en afp share. SMB is wat langzamer.

Gebruik geen ZFSguru maar vanilla FreeBSD (daar zal het niet aan liggen) en geen virtualisatie.

[Verwijderd]

Geen virtualisatie verandert natuurlijk alles. Als Firedrunk geen ESXi zou gebruiken, zouden waarschijnlijk alle performanceproblemen verdwenen zijn. Dat betekent niet dat ESXi niet snel kan presteren, maar wel dat er altijd issues kunnen zijn die de performance ernstig benadelen. ESXi is een proprietaire virtualisatieengine en dat gaat meestal niet optimaal samen met open source, met name FreeBSD want die combinatie is toch erg zeldzaam onder commerciële gebruikers. Waarschijnlijk wordt vooral Linux getest en issues die dan boven komen drijven worden gefixed, maar issues in combinatie met FreeBSD juist weer niet.

Ik ben altijd al kritisch geweest over ESXi; het is niet mijn ding. Eigenlijk vind ik ook dat FireDrunk zichzelf een dienst zou moeten bewijzen en voor de beste setup te gaan: een aparte ESXi bak en aparte ZFS bak. Zit je alleen met de NICs maar dat kun je wellicht met 10GbE of InfiniBand oplossen. Dat zou denk ik zijn setup versimpelen en een heleboel potentiële issues de nek omdraaien.

Het enige wat je kunt doen met ESXi is eindeloos combinaties uitproberen en proberen het probleem te isoleren. Maar er zijn zoveel verhalen, ook in combinatie met Solaris en ook Linux. Ik word daar soms een beetje hopeloos van.

[FireDrunk]

Ik heb ook een losse NAS hoor, het is alleen dat ik een homelab in 1 doos aan het maken ben (met een eigen netwerksegment). Er komen heel wat VM's op (vandaar de 64GB geheugen) en het leek mij handig om een dedicated NAS te hebben voor die VM's lokaal op de machine zelf.

Of ik nou ESXi gebruik met ZFS op dezelfde machine via NFS, of op mijn dedicated NAS, het haalt niets uit qua snelheden. ZFS is gewoon een stuk trager dan elk ander filesystem, en dat vind ik nogal balen... Ik weet ook wel dat ZFS voordelen heeft die een hoop andere filesystems niet hebben, maar de performance impact die je terugkrijgt is gewoon belachelijk in sommige gevallen.

ESXi gebruiken op een ZFS backend is gewoon een real-life scenario wat gewoon moet werken. Als het ligt aan de sync perikelen van ESXi icm NFS en ZFS moeten ze daar eens wat meer focus op leggen bij de development, want 30MB/s op een array die normaal ruim 300MB/s doet, is gewoon waardeloos...

@CiPHER, ik zal morgen eens gstat bekijken als de benches lopen. Overigens gebruik ik altijd NFS. iSCSI vind ik waardeloos in vergelijking tot de vrijheid die NFS biedt...
Bovendien is de iSCSI configuratie in ZFSguru (en uberhaupt op FreeBSD) nodeloos ingewikkeld.

[ Voor 10% gewijzigd door FireDrunk op 07-07-2013 02:26 ]

[Q]

@FireDrunk

FF stomme vraag: werk je met hardware pass-through dat je die schijven + controller aan een virtuele NAS VM geeft?

Ik begrijp je setup niet helemaal, zou je dat toe willen lichten? Ik begrijp dat je ESXi bak 64 RAM heeft en ook een sloot lokale storage. Die lokale storage wordt niet als datastore geformatteerd, maar wordt aan een VM gegeven die als NAS/NFS share dienst doet en waarop je de datastore plaatst? In plaatst van de data rechtstreeks op de hardware te stoppen plaats je de datastore dan op ZFS.

Klopt dit?

[ Voor 61% gewijzigd door Q op 07-07-2013 12:29 ]

[sphere]

Op zoek naar een oorzaak vond ik nog FireDrunk in "Zuinige ESXi Server" en toen https://blogs.oracle.com/roch/entry/nfs_and_zfs_a_fine

Maar goed, ESXi met een bsd client voor zfs die dan weer de storage ontsluit via een networked fs lijkt vrij populair, dus niet iedereen zal een performance hebben die om te huilen is? Wat halen anderen met een dergelijke setup?

Zeg 6x 5x00 schijven zonder ZIL en L2ARC? Heeft iemand informatie over hoe snel andere clients van ESXi bij data kunnen van de ZFS client? Lijkt me dat dat sneller kan dan via een machine die over gigabit bij het netwerk fs wil.

[FireDrunk]

Q schreef op zondag 07 juli 2013 @ 12:18:
@FireDrunk

FF stomme vraag: werk je met hardware pass-through dat je die schijven + controller aan een virtuele NAS VM geeft?

Ik begrijp je setup niet helemaal, zou je dat toe willen lichten? Ik begrijp dat je ESXi bak 64 RAM heeft en ook een sloot lokale storage. Die lokale storage wordt niet als datastore geformatteerd, maar wordt aan een VM gegeven die als NAS/NFS share dienst doet en waarop je de datastore plaatst? In plaatst van de data rechtstreeks op de hardware te stoppen plaats je de datastore dan op ZFS.

Klopt dit?

Klopt, ik heb een virtuele ZFSguru VM die de 2 controllers via VT-d door krijgt gegeven.

En dat verhaal over sync geld vooral voor random IO, en wat minder voor sequentieel...
En het verschil zou niet een factor 20 moeten zijn (7MB/s ipv 140MB/s).

Over de toedracht van de setup, ik had al die hardware nog liggen, dus ik heb maar een homelab server in elkaar geknutseld

[ Voor 6% gewijzigd door FireDrunk op 07-07-2013 14:12 ]

[Verwijderd]

Even een klein vraagje tussendoor mbt zfsguru:

Als ik een pool wil benchtesten, krijg ik de volgende melding:

An unexpected exception occurred. When asking for help about this issue, please write down the message below.

ERROR: test filesystem Data/zfsguru-performance-test already exists, please remove manually!

rm geprobeerd, maar dit werkt niet. Ook niet als root. Zijn er toevallig nog andere manieren om de folder te verwijderen?


________

Maar goed, ESXi met een bsd client voor zfs die dan weer de storage ontsluit via een networked fs lijkt vrij populair, dus niet iedereen zal een performance hebben die om te huilen is? Wat halen anderen met een dergelijke setup?

In eerste instantie haalde ik ook iets van 15MB/s, nu zo'n 700-800. (Ik gok dat VMXNET3 nu de beperkende factor is.) Ik heb iets met NFS synchronous writes uitgeschakeld, als ik me niet vergis. Het kan wel corruptie veroorzaken bij stroomuitval. Maar daarvoor heb ik een UPS aan de server hangen die het geheel netjes afsluit.

[ Voor 38% gewijzigd door Verwijderd op 07-07-2013 14:18 ]

[FireDrunk]

is het wel een folder en niet gewoon een filesystem?

zpool status -v

[Verwijderd]

ik zie alleen maar de zpools 'Data' en 'installatie'. Een ls /Data laat wel /zfsguru-performance-test zien naast /files en /esxidatastore. Maar die map is gewoon leeg.

Bij rm -rf /Data/zfsguru-performance-test krijg ik de melding 'device busy'

[ Voor 19% gewijzigd door Verwijderd op 07-07-2013 14:37 ]

[FireDrunk]

Sorry, het is:

 zfs list 

Ik ben nog niet wakker...

[Verwijderd]

code:

NAME                                   USED  AVAIL  REFER  MOUNTPOINT
Data                                  12.9T  28.5T   279K  /Data
Data/ESXiDataStore                     137G  28.5T   137G  /Data/ESXiDataStore
Data/Files                            12.8T  28.5T  12.8T  /Data/Files
Data/zfsguru-performance-test          329K  28.5T   329K  /Data/zfsguru-performance-test
installatie                           7.03G   806M    34K  /installatie
installatie/share                       31K   806M    31K  /installatie/share
installatie/zfsguru                    535M   806M    33K  /installatie/zfsguru
installatie/zfsguru-performance-test  6.50G   806M  6.50G  /installatie/zfsguru-performance-test
installatie/zfsguru/9.1-005            535M   806M   141M  legacy
installatie/zfsguru/9.1-005/usr        390M   806M   390M  legacy
installatie/zfsguru/9.1-005/var       3.65M   806M  3.17M  legacy
installatie/zfsguru/9.1-005/var/log    500K   128M   500K  legacy
installatie/zfsguru/SWAP                16K   806M    16K  -
installatie/zfsguru/download            31K   806M    31K  /installatie/zfsguru/download
installatie/zfsguru/services            63K   806M    32K  /installatie/zfsguru/services
installatie/zfsguru/services/9.1-005    31K   806M    31K  /installatie/zfsguru/services/9.1-005

Met umount -f en daarna rm -rf kon ik de directory wel verwijderen, maar ik krijg nog steeds dezelfde error - al had ik hier waarschijnlijk beter even mee kunnen wachten.

[ Voor 6% gewijzigd door Verwijderd op 07-07-2013 14:53 ]

[FireDrunk]

Precies, er is dus een filesystem met die naam...

Even naar het tabje filesystems gaan in zfsguru, selecteren, en dan helemaal rechts onderin op destroy filesystem klikken.

LET OP welke je selecteerd, het is gevaarlijk...

[Verwijderd]

Je bent geweldig, nu kan ik eindelijk een benchmark uitvoeren sinds ik een tweede zpool heb toegevoegd!

En de goede selecteren zal wel lukken, een ezel stoot zich geen twee keer aan dezelfde steen.

[Q]

FireDrunk schreef op zondag 07 juli 2013 @ 14:11:
[...]


Klopt, ik heb een virtuele ZFSguru VM die de 2 controllers via VT-d door krijgt gegeven.

En dat verhaal over sync geld vooral voor random IO, en wat minder voor sequentieel...
En het verschil zou niet een factor 20 moeten zijn (7MB/s ipv 140MB/s).

Over de toedracht van de setup, ik had al die hardware nog liggen, dus ik heb maar een homelab server in elkaar geknutseld

Test eens met Linux (ubuntu/debian) + ZFS on Linux + NFS, zo opgezet en dan kun je uitsluiten of het bijvoorbeeld aan BSD ligt in combo met ESXi.

[FireDrunk]

Dat is wel een plan, was toch al van plan om eens met BTRFS te gaan testen. Kan ik dat mooi op dezelfde VM doen.

Overigens heb ik net met Sync uit getest, en de SSD's performen dan een stuk beter: 300MB/s lezen, en 200MB/s schrijven.

Maar de SAS schijven zijn nog steeds niet vooruit te branden... Die doen nog steeds maar 7MB/s seq schrijven.

[ Voor 70% gewijzigd door FireDrunk op 07-07-2013 17:03 ]

[Q]

FireDrunk schreef op zondag 07 juli 2013 @ 17:02:
Dat is wel een plan, was toch al van plan om eens met BTRFS te gaan testen. Kan ik dat mooi op dezelfde VM doen.

Overigens heb ik net met Sync uit getest, en de SSD's performen dan een stuk beter: 300MB/s lezen, en 200MB/s schrijven.

Maar de SAS schijven zijn nog steeds niet vooruit te branden... Die doen nog steeds maar 7MB/s seq schrijven.

Als de SSDs niet op de zelfde controller zitten dan zou dat eea kunnen verklaren?

[FireDrunk]

De SSD's zitten op een M1015, en de SAS schijven zitten op een LSI1068 Controller.
De LSI1068 is vast langzamer, maar niet ZO veel...

[StygMa]

Hoe krijg ik die paste knop en shell size in Freenas (8.3.1) ? In Chrome en FF geeft hij het niet weer. Of kan ik handmatig makkelijk de default size veranderden in de shell/menu?

[ Voor 7% gewijzigd door StygMa op 07-07-2013 21:07 ]

[FireDrunk]

Juist nu ik lekker met een stabiele setup aan het testen ben, lijkt het erop dat 1 van de SSD's de geest gegeven heeft... To be continued dus nog maar even...

[sphere]

Misschien ook wel de reden dat het zo slecht performde ipv ZFS onder virtualisatie.

[FireDrunk]

Nee, ik heb constant alle logs bekeken, en dat ging goed.
Zojuist de hele controller doorgegeven aan Windows en met CrystalDiskInfo alle SSD's bekeken, en ze zijn allemaal 100% in orde. Het lijkt eerder een probleem van Ubuntu te zijn icm MDADM (dat was ik aan het testen op dat moment).

Onder Windows 2012 eens zitten spelen met Storage Pools, en in de VM haal ik lokaal ietsiepietsie meer:



Ik ga eens een Windows 2012 Storage Pools server inrichten met iSCSI en kijken hoe dat performt...

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

[Nism0]

Iemand enig idee wat deze fout codes precies betekenen op beide ZFS bakken?

[ Voor 7% gewijzigd door Nism0 op 08-07-2013 13:35 ]

[FireDrunk]

Wat zegt google?

[Nism0]

noppes

[ Voor 15% gewijzigd door Nism0 op 08-07-2013 14:21 ]

[DrFlash]

Ik ben toch wel erg tevreden met m'n snelheid van m'n raid, in m'n testen (1k en 4k blocksize) zit ik rond de 300 tot 350Mb/s schrijfsnelheid, en dat over 9 schijven (3x raid-z). Dat zijn toch nette scores ?

[FireDrunk]

Mwoh, watvoor schijven zijn het?

[Q]

DrFlash schreef op maandag 08 juli 2013 @ 16:13:
Ik ben toch wel erg tevreden met m'n snelheid van m'n raid, in m'n testen (1k en 4k blocksize) zit ik rond de 300 tot 350Mb/s schrijfsnelheid, en dat over 9 schijven (3x raid-z). Dat zijn toch nette scores ?

Dat is ~100MB/s per RAID-Z en dat is niet zo heel snel, maar inderdaad: hangt een beetje van de schijven af.