[Sammelthread] ZFS Stammtisch

[gea]

grundsätzliche Punkte

- Special Vdev geht nicht als Raid-Z, nur als Mirror
- Special Vdev kann man oft entfernen (je nach Pool Layout)
- mechanische Platten sind immer powerloss save weil ein schreibender Prozess volle Kontrolle hat
(nur SSD brauchen plp nicht nur wegen Cache sondern wegen Block update mit read/modify/write,
Trim oder Garbage Collection)
- Im Mirror ist das Risiko ohne plp viel geringer weil es bei Problemen eine zweite Kopie gibt

 

[fallenguru]

- mechanische Platten sind immer powerloss save weil ein schreibender Prozess volle Kontrolle hat

Naja. Mit write cache auch nur, wenn sie sync writes / flushes / barriers tatsächlich korrekt umsetzt.

- Im Mirror ist das Risiko ohne plp viel geringer weil es bei Problemen eine zweite Kopie gibt

Gemeint ist nicht "mit Mirror lieber kein PLP", sondern "bei einem Mirror tut fehlendes PLP nicht so weh", oder? Die Formulierung ist irgendwie nicht ganz eindeutig.

 

[gea]

Eine mechanische Platte die es nicht zuläßt dass bestätigte Schreibvorgänge tatsächlich auf Platte sein müssen ist defekt oder buggy. Der Plattencache ist ja kontrollierbar und die Platte macht nichts im Hintergrund auf eigene Veranlassung wie bei SSDs.

"bei einem Mirror tut fehlendes PLP nicht so weh" ist korrekter.
Genauer wäreie Wahrscheinlichkeit eines Datenverlusts ist sehr gering da beide Mirrors nacheinander beschrieben werden. Der ZFS CoW Schreibvorgang ist daher nür gültig wenn beide Platten korrekt geschrieben haben. Die Wahrscheinlichkeit dass auf beiden Platten beim Lesen ein bestimmter Datenblock korrupt ist, ist sehr niedring. ZFS kann ja erkennen ob ein Datenblock gut ist oder nicht.

 

[fallenguru]

Eine mechanische Platte die es nicht zuläßt dass bestätigte Schreibvorgänge tatsächlich auf Platte sein müssen ist defekt oder buggy.

Ja, eh. Kam halt, früher zumindest, bei Consumer-HDDs zuhauf vor. Genau wie jetzt bei Consumer-SSDs. :-p

da beide Mirrors nacheinander beschrieben werden.

Ah, ok, das wusste ich nicht. Danke.

 

[gea]

Nur bei einem analogen Lichtschalter passiert etwas gleichzeitig.
In der digitalen Welt geht alles sequentiell, nacheinander, selbst bei Hardwareraid. Bei ZFS werden Platten völlig unabhängig mit Datenblöcken, je mit eigenen Prüfsummen beschickt.

 

[pwnbert]

- Special Vdev geht nicht als Raid-Z, nur als Mirror

Ne, meinte zum Z1 ein Mirror-SVDEV dazu machen.

Genauer wäreie Wahrscheinlichkeit eines Datenverlusts ist sehr gering da beide Mirrors nacheinander beschrieben werden. Der ZFS CoW Schreibvorgang ist daher nür gültig wenn beide Platten korrekt geschrieben haben. Die Wahrscheinlichkeit dass auf beiden Platten beim Lesen ein bestimmter Datenblock korrupt ist, ist sehr niedring. ZFS kann ja erkennen ob ein Datenblock gut ist oder nicht.

Spannende Info.


Aber, kann man ein SVDEV jetzt auch im nachhinein hinzufügen?

 

[fallenguru]

Aber, kann man ein SVDEV jetzt auch im nachhinein hinzufügen?

Ja.

 

[pwnbert]

Uh, ich fürchte, ich muss Geld ausgeben.

Wie ist das dann mit der "Migration" der Metadaten?
Die "kleinen" Files werden aufs SVDEV geschrieben wenn sie neu geschrieben werden, oder?

 

[Icenice]

Hinzufügen ging doch schon immer(?), nur entfernen ist wohl nicht drin? Wenn ich jetzt mein svdev von 2x SATA auf 2x nvme ändern möchte, darf ich also alles neu erstellen?

 

[gea]

Vdev entfernen geht wenn kein Raid-Z vorhanden ist (nur Solaris ZFS kann das) und alle vdevs gleichen ashift haben.

Kleine Dateien (< small blocksize z.B. 128K) und Metadaten landen beim Neuschreiben auf dem special vdev.Vorhandene Daten bleiben wo sie sind bis zum nächsten Ändern (wg CoW)

Sata -> NVME ist kein Problem (zpool replace). Die NVMe muss halt mindestens die gleiche Größe haben und gleiches ashift unterstützen

 

[Icenice]

In meinem Fall wären die NVMes bzw. Optanes kleiner. Also wird es doch wieder eine kleine Kopierorgie. Irgendwann, wenn ich Zeit für sowas habe, wird der Umbau dann gemacht. Im Prinzip weiß ich gar nicht, ob es was bringen würde. Jedenfalls komme ich im Moment trotz 8x16 TB Exos als Z2 nicht über 750 MB/s über Netzwerk hinaus. Eher so 700 im Durchschnitt.
Da sollte doch eigentlich mehr gehen?

 

[pwnbert]

Geht ja eher ums Indexieren und so Kram, Kleine Dateien und so...

 

[gea]

Wenn man sich mal einen Benchmark über Datenblockgröße z.B. Crystal anschaut, sieht man schnell dass die Performance bei kleineren Blöcken z.B. bis 64K unterirdisch schlecht wird. Genau da soll das special vdev helfen.

700 MB/s im 10G Netzwerk würde ich als sehr gut ansehen. Meist landet man unter 500 MB/s ohne Tuning und das mit ordentlich CPU Last. Wenn man wirklich deutlich mehr will oder braucht (z.B. Videoschnitt) dann geht das nur mit RDMA z.B. SMB Direct und RDMA Nics. Damit wird das NAS fast so schnell wie eine lokale NVME (wenn der Pool das hergibt)

 

[fallenguru]

Damit [mit RDMA] wird das NAS fast so schnell wie eine lokale NVME (wenn der Pool das hergibt)

Oho! Muss ich gleich einmal schauen, was es heutzutage an high-speed Storage-Anbindung gibt. Für SMB/CIFS brauch ich's eigentlich nicht, aber sowas wie iSCSI mit annähernd lokaler Geschwindigkeit wär natürlich ein Traum.

 

[VirtuGuy]

dann am besten gleich "nvme-of"

 

[gea]

Das ist wie iSCSI als Blockstorage perfekt für DAS Aufgaben geeignet. Die häufigste NAS Nutzung ist aber shared storage über NFS und vor allem SMB, für high performance halt mit RDMA statt ip basiert. Bei SMB nennt sich das SMB Direct, siehe die ganzen aktuellen threads hier zu dem Thema (ist gerade ein Top Thema) in100G Netzwerk, Hyper-V, Proxmox oder ZFS on Windows. Aktuell funktioniert das nur mit Windows Server und Clients gut (wurde von Microsoft für Windows Server entwickelt). Besterino versucht gerade SMB direkt mit ksmbd unter Linux zum Laufen zu bringen.

Falls man in der Windows Welt unterwegs ist z.B. wegen Adobe, kann man SMB und DAS kombinieren mit SMB Direkt für SMB und falls man lokales Blockstorage braucht mit .vhdx virtual harddisk auf dem SMB Server. Ist vom Handling so wie man es sich wünscht, tut einfach und ist auch für Raid over Lan geeignet.

sehe gerade

[Sammelthread] - Der 100Gbit Netzwerk Thread, ein bisschen 40gbit und „beyond“ ;)

Ok, so einer bist du. ;) Evtl. für die etwas nicht so Käferlastigen: Damit kann man, sofern das PW nicht bekannt ist, bruteforce machen. Sofern der SFP frei ist bzw. das PW bekannt, ist das easy. Ist in erster Linie auch nur nen Prommer, der eben noch nen xSFP daughter board dabei hat. (da...

www.hardwareluxx.de

 

[kandamir]

Hi, ich habe ein Problem dabei, auf einem Xerox C325 MFP die Scan2Network Funktion einzurichten. Der Scanner soll auf ein vorhandenes SMB Share auf meiner Napp-It Instanz scannen. Sowohl Napp-It als auch der C325 sind im gleichen Netz, das Share ist auf dem C325 in der Notation \\server\share angegeben und der verwendete Nutzer hat auch ein korrektes Passwort. Auf die gleiche Rt und Weise habe ich schon einen Dokumentenscanner von Brother angebunden, auf‘s selbe Share mit dem selben User. Funktioniert dort ohne Probleme. Auf dem C325 kann ich das angegebene Share browsen - zumindest theoretisch. Da meckert die Oberfläche über fehlende Rechte. Bei der Angabe des Users hingegen kann man die Verbindung testen - da wir gemeckert, dass der SMB Share nicht korrekt sei. Beides jeweils x-mal geprüft, statt Rechnername auch mal die IP von Napp-It angegeben, Arbeitsgruppe neu gesetzt. Ohne Erfolg. Im Zusammenspiel mit Napp-It will sich der C325 nicht überzeugen lassen, auf‘s SMB-Share zu speichern.

Der Xerox Support hat sich schon eine geschlagene Stunde damit beschäftigt, durfte sich auf meinen Rechner schalten und in meinem Beisein alles mögliche ausprobieren. Nachdem der Zugriff des C325 auf eine eigens dafür auf einem Windows Client angelegte Netzwerkfreigabe problemlos funktionierte, sagte der Techniker nur noch: Sorry, Server-Problem, mit der Windows Netzwerkfreigabe klappt‘s bei mir und auch bei Dir, wir sind raus. Ich konnte ihm nich entlocken, dass der C325 bevorzugt mit SMB V1 arbeitet, die Versionen 2 und 3 aber auch gehen sollten. Und dann war er weg…

Nun also meine Frage in die Runde und ganz speziell auch wieder an @gea: Irgendwelche Ideen? In Napp-It hab ich eigentlich nix spezielles in Sachen SMB Shares konfiguriert. Vielleicht ist aber auch genau das das Problem?! Ich würde mich wieder sehr über sachdienliche Hinweise freuen!

 

[gea]

Ich würde erstmal schauen on der anonymous Zugriff von Windows sauber klappt.

Dann in Services > SMB Properties die Servereinstellungen prüfen/ändern (mit Service restart)
smbmin: 1
testhalber smbmax auch auf 1
encrypt: disabled
signing required: false
oplock: testhalber umstellen, wenn gleiches Ergebnis zurückstellen

 

[kandamir]

Das Setzen von min_protocol und max_protocol auf 1 hat‘s gebracht, allerdings konnte mein iPad dann nicht mehr darauf zugreifen. Ich habe max_protocol dann auf 2.1 gesetzt und damit kommen sowohl der Xerox, mein Dokumentenscanner als auch das iPad klar. Ich werde nochmal schauen, wie hoch ich max_protocol „treiben“ kann und noch alles funktioniert. Jedenfalls hast Du mir damit die Retoure des Xerox erspart, denn das wäre für mich ein Killer gewesen.

Danke für Deine erneute super Unterstützung! 👍

 

[gea]

SMB1 gilt als unsicher und wird zunehmend per default deaktiviert.
Sollte man nur "zur Not" und in sicheren Netzen aktivieren.

Wäre gut wenn 2.1 als min ginge.

 

[chicken]

Wollte mal kurz nachfragen, ob es möglich ist, aus der Napp-IT GUI heraus auf ZFS-basierte Fileserver zu replizieren, die nicht OmniOS / Napp-IT sind? Konkret: Napp-IT @ OmniOS auf TrueNAS Scale?

Ich hab zwar Napp-IT Pro mit einer Backup-Lizenz, aber ich würde auch gerne auf ZFS-Ebene ein paar verschlüsselte Sachen auf die TrueNAS-Kiste vom Kumpel senden.

Aktuelle OmniOS r151052 mit letzter Dev-Version von Napp-IT ist installiert.

Falls das nicht über die GUI geht: Gibts Probleme wenn man das über die CLI mit zfs send macht?

 

[gea]

Kein Problem

Ein ZFS Dateisystem kann man ganz einfach mit netcat übertragen z.B.

Fast ZFS Send with Netcat

The general way to send ZFS data sets to remote nodes is normally achieved by sending the ZFS stream through ssh. Example: zfs send zones/UUID@snapshot | ssh root@10.10.11.5 zfs recv zones/UUID T…

blog.yucas.net

alternativ: napp-it cs (client server)
Das kann beliebige ZFS Server managen (TN nur eingeschränkt da man da kaum was außerhalb der GUI machen kann) mit Replikation any OS to any OS. Die Web-Gui läuft unter Windows mit remote control für ZFS unter BSD, Illumos, Linux, OSX, Windows oder Solaris.

 

[bbott]

Ich habe per Altach HDDs hinzugefügt. Ich habe von Rebalance gelesen, um die Daten neu zu verteilen und auch die volle Kapazität wiederzuerhalten. Teilweise habe ich Anleitungen mit zfs-inplace-rebalancing - Script gefunden, welche ein Rebalancing durchführen, dann wieder das Resivering das mit durchführt. Ich bin verwirrt

Warum ist das zfs-inplace-rebalancing Skript nicht in TrueNAS integriert?

 

[ludwinator]

das braucht keiner, schreib doch mal ganz genau, was du mit zpool attach gemacht hast.

 

[gea]

Wenn man einen Pool irgendwie vergrößert, z.B. einem Mirror einen weiteren Mirror für ein Raid-10 hinzufügt, so steht die zusätzliche Kapazität sofort zur Verfügung. Schreibt man eine neue Datei so verteilt die sich auf allen Platten und ist damit viel schneller als beim Schreiben/Lesen von einem einfachen Mirror.

Die bisherigen Daten bleiben aber da wo sie sind. Ändert man allerdings eine Datei so werden die geänderten Daten wegen Copy on Write auf allen Platten verteilt. ZFS macht damit für aktive Daten ein automatisches Rebalancing.

Manuelles Rebalancing hat das Ziel alle Dateien des Pools durch erneutes Schreiben auf allen Platten zu verteilen. Das erzeugt viel Last und die Daten stehen während des Umkopierens nicht zur Verfügung.

Über den Sinn eines manuellen Rebalancing kann man daher trefflich streiten, ich halts für überflüssig.

 

[pwnbert]

Über den Sinn eines manuellen Rebalancing kann man daher trefflich streiten, ich halts für überflüssig.

Ich überlege in die Richtung bezüglich SVDEV hinzufügen...

 

[gea]

Wenn dann aber nicht per file copy sondern durch Replikation eines ZFS Dateisystems -> ./filesystem.neu, nach Erfolg dann Umbenennen - ist massiv schneller. Mann muss halt darauf achten dass bei der Replikation (oder im Parent Dateisystem) die benötigte Small Block und Recsize gesetzt ist.

 

[bbott]

Ich habe zu dem Pool drei neue HDDs hinzugefügt, per zfs Attach.

Wenn dann aber nicht per file copy sondern durch Replikation eines ZFS Dateisystems -> ./filesystem.neu, nach Erfolg dann Umbenennen - ist massiv schneller. Mann muss halt darauf achten dass bei der Replikation (oder im Parent Dateisystem) die benötigte Small Block und Recsize gesetzt ist.

Da braucht man aber die doppelte Kapazität, oder?

... Die bisherigen Daten bleiben aber da wo sie sind. Ändert man allerdings eine Datei so werden die geänderten Daten wegen Copy on Write auf allen Platten verteilt. ZFS macht damit für aktive Daten ein automatisches Rebalancing.

Manuelles Rebalancing hat das Ziel alle Dateien des Pools durch erneutes Schreiben auf allen Platten zu verteilen. Das erzeugt viel Last und die Daten stehen während des Umkopierens nicht zur Verfügung.

Über den Sinn eines manuellen Rebalancing kann man daher trefflich streiten, ich halts für überflüssig.

Da ich die Daten aber so schnell nicht neu schreibe würde ich gerne das Rebalacing durchführen, bevor ich weitere Daten hinzufüge. Damit dürfte auch die Fragmentierung niedriger ausfallen. Wenn ich nun neue draufkopiere dürfte die Fragmentierung deutlich(er) steigen.
Außerdem dürfe die Performance danach steigen.