[Sammelthread] ZFS Stammtisch

So, die Overlandkiste hat sich erledigt. Unter OI und OmniOS seh ich keine Möglichkeit die Kiste sauber anzubinden. Die LUNs werden zwar gesehen, aber bei schreibenden Operationen (format, fdisk,etc.) ka..t mir das komplette OS ab. Selbst unter Windows musste ich mit speziellen Treibern hantieren, aber dann läufts dort super... Dumm ist nur, ich hab keine dauerhafte Windowskiste, an der ich den Speicher bräuchte. Also wird die Kiste demnächst (ohne HDD) in der Bucht auftauchen...

Da ich aber dennoch viel auf FC setze, hab ich immernoch ein Problem:
Hat jemand schon mal einen 4GBit-FC-HBA per VT-d in ESXi 5.1 durchreichen können? Meine ersten Versuche in OI verliefen negativ. Daher dachte ich, es läge an meinem fehlenden Fachwissen und ich probierte es mal mit Windoofs. Leider auch negativ. :heul: Nur gelbe Ausrufezeichen im Gerätemanager.
Ich hätte zur Verfügung Emulex LPe11002, versch. Qlogic QLE24xx und QLE220 oder 2GBit QLA23xx.
Ich konnte leider bisher nur erlesen, dass es mit Emulex LPe1200x gehen soll. Sowas feines hab ich aber nicht.
Boards, auf denen ichs versucht habe:
Intel S5520HC und ASRock X58 Supercomputer
Hat vielleicht doch einer ne Idee?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Da meine Frage etwas untergegangen ist:
Wenn ich ein Backup auf eine externe ZFS Platte mache, muss ich irgendwas beachten beim entfernen?
Unmount?

Pool exportieren -> Platte entfernen
Platte einstecken - > Pool importieren

Es wird ja außerdem immer gesagt, dass für ZFS ECC wichtig ist. Ist ZFS ohne ECC unsicherer als andere Dateisysteme?

Auch ohne ECC ist ZFS sicherer als andere Dateiesysteme.
Allerdings wird jeder Rechner mit ECC noch sicherer als ohne da Speicherfehler entdeckt werden.

Mit ZFS wird das so oft betont weil
- ZFS besonders sicher ist (so in der Art: Wenn ich schon Airbag habe, will ich auch ESP)
- ZFS den gesamten Speicher als Cache nutzt (Das machen heute aber praktisch alle Systeme - wenn meist auch nicht so effektiv wie ZFS)
 
Eine Frage: bringt es irgendwelche Vorteile wenn man copies=2 oder sogar 3 auf dem rpool setzt? Klar ist ein Mirror besser, aber wenn man eine 200GB HDD nur für den rpool hat, spricht doch nix dagegen oder? 1) Bringt das Performance-Nachteile? 2) Klar hilft es nicht gegen ein HDD-Ausfall, aber wenn mal der unwahrscheinliche Fall passiert, dass eine wichtige Datei auf dem rpool korrupt ist, nimmt ZFS automatisch die noch intakte zweite copie oder? (somit besser als nichts oder^^)
 
Zuletzt bearbeitet:
Eine Frage: bringt es irgendwelche Vorteile wenn man copies=2 oder sogar 3 auf dem rpool setzt? Klar ist ein Mirror besser, aber wenn man eine 200GB HDD nur für den rpool hat, spricht doch nix dagegen oder? 1) Bringt das Performance-Nachteile? 2) Klar hilft es nicht gegen ein HDD-Ausfall, aber wenn mal der unwahrscheinliche Fall passiert, dass eine wichtige Datei auf dem rpool korrupt ist, nimmt ZFS automatisch die noch intakte zweite copie oder? (somit besser als nichts oder^^)

Ja, wenn durch welchen Grund auch immer ein Bit auf der Platte kippt oder ein Sektor nicht mehr lesbar ist, ohne dass die Platte komplett ausfällt, dann hilft copies.
 
Hab grad wiedermal erfolgreich OmniOS (OmniOS_Text_bloody_20130208.iso) in VMware 5.1 installiert. Nur zur Info: das virtuelle Floppy wird weiter zur Installation benötigt. VMwareNotes
 
Hast du dein iSCSI Target unter Windows schon komplett mit NTFS normal formatiert, oder hast du nur Quickformat gemacht? Wie hast du das iSCSI Target genau eingerichtet? Ich hab unter Solaris + Comstar über 115 MB/s beim schreiben im normalen Gigabit LAN.

wie im forum beschrieben:
1. thin pro LU
2. target
3. target group
4. view


formatiere grade in der plattenverwaltung(nicht schnell) für 24% brauchte er 1 1/2 stunden ;(

Ciao,
david
 
Hallo ZFS'ler,

ich bin gerade dabei, mir mit Nas4Free ein ZFS-NAS aufzubauen. Ich benötige vorwiegend NFS (zum hosten von KVM VM's), AFP + TimeMachine und SMB.

Meine Hardware:
- Intel DQ67SW mit i5-2500T
- 24 GB RAM
- 2x Hitachi 3TB (5K3000 / HDS5C3030ALA630)
- 1x Samsung SSD 840 Pro 256GB (nur um ZIL & Cache zu testen)
- 1x USB Stick für das NAS-System

Zum testen hab ich aktuell "Nas4Free 9.1.0.1 - Sandstorm (Revision 636)" installiert.
Die beiden Festplatten laufen als Raid-1 (mirror), evtl. noch zwei SSD's für ZIL-Mirror & Cache (wenn es denn Sinn macht).

Hier mal ein paar Test-Daten:
nas4free:~# zpool status
pool: raid1-pool
state: ONLINE
scan: resilvered 33.8G in 0h7m with 0 errors on Sun Mar 17 00:16:55 2013
config:

NAME STATE READ WRITE CKSUM
raid1-pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada2 ONLINE 0 0 0

errors: No known data errors

Mit dieser Config habe ich folgende Werte (gemessen mit "AJA System Test" / File-Size 1GB):

AFP -> write: 67 MB / read: 103 MB
SMB -> write: 69 MB / read: 79 MB
NFS -> write: 30 MB / read: 99 MB




Dann hab ich mal die Samsung-SSD mit 2 Partitionen bestückt (1GB für ZIL, Rest für Cache):
nas4free:~# zpool status
pool: raid1-pool
state: ONLINE
scan: resilvered 33.8G in 0h7m with 0 errors on Sun Mar 17 00:16:55 2013
config:

NAME STATE READ WRITE CKSUM
raid1-pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada1 ONLINE 0 0 0
ada2 ONLINE 0 0 0
logs
ada0p1 ONLINE 0 0 0
cache
ada0p2 ONLINE 0 0 0

errors: No known data errors

Hiermit erreiche ich folgende Werte:

AFP: write: 84 MB / read: 101 MB
SMB: write: 77 MB / read: 79 MB
NFS: write: 67 MB / read: 96 MB


Wie ich hier im Forum schon oft gelesen und somit auch erwartet habe, bringt ZIL nur was bei NFS (synchrone writes) und der Cache eigentlich gar nix, wenn man genug RAM hat.



Zu dem ganzen habe Ich nun noch ein paar Fragen:

- Sind diese Werte für meine Hardware ok oder müssten die Werte besser sein (vor allem die write's)?

- Bei den ganzen Tests ist die CPU eigentlich nicht sonderlich gefordert, und die Speicherbelegung kam nie über 19% hinaus, muss ich da noch was optimieren/einstellen?

- Wie arbeitet denn der Cache auf der SSD genau, lagert da ZFS automatisch im laufe der Zeit aus, was man öfter benutzt?

- Was hat es denn mit dieser 4K Sache auf sich? Meine Hitachi-Platten haben wohl eine Blockgrösse von 512, steht zumindest so geschrieben. Kann oder soll man dann trotzdem 4K einstellen?

- Wie kann ich denn die eigentliche Geschwindigkeit des Pools am Host selbst messen, damit ich sehe was theoretisch überhaupt möglich wäre?

Wäre Super wenn Ihr mir da unter die Arme greifen könntet.


Gruß Alex
 
@trendco

Was die ZFS Perfomance angeht schau mal hier: http://www.hardwareluxx.de/community/f211/der-nas4free-anleitungen-tipps-hilfe-thread-935734.html

Mit der Hardware selbst wenn es nur ein Mirror aus 2 HDDs ist, um die ~ 85-90 MB/s liegen. Das Alginment bei 512 Byte Sektoren ist nicht so wichtig, das ist nur für Advanced Format SATA HDDs interessant, aber "Schaden" würde es dir nicht wenn der Pool so ausgerichtet wäre für ein 4K Alignment.

Deinen Pool "intern" kannst du mit DD benchen, einfach mit PuttY via SSH auf NAS4Free einloggen und loslegen (weiß aber nicht wie dein Pool gemountest ist hab mal geraten mit /raid1-pool):

WRITE Test: time dd if=/dev/zero of=/raid1-pool/dd.tst bs=2048000 count=16301

Nach dem Ergebnis ~ 1 Minute warten und dann den zweiten Test starten.

READ Test: time dd if=/raid1-pool/dd.tst of=/dev/null bs=2048000
 
Zuletzt bearbeitet:
Hallo,

ich habe heute in mein nas eine neue HDD eingebaut (Toshiba DT01ACA2). Im Moment möchte ich mit Hilfe von Snapshots meinen bisherigen Datenpool per zfs send auf die neue Platte intern kopieren. Funktioniert alles soweit, nur die Performance lässt meiner Meinung nach zu wünschen übrig. Hier ein paar Daten:

- Pool Daten (bisheriger Datenpool): 2x Hitachi DeskStar 5k3000 3TB --> Mirror
- Pool Temp_Daten (Zwischenspeicher-Pool): 1x Toshiba DT01ACA2 --> Basic
- nas ist auf Stromsparen ausgelegt (Atom CPU, 4GB RAM, rpool auf SSD)

Habe den Basic-Pool aufgrund der advanced sector-Platte mit gesetztem ashift12 angelegt (sd.conf bearbeitet). Wenn ich Bonnie laufen lasse liegt die Toshiba sequentiell bei 164MB lesend und 92MB schreibend. In den angehängten Bildern die Werte während des zfs send aus dem napp-it-Menü Statistics.

Kann mir jemand sagen wo das Problem liegen könnte?

Pool.JPGDisk.JPGcpu.JPGram.JPGarc.JPG
 
Hallo gea,

ich hab erstmalig die Replikation-Funktion getestet. Es lief auch gut an... Ich hatte aber meine Backupmaschine gestern nacht aus gemacht und vor 1h erst wieder an, so dass er ein paar Jobs verpasst hat.
Jetzt schreibt er mir komische Fehler...
zuerst:
info: check network 132, error this host 192.168.3.71 is not a member error
Zur Erläuterung - sowohl Quelle als auch Ziel haben beide 2 IP-Adressen. Ich hatte jeweils die schnelleren Ports in der Appliance-Group eingetragen.
Nachdem ich jeweils beide anderen IPs hinzugefügt habe, war der Fehler weg. Hmmm, woher weiß er nun, dass er über die schnellere Schnittstelle gehen soll?

dann:
info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps
Hier komm ich gar nicht weiter... Die Paar-Nummern find ich auch nur auf ein paar Quell-Snapshots:
Code:
 ZFS  	   	 NAME  	 CREATION  	 USED  	 REFER  	   
 dpool/Daten  	   	 dpool/Daten@1363571383_repli_zfs_SAN-02_nr_36  	 Tue Mar 19 22:57 2013  	 1K  	 84.6G  	 delete 
 dpool/Daten  	   	 dpool/Daten@1363571383_repli_zfs_SAN-02_nr_37  	 Tue Mar 19 23:57 2013  	 1K  	 84.6G  	 delete 
 dpool/Lager  	   	 dpool/Lager@1363571534_repli_zfs_SAN-02_nr_12  	 Tue Mar 19 21:28 2013  	 1K  	 342G  	 delete 
 dpool/Lager  	   	 dpool/Lager@1363571534_repli_zfs_SAN-02_nr_13  	 Wed Mar 20 0:2013  	 1K  	 342G  	 delete 
 dpool/MM  	   	 dpool/MM@1363571468_repli_zfs_SAN-02_nr_36  	 Tue Mar 19 23:12 2013  	 37K  	 396G  	 delete 
 dpool/MM  	   	 dpool/MM@1363571468_repli_zfs_SAN-02_nr_37  	 Wed Mar 20 0:2013  	 16K  	 396G  	 delete

Code:
SAN-02 (Backup)
 error  	  replication 1363571468  	  time: 2013.03.21.00.15.03  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571383  	  time: 2013.03.21.00.05.44  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571534  	  time: 2013.03.21.00.02.55  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571383  	  time: 2013.03.20.23.55.37  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571383  	  time: 2013.03.20.23.53.44  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571468  	  time: 2013.03.20.23.49.47  	  info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps 
 error  	  replication 1363571468  	  time: 2013.03.20.23.48.28  	  info: check network 132, error this host 192.168.3.71 is not a member error 
 error  	  replication 1363571468  	  time: 2013.03.20.23.44.55  	  info: check network 132, error this host 192.168.3.71 is not a member error 
 error  	  replication 1363571468  	  time: 2013.03.20.23.15.10  	  info: check network 132, error this host 192.168.3.71 is not a member error 
 error  	  replication 1363571383  	  time: 2013.03.20.23.00.11  	  info: check network 132, error this host 192.168.3.71 is not a member error 
 ok  	  replication 1363571534  	  time: 2013.03.20.00.30.08  	  info: incremental remote replication finished (time: 4 s) 
 ok  	  replication 1363571468  	  time: 2013.03.20.00.15.07  	  info: incremental remote replication finished (time: 4 s) 
 ok  	  replication 1363571383  	  time: 2013.03.20.00.00.05  	  info: incremental remote replication finished (time: 2 s) 
 ok  	  replication 1363571468  	  time: 2013.03.19.23.15.09  	  info: incremental remote replication finished (time: 5 s) 
 ok  	  replication 1363571383  	  time: 2013.03.19.23.00.08  	  info: incremental remote replication finished (time: 3 s) 
 ok  	  replication 1363571468  	  time: 2013.03.19.22.15.09  	  info: incremental remote replication finished (time: 4 s) 
 ok  	  replication 1363571383  	  time: 2013.03.19.22.00.50  	  info: incremental remote replication finished (time: 3 s) 
 ok  	  replication 1363571534  	  time: 2013.03.19.21.30.51  	  info: incremental remote replication finished (time: 4 s) 
 ok  	  replication 1363571468  	  time: 2013.03.19.21.15.51  	  info: incremental remote replication finished (time: 5 s) 
 ok  	  replication 1363571383  	  time: 2013.03.19.21.00.51  	  info: incremental remote replication finished (time: 3 s) 
 ok  	  replication 1363571468  	  time: 2013.03.19.20.15.10  	  info: incremental remote replication finished (time: 5 s)

Code:
SAN-01 (Quelle)
ok  	  snap 1363564563  	  time: 2013.03.21.00.00.04  	  info: zfs snapshot -r p-sata/Daten@daily-1363564563_2013.03.21.00.00.03 
 ok  	  snap 1363564591  	  time: 2013.03.21.00.00.04  	  info: zfs snapshot -r p-sata/Lager@daily-1363564591_2013.03.21.00.00.03 
 ok  	  snap 1363564651  	  time: 2013.03.21.00.00.04  	  info: zfs snapshot -r p-sata/MM@daily-1363564651_2013.03.21.00.00.03 
 ok  	  snap 1363564563  	  time: 2013.03.20.18.00.46  	  info: zfs snapshot -r p-sata/Daten@daily-1363564563_2013.03.20.18.00.01 
 ok  	  snap 1363564651  	  time: 2013.03.20.18.00.46  	  info: zfs snapshot -r p-sata/MM@daily-1363564651_2013.03.20.18.00.01 
 ok  	  snap 1363564591  	  time: 2013.03.20.16.00.45  	  info: zfs snapshot -r p-sata/Lager@daily-1363564591_2013.03.20.16.00.01 
 ok  	  snap 1363564651  	  time: 2013.03.20.12.00.48  	  info: zfs snapshot -r p-sata/MM@daily-1363564651_2013.03.20.12.00.03 
 ok  	  snap 1363564563  	  time: 2013.03.20.12.00.48  	  info: zfs snapshot -r p-sata/Daten@daily-1363564563_2013.03.20.12.00.03 
 ok  	  snap 1363564591  	  time: 2013.03.20.06.00.48  	  info: zfs snapshot -r p-sata/Lager@daily-1363564591_2013.03.20.06.00.02 
 ok  	  snap 1363564651  	  time: 2013.03.20.06.00.48  	  info: zfs snapshot -r p-sata/MM@daily-1363564651_2013.03.20.06.00.02 
 ok  	  replication 1363571534  	  time: 2013.03.20.00.27.54  	  info:  
 ok  	  replication 1363571468  	  time: 2013.03.20.00.12.54  	  info:  
 ok  	  snap 1363564591  	  time: 2013.03.20.00.00.03  	  info: zfs snapshot -r p-sata/Lager@daily-1363564591_2013.03.20.00.00.02 
 ok  	  snap 1363564651  	  time: 2013.03.20.00.00.03  	  info: zfs snapshot -r p-sata/MM@daily-1363564651_2013.03.20.00.00.02 
 ok  	  replication 1363571383  	  time: 2013.03.19.23.57.52  	  info:  
 ok  	  replication 1363571468  	  time: 2013.03.19.23.12.58  	  info:  
 ok  	  replication 1363571383  	  time: 2013.03.19.22.57.55  	  info:  
 ok  	  replication 1363571468  	  time: 2013.03.19.22.12.57  	  info:  
 ok  	  replication 1363571383  	  time: 2013.03.19.21.58.39  	  info:  
 ok  	  replication 1363571534  	  time: 2013.03.19.21.28.39  	  info:

Du hast da bestimmt die Lösung parat!? :cool:
 
Hallo gea,

ich hab erstmalig die Replikation-Funktion getestet. Es lief auch gut an... Ich hatte aber meine Backupmaschine gestern nacht aus gemacht und vor 1h erst wieder an, so dass er ein paar Jobs verpasst hat.
Jetzt schreibt er mir komische Fehler...
zuerst:
info: check network 132, error this host 192.168.3.71 is not a member error
Zur Erläuterung - sowohl Quelle als auch Ziel haben beide 2 IP-Adressen. Ich hatte jeweils die schnelleren Ports in der Appliance-Group eingetragen.
Nachdem ich jeweils beide anderen IPs hinzugefügt habe, war der Fehler weg. Hmmm, woher weiß er nun, dass er über die schnellere Schnittstelle gehen soll?

dann:
info: job-repli 299, source-dest snap-pair not found, check target ZFS and repli_snaps
Hier komm ich gar nicht weiter... Die Paar-Nummern find ich auch nur auf ein paar Quell-Snapshots:

Zwei Probleme:

1. Wenn zwei Netzwerkkarten, dann beide in unterschiedliche Subnets legen
- 192.168.3.x und 192.168.4.x

2. Replikation, die geht so:

- der erste Replikationslauf legt einen Quellsnap an und überträgt diesen in das Zieldateisystem
Wenn er komplett übertragen wird, wird ein Zielsnap angelegt

- der nächste Replikationslauf arbeitet inkrementell auf Basis der beiden Snaps und überträgt die Differenz
zu einem neu angelegten Quellsnap

In diesem Fall wurde der erste Lauf unterbrochen. Das Zieldateisystem ist damit vorhanden (aber unvollständig)
und der Zielsnap fehlt -> daher die Fehlermeldung snappair not found.

Lösung:
Unvollständiges Zieldateisystem löschen und Erstreplikation neu starten.

---------- Post added at 10:16 ---------- Previous post was at 09:36 ----------

Hallo,

ich habe heute in mein nas eine neue HDD eingebaut (Toshiba DT01ACA2). Im Moment möchte ich mit Hilfe von Snapshots meinen bisherigen Datenpool per zfs send auf die neue Platte intern kopieren. Funktioniert alles soweit, nur die Performance lässt meiner Meinung nach zu wünschen übrig. Hier ein paar Daten:

- Pool Daten (bisheriger Datenpool): 2x Hitachi DeskStar 5k3000 3TB --> Mirror
- Pool Temp_Daten (Zwischenspeicher-Pool): 1x Toshiba DT01ACA2 --> Basic
- nas ist auf Stromsparen ausgelegt (Atom CPU, 4GB RAM, rpool auf SSD)

Habe den Basic-Pool aufgrund der advanced sector-Platte mit gesetztem ashift12 angelegt (sd.conf bearbeitet). Wenn ich Bonnie laufen lasse liegt die Toshiba sequentiell bei 164MB lesend und 92MB schreibend. In den angehängten Bildern die Werte während des zfs send aus dem napp-it-Menü Statistics.

Welche Performancewerte sind denn nicht gut genug?
Bonnie ist ja ok - Transferperformance insgesamt?

Die Logs sind ansonsten nur Momentaufnahmen. Daraus ist nichts Auffälliges erstichtlich.
Ist denn dedup und compress aus und Sata auf AHCI? Ist es ein 64Bit Atom?
Viel mehr kann man nicht machen.

Ansonsten
Atom ist langsam wie sparsam und mehr Performance geht ansonst nur über mehr RAM als Cache.
(Sparsam und schnell wäre sowas wie ein LowPower Xeon)
 
Welche Performancewerte sind denn nicht gut genug?
Bonnie ist ja ok - Transferperformance insgesamt?

Die Logs sind ansonsten nur Momentaufnahmen. Daraus ist nichts Auffälliges erstichtlich.
Ist denn dedup und compress aus und Sata auf AHCI? Ist es ein 64Bit Atom?
Viel mehr kann man nicht machen.

Ansonsten
Atom ist langsam wie sparsam und mehr Performance geht ansonst nur über mehr RAM als Cache.
(Sparsam und schnell wäre sowas wie ein LowPower Xeon)

Ich schiebe die Daten mit 20MB/s im Schnitt intern rüber, das finde ich zu wenig (habe das schon einmal mit diesem System und im Schnitt 100MB/s geschafft).
Wahrscheinlich liegt es am aktivierten Dedup, um etwas Platz zu sparen. Kann es daran liegen, dass der wait-Wert der Toshiba so hoch ist?
 
Hi AG1M,

ich hab nun mal die DD Tests gemacht, jeweils 2x schreiben hintereinander in verschiedende Testdateien und anschliessend zwei mal den Lesetest:

2x schreiben:
nas4free:~# time dd if=/dev/zero of=/mnt/raid1-pool/PVE-Datastore/dd.tst bs=2048000 count=16301
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 363.103537 secs (91941952 bytes/sec) → ~87MB/Sek.
0.045u 9.930s 6:07.03 2.7% 22+2378k 2016+28527io 0pf+0w

nas4free:~# time dd if=/dev/zero of=/mnt/raid1-pool/PVE-Datastore/dd2.tst bs=2048000 count=16301
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 367.474666 secs (90848298 bytes/sec) → ~86MB/Sek.
0.018u 9.710s 6:07.47 2.6% 21+2357k 1+28528io 0pf+0w


2x lesen:
nas4free:~# time dd if=/mnt/raid1-pool/PVE-Datastore/dd.tst of=/dev/null bs=2048000
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 252.222067 secs (132361329 bytes/sec) → ~126MB/Sek.
0.032u 5.050s 4:12.22 2.0% 24+2678k 256708+0io 0pf+0w

nas4free:~# time dd if=/mnt/raid1-pool/PVE-Datastore/dd2.tst of=/dev/null bs=2048000
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 285.384970 secs (116980400 bytes/sec) → ~111MB/Sek.
0.000u 5.111s 4:45.38 1.7% 25+2806k 256711+0io 0pf+0w

Dann hab ich das ganze mal noch mit den Tuning-Tipps von Dir probiert (die 16GB Variante):

vm.kmem_size="15G"
vfs.zfs.arc_max="10240M"
vfs.zfs.arc_min="8192M"
vfs.zfs.txg.timeout="5"
vfs.zfs.txg.write_limit_override="1073741824"
vfs.zfs.vdev.min_pending="1"
vfs.zfs.vdev.max_pending="1"
vfs.zfs.prefetch_disable="0"

und noch mal getestet:

2x schreiben:
nas4free:~# time dd if=/dev/zero of=/mnt/raid1-pool/PVE-Datastore/dd.tst bs=2048000 count=16301
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 356.020084 secs (93771249 bytes/sec) → ~89MB/Sek.
0.018u 9.894s 6:06.43 2.7% 21+2312k 2016+28527io 0pf+0w

nas4free:~# time dd if=/dev/zero of=/mnt/raid1-pool/PVE-Datastore/dd2.tst bs=2048000 count=16301
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 389.818924 secs (85640912 bytes/sec) → ~81MB/Sek.
0.009u 9.614s 6:37.66 2.4% 21+2339k 2014+28527io 0pf+0w


2x lesen:
nas4free:~# time dd if=/mnt/raid1-pool/PVE-Datastore/dd.tst of=/dev/null bs=2048000
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 199.617919 secs (167241739 bytes/sec) → ~159MB/Sek.
0.046u 5.762s 3:19.61 2.9% 26+2819k 259560+0io 0pf+0w

nas4free:~# time dd if=/mnt/raid1-pool/PVE-Datastore/dd2.tst of=/dev/null bs=2048000
16301+0 records in
16301+0 records out
33384448000 bytes transferred in 184.317644 secs (181124537 bytes/sec) → ~172MB/Sek.
0.016u 5.518s 3:04.31 2.9% 24+2696k 206599+0io 0pf+0w

Beim schreiben tut sich da leider nicht viel, aber dafür ein bisschen was beim lesen. Da mir die Schreibperformance aber einfach zu langsam vorkommt, hab ich mal nach meinen Platten gegoogelt und siehe da: 3-TB-Speicherriesen im Vergleichstest - Ergebnisse: Datendurchsatz und Interface-Bandbreite -> Die können wohl einfach nicht mehr...heul :wall:

Ich dachte aber, dass die ZIL SSD genau dafür da ist, damit das dann mit Vollgas zuerst da rein geht und irgenwann auf die Platte geschrieben wird. Während der verschiedenen Tests die ich gemacht habe, hab ich den Pool immer mit "zpool iostat -v 1" beobachtet, das komische ist, dass im ZIL eigentlich immer nur maximal ein paar MB's rum lungern!? Irgendwie ist mir das ganze immer noch nicht ganz klar mit dem ZIL & Cache, wie das genau arbeitet? Bitte erklärt es mir :)


Gruß Alex
 
@trendco

Ich würde dir empfehlen, löse deinen Pool nochmal auf. Dann leg nochmal den Mirror an, ohne ZIL und L2ARC, also lass die SSD weg. Wichtg achte darauf das der Pool mit 4K Aligment angelegt wird.

Hast du die compression=lzjb aktiviert? Würde bei deinem super schnellen CPU viel Sinn machen. Bei deinem System mach mal folgende Settings als Test für die loader.conf:

Code:
vm.kmem_size="23G"
vfs.zfs.arc_max="19456M"
vfs.zfs.arc_min="16384M"
vfs.zfs.vdev.min_pending="1"
vfs.zfs.vdev.max_pending="1"

P.S. wegen ZIL und L2ARC schau mal hier: http://constantin.glez.de/blog/2011/02/frequently-asked-questions-about-flash-memory-ssds-and-zfs


@1chris

Dedup bei 4 GB Ram und einen Intel Atom = keine gute Idee. Da musst du dich über diese Übertragungsraten nicht wundern, idR brauchst du pro TB Daten ~ 5 GB Ram (kommt immer auf die Daten an) für die Deduptabelle, solange du keine SSD für den L2ARC nimmst.

Etwas zum lesen zu dem Thema: http://constantin.glez.de/blog/2011/07/zfs-dedupe-or-not-dedupe
 
Zuletzt bearbeitet:
Ich schiebe die Daten mit 20MB/s im Schnitt intern rüber, das finde ich zu wenig (habe das schon einmal mit diesem System und im Schnitt 100MB/s geschafft).
Wahrscheinlich liegt es am aktivierten Dedup, um etwas Platz zu sparen. Kann es daran liegen, dass der wait-Wert der Toshiba so hoch ist?

Es lag am Dedup. Dedup und Compression ausgeschaltet und siehe da: 110MB/s.
 
Hi AG1M,

genau das habe ich vorhin schon mal gemacht, den Pool "destroyed" und neu angelegt, dieses mal mit 4K. Die DD Tests sehen irgendwie nicht viel besser aus als vorher, wenn nicht sogar schlechter, aber der Netzspeed ist definitiv besser geworden, keine Ahnung wie das geht!?

AFP: write: 92 MB / read: 103 MB
SMB: write: 79 MB / read: 82 MB
NFS: write: 72 MB / read: 97 MB


Das ganze hab ich wieder mit dem "Aja System Test" gemacht. Sieht jetzt zwar nicht extrem besser aus als vorher, aber eben beim schreiben ein Zugewinn. Ich lasse beim Testen auch immer die Aktivitätsanzeige vom Mac mitlaufen, und da war vor der Umsetllung auf 4K nix mit über 100MB beim schreiben, nun klettert die Anzeige bei AFP oft auf 105-108MB hoch. Und wenn ich eine 3GB grosse Datei aufs Netz schiebe, dann bleibt die Anzeige fast dauernd bei über 100MB - sehr schön.

Zur Info: Wenn die ZIL/Cache-SSD weg ist, wird es definitiv schlechter! Die Komprimierung, egal ob "Aktiviert" oder "lzjb", hat bei mir keine besonderen Auswirkungen gezeigt. Was bei ZIL/Cache noch interessant ist: Wenn nur ZIL benutzt wird, bringt es nur etwas bei NFS (syncron wirtes), wenn allerdings ZIL & Cache drin ist, dann steigt die Performance im ganzen, das hatte ich schon hier ZIL / L2ARC Experimente | Markus Grundmann gelesen und kann ich auch so bestätigen.


nas4free:~# zpool status
pool: raid1-pool
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
raid1-pool ONLINE 0 0 0
mirror-0 ONLINE 0 0 0
ada1.nop ONLINE 0 0 0
ada2.nop ONLINE 0 0 0
logs
ada0p1 ONLINE 0 0 0
cache
ada0p2 ONLINE 0 0 0

errors: No known data errors

Zwei Fragen noch:
- macht das denn nix, wenn ich bei einer "normalen" Platte "4K" benutze?
- kann man, und wenn ja wie, bei ZIL & Cache auch 4K einstellen?
- und warum heissen meine beiden Platten eigentlich jetzt ".nop"?


Gruß Alex
 
@trendco

Hmm ok, dann probier nochmal damit:

Code:
vm.kmem_size="23G"
vfs.zfs.arc_max="19456M"
vfs.zfs.arc_min="16384M"
vfs.zfs.txg.timeout="5"
vfs.zfs.txg.write_limit_override="1073741824"
vfs.zfs.vdev.min_pending="1"
vfs.zfs.vdev.max_pending="1"
vfs.zfs.prefetch_disable="0"

Immer Neustart durchführen vor dem Test.

- macht das denn nix, wenn ich bei einer "normalen" Platte "4K" benutze?

Nein macht garnichts, weder im negativen wie positiven. Nur ein Mischbetrieb aus 4 Kbyte HDDs und normalen 512 Byte HDDs ist nicht so sinnvoll, aber fast (oder so gut wie) alle normalen Consumer SATA HDDs haben Advanced Format, als 4 Kbyte Sektoren.

- kann man, und wenn ja wie, bei ZIL & Cache auch 4K einstellen?

Nein nicht möglich, brauchst du auch nicht.

- und warum heissen meine beiden Platten eigentlich jetzt ".nop"?

Weil NAS4Free auf FreeBSD 9.1 basiert und bei FreeBSD kann man mit dem QNOP Utility den Pool mit 4 K Aligment ausrichten, bei NAS4Free geht das eben gleich im WebGUI weils halt bequem gehen soll, du kannst auch nachträglich das .nop wieder wegmachen, aber macht keinen wirklichen Sinn, da es nur eine Optikgeschichte ist und sonst nichts ändert.
 
Danke für die Infos.

Das ".nop" Problem lässt sich übrigens ganz einfach lösen -> Pool exportieren und wieder importieren.
Hab ich hier gelesen: zfs_ashift - BSDForen.de Wiki

Meine Hitachi Platten sind aber definitv keine "Advanced Format" Platten, da hatte ich extra mal bei Hitachi angerufen und es steht auch so im Datasheet der Platte. Na dann hoffen wir mal, dass das dann echt kein Problem ist, vor allem was die Datensicherheit angeht.
 
Ich weiß, hatte ich ja geschrieben ist nur eine Optiksache.

Was meinst du bitte mit Datensicherheit? Das Aligment = ist nur Ausrichtung mehr nicht und bei 512Byte Sektoren Festplatten, hat ein 4KByte Alignment keinen Nachteil, wenn aber 4KByte Sektoren Festplatten nicht korrekt ausgerichtet sind, gibt es Performanceeinbußen, das ist eigentlich schon alles.

/EDIT Als Beispiel was mir noch einfällt, wenn du unter Windows 7 eine neue Festplatte einrichtest, dann wird normal sogar automtisch das 4Kbyte Aligment mit einem 1024er Offset eingerichtet.
 
Zuletzt bearbeitet:
Was meinst du bitte mit Datensicherheit? Das Aligment = ist nur Ausrichtung mehr nicht und bei 512Byte Sektoren Festplatten, hat ein 4KByte Alignment keinen Nachteil, wenn aber 4KByte Sektoren Festplatten nicht korrekt ausgerichtet sind, gibt es Performanceeinbußen, das ist eigentlich schon alles.
Ah ok, dann bin ich ja beruhigt :)

Noch mal zum Thema ZIL: Ich war bisher immer der Meinung, dass man die der Sicherheit wegen spiegeln muss, jetzt hab ich aber schon paar mal geslesen, dass das seit Pool-Version 28 nicht mehr nötig sei!? Weiss da jemand etwas genaueres dazu?


Alex
 
- macht das denn nix, wenn ich bei einer "normalen" Platte "4K" benutze?

Nein macht garnichts, weder im negativen wie positiven. Nur ein Mischbetrieb aus 4 Kbyte HDDs und normalen 512 Byte HDDs ist nicht so sinnvoll, aber fast (oder so gut wie) alle normalen Consumer SATA HDDs haben Advanced Format, als 4 Kbyte Sektoren.

Naja, du nagelst halt die minimale Häppchengröße auf 4K fest, ansonsten hat ZFS afaik auch die Möglichkeit, bis hinunter zu 512B zu splitten. Dürfte aber nur bei sehr großen Mengen an sehr kleinen Dateien was ausmachen.

Wo siehst du das Problem bei Mischbetrieb? Die 512er stört das 4K ja nicht, während es die 4K "zwingend" brauchen. Ich steuer grade auf ne solche Konfiguration zu und würde da jetzt nur anführen, dass 4K-Platten idR schneller sind, da meistens neuer. Was in meinem Szenario aber auch wieder wurscht ist, weil ich auch mit 8 böse langsamen Platten Gigabit gestrichen voll kriegen sollte. Schneller kann ich meinen einzigen Clienten nicht anbinden, und schneller wird auch kein Backupmedium sein.
 
Noch mal zum Thema ZIL: Ich war bisher immer der Meinung, dass man die der Sicherheit wegen spiegeln muss, jetzt hab ich aber schon paar mal geslesen, dass das seit Pool-Version 28 nicht mehr nötig sei!? Weiss da jemand etwas genaueres dazu?

Hatte dir eine Seite zuvor einen Link gegeben zu dem Thema ich zitiere Mal:

The role of the ZIL is to store a transaction group until it has safely been written to disk. After that, this can be safely deleted and the space used for the next transaction group.
So the question becomes: How much transaction group data is "in flight" (i.e. not yet written to disk) at any time?
ZFS issues a new transaction group (and consequently a new pool update) every 5 seconds at the latest (more if the load is higher). While one transaction group is written to the ZIL, the previous one may still be in the process of being written to disk, so we need enough space to store two transaction groups, which means 10 seconds of maximum write throughput worth of data.
What's the maximum amount of data that your server writes in 10 seconds? Well, an upper boundary would be the maximum write speed of your SSD. At the time of this writing this was about 170 MB/s for an Intel X25-E, times 10 that would be just short of 2 GB for a typical ZIL.
So for ZILs, a little can go a long way.


Also wie du siehst nur die letzten Sekunden an Daten werden verloren und nicht dein ganzer Pool geht kaputt weil den ZIL ausfällt. Bei älter als Pool V19 unter gab es da es aber mehr Probleme, wenn da dein ZIL nicht als Mirror war = Pool kaputt.

Wo siehst du das Problem bei Mischbetrieb? Die 512er stört das 4K ja nicht, während es die 4K "zwingend" brauchen. Ich steuer grade auf ne solche Konfiguration zu und würde da jetzt nur anführen, dass 4K-Platten idR schneller sind, da meistens neuer. Was in meinem Szenario aber auch wieder wurscht ist, weil ich auch mit 8 böse langsamen Platten Gigabit gestrichen voll kriegen sollte. Schneller kann ich meinen einzigen Clienten nicht anbinden, und schneller wird auch kein Backupmedium sein.

Ich habe mal Benchmarks von Mischnbestückungen gesehen wo halt auch die Perfomance nicht so super war, war glaub ich im Hardforum. Natürlich kommt es dann auch noch drauf ob die HDDs z.B. pro TB nur einen Platter haben und mit 7200 rpm laufen und die anderen HDDs mit mehr Plattern und z.B. nur 5400 rpm laufen etc.
 
Ok, das heisst, wenns dann knallt und die SSD ausfällt, dann fehlen evtl. die Daten von den letzten Schreibvorgängen, der Pool bleibt aber unbeschadet. Das ist schon mal gut so.


Apropos Pool, beim testen gestern Abend blieb meine Kiste auf einmal komplett stehen. Nach dem Neustart war der Pool weg, importieren geht auch nicht mehr, hab schon alles mögliche probiert. Habs im Nas4Free Forum auch mal reingeschrieben: NAS4Free Forums • View topic - Pool zerschossen?
Hat da jemand eine Idee dazu? Ist zwar nur ein Test-Pool, aber das beunruhigt mich doch sehr, ZFS sei doch gerade bei solchen Dingen sehr sicher, dachte ich?
 
Echtzeit-Dedup ist nur in ganz wenigen (Highend) Szenarien sinnvoll.
Kompression ist schon eher sinnvoll - vor allem mit dem neuen ZFS-LZ4 Kompressor.
Der ist teils massiv schneller als bisher.

Bei wenig RAM und langsamen Systemen ansonst beides ausschalten.
LZ4 Compression - illumos - illumos wiki

Kann Openindiana 151a7 LZ4-Compression?
Ich kann es nicht aktivieren (nur lzjb, zle oder gzip).
 
Ok, das heisst, wenns dann knallt und die SSD ausfällt, dann fehlen evtl. die Daten von den letzten Schreibvorgängen, der Pool bleibt aber unbeschadet. Das ist schon mal gut so.


Apropos Pool, beim testen gestern Abend blieb meine Kiste auf einmal komplett stehen. Nach dem Neustart war der Pool weg, importieren geht auch nicht mehr, hab schon alles mögliche probiert. Habs im Nas4Free Forum auch mal reingeschrieben: NAS4Free Forums • View topic - Pool zerschossen?
Hat da jemand eine Idee dazu? Ist zwar nur ein Test-Pool, aber das beunruhigt mich doch sehr, ZFS sei doch gerade bei solchen Dingen sehr sicher, dachte ich?

Boote mal von einer OI Live DVD oder napp-it to Go und versuche es da nochmal, evtl. read-only importieren. ZFS auf Solaris ist schon sehr stabil, aber zur Implementierung unter FreeBSD oder Linux kann ich dir nix sagen.

cu
 
Hallo gea,

kurze Frage, gibt es eigentlich bei dieser "AllInOne-Lösung" von Dir Performance Einbussen durch die Virtualisierung?
Was erreichst Du damit für Werte beim schreiben/lesen bei SMB, AFP, NFS?

Gruß Alex

PS: Hast Du eine Idee dazu: http://www.hardwareluxx.de/community/f101/zfs-stammtisch-570052-129.html#post20367739

Bei All-in-One werden Controller und Platten direkt durchgereicht, da gibt es gar keinen Verlust. Wenn man jetzt ein virtuelles NAS mit z.B. 8 GB fester RAM-Zuordnung mit einem direkt installiertem NAS vergleicht, das auf der gleichen Hardware auch 8GB RAM läuft, so würde ich durchaus erwarten, dass weit über 90% der Leistung erhalten bleibt - sofern genug CPU Leistung da ist (Andere VM's nicht alles wegnehmen).

Ein NAS-VM ist aber nicht so CPU hungrig und insgesamt ist CPU bei Virtualisierung meist nicht das Problem. Bei Datentransfers zwischen Storage und ESXi ist es dagegen viel schneller als getrennte Lösungen da der Datentransfer intern bleibt (mehrere GB/s ohne teures Netzequipment),

Zur Frage 2.
Ich habe mit BSD keine Erfahrung. Bei einem ausgefallenen Logdevice kennt ZFS aber den Importparameter -m um einen Pool ohne Logdevice zu importieren.
 
Hi gea,

hast Du zufällig mal die Performance gemessen? Ich frage nur darum, weil ich hier mal ein paar Tests mit Proxmox gemacht habe. Zuerst alles direkt betrieben und gemessen, dann Proxmox auf eine USB-SSD, onboard-Controller durchgereicht an Nas4Free und dann wieder gemessen. Da fehlte dann vor allem beim "write" doch ein ganzes Stück zum "Direktbetrieb". Ist ja im Prinzip das gleiche wie mit ESXi, nur eben mit Proxmox.

Direkt:
AFP: 92MB write / 100MB read
SMB: 78MB write / 82MB read
NFS: 70MB write / 94MB read


Virtualisiert:
AFP: 64MB write / 92MB read
SMB: 57MB write / 64MB read
NFS: 51MB write / 91MB read


Mit ESXi kann ichs leider hier nicht testen, da bekomme ich immer so "schöne rosafarbene" Bildschirme :)

Das mit dem Import Parameter werde ich später mal testen und berichten, hab gerade meine Config wieder umgebaut.


Gruß Alex
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh