[Sammelthread] ZFS Stammtisch

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
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
- 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.
 
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äre:die 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.
 
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.
 
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.
 
- Special Vdev geht nicht als Raid-Z, nur als Mirror
Ne, meinte zum Z1 ein Mirror-SVDEV dazu machen.
Genauer wäre:die 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?
 
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?
 
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?
 
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
 
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?
 
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)
 
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.
 
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
 
Zuletzt bearbeitet:
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!
 
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
 
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! 👍
 
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.
 
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?
 
Kein Problem

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

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.

1731973038249.png
 
Zuletzt bearbeitet:
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