XigmaNAS

Hi,

wir haben hier auf einem ZFS Mirror unter anderem ein Verzeichniss, dass extrem viele Dateien enthält und wenn man mit dem Explorer das Verzeichniss öffnet (über eine SMB Freigabe) erstmal diverse Gedenksekunden einrechnen muss - bis zu 10 Sekunden kann es schonmal gehen.

Das Verzeichniss hat derzeit eine Größe von 90GB und es sind ~130000 Dateien drin.
Es wäre nur unter großem Logistischen Aufwand möglich da eine Ordnerstruktur zu erstellen, sprich ich suche nach anderen Lösungen.
Es ist wie gesagt ein ZFS Mirror aus zwei 2TB Platten.

Der Aufbau dauert gleichlang ob ich jetzt über Gigabit Netzwerk den Ordner öffne oder über 54Mbit Wlan.
Ich hole mir jetzt zwei 250GB SSD's und mache eine extra Volume für den Ordner - erste Tests haben eine deutliche Verbesserung gezeigt.

Kann ich sonst noch etwas bei der Samba Freigabe oder am ZFS ändern/einstellen um den Zugriff zu beschleunigen?
Alle Sachen wie Kernel Tuning usw. habe ich aktiviert.
Achja - eine 128GB SSD als Mirror Cache ist schon im System.
Kann ich die nicht konfigurieren, dass die nur ein bestimmtes Verzeichniss cachet?

Das einzige was mich wundert ist der geringe Ram Verbrauch.
Es sind 8GB installiert (bei wie gesagt 2TB Speicherplatz) und ich habe ca. 50% Ram Auslastung.

Danke schonmal.

Hi,

wie ist denn grundsätzlich dein Setup beim kopieren von (großen) Daten bzgl. Geschwindigkeit?
Ist da der Speed in Ordnung? Ca. 100Mb/sec @ 1Gbit.

Gruß

Hm, ok - da stimmt wohl schon was nicht...
Wenn ich eine große Datei kopiere, fängt er für grob 5 Sekunden mit 90MB/s an, fällt dann ab und pendelt zwischen 30MB und 80 MB/s aber er stockt auch immer wieder dazwischen.
Ich habe noch eine zweite NAS im Netzwerk, wenn ich da drauf was kopiere, läuft es mit konstant 80MB/s durch (die ist durch die AES Verschlüsselung vielleicht etwas langsamer).
Ist es eigentlich noch sinnvoll das ZFS Kernel Tune Plugin zu installieren?

Okay, ich würde hier erst Mal 2 Dinge trennen.

1.) ZFS
2.) Samba

Die ZFS Geschwindigkeit kannst du ja hier ohne korrekte SMB Settings gar nicht beurteilen, deswegen würde ich daran erst Mal nichts drehen.

Also Samba: Was hast du als Maximale Client SMB Version eingestellt? SMB3.0? Falls ja, Prüfe mal im GUI System - Info - SMB, mit welcher Samba Version sich dein Client meldet - Falls auch SMB3.0 - Gut!
Ich erreiche bei mir mit SMB3 ohne Verschlüsselung schreibend ca. 100-105Mb/s und lesend knapp 110Mb/s.

Falls die Client Version passt, aber die Geschwindigkeit nicht annähernd in Richtung der Gigabit Verbindung pendelt, müssen wir weiter schauen, aber ich würde zunächst versuchen die maximale Samba Performance zu finden und dann zu beurteilen, ob die Aufbaugeschwindigkeit für das betroffene Verzeichnis ausreichend ist oder nicht.

Momentan habe ich SMB auf NT1 gestellt.
Anders bekomme ich einen zugriff ohne Anmeldung nicht hin.
Ich kann ja heut abend mal testweise umstellen und schauen ob sich etwas ändert.

Den Zusammenhang versteh ich jetzt nicht, für mein Verständnis hat das nichts mit der Authentifizierung, sondern eben mit der größt möglichen Client/Server-Versions-Kombination zu tun.
Ab SMB3 wurde eben Multichannel-SMB eingeführt: Quelle: https://de.wikipedia.org/wiki/Server_Me ... Geschichte

Bei mir brachte der Wechsel von NT1 nach SMB3 auf einem Ubuntu Client einen Geschwindigkeitsgewinn von 10-20Mb/s auf über 100Mb/s.

Hallo mahlzeit,

dein Problem liegt nicht in einer unzureichenden Datenübertragungsgeschwindigkeit (dein Ergebnis ist bei Zugriff über WLAN und GB-Ethernet gleich), sondern liegt an der Art, wie dein Dateibrowser mit dem Netzwerkdateisystem kommuniziert.

Vereinfacht gesagt: Dein Dateibrowser sendet die Anfrage "Gib mir alle Dateinamen aus dem Verzeichnis", das NAS sucht dann die ganzen Dateieinträge zusammen, und sendet das Ergebnis an den Browser zurück.

Der Dateibrowser wartet ab, bis er das Ergebnis hat, und zeigt dir dann die Dateien an. Dabei werden allerdings nur relativ wenige Daten übertragen.

Das Problem dabei ist, daß bei dir eine Fragmentierung der Verzeichniseinträge vorliegt, und damit das Ermitteln der ganzen Dateinamen "etwas" länger dauert.

Das erklärt auch, weshalb dein Problem beim Zugriff auf SSD-Platten nicht auftaucht.

Es stellt sich jetzt die Frage, ob der Einsatz von SSD-Platten dein Problem tatsächlich löst, oder ob es nicht auch eine andere Lösung dafür gibt.

Die Antwort ist etwas tricky, denn sie hängt davon ab, ob es sich um eher statische Datein handelt, oder ob sich diese Daten permanent ändern.

Wenn es sich um statische Daten handelt, reicht ein simpler Backup/Restore Vorgang mittels zfs send/receive auf ein Backup-ZFS-Dateisystem aus.

Da ich der Meinung bin, daß man grundsätzlich ein solches Backup-System haben sollte, ist das imho auch die einfachste Lösung.

Die Anzeige der Dateien wird nach diesem Vorgang ganz erheblich schneller sein.

Etwas anders sieht es aus, wenn sich diese Daten permanent ändern. Dann kann es tatsächlich besser sein, für diesen Datenbereich SSDs einzusetzen.

Zu deinen anderen Fragen:

Ist die Installation des ZFS Kernel Tune Plugins sinnvoll?
Nein.

Es handelt sich um ein Plugin, welches für NAS4Free 9.1 (im Jahr 2012) entwickelt wurde.

Es gibt zwei Dinge, welche mich von einer uneingeschränkten Empfehlung abhalten:

1. Das Plugin ändert Werte an Stellen, die nicht vom Backup der Konfigurationseinstellungen erfasst werden. Das ist doof.
2. Es werden Werte fest eingetragen, welche von neueren NAS4Free-Versionen durchaus anders gehandhabt werden.

Ich hatte hier mal etwas dazu geschrieben: viewtopic.php?f=29&t=5787#p32277

Alerdings ist das auch ein Posting aus 2014, und es bezieht sich auf die damalige NAS4Free-Version.

Heutzutage würde ich daraus höchstens die Werte für

vfs.zfs.arc_min
vfs.zfs.arc_max
vm.kmem_size

übernehmen.

Und auch dies nur, wenn sich daraus tatsächlich eine signifikante Verbesserung der Performance ergibt.

Eine Optimierung der Performance ist ein etwas heikles Thema, da hierbei eine Vielzahl von Faktoren eine Rolle spielen.

Die hast z.B. geschrieben, daß deine Übertragung für 5 Sekunden bei 90MB/s liegt, und danach zwischen 30MB/s und 80MB/s pendelt.

Sind das Werte, welche dir dein Datei-Browser anzeigt, oder die Werte, welche dir der Status-Graph vom NAS meldet?

So habe ich hier (mit einer etws älteren N4F-Version) über CIFS/SMB nur eine Übertragungsrate von ~45MB/s.

Das mag dem einen oder anderen als viel zu wenig vorkommen, spielt aber für meinen Einsatzzweck überhaupt keine Rolle, da ich hier hauptsächlich Daten von SD-Karten auf das NAS kopiere, und die SD-Karten sowieso nur max. 18 MB/s hergeben.

Eine Optimierung von CIFS/SMB würde mit daher kaum etwas bringen.

Für mich sind die Übertragungsprokolle von rsync und NFS viel interessanter, da darüber meine Backups der PCs ablaufen. Da habe ich selbst ohne Optimierungen meine 1 Gb/s zum NAS.

Worauf ich hinaus will:
Optimierungen sind eine spannende Angelegenheit, können aber auch schnell zum Selbstzweck mutieren, ohne eine tatsächlichen Vorteil zu bringen.
Beispiel: eine Datei wird innerhalb von 40 Sekunden auf das NAS übertragen. Nach einer Optimierung kann man sie in der Hälfte der Zeit kopieren (20s).
Auf den ersten Blick ist das eine Verdopplung der Geschwindigkeit.
Was ist aber, wenn ich für das Erstellen dieser Datei vorher zwei Stunden brauche (z.B. beim Videoschnitt)?
Da bringt einem die Optimierung im Gesamtablauf gar nichts.

Man sollte das immer im Gesamtzusammenhang sehen. Und da kann es durchaus sein, daß eine Rate von ~45MB/s völlig ok ist.

Etwas anderes ist es natürlich, wenn das NAS total kraucht.

Grüße
Princo

Princo wrote: dein Problem liegt nicht in einer unzureichenden Datenübertragungsgeschwindigkeit (dein Ergebnis ist bei Zugriff über WLAN und GB-Ethernet gleich)

Hi,
das würde ich nicht unbedingt ausschließen, nur weil WLAN & Gigabit "gleich langsam" sind, kann man ja eben trotzdem sicherstellen, dass das Gigabit auch voll ausgenutzt wird.
Gruß

Danke erst mal an euch beide!

zuerst zu spy0r:

ich habe gestern mal testweise auf SMB2 umgestellt und habe nicht wirklich einen Unterschied bemerkt.
SMB3 habe ich nicht, da ich noch eine 9.2 er Version benutze und SMB3 eh erst ab Win8 unterstützt wird (wir benutzen eigentlich nur Win7 Systeme).

@Princo

Mit dem Win7 Explorer geht es mal besser als früher, da er ja das Verzeichniss Schritt für Schritt darstellt aber insgesamt dauert es trotzdem ewig.
Mit der Fragmentierung könntest du recht haben - ich habe ja für den SSD Test, das ganze Verzeichniss auf eine SSD kopiert, die ich kurz zum testen einzeln als Stripe eingebunden habe.
Da war danach natürlich nichts fragmentiert...

Es handelt sich leider nicht um statische Dateien. Sprich - es werden manchmal alte Dateien geändert bzw. es kommen pro Tag 20-40 neue Dateien hinzu.
Ich habe zwar einen identischen externen Nas4Free Server, auf den mache ich aber das Backup bis jetzt über Rsync.
Bringt mir die umstellung auf zfs send/receive große Vorteile?
Bis jetzt habe ich halt entsprechende Backupscripte mit entsprechender Logauswertung und Mailalarmierung.
Wenn es etwas bringt das Verzeichniss jede Nacht zu ordnen, kann ich das natürlich schon irgendwie machen...
Die SSD's kommen wohl trotzdem rein, da hätte ich nur ein andres problem.

Ich hätte ja dann einen zusätzlichen Pool bzw. ein neues Dataset aber es wäre echt gut wenn sich an der freigegeben Verzeichnissstruktur nichts ändert.
Wäre es möglich, das neue Dataset in das alte Verzeichniss zu "mounten"?

mahlzeit wrote:Mit dem Win7 Explorer geht es mal besser als früher, da er ja das Verzeichniss Schritt für Schritt darstellt aber insgesamt dauert es trotzdem ewig.
Mit der Fragmentierung könntest du recht haben - ich habe ja für den SSD Test, das ganze Verzeichniss auf eine SSD kopiert, die ich kurz zum testen einzeln als Stripe eingebunden habe.
Da war danach natürlich nichts fragmentiert...

Jau, aber bei SSDs fällt sowieso das aufwändige Positionieren der Schreib-/Leseköpfe der Festplatten weg, wodurch sich die Effekte der Fragmentierung kaum bemerkbar machen.

mahlzeit wrote:Es handelt sich leider nicht um statische Dateien. Sprich - es werden manchmal alte Dateien geändert bzw. es kommen pro Tag 20-40 neue Dateien hinzu.

An dieser Stelle wäre es hilfreich, wenn ich wüßte, was das für Dateien sind.
Aus deiner Angabe 130.000 Dateien mit insg. 90GB hätte ich spontan auf so etwas wie einen Mail- oder News-Server getippt. Die Dateien hätten dann eine durchschnittliche Größe von ~700kB, was ungefähr passen könnte.
Die spannende Frage ist nämlich, ob diese Dateien durch eine Softwareanwendung in dieses Verzeichnis geschaufelt werden, oder ob du sie quasi "per Hand" dort verwaltest, also selbst Dateien reinkopierst, und bestehende Dateien editierst.

Für Softwareanwendungen besteht nämlich idR das Problem mit dem verzögerten Anzeigen des Verzeichnisinhaltes nicht, das betrifft eher nur die Dateibrowser. Insofern wäre das durchaus mal von Interesse.

mahlzeit wrote:Ich habe zwar einen identischen externen Nas4Free Server, auf den mache ich aber das Backup bis jetzt über Rsync.
Bringt mir die umstellung auf zfs send/receive große Vorteile?

Ein Beispiel aus der Praxis: Ich habe soeben meine Datenbestand von ~6,6TB auf mein Backupsystem per ZFS- send/receive abgeglichen. Dabei ging es um 8,6 GB an Datenveränderungen.
Die ganze Aktion hat sechs Minuten gedauert.
Natürlich brauchte er diese sechs Minuten nicht dafür, um diese 8,6 GB zu übertragen.
Meine Daten sind in derzeit 31 Datasets organisiert, und pro Dataset muß man 5 Sekunden Bearbeitungszeit einrechnen, auch wenn sich im Dataset keine Daten geändert haben. Dadurch verliere ich insgesamt krasse 2,5 Minuten. Dazu kommt nochmal ungefähr eine Minute für sonstigen Organisationskram hinzu, und mein Backup-System ist über einen langsamen eSATA-Port angeschlossen.
Vergleiche das mal mit den Zeiten, welche du für deine Abgleich per rsync ansetzen mußt.

Jetzt kommt noch eine kleine Gemeinheit mit ins Spiel: Du nutzt ja Backupskripte, um das Backup zu automatisieren. Schau doch bitte mal nach, ob dort der rsync-Parameter "-c" verwendet wird.

Ohne diesen Parameter ist rsync zwar ziemlich schnell, kopiert aber nicht unbedingt alle tatsächlich veränderten Dateien. Mit diesem Parameter kopiert rsync zwar ganz exakt, braucht aber viel länger.

Das Problem ergibt sich daraus, daß rsync ohne den Parameter "-c" veränderte Dateien nur anhand der unterschiedlichen Größe oder eines anderen Dateidatums erkennt. Es gibt aber auch Dateien, die haben immer die gleiche Größe, und das selbe Datum, aber einen anderen Inhalt.
Mir ist das vor zig Jahren mal bei Truecrypt-Containern aufgefallen. Die hatten immer die selbe Größe, und auch immer das gleiche Dateidatum, auch wenn sich der Inhalt komplett geändert hat. In späteren Truecrypt-Versionen wurde dann die Default-Einstellung diesbezüglich geändert, so daß sich das Dateidatum des Containers änderte, wenn der Inhalt verändert wurde.

Damals habe ich viel mit rsync als Backup-Werkzeug gearbeitet, und irgendwann den Parameter "-c" ausprobiert. Ich habe nicht schlecht gestaunt, als auf einmal ein Truecrypt-Container in der Backup-Liste auftauchte, welchen ich seit einem halben Jahr gar nicht angefasst hatte.

Truecrypt ist aber nur ein Beispiel von vielen. Es gibt auch andere Situationen/Anwendungen, bei denen sich das Dateidatum und die Dateigröße nicht ändert, aber der Inhalt ein anderer ist. Da man daß normalerweise gar nicht weiß, kann es sein, daß man beim Einsatz von rsync (oder anderer Kopierprogramme) eine böse Überraschung erlebt, wenn man mal an das Backup ran muß.

An dieser Stelle hätte ich eine Bitte an dich:
Schau mal in deine Backup-Skripte, ob dort der Parameter "-c" verwendet wird.
Wenn er nicht eingetragen ist, dann führe bitte einen Abgleich auf dein Backup-System durch.
Danach fügst du diesen Parameter in dein Backup-Skript ein, und machst einen erneuten Abgleich.
Der wird viel länger dauern.
Kontrolliere danach bitte anhand deiner Logdaten, ob durch den zusätzlichen Parameter "-c" (ohne die Gänsefüßchen) auf einmal zusätzliche Daten übertragen wurden.
Das funktioniert natürlich nur ein einziges Mal, denn danach sollten beide Systeme tatsächlich einen identischen Datenbestand haben.
Es wäre nett, wenn du das mal ausprobieren würdest.

rsync ist ansonsten eine tolle Sache, aber wenn es um den reinen Datenabgleich zwischen zwei ZFS-Dateisystemen geht, sollte man durchgehend zfs send/receive einsetzen.

Während rsync für einen exakten Datenabgleich die Unterschiede zwischen jeder Datei erst aufwändig ermittelt muß, "weiß" ZFS ganz exakt, welche Dateien sich geändert haben, und kann daher sehr viel schneller und genauer übertragen.
Außerdem kann nur zfs send/receive die Eigenschaften deiner Datasets (z.B. Kompression, Quotas) auf dein Backup-System übertragen.
Der Einsatz von rsync zwischen zwei ZFS-Dateisystemen bringt dir eigentlich nur Nachteile.

Der einzige, mir bekannte, sinnvolle Einsatzzweck von rsync bei zwei ZFS-Systemen ist dann gegeben, wenn man ein ZFS-Downgrade durchführen muß. Das hatte ich letztens, als ich bemerkte, daß die NAS4Free Versionen 10.xx für mich nicht einsetzbar sind, und ich auf NAS4Free 9.3 zurück gehen mußte. Dummerweise hatte hatte ich aber meinen ZFS-Pool bereits upgedatet, und mußte meine Daten dann aufwändig auf die niedrigere Version umkopieren. Aber so etwas ist ein absoluter Sonderfall.

mahlzeit wrote:Bis jetzt habe ich halt entsprechende Backupscripte mit entsprechender Logauswertung und Mailalarmierung.

Btw: diesen Vorgang führe ich lieber "per Hand" aus. Dafür habe ich meine Gründe, und ich weiß, daß ich da etwas exotisch bin. Das hat nix mit ZFS oder so zu tun, sondern mit meiner grundsätzlichen Arbeitsweise.

mahlzeit wrote:Wenn es etwas bringt das Verzeichniss jede Nacht zu ordnen, kann ich das natürlich schon irgendwie machen...

Du mußt das nicht jede Nacht machen.
Es reicht erstmal völlig aus, deine Daten per zfs send/receive einmal im Ping-Pong-Verfahren hin und her zu kopieren. Danach sind deine Daten sowohl im Backup, als auch im Echt-Datenbestand defragmentiert.
Die Anzeige des Verzeichnisinhaltes sollte danach ohne Verzögerungen möglich sein.
Danach muß man das eine ganze Weile beobachten.
Es kann sich dann herausstellen, daß das Problem eine ganze Weile lang nicht mehr auftreten wird, einfach weil dein gesamtes NAS komplett defragmentiert wurde, und sich die einzelnen Änderungen in diesem Verzeichnis nicht mehr so sehr auf die Anzeige des Verzeichnisses negativ auswirken werden.

Das wäre die ideale Vorgehensweise, denn dadurch hättest du eine klar definierte Ausgangslage geschaffen.

Fallls sich dann aber zeigen sollte, daß sich der alte Zustand innerhalb weniger Wochen erneut einstellt, sollte man andere Maßnahmen ergreifen.

"Andere Maßnahmen" bedeutet erstmal, daß man diesen speziellen Datenbestand auf einen anderen ZFS-Pool transferieren sollte.
Im Prinzip hast du das mit deine SSDs ja bereits durchexerziert, aber meiner Meinung nach, ist das derzeit nicht unbedingt nötig.

mahlzeit wrote:Die SSD's kommen wohl trotzdem rein, da hätte ich nur ein andres problem.

Ich hätte ja dann einen zusätzlichen Pool bzw. ein neues Dataset aber es wäre echt gut wenn sich an der freigegeben Verzeichnissstruktur nichts ändert.
Wäre es möglich, das neue Dataset in das alte Verzeichniss zu "mounten"?

Nein, das wäre keine gute Idee.
Wir müssen an dieser Stelle zwischen der ZFS-Dateistruktur (Pools, Datasets) und dem, was du als Freigabe definierst, unterscheiden.
Das eine ist eine technisch bedingte Struktur, und das andere ist eine organisatorische Struktur.
Bei genauerer Betrachtung kann es sich u.U. als sinnvoll erweisen, für dieses spezielle Verzeichnis eine eigene Freigabe zu erstellen, und die Anwendung darauf zu konfigurieren. Danach kannst du den physikalischen Speicherort der Daten jederzeit ändern, und mußt nur die Freigabe entsprechend konfigurieren, brauchst aber keine Änderungen in der Konfiguration der zugreifenden Anwendung vornehmen.

Verstehst du, was ich meine?

Grüße
Princo

Ui - das war jetzt ja ne echt ausführliche gute Antwort...

Vielen Dank für deine Mühe und die Zeit die du investiert hast!

Grundsätzlich zur Software:
Es handelt sich um eine CAD/CAM Software.
Die einzelnen Daten haben eine Größe von im Schnitt 1MB. Manche nur ein paar KB, manche auch 20-30MB aufwärts.
Hab mal geschaut - es sind 9000 Dateien über 2MB Größe und vielleicht ein paar hundert die von 20 - bis max 100MB gehen.

Im CAD Programm gibt es eine Kommandozeile mit der einfach mit Load bzw. Save geladen/gespeichert wird.
Das geht auch ohne Zeitverlust.
Es kommt aber öfters vor, dass an alten Werkzeugen etwas geändert wird, dann wird über den Explorer gesucht, was es alles zu der Werkzeugnummer gibt.
Die Dateien sind alle nach einer Logik aufgebaut.
Sprich w3035502 ist die Original Düsenplatte von Werkzeug 3035
w3035502-ansichtz+ ist die Datei die zum Vorfräsen dieser Platte erstellt worden ist.

Im Programm kann ich mehrere Pfade angeben, d.h. die selbstgenerierten Dateien, landen automatisch im Verzeichniss Cad2, Cad3... je nach Art der Datei.
Alles was wir von Hand erstellen/ändern, landet im Hauptordner Cad
Wir könnten natürlich für jedes Werkzeug einen eigenen Unterordner erstellen aber dann müssten wir für jede Lade und Speicheraktion über den "Datei öffnen" Dialog gehen - das wollen wir vermeiden, da wir mit der bisherigen Methode viel schneller sind.

Das Backup startet jede Nacht um 1 und ist grob nach ner halben Stunde mit 5000kBit Upload fertig.
Ich habe mal geschaut - Rsync läuft ohne Parameter c, sprich da sollten wir was ändern...
Das Backup läuft auch nicht direkt über Nas4Free ab, sondern über eine virtuelle Maschine.
Ich habe unseren Oracle Datenbankserver mit den vorhandenen Scripten vom alten Programmierer hier einfach übernommen und nur leicht angepasst.
Es spricht aber nichts dagegen, es mal vernünftig über die neuen Möglichkeiten zu realisieren.
Ich habe am Wochenende auch mal testweise einen FreeNas Server installiert - da gibt es in den Menus ja wunderbar die ZFS Replikations Funktion - wie realisiere ich das hier?
Einfach unter "Command Scripts" die entsprechenden geschriebenen Scripte starten?

Das Cad Verzeichniss ist leider kein eigenes Dataset bzw. eine eigene Freigabe, sondern Teil eines größeren Datasets (das wurde vom alten Server so übernommen und ich dachte auch nicht irgendwann auf solche Probleme zu stossen).
Sprich wenn ich ein zfs send/receive mache betrifft das ca. 500GB und die Gegenstelle hat nur 1000kBit Upload - nicht so gut.

Obwohl - ich habe hier im lokalen Netzwerk ja noch einen Nas4Free Testserver... da könnte ich ja eigentlich den send/receive Transfer ausführen.
Dann wäre der externe Backupserver zwar noch fragmentiert aber das spielt ja erstmal keine Rolle...

Sollte ich dem Cad Verzeichniss ein eigenes Dataset geben (egal ob durch eine extra SSD oder einfach so), kann ich zwar die Pfade im Cad Programm entsprechend ändern, wir haben aber dummerweise auch einige selbergeschriebenen Scripte und kompilierte Delphi Tools, die die Pfade entsprechend benötigen (sprich alles ändern).
Das Cad Programm ist Script fähig, was bei uns richtig ausgenutzt wird...

Ja, ich verstehe was du meinst

Hallo mahlzeit,

Vielen Dank für die zusätzlichen Infos.
Dein Problem läßt sich auf eine recht triviale Art lösen.
Wenn du mir jetzt noch den Namen deines Pools verrätst, könnte ich dir eine funktionierende Step-by-Step-Anleitung geben.
Grüße

Princo

Na da bin ich mal gespannt

Der Pool heisst ganz einfach: Daten

Hey Princo - du scheinst grad wenig Zeit zu haben aber vielleicht findest du noch kurz Luft mir deine Lösung zu zeigen - wäre echt toll

Danke nochmal!

Hallo mahlzeit,

leider habe ich tatsächlich gerade etwas wenig Zeit, was dazu führt, daß ich bei einigen Projekten leider nur mit erheblicher Verzögerung antworten kann.
Das schmerzt mich sehr, und ich kann da nur um Verständnis bitten.

Ich fasse zuerst einmal die bisher bekannten Fakten zusammen:

1. Es handelt sich um eine Produktivumgebung.
2. Du hast ein Haupt-NAS, auf dem deine ganzen Daten liegen.
3. Du hast ein Backup-NAS, welches über eine "dünne" Leitung angeschlossen ist.
4. Du hast ein Test-NAS, welches sich im gleichen Netz befindet.
5. Du setzt NAS4Free in der Version 9.2 ein.
6. Du hast beim Haupt-NAS ein Performance-Problem, welches sich hauptsächlich bei der Verzeichnisanzeige auswirkt, und welches ich auf Fragmentierung zurückführe.
7. Dein Backup läuft derzeit über eine virtuelle Maschine.
8. Als Backup-Protokoll wird rsync verwendet.

Ein paar Fragen stellen sich mir aber noch:

1. Ist NAS4Free auf dem Haupt-NAS als Full-, oder als Embedded-Version installiert?
2. Wie hoch ist der Füllstand des Pools "Daten", in Prozent?
3. Wo liegt die VM, was treibt die sonst so, und ganz besonders: was hat sie außer dem Backup noch speziell mit dem Haupt-NAS zu tun?
4. Wäre es möglich, die Platten aus dem Test-NAS (vorübergehend) zusätzlich in das Haupt-NAS einzubauen?

Dinge, die du jetzt schon tun kannst:
1. In der Web-GUI vom Haupt-NAS:
Gehe zu Disks|ZFS|Snapshots|Snapshot, stelle den Filter auf "All" und klicke auf "Apply".

Werden dir dort Snapshots aufgelistet?

2. Gehe zu Disks|ZFS|Pools|Information
Gibt es dort beim Pool "Daten" eine Zeile "scan: scrub repaired...in"?
Wenn ja, dann notiere dir die benötigte Zeit, welche gleich nach "in" steht ($h$m).

3. Gehe zu Disks|ZFS|Pools|Tools, wähle als Command "scrub" aus, und beim Pool sollte "Daten" ausgewählt sein. Klicke dann auf "Send Command!".
Das kannst du am Besten abends starten. Dieser Vorgang wirkt sich zwar kaum auf die Performance aus, aber mir geht es um die dafür benötigte Zeit, und da ist es besser, wenn nicht zig-Leute währenddessen auf das NAS zugreifen.
Den Scrub-Lauf kannst du übrigens über Disks|ZFS|Pools|Information beobachten.
Dieser Vorgang wird ~3h dauern.

Es kann sein, daß du bereits regelmäßig Scrub-Läufe machst, dann brauchst du das jetzt nicht extra ausführen. Es wäre dennoch interessant, welche Zeit dein System dafür braucht.

Ich erwähne das deshalb, weil evtl. auch jemand anders das gleiche Problem hat, und evtl. auf diesen Thread stoßen könnte.

Warum ist der Scrub-Lauf so interessant?

Für einen vorher/nacher Vergleich.

Auch wenn ich glaube, daß bei dir eher Verzeichnis-Fragmentierung vorliegt, können natürlich auch Dateien fragmentiert sein. Das hängt mit der bisherigen Daten-Historie deine Pools zusammen, und läßt sich nur schwer mit anderen Mitteln herausfinden.

Nach dem Backup/Restore-Vorgang wirst du wieder eine Scrub-Lauf durchführen, und evtl. wird dieser Task dann schneller abgearbeitet werden.

Das sind wertvolle Informationen, welche dir beim späteren Management des Haupt-NAS nützlich sein können.

Das weitere Vorgehen:

Es hängt von den Antworten auf meine o.a. Fragen ab.

Normalerweise bevorzuge ich in diesen Fällen eine Vorgehensweise, welche die vorhandenen Ressourcen (z.B. den Test-Server) möglichst effektiv nutzt, und dabei den laufenden Produktiv-Betrieb nur minimal berührt.

Daher würde ich die beiden Problemfelder "Performance" und "externes Backup" getrennt voneinander angehen.

Dummerweise lassen sich aber beide Problemfelder aber sogar auf eine Schlag lösen

Mögliche Vorgehensweise (schematisch):
1. Einbau der Festplatten aus dem Test-NAS zusätzlich in das Haupt-NAS.
2. Die Festplatten aus dem Test-NAS werden als Pool "Backup" eingerichtet.
3. Transfer des Pools "Daten" mittels zfs send/receive auf den Pool "Backup" innerhalb des Haupt-NAS.
4. Während des Vorgangs aus 3. kann ganz normal mit den Daten weitergearbeitet werden.
5. Nachsynchronisation der mittlerweile veränderten Daten von "Daten" nach "Backup" auf dem Haupt-NAS. Das geht dann ratzfatz.
6. Umbenennen des Pools "Daten" (fragmentiert) nach "DUMMY".
7. Umbennenen des Pools "Backup" (defragmentiert) nach "Daten".

Jetz hast du auf dem Haupt-NAS eine defragmentierten Pool "Daten", der allerdings auf den Festplatten aus dem Test-NAS liegt.

Also weiter im Text:

8. Löschen des Pool "DUMMY", und Neuanlage des Pools "Backup" auf den jetzt freien Platten.
9. Transfer des Pools "Daten" (defragmentiert) auf den Pool "Backup".
10. Währenddessen kann mit dem Pool "Daten" ganz normal weitergearbeitet werden.
11. Nachsynchronisation der mittlerweile veränderten Daten von "Daten" nach "Backup".
12. Umbenennung des Pools "Daten" nach "DUMMY".
13. Umbenennung des Pools "Backup" nach "Daten".
14. Umbenennung des Pools "DUMMY" nach "Backup".
15. Jetzt ist alles wieder an seinem Platz. Der Pool "Daten" ist defragmentiert, und befindet sich auf den ursprünglichen Festplattten. Auf den Festplatten aus dem Test-NAS befindet sich der Pool "Backup", und ist auch defragmentiert.

Diese Methode bringt dir die geringste Downtime auf dem Haupt-NAS ein, und du brauchst keine Nachtschichten schieben

Außerdem hast du jetzt folgende Option:
16. Du baust die Platten aus dem Test-NAS mit dem Pool "Backup" in das externe Backup-NAS ein.
17. Du benennst den Pool "Backup" auf dem externen Backup-NAS in "Daten" um.
18. Du richtest dein Backup auf "zfs send/receive ein" (u.U. vorerst manuell).
19. Du baust die Platten aus dem externen Backup-NAS in dein Test-NAS ein.

Welchen Vorteil bringt dir das?
Nun, wenn du so vorgehst, hast du erstmal überall defragmentierte Dateisysteme.
Dann hättest du auch ein lokales Backup deines Haupt-NAS geschaffen.
Au0erdem sind alle drei Pools (im Haupt-NAS, im Test-NAS, und im Backup-NAS) über eine gemeinsamen Snapshot "logisch miteinander verbunden".

So kannst du dann zukünftig mit ganz einfachen Befehlen den Datenbestand vom Haupt-NAS sowohl auf das Test-NAS, als auch auf das Backup-NAS synchronisieren.

Selbstverständlich kannst du das Test-NAS auch jederzeit für andere Aufgaben verwenden, dann ist halt u.U. ein kompletter Datentransfer vom Haupt-NAS auf das Test-NAS fällig.

Der wichtigste Punkt bei der ganzen Aktion ist aber dieser hier:
Du bist gezwungen mit Snapshots zu arbeiten.
Snapshots sind DAS Killerfeature von ZFS.
NAS4Free bietet die Möglichkeit, mit Auto-Snapshots zu arbeiten (tägliche rekursive Snapshots auf Datasets).
Damit kannst du fast 100% der Anwendungsfälle erschlagen, bei denen du normalerweise auf die Daten auf das Backup-NAS zugreifen müsstest.
Beispiel: versehentlich gelöschte Datei, erst nach drei Tagen bemerkt.
Diese Datei holt man sich einfach aus den Auto-Snapshots auf dem Haupt-NAS zurück.

Auf das Backup-NAS wirst du i.d.R. nur zugreifen müssen, wenn:
a) Die Firma bis auf die Grundmauern niedergebrannt ist.
oder
b) Das Haupt-NAS geklaut wurde.

Wie geht es weiter?
Ich habe extra noch keine Step-by-Step-Anleitung gegeben, da noch ein paar Fragen offen sind, und ich dir erstmal das Migrationskonzept verklickern möchte.
Die o.a. Schritte solltest du mal gedanklich durchspielen, und nachfragen, wenn etwas unklar ist.
Bei der Problemlösung bin ich den "Admins-Way" gegangen, d.h. ich habe alle zur Verfügung stehende Ressourcen (Systeme und Festplatten) genutzt, und auf den minimalen Aufwand für den Datentransfer optimiert.
Das wirbelt zwar die Festplatten etwas durcheinander, aber es spart viel Zeit.
Hat man das Prinzip aber verinnerlicht, dann kann man die Festplatten ohne Probleme auch leicht zurück tauschen.

Welche NAS4Free-Version?
Du hattest geschrieben, daß ihr derzeit eine 9.2 Version nutzt.
Die o.a. Vorgehensweise funktioniert zwar prinzipiell mit allen N4F-Versionen (wobei es aber einige wichtige Detailunterschiede gibt), aber ich kann derzeit nur den Einsatz bis zur Version 9.3 empfehlen.
Diese Version wurde jedoch in den letzten Tagen eingestellt.

Leider gab/gibt es in den N4F-Versionen 10.X eine sehr unangenehme Einschränkung, was das Arbeiten mit Snapshots betrifft (kein direkter Zugriff per SMB auf Snapshot-Verzeichnisse mehr möglich).

Daher würde ich dir empfehlen, derzeit entweder bei deiner derzeit eingesetzten Version zu bleiben, oder maximal auf die Version 9.3.0.2 (revision 1955) upzugraden, welche offiziell nicht mehr verfügbar ist.

Diese Einschränkung scheint mir eher unabsichtlich geschehen zu sein, und die allermeisten User werden das gar nicht bemerken, aber für mich stellt das derzeit ein recht großes Problem dar, da ich sehr aktiv mit Snapshots arbeite.

Also werde ich die derzeit aktuelle Version 10.2.0.2.2332 dahingehend testen müssen, um zu sehen, ob das Problem dort noch besteht.

An der Vorgehensweise ändert dieser Fakt jedoch nichts.
Es wäre gut, wenn du die o.a. Fragen noch klären könntest.

Grüße
Princo

mal was ganz anderes, hast Du schon versucht in Services|CIFS/SMB|Settings --> Auxiliary parameters
zu verwenden?

Kurz zu crowi:

Habe ich gerade mal versucht, scheint minimal was zu bringen - behalte ich mal im Auge ob der Chef und die anderen morgen eine Veränderung/Verbesserung feststellen.

@Princo
Ich schreibe ich gerade mal die Antwort zusammen.
Schonmal vorab mal wieder meinen äusserten Dank für deine Mammutantwort - ich wollte dir bewusst keine unnötige Zeit rauben aber nach deiner Aussage "Dein Problem läßt sich auf eine recht triviale Art lösen." dachte ich, es braucht keine lange Antwort von dir...

Hey Princo

Wie schon erwähnt vielen vielen Dank für deine Mühe!

Mal zu den einzelnen Punkten:
Die Faktenzusammenstellung passt soweit.
Das HauptNas ist mit VDSL50/5 angebunden (innerhalb natürlich Gigabit) am BackupNas liegt nur 15/1 an - reicht aber um mit 5000 upload zu pushen und der Rsync läuft ja nicht lang.

Zu den Fragen:

1. Ist NAS4Free auf dem Haupt-NAS als Full-, oder als Embedded-Version installiert?

Embedded 9.2.0.1 972

2. Wie hoch ist der Füllstand des Pools "Daten", in Prozent?

Daten 1.81T 1.38T 418G 75% 1.00x
Wobei da Test und Temp Verzeichnisse enthalten sind die nicht gesichert werden.
Auf dem BackupNas sind es 51%
Es liegen übrigens schon mehrere 5TB Platten da, die eh demnächst die 2TB ablösen sollten - vielleicht auch eine wichtige Sache wegen der Vorgehensweise

3. Wo liegt die VM, was treibt die sonst so, und ganz besonders: was hat sie außer dem Backup noch speziell mit dem Haupt-NAS zu tun?

Die VM liegt auf dem Dataset "Virtualbox"
Jetzt kommt das Special... und du wirst dir deinen Teil denken
Das ist im Prinzip mein alter Server den ich vom Dateimanagement und den Freigaben "entbunden" habe.
Da läuft unsere Oracle Datenbank drauf (ist also soweit sehr wichtig!) und die Rsync Skripte.
Von der Oracle Datenbank wird stündlich ein Datenexport gemacht und auf einen FTP geschoben.
Nachts wird dann auf dem Backupserver die letzte Exportdatei importiert.
Zudem (wie gesagt - ich habe unser bisheriges gut funktionierendes Konzept einfach übernommen), läuft darauf BackinTime für die Zeitsicherung.
Wir haben seit ein paar Jahren die entsprechenden Zeitverzeichnisse und ich wollte es erstmal so beibehalten.
Ich habe am Anfang mal die Snapshots aktiviert aber es hat irgendwie viel mehr Speicher benötigt als die BackinTime Variante, deshalb habe ich es erstmal wieder verworfen... macht aber nichts wenn man im Laufe dessen (und mit den großen Platten) darauf zurückkommt

4. Wäre es möglich, die Platten aus dem Test-NAS (vorübergehend) zusätzlich in das Haupt-NAS einzubauen?

Ich nehm dann wie oben erwähnt einfach die neuen Platten und wir können uns vielleicht dadurch Zwischenschritte sparen.
Den Rechner den ich gerade für das TestNas benutze, brauche ich bald für was anderes - sprich als zukünftiges Backup fällt der raus.

Werden dir dort Snapshots aufgelistet?

Nein - die habe ich wieder (wie oben beschreiben) deaktiviert und nicht mehr benutzt

Gibt es dort beim Pool "Daten" eine Zeile "scan: scrub repaired...in"?
Wenn ja, dann notiere dir die benötigte Zeit, welche gleich nach "in" steht ($h$m).

Ich habe erst vor kurzem um einen Festplattenausfall zu simulieren eine Platte getauscht.
Sprich ein Resilver für 1.45TB hat 8h50min gebraucht, ein Scrub war nicht aufgelistet.
Ok - habe einen Scrub gestartet - das dauert aber wesentlich länger als 3h:
scrub in progress since Mon Feb 29 18:04:15 2016 247G scanned out of 1.38T at 37.4M/s, 8h50m to go

Die o.a. Schritte solltest du mal gedanklich durchspielen, und nachfragen, wenn etwas unklar ist.

Die meisten deiner Schritte sind mir soweit klar und kann ich leicht abgewandelt (also ohne TestNas aber mit neuen großen Platten) so durchspielen.
Die Downtime ist auch nicht so schlimm - ich wohne direkt neben der Arbeit und am Wochenende kann ich da unbesorgt ran.
Vielleicht bestelle ich auch nochmal einen Dell T20 (oder was auch immer gerade gut ist), damit ich wie du vorschlägst ein zweites Reservesystem habe.

Den Umstieg auf Snapshots kann ich mit dem Umstieg auf die großen Platten auch problemlos vollziehen (ja, ich weiss dass Snapshots theoretisch nicht viel Platz brauchen).

Wie läuft eigentlich die send/receive Sache ab?
Bei FreeNas gibts dafür extra Menüpunkte und auch sonst finde ich FreeNas in dem Bereich Anwenderfreundlicher aufgebaut.
Geht das nur über die Konsole?

Ich hoffe ich habe auf die schnelle nichts zum beantworten übersehen.
Mein eher größeres anliegen wäre ja noch die SSD Sache (die eh schon hierliegen).
Da sich in Sachen Geschwindigkeit wohl am meisten etwas ändert, wenn das betreffende Verzeichniss auf eine SSD kommt, wäre es meiner Ansicht nach immer noch das beste dafür einen zweiten SSD Mirror nur für dieses Verzeichniss einzubauen.
Dann habe ich da ja immer noch das Problem, dass es dann ein extra Dataset wäre und die Verzeichnisse sich ändern würden.
Dafür wirst du wohl keine Lösung haben?

Danke!

Hallo mahlzeit,

zuerst einmal der "Beweis", daß sich der Datentransfer mit nur zwei Befehlen durchführen läßt:
Das wäre im Kern die Vorgehensweise für den Fall, daß sich der Pool "Daten" und der Pool "Backup" auf dem gleichen System befinden (lokales Backup). Dabei handelt es sich um die Befehle für den Erstabgleich.

Mit diesen Befehlen wird der Pool "Daten" mit allen seinen Eigenschaften auf den Pool "Backup" übertragen, d.h. auch die Einstellungen für Kompression, Zugriffsrechte, usw. werden dabei mit transferiert.
Dabei gibt es leider einen klitzekleinen Haken in den älteren ZFS-Versionen, wie sie bei der Version 9.2 eingesetzt werden: Es wird auch die Einstellung für den Mountpoint mit übertragen, d.h. beide Pools haben dann den Mountpoint "/mnt/Daten".

Das ist natürlich nicht erwünscht, und deswegen sollte man gleich nach dem Start des Erstabgleichs mit einer zweiten Terminalsession den Mountpoint des Backup-Pools wieder auf "/mnt/Backup" setzen.

Das macht man einfach mit dem Befehl
Mit diesem Befehl kann man dann testen, ober der Mountpoint richtig gesetzt wurde:
In den neueren NAS4Free-Versionen (ab 9.3) besteht dieses Problem nicht mehr. Da wird der Mountpoint von "Backup" nicht verändert.

Der Mountpoint muß übrigens nur beim Erstabgleich geändert werden, bei den nachfolgenden inkrementellen Abgleichen bleibt er auf der korrigierten Einstellung.

Auch wenn diese beiden Befehle im Prinzip für den Erstabgleich ausreichen, bevorzuge ich jedoch eine etwas ausführlichere Vorgehensweise:
So kannst du sehr schön auf der Kommandozeile (ssh-Session) sehen, was die Kommandos bewirkt haben.

Nicht vergessen: nach dem Start der echten Datenübertragung muß den Mountpoint des Backup-Pools mit Hilfe einer zweiten ssh-Session geändert werden!
Für die Datenübertragung spielt der Mountpoint übrigens keine Rolle, aber wenn man während der Übertragung weiter mit dem System arbeiten möchte, würden die geänderten Daten u.U. auf dem falschen Pool landen, und das wäre doof.

Hier jetzt gleich die Befehle für die späteren inkrementellen Abgleiche:
Erklärbär-Sektion:
Es handelt sich um die Beschreibung für eine 1:1 Kopie eines Pools innerhalb eines lokalen Systems.
Durch Abwandlung des zfs send/receive Befehls kann ein Abgleich über das Netzwerk realisiert werden.
Für den Abgleich über das Netzwerk kann sowohl das ssh-Protokoll verwendet werden (z.B. Abgleich auf das externe NAS über das Internet, verschlüsselt),
oder es kann auch netcat eingesetzt werden (i.d.R. im lokalen Netzwerk, unverschlüsselt und daher sehr schnell).
Eine weitere Abgleichmöglichkeit wäre übrigens über eine Transportfestplatte möglich. Dafür brauchen die Systeme nicht über ein gemeinsames Netzwerk miteinander verbunden sein.

Dein Verweis auf Freenas: Ja, es ist richtig, daß es dort eine Option für den automatischen Datenabgleich gibt.
An dieser Stelle schlagen zwei Herzen in meiner Brust: einerseits weiß ich, daß sich viele Leute eine solche Option wünschen, andererseits ist ein automatisiertes Backup des Hauptsystems etwas, was ich selbst auf gar keinen Fall betreiben möchte.
Für mich hat das Backup einen so hohen Stellenwert, daß ich es nicht als "Fire and forget"-Lösung sehe, welche man einmal einrichtet, danach vergißt, und darauf vertraut, daß es für alle Zeiten funktioniert.

Es gibt übrigens ein Skript, welches diese Funktion zumindest im Ansatz umsetzt, allerdings arbeitet es nicht so, wie ich es gerne hätte, und daher kann ich den Einsatz aktuell auch nicht empfehlen. Vielleicht findet sich ja ein Hacker, der das mal entsprechend anpasst.

Vielen Dank übrigens für die ganzen Informationen. Für mich deutet alles darauf hin, daß du ein ganz massives Problem mit Fragmentierung hast.

Das Umkopieren der Daten wird das zwar zumindest vorübergehend beheben, aber für eine richtige Lösung sollte man die Datenorganisation etwas genauer betrachten. Es kann bei dir durchaus sinnvoll sein, mit mehreren Datenpools auf dem Haupt-NAS zu arbeiten, aber das sollten wir später klären.
Daher würde ich aktuell empfehlen, die Kopieraktion auf einen 5TB-Mirror durchzuführen.
Möglicherweise willst du dir aber ein 3x5TB RaidZ1 o.ä. einrichten.
Ob das sinnvoll ist, läßt sich nicht so leicht beantworten. Im Allgemeinen rate ich aber vor übergroßen Pools eher ab.
Mein Bauchgefühl sagt mir, daß das eigentliche Optimierungspotential im Bereich deiner VM-Lösung versteckt ist.

Hinweis: die obigen Routinen behandeln nur das reine Umkopieren (und Defragmentieren) der Daten. Das Umbenennen der Pools ist dort noch nicht beschrieben.

Grüße
Princo