[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