Welches FS für einen NAS

hi
hm ... optimieren ist immer so eine sache welche nfs version wird verwendet

wenn du local 100 MB/s read solltest du eine hohe schreib rate haben pc->nas ( read local , write nas )

wie hoch ist den die schreib rate local ? die gilt dann fuer pc<-nas ( read nas , write local )

holger
 
Hi

Also lokal am PC ists ein sehr voller zpool (37G/3.6T frei), was wohl auch etwas auf die Geschwindgikeit drückt.
Jedenfalls (grober mittelwert):
lokal: 100MB/s write, 160MB/s read
nas: 100MB/s write, 200-300MB/s read


ich hab etwas mit rsize,wsize beim nfs mount gespielt, und habe jetzt ~34MB/s PC->NAS (das ist ja erstmal die wichtige, da die 3.5T vom alten zpool ja mal auf den NAS sollen ^^).


NFSv3 wird verwendet. Beide ZFS sind mit sync=disabled, da das ja angeblich ev bei NFS auf ZFS ausbremsen könnte.


mfg Tobias
 
oh ja ... selbst die entwickler von zfs sagen das man nicht mehr als 80% nutzen
der kapazitaet nutzen sollte da es sonst zu performace einbussen kommt .

was mit , so wie ich es verstanden habe , dem copy on write mechanismus zu tun hat.

du koenntest mal versuchen ein zil laufwerk einzubinden.

aber wenn du sync aus hast und mit sync = zil meinst das ist nicht recommended by sun.

nimm einen usb stick steck den in einen ehci port und binde diese als zil (log) lw ein
das ist besser als sync abzuschalten.

docu findest du via google suche nach zfs und zil

holger
 
Ja, dass es nicht empfohlen ist, ist klar. Sobald ich einen entsprechende USB-Sticks auftreiben kann werde ich das tun.

mfg Tobias
 
es gibt wirklich lahme USB-Sticks und zumindest mit meinen FreeBSDs sind die in der Regel nochmal ein Stück lahmer, als etwa mit Mac oder Linux.
Grundsätzlich bin ich ein großer Fan von USB-Sticks im Einsatz und habe ja mein System komplett auf einen gelegt. Als Cache- oder Log- Device, nun, da bin ich noch etwas skeptisch.
Ehrlich gesagt hatte ich es aber nie probiert, weil ich die man-page so verstanden hatte, dass es bei raidz nicht geht? Wenn ich nun nachlese, könnte es auch meinen, dass nicht auf ein raidz angelegt werden sollte.
Also, da bin ich mal auf die Ergebnisse gespannt. So ein paar übrige Sticks habe ich immer rumliegen...
 
ah, ich wollte noch was ergänzen:
Meiner bisherigen Erfahrung nach sollte man Übertragungsraten am besten mit einem großen file testen. Nur dann sind die Ergebnisse halbwegs vergleichbar. Groß bedeutet in dem Fall: groß gegenüber Cache (=RAM).
dd if=/dev/zero of=10GB.tst bs=1g count=10
könnte etwa so ein File bauen und auch gleich die Geschwindigkeit des lokalen Datenträgers testen (zu Vergleichszwecken). Der hier erzielte Wert wird sicher nicht beim Netzwerktransfer erreicht werden können, kann vielleicht als eine Art absolute Obergrenze angesehen werden. (wer es mal testen will und /dev/random statt /dev/zero nimmt, sieht gleich, dass nicht nur die Geschwindigkeit der Platte in diesem test eine Rolle spielt).
Das erzeugte File kann anschließend kopiert und die Zeit gemessen werden (etwa über time). Sinnvoller ist aber vielleicht rsync, was eine ziemlich treffende Übertragungsrate ermittelt. dd direkt auf das gemountete share habe ich nie probiert. In meiner Vorstellung ist das nicht so aussagekräftig.
Die eigentliche Übertragung betrachte ich mir ganz gern mit iftop.
 
hi

zil existiert per se immer egal ob du raidz raidz2 , mirroe oder nur eine einzelene platte
zum pool hinzufuegst.

zil kannst somit auch immer auf ein seperates device legen via

zpool add tank log device oder , wenn man z.b. festplatten als zil nutzt
zpool add tank log mirror deviceA deviceB

die perfomance von usb2.0 sollte reichen .

zil kann dann eine bremse sein wenn man syncron screibt, und gerade das wird bei
nfs gemacht.
wenn man nun den eigentlichen tank entlasten will ist es besser zil auf einem seperaten device zu haben.

details auch hier

http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide

was perfomance messungen betrifft . ich denke wichtig ist dabei das man mit ein und dem selben tool , methode arbeitet um die werte vergleichbar zu halten.
deswegen hatte ich ja bei mir angemerkt das die werte via mc ermittelt wurden.

natuerlich kann man auch jedes andere tool nutzen , oder sogar bonnie.

fuer mich ist mc einfach schoen bequem da es die werte beim kopieren schoen anzeigt.
wenn man nun ein verzeichnis hat mit schon vielen datein unterschiedlichster groesse,
kommt man gut auf einen praxis wert.

holger
 
Beachtet dabei bitte, dass erst ab FreeBSD 9.0 bzw. den kommendem 8.3 ein sperates Log-Device (aka ZIL-Device) wieder entfernt werden kann! Bei FreeBSD 8.2 und älter - also auch darauf aufsetzenden Versionen von FreeNAS - ist ein entfernen nur durch Neuerstellen des Pools möglich!
 
Yamagi schrieb:
Beachtet dabei bitte, dass erst ab FreeBSD 9.0 bzw. den kommendem 8.3 ein sperates Log-Device (aka ZIL-Device) wieder entfernt werden kann! Bei FreeBSD 8.2 und älter - also auch darauf aufsetzenden Versionen von FreeNAS - ist ein entfernen nur durch Neuerstellen des Pools möglich!
Zum Vergrößern anklicken....


hi

danke , und ja das ist ein wichtiger hinweis ... ich bin es schon so gewohnt mit
zfs v28 zu arbeiten das ich an solche kleinigkeiten nicht mehr denke ;)

holger
 
nun, vielleicht meine Bedenken dazu:
mein System läuft von USB-Stick, den ich in das Gehäuse verlegt habe. Die Performance des Sticks ist unter FreeBSD (7.4) nicht Welterschütternd, aber ausreichend. Dabei vermeide ich so gut es geht jeglichen Zugriff auf den Stick, er wird quasi nur zum Booten benutzt. Die Verzeichnisse, wohin ich interessante logs schreibe, sind nicht darauf, es gibt keinen Journal zu dem verwendeten Filesystem und es ist tempfs genutzt. Ich betreibe also einigen Aufwand, den Stick von allen Zugriffen während des Betriebs zu entlasten und nun soll ich genau das Gegenteil machen und einen Stick zusätzlich anbringen, der nicht nur immens wichtige Daten enthält, sondern auch noch die Geschwindigkeiten erhöht, weil nun reichlich darauf geloggt wird. Das steht doch im Widerspruch zu meinen bisherigen Bemühungen.

Ich habe eben mal einen beliebigen Sick aus meiner Kiste gegriffen, jener Kiste, wo die "guten" Sticks drin liegen. In einer anderen habe ich die sehr langsamen und trägen liegen, die eigentlich mal entsorgt werden könnten. Ich denke, der Stick war leer, nun ist er es jedenfalls. Er hat 4GB, ich schreibe mal 1G dorthin:
Code: 
pit@syo ~:-> dd if=/dev/zero of=/dev/da0s1 bs=1g count=1
1+0 records in
1+0 records out
1073741824 bytes transferred in 152.691094 secs (7032118 bytes/sec)
Wenn ich das richtig lese, sind das ca 7MB/s schreibend. Dabei ist nicht irgendein Dateisystem berücksichtigt, ich schreibe ja direkt auf das Gerät, bzw in die Partition. Ich denke, das dürfte die Maximal-Geschwindigkeit sein.
Mein PC ist etwa Baujahr 2006, die ältesten Dateien finde ich seit 2007. dmesg sagt zum Stick:
Code: 
ugen6.2: <USBest Technology> at usbus6
umass0: <USBest Technology USB Mass Storage Device, class 0/0, rev 2.00/1.00, addr 2> on usbus6
umass0:  SCSI over Bulk-Only; quirks = 0x0000
umass0:3:0:-1: Attached to scbus3
da0 at umass-sim0 bus 0 scbus3 target 0 lun 0
da0: <Ut165 USB2FlashStorage 0.00> Removable Direct Access SCSI-2 device
da0: 40.000MB/s transfers
da0: 3856MB (7897088 512 byte sectors: 255H 63S/T 491C)
Mit meiner eingebauten SATA Platte (es sind zwei am eingebauten HW Raid als Raid0 zusammengeschaltet) komme ich auf etwas mehr, als das zehnfache dieser Rate!
Auf meinem Fileserver, der etwa gleiche HW hat, dürfte das nicht viel anders aussehen. Wir hatten verschiedene Tests hier schon mal durchgeführt und auch mit bonnie ergaben sich ziemlich gleiche Werte. Jedenfalls in der Größenordnung deutlich sehr viel schneller auf die Festplatten, als auf ein USB-Gerät.

Wenn ich mir das vor Augen halte und auch die Beschreibung, dass ein etwa 100MB großes Gerät genügt, frage ich mich, ob es nicht sehr viel besser wäre, ein Stück Speicher dafür zu verwenden und als ZIL-Gerät festzulegen. Ich habe mir nicht wirklich viele Gedanken darum gemacht, denke mir, ein Verzeichnis im /tmp, das auf tmpfs läuft, könnte bereits alles sein, was es dazu braucht. Im Zweifel halt ein md-Gerät, das noch gebaut werden müsste.
USB will mir nicht so recht eingehen. Dann schon eher eine SD-Platte, doch die wäre ja ziemlich verschwendet.

und vielleicht probiere ich später den gleichen Stick mal noch an einem anderen Rechner. Mit Betriebssystemen vom Stick erlebte ich, dass ein GNU/Linux in einen unglaublichen Geschwindigkeitsrausch kam und ein FreeBSD von gleichen Stick nur so vor sich hinkroch. Da gibt es offenbar Unterschiede und die ursprünglichen Empfehlungen bezogen sich ja immer auf ein Solaris, das vielleicht ja auch flotter mit Sticks umgehen kann. Meine Erfahrung ist nicht aktuell. Die Vergleiche machte ich mit FreeBSD 6er und 7er Versionen. Meine derzeit benutzte 8.2-RELEASE sieht mir aber ziemlich gleich aus.
 
hi
also so wie ich das verstanden habe muss man aufpassen das man den richtigen usb port erwischt nicht alle sind ehci !
und zusaetzliches ram ist fuer zfs positiv , aber negativ wenn man diese dedeziert fuer
zil verwendet .

am optimalsten ist natuerlich an der stelle eine ssd , es reichen aber auch gemirror te platten .

fuer zil ist die performance nicht so wichtig , eher das es ausfall sicher ist , deswegen
sollte ein schneller usb stick oder mirror platten reichen , da die logging informationen
ggf vom system asyncron hier geschrieben werden.

und es ist ja auch nicht immer sinvoll zil zu separieren . haengt halt starkt von der anwendung ab.

fuer nfs macht es sinn ,und bevor ich gar kein sync ( zil ) habe wie es ja hier der fall
ist , selbst ueber einen usb stick nach zu denken da
die dinger nu mal nicht mehr die welt kosten und durchaus eine akzeptable speed
bieten um diese aufgabe zu schaffen und damit die gesamt performace zu steigern.

holger
 
Was ich nicht genau verstehe, ist warum ich, wenn ich eine datei mittesl dd vom PC auf den NAS "kopiere", eine Geschwindigkeit von 50-60MB/s habe. Wenn ich aber mc,cp,rsync verwende nur auf 25MB/s komme (auch bei grossen Dateien).
 
Hi ,
Mit dd generist du eine datei wobei der plattenkopf sich nur fuer das seqenzielle schreiben bewegt.

Bei mc werden dateien wirklich an ,im zweifel, an verschiedenen stellen gelesen.

Ergo dd erzeugt eine datei , mc liest wobei der kopf deutlich mehr bewegen
Muss.
Ich hoffe das war halbwegs verstaendlich erklaert.

Holger
 
und lesen natürlich auch. Wenn du dd von /dev/zero nimmst, fällt das ja quasi komplett weg. Wenn du eine Datei von einem Datenträger nimmst, wird die zwar gelesen, aber eben auch "nacheinander", wie sie reinkommt, geht sie auch wieder raus. Dabei spielt deshalb auch das Dateisystem keine Rolle, oder solche Dinge wie Inodengröße etc.
Ich denke, cat und vielleicht tar dürften das ähnlich machen, wobei cat natürlich nie empfohlen wird, Dateien zu übertragen. Missbraucht wird es dazu natürlich schon gelegentlich.

Es ist natürlich eine gute Frage, ob das Positionieren, also auch die Übertragung unterschiedlicher Dateien nicht den Echtbetrieb besser darstellen kann.
Zum Vergleich eignet sich das aber deshalb eben nicht, weil ja nicht die gleichen Dateien bei unterschiedlichen Usern vorhanden sind. Deshalb nehme ich immer gerne eine einzige große Datei.
 
hi

man sieht also benchmarking mit festplatten bzw storage ist garnicht so einfach,
da es viele punkte gibt die zu bachten sind und die werte nicht in jedem falle
vergleichbar sind .
deswegen finde ich bonnie nachwie vor ein sehr schoene tool zum messen.

holger
 
bei ZFS (und generell allen COW-Dateisystemen) fragmentiert es sowieso schon aus Prinzip. Daher ist es eh immer langsamer.
 
pit234a schrieb:
Mit meiner eingebauten SATA Platte (es sind zwei am eingebauten HW Raid als Raid0 zusammengeschaltet) komme ich auf etwas mehr, als das zehnfache dieser Rate!
Zum Vergrößern anklicken....

Ein Raid0 und nur 70MB/sec? Das macht meine 7 Jahre alte Hitachi alleine. Sicher dass das kein Raid1 ist? Ansonsten läuft da imo irgendwo was falsch oder nutzt du da 7.4 mit ZFS drauf?

Back to Topic: Das mit ZFS und der Fragmentierung ist auch so eine Sache. Problematisch wird es vor allem mit zunehmend vollem Pool. Wenn man es tatsächlich mal geschafft hat den voll zu hauen dann merkt man es schon bevor das Dateisystem voll ist relativ deutlich an der Performance.

Interessant wäre ausserdem mal ein Real World Performance Benchmark. man findet viele Benchmarks die Dateisystem xy mit ZFS vergleichen oder auch einen, der OpenSolaris mit FreeNAS 0.7 vergleicht, was imo absolut daneben ist. Einen Benchmark, der ZFS auf allen Plattformen die es unterstützen vergleicht habe ich bisher aber leider nicht gesehen.
 
MuffiXXL schrieb:
Ein Raid0 und nur 70MB/sec? Das macht meine 7 Jahre alte Hitachi alleine. Sicher dass das kein Raid1 ist? Ansonsten läuft da imo irgendwo was falsch oder nutzt du da 7.4 mit ZFS drauf?
Zum Vergrößern anklicken....

Bin sehr sicher, dass es ein Raid0 ist, mit 8.2-RELEASE und UFS.
Dies ist ein PC aus dem Laden, wie er dort angeboten wurde. Ich habe den nur auf gehabt, als mal was kaputt war und ich was tauschen musste, glaube NIC, Sound oder GraKA. Weiß nicht mehr.
Ich hatte mir das nicht so ausgesucht, es war mir also egal, was da verbaut war, aber da gab es zwei Platten drin und an einem Controller auf dem MainBoard, keine Ahnung welcher. Meine Datensicherung wollte ich extern und keinesfalls einem Controller auf einem Mainboard anvertrauen, deshalb wählte ich da Raid0, ziemlich sicher.
Sehe demnächst mal wirklich nach, ist ja schon so lange her.
Für mich war die Performance immer OK, es ist auch damals schon 8GB Ram verbaut gewesen (das war ein Irrtum von mir, den hatte ich falsch bestellt) und weil ich manche Daten über NFS austausche, war mir die Plattenperformance nie fragwürdig.

Bei meinem "dd Test" habe ich allerdings auch nicht andere Arbeiten gestoppt. Es kann sein, dass noch mehr auf die Platte zugriff, es lief jedenfalls mein DesktopEnvironment komplett mit etlichen Browsern und E-Mail...

Nun aufmerksam, sehe ich mir das mal noch genauer an. Danke für den Hinweis.
 
Moin

Oo zum ersten mal jetzt gerade den NAS via NFS am PC eingehängt.. ich kriege sagenhafte 3MB/s zum kopieren...

Also irgendwas läuft da ganz schief.

Nachtrag: samba geht mit ca 20, und nachdem ich NFS mit tcp,wsize=32768,rsize=32768 mounte hab ich ich meine gewünschten ~30-40MB/s ^^ seltsam, dass das nicht mehr per Default klappt. Aber besser als 3 :P


mfg Tobias
 
Zuletzt bearbeitet:
die mount-Optionen sind bei NFS nicht zu vernachlässigen und besonders, wenn FreeBSD der Server und ein Linux der Client sind, kann durch "Drehen an den Stellrädern" durchaus was gewonnen werden. Weder mit FreeBSD noch mit OpenSolaris in einem kurzen Test hatte ich das nötig, doch bei Linux zeigte es sich ähnlich, wie du das beschreibst. Allerdings, sooo schlecht war es dann bei ir doch nicht, die 3MB/s kann ich mir da nicht wirklich erklären.
Es kann sich übrigens ganz gut machen, einem Client (Linux) eine ganze Reihe von Optionen schon fertig mitzugeben und nicht dem Aushandeln zu überlassen. Ich gebe mal ein Beispiel aus einem Sat-Receiver, auf dem bei mir ein busybox/Linux installiert ist. Diese Geräte haben einige Besonderheiten was den Datenverkehr anbelangt und deshalb ist dieses Beispiel keineswegs universell zu verstehen, es soll nur zeigen, an was man vielleicht alles so denken könnte:
Code: 
rw,v3,rsize=16384,wsize=16384,hard,udp,lock,

Auch die Übertragung mittels Samba ist mitunter sehr vom Client abhängig. So erhalte ich die besten Raten zu Mac-OS-X und etwa gleich zu GNU/Linux, aber zu Windows Clienten ist es meist ein Stück schlechter.
Bei FreeSBD als Client habe ich eine Besonderheit. Da nutze ich KDE3 als DesktopEnvironment und das kann einen smb im systemeigenen Webbroser, womit ich ohne zu mounten die Quelle aufrufen kann, analog zum Aufruf eines ftp oder http Servers. Der Browser zeigt mir alle Freigaben und wenn ich eine anklicke, wird das notwendige Passwort abgefragt. Anschließend kann ich das Verzeichnis browsen und Daten verschieben. Der Unterschied zu einem smb-mount ist aber, dass Dateien, die ich nun öffnen will, erst vollkommen kopiert werden. Ein Film zum Beispiel, wird nicht gleich gespielt, wie das mit einer eingebundenen Share der Fall wäre. Erst wird er komplett übertragen und dann gespielt. Ob andere DE oder Browser so etwas auch können, weiß ich nicht. Jedenfalls ist hierbei die reine Datenübertragung seltsamerweise auch ein kleines Stückchen langsamer, als wenn gemountet ist und zwar vor allem, wenn Dateien angelegt werden müssen. Wahrscheinlich ist da der Aufwand größer, ich weiß aber nicht, was da im Hintergrund läuft.

Du könntest noch ftp probieren. Das hat sich bei mir Plattform-unabhängig als bestes Verfahren zum Übertragen von Dateien bewährt. Ich nutze meist den erwähnten Browser meines DE dazu, weil der da wirklich super einfach zu handhaben ist. Bewährt ist auch Filezilla, doch, wenn ich meinen Browser nicht habe, mache ich es oft schnell über eine Konsole. Dabei ist nur dann Vorsicht geboten, wenn dein Client ein Windows ist, denn dann muss der binary Mode explizit gesetzt werden. Alle anderen System, die ich dafür bisher nutzte, machen das per Default richtig.
 
Moin

Beide Systeme sind FreeBSD-Current. Daher war ich ja auch etwas überrascht, dass ich schrauben musste. Denn bis jetzt gings immer ohne was zu machen.

Mit der Samba Geschwindigkeit bin ich eigentlich sehr zufrieden. Vorhin wars deutlich weniger. Also nun reicht die Geschwindigkeit, dass man auch von Windows raus direkt Videodateien abspielen, ohne erstes kopieren.


Aber ingesamt läufts mittlerweile befriedigend. Schneller wäre natürlich immer schöner, aber vorerst ist es zumindest genügend.

Die 4GB Ram scheinen bis jetzt auch zu reichen, das war ja Ursprünglich mein anvisierter Problemherd, dass es dann zu lahmen NFS-Mounts mutierte war für mich nicht absehbar :P


mfg Tobias
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben