[Sammelthread] ZFS Stammtisch

War wohl die Komprimierung, was auch immer die GUI vom TNS hier für eine Methode wählt (wenn man das denn wählen kann).


Ich hab jetzt mal endlich mein Metadata-SVDEV hinzugefügt (2x 4tb Kingston Fury Renegade als Mirror) und mal paar große Verzeichnisse gelöscht und neu bespielt.
Wirkt ziemlich grandios schnell, das Ganze (also über SMB verbunden baut sich das alles schnell auf, die Ordnerstruktur und so), muss aber mal rebooten und so, nicht, dass es am ARC liegt (glaub ich aber fast nicht).

__________
1)
Ich hab da noch eine Frage dazu, das Pool selbst hab ich mit Standardwerten angelegt (was TNS da eben verwendet).
Da hab ich ein paar Datasets drauf, die meisten Einstellungen eigentlich gleich (inherit), smallbock 64k.

Wenn ich jetzt bei einem Dataset (wo hauptsächlich Medien liegen) die Recordsize von 128 auf z.B. 1M stelle und die Smallblocksize auf 256k/512k geht das so einfach, wenn die Pool Settings anders sind?
Was ich gelernt hab ist das hier ebenso, dass das dann eben nur neu geschriebene Dateien betrifft.
Beim anderen Dataset am gleichen Pool würde ich das lassen wie es ist (128/64).

Funktioniert das so?
__________
2)
Dann schwirrt mir noch das Thema Write-Amplification im Kopf herum, wobei das wahrscheinlich egal ist, weil auf dem Dataset/Pool wenig geschrieben wird... kann man vermutlich außen vor lassen?

__________
3)
Nochwas, ich hab da noch so ne andere Frage im Kopf, die mir bisher ungelöst ist, bezüglich SLOG und PLP.

Ich würde gern Proxmox auf 2x KC3000 2tb im Mirror installieren.
Ich hätte noch eine 1tb Micron 7400pro mit PLP über.
Nun ist es ja so, dass die PLP SSDs bei Sync-Writes wohl "cheaten", den Write also vorab bestätigen (weils durchs PLP als gesichert gilt).

Wenn ich jetzt für ein Pool ohne PLP ein SLOG mit PLP einrichte, funktioniert das dann so, oder ist das unnötig?
In anderen Worten, gilt der Sync-Write als durchgeführt, wenn er im ZIL (hier am PLP SLOG) gelandet ist, oder erst wenn er vom ZIL auf seinen "endgültigen Platz" geschrieben wurde?

Sonst wäre man dadurch ja nicht schneller, würde nur ein klein wenig Sicherheit gewinnen (worauf ich wohl verzichten kann, das Thema haben wir ja schon ausführlich behandelt, dass ein Mirror schon relativ stabil ist) und halt wohl die Schreiblast der Sync-Writes halbieren, da ja das ZIL dann wo anders liegt.

Ist nachvollziehbar, was ich meine?

3.1)
Ich überlege gerade, obs nen einfachen Weg gibt, das zu benchen.
Ich könnte am Testrechner ne VM erstellen, 1 M2 SSD und 1 M2 PLP SSD passthroughen, dort irgend ein Linux installieren, openzfs installieren und dann ein Pool erstellen aus der M2 und mit bzw. ohne M2 PLP als SLOG (hmmm.... könnte mir dafür napp-it ansehen, da hätte ich 2 Fliegen auf einen Schlag...) und dann.... benchen...

Aber wie benche ich das, wie erzwinge ich Syncs in so einem Fall? Kann ich das forcen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Small Blocksize und recsize sind Eigenschaften eines ZFS Dateisystems, können für jedes Dateisystem anders sein und wirken nur für folgende Writes, nicht für vorhandene Daten. Mit größeren smallblock sollte ein Vdev ausreichend groß sein weil alle Dateien <= sb Wert dann darauf landen, mit recsize <= sb sogar das ganze Dateisystem mit allen Daten.

Write amplification wird vor allem durch CoW hervorgerufen. Ein Byte ändern in einer großen Datei mit recsize=1M bedeuted dass für das eine Byte 1M geschrieben werden.

Sync kann man per dataset einstellen. Mit sync=always sind alle Writes sync

Mit sync gilt ein Write als auf Pool, wenn ZIL oder Slog das Write bestätigen. Bei einer SSD ohne PLP kann das aber bedeuten dass im Crashfall der bestätigte Write verloren geht. Ein Slog mirror (ohne plp) ist unkritischer da die SSD nacheinander beschrieben werden. Bei einem Fehler auf der 2. SSD hat man gute Chancen dass auf der ersten SSD bereits gültige Daten sind.
 
Ein Byte ändern in einer großen Datei mit recsize=1M bedeuted dass für das eine Byte 1M geschrieben werden.
Ja, wie ich verstehe im Fall des Fusion Pools auf der Harddisk.
Wenn man hier z.B. recsize=1M und smallblock 256k hat, wird das auf der SSD dann ja 256k-weise geschrieben, meinem Verständnis nach, oder?

Wie ist das dann bei den Metadaten? Wie sind die angelegt? Da wird doch auch der letzte Zugriff etc. hinterlegt, also ggf. auch mal beim Lesen geschrieben, oder?
Weisst du, wie das in diesem Fall aussieht?

Nachtrag: Vermutlich... abhängig von ashift?
Mit sync gilt ein Write als auf Pool, wenn ZIL oder Slog das Write bestätigen.
... also reicht es theoretisch, wenn das SLOG vdev PLP hat (damit könnte man günstigere kleinere PLPs verwenden...).
Wobei ich mir noch nicht sicher bin, wie schlau das ist... mh.
 
Zuletzt bearbeitet:
Mit recsize=1M wird jede Datei < 1M mit einem Datenblock in Dateigröße geschrieben (recsize ist bis auf draid dynamisch),
egal ob der Block auf den normalen oder special vdevs landet. Größere Dateien werden in 1M Blöcken geschrieben.

Smallblocksize=128K bedeutet dass Datenblöcke <= 128K auf SSD landen, größere auf HD
Metadaten sind kleine Datenblöcke. Die landen auch auf dem special vdev.

Ashift hat Auswirkung auf den kleinstmöglichen zu schreibenden Datenblock, mit asift=9 sind das 512B, mit ashift=12 ist das 4K

Kleine Slog ist ok, muss nur 10G groß sein, schade dass es kleineren Intel Optane nicht mehr gibt.
 
Metadaten sind kleine Datenblöcke.
Genau, aber ist bekannt, wie groß/klein die sind? Ich nehm an, der Wert ist nicht beeinflussbar (ggf ergibt er sich übers ashift?), weil die Metadaten ja sein müssen, wie sie eben sein müssen?
Kleine Slog ist ok, muss nur 10G groß sein, schade dass es kleineren Intel Optane nicht mehr gibt.
Meinst du diese 16/32er? Die 16er bekommt man aus China nachgeworfen, die 32er sind bissl schwer.
Wobei die alle recht "langsam" sind ob die wirklich schneller als die Micron sind (X-Point hin oder her...)?

Die besseren 58GB etc. gibts kaum zu vernünftigen Preisen.
 
Über ashift ließen sich die minimalen Blockgrößen anpassen. Man muss da aber aufpassen. Eine 512B Platte läßt sich nicht durch eine 4K Platte ersetzen. Ich würde daher in der Regel alles auf ashift=12 zwingen.

Die idealen Slog waren die 1600er Optane.
 
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