[Sammelthread] ZFS Stammtisch

[pwnbert]

@pwnbert

• 5400 RPM: ~70–90 IOPS
• 7200 RPM: ~80–120 IOPS
• Enterprise (15k SAS): ~150–250 IOPS (Maximum)

Die 700-800 IPOS per Raid z.B:
Reads: Acht HDDs × 100 IOPS = ~800 IOPS

Das ist mir zu ungenau.
Ich poste die Screens nochmal hier rein.

WD Extern:

MG10 22tb:

Man sieht, dass die RND4k Q32T1 stark kleiner sind - meine Frage ist, ob das egal ist, oder ob das stört bzw. WANN das stört.

Sequentiell ist wohl gleich, RND4k Q1T1 ist auch gleich.
128k (für ZFS Standard) müsste ich noch testen, kann man bei CDM imho einstellen.

SVDEV (M.2) hätte ich allerdings in dem VDEV (als Smallblock <64 und Metadata) - würde die M.2 theoretisch die ganzen RND4k "abfangen"?

 

[gea]

Wie sagte mein Messtechnik Prof:
Wer misst, misst Mist

oder
was ist schneller, ein Fahrrad oder ein Porsche

Antwort: Das Fahrrad ist schneller (im freien Fall vs dem Porsche auf der Straße)

Was ich damit sagen will, ist dass Messergebnisse immer nur für bestimmte Rahmenbedingungen bewertet werden können, meist sogar nur im direkten Vergleich zu anderem Gerät bei gleichen Einstellungen z.B. ssd vs hd, nie absolut. Die iops sagen ja nur output per second. Ist ein output nun ein random Byte, ein random 4K physical Disk Datenblock oder ein ZFS Block in recsize (128K bis 1M). Dadurch ergeben sich bei gleichen iops riesig unterschiedliche Datentransfers.

Wenn man absolute Werte sucht, landet man schnell bei den ca 100 physikalisch möglichen iops bei hd, 1000 bis 10000 bei ssd und >100000 bei NVMe wobei da nur Intel Optane das bei beliebigen Rahmenbedingungen erreichte, normale NVMe können bei steady write oder mixed read/write auch mal viel schlechter sein als eine gute ssd die laut Datenblatt eigentlich viel schlechter sein sollte,

Zu special vdev
Da zählt nur wie groß der ZFS Datenblock in recsize ist im Vergleich zur small blocksize, damit der Block auf hd statt ssd landet, hat nichts mit iops oder Testeinstellungen in Chrystal zu tun sondern da zählt nur die physikalische Datenstruktur.

Ansonst
Die Erfahrung lehrt, dass man schon 30% und mehr braucht, damit man eine schnellere IT Technik als solche "spürt". Etwas schneller ist ok wenn es nicht viel mehr kostet, sonst nicht.

 

[pwnbert]

Wie sagte mein Messtechnik Prof:
Wer misst, misst Mist

Nene, ich denke nicht, dass das Mist ist.

Die WD hat ne Frimware für die Verwendung in externen Festplatten drauf, auch wenn sie genetisch ne Ultrastar ist.
Ich bin mir relativ sicher, dass man hier etwas "eingebremst" hat, aus "politischen" Gründen, um die Platte fürs Datacenter uninteressant zu machen...

Da zählt nur wie groß der ZFS Datenblock in recsize ist im Vergleich zur small blocksize, damit der Block auf hd statt ssd landet, hat nichts mit iops oder Testeinstellungen in Chrystal zu tun sondern da zählt nur die physikalische Datenstruktur.

Nene, es geht darum benchmarken zu können, was in der Realität am ZFS VDEV zählt... wie die Einstellungen fürs Benchmark aussehen sollen, damit das Ergebnis halbwegs aussagekräftig ist.

Die Erfahrung lehrt, dass man schon 30% und mehr braucht, damit man eine schnellere IT Technik als solche "spürt". Etwas schneller ist ok wenn es nicht viel mehr kostet, sonst nicht.

Q32T1 sind aber ~400% bzw. 25%, daher meine Sorge bzw. Frage.

 

[gea]

Kann man nicht ausschließen, solche "Marketinggags" gibt es immer wieder. Ist aber eher unwahrscheinlich, dass man derlei im Alltag merkt. Schließlich steht die externe Platte auch im Wettbewerb mit anderen Desktopplatten nicht nur mit Enterprise Platten.

Die Enterprise Platten haben fast immer eine andere Firmware, sieht man allein schon daran dass die im Verbund mit anderen Platten wegen Vibrationen nicht einbrechen sollen. Bei Desktop Platten kann man die Performance schon durch "Anschreien" verringern.

Die Q Werte von Crystal zeigen zudem eher wie sich die Leistung bei paralleler Verarbeitung in der Warteschlenge ändert. Hier hätte ein unterschiedlich großer Plattencache Auswirkung.

Q1T1 ist der Wert der am Wichtigsten für realworld ist

 

[besterino]

CDM ist generell Mist. Taugt als grobes Schätzeisen, aber mehr auch nicht.

 

[bbott]

@pwnbert
Die max. IOPS bei HDDs ergeben sich im Prinzip aus der Zugriffszeit:
IOPS ≈ 1000 / (Seek + Rotationslatenz)
Bei 7200 rpm sind das grob ~4 ms Latenz (7200 upm) + ~8 ms Seek (Kopf bewegt sich zur Spur) → ~80–120 IOPS realistisch. Alles darüber im Benchmark ist meist Queueing/ Cache.

Q32T1 ist bei HDDs wenig aussagekräftig, weil sie nichts parallel abarbeiten können, relevant ist eigentlich Q1T1. Problematisch wird’s nur bei vielen gleichzeitigen kleinen Zugriffen (VMs, DBs etc.).

Fun Fact:
Die ~100 IOPS gelten für Worst/Full-Disk. Wenn die Daten nur außen liegen (Short Stroking), steigen die IOPS spürbar. Die 3,5er WD VelociRaptor hat das im Prinzip genau so gemacht (kleinere Fläche genutzt (nur äußere Bereich) → kürzere Wege).

 

[pwnbert]

Q32T1 ist bei HDDs wenig aussagekräftig, weil sie nichts parallel abarbeiten können, relevant ist eigentlich Q1T1. Problematisch wird’s nur bei vielen gleichzeitigen kleinen Zugriffen (VMs, DBs etc.).

Aber wie kommt man im Benchmark dann zu diesen unterschiedlichen Werten?

Kann man das nun ignorieren?

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

 

[asm@s24]

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

M.E. spielt Rost da eh keine Rolle, die Performance kommt von den SSD im special vdev. 🚀
Edit: special vdev & arc.

 

[pwnbert]

M.E. spielt Rost da eh keine Rolle, die Performance kommt von den SSD im special vdev. 🚀

Leider nicht. ATM schwankt mein Schreiben über SMB so bei 300-440, eher selten über 400... bei großen Dateimengen.

 

[asm@s24]

MB/s im 10 GbE? Das hab ich auch meist so. Ist doch ok.
Hab auch schon 700 gesehen im Zusammenhang mit PBS. Allerdings weiß ich grad die Umstände nicht mehr. Es war ein eher künstlicher Test.

Beitrag automatisch zusammengeführt: 12.04.2026

Schreiben über SMB

SMB ist doch eh problematisch.

 

[bbott]

Aber wie kommt man im Benchmark dann zu diesen unterschiedlichen Werten?

Kann man das nun ignorieren?

Ich hab halt Sorge mir die Performancde vom Pool zu "vergiften" in dem ich langsame HDDs zur guten Ware stecke.

Der Unterscheid kommt daher, das wenn die Daten direkt in der Nebenspur sind schneller Zugreifbar sind, als wenn man den Lesekopf von ganz außen bis zu inneren (oder umgekehrt) den Lesekopf bewegen muss. In deinen Benches lagen die Daten (sehr) nah beieinander. Das ist auch ein Faktor, warum volle HDDs langsamer werden.

Daher hat man in vor SSD Zeiten auch gerne mehr HDDs verbaut und per Patition, die Daten nach außen erzwungen und auf Kapazität verzichtet, wenn eine Anwendung sehr stark auf IO angewesen war.

 

[pwnbert]

Versteh ich eh.
Offenbar liegt hier irgend ne künstliche FW Begrenzung vor, die irgendwie bei vielen parallelen Anfragen (Datacenterkram) bremst, damit die Platte für den Betrieb wohl uninteressant wird?

War mir nur nicht sicher, inwiefern mich das betreffen könnte.. imho is auch Q1T1 wichtig (wobei das eben das SVDEV abfedern sollte) und halt das SEQ...

Grad geschaut, mittlererweile kosten die 20tb HC560 und MG10 knapp 700, total insane, werd die Platten wohl so oder so einbauen.


Ne Idee wie ich mein Pool sinnvoll Benchmarken kann (unter TrueNAS Scale)?
Würde gern nen Vorher-Nachher Vergleich machen irgendwie.

 

[toscdesign]

Ich hatte ja meine Datenbasis von TrueNAS Scale auf mein neues System übernommen.
Und auch entsprechend fie ACLs der Dataset auf Posix umsgestellt mit folgenden Befehlen:

zfs set acltype=posixacl pool/dataset
zfs set aclinherit=passthrough-x pool/dataset
zfs set aclmode=passthrough pool/dataset

Jetzt ist mir durch zufall aufgefallen das die entsprechenden Child Datasets noch die alte ACL Variante von TrueNAS haben.
Gibt es eine Möglichkeit die ganzen Childs auf einmal umszustellen oder muss ich es für jedes Child einzeln machen, also entsprechend:

zfs set acltype=posixacl pool/dataset/child1
zfs set aclinherit=passthrough-x pool/dataset/child1
zfs set aclmode=passthrough pool/dataset/child1

zfs set acltype=posixacl pool/dataset/child2
zfs set aclinherit=passthrough-x pool/dataset/child2
zfs set aclmode=passthrough pool/dataset/child2

 

[zos]

Sollte mit

zfs inherit -r acltype pool/dataset/child1
zfs inherit -r aclinherit pool/dataset/child1
zfs inherit -r aclmode pool/dataset/child1

gehen. So erben rekursiv alle child datesets das Attribut von ihrem parent dataset „pool/dataset“ wenn ich das noch richtig in Erinnerung habe.

 

[gea]

ZFS Backup/Restore mit S3 im Lan/Internet

Aktuell sind ZFS-Replikation und rsync mit einem ZFS-Snapshot als Quelle die klassischen Methoden für ZFS-Backup und -Wiederherstellung. Die wichtigste Alternative für mich ist neben einer lokalen Replikation zunehmend S3-Objektspeicher mit S3-basierten Backup-Tools wie restic weil.

- Die Zugriffsperformance ist bei 10 TB und 10 PB Speicher nahezu identisch
- jede Datei ist über eine authentifizierte HTTPS-URL erreichbar.

- Ein S3-Server kann im einfachen Einzelknoten-/Einzelplatten-Modus für normales Backup und Wiederherstellung betrieben werden.
- oder als Cluster im x-Servernode-/y-Platten-Modus. Ab vier Servern bietet ein solcher Cluster Hochverfügbarkeit
— vereinfacht betrachtet ähnlich einem RAID über Server: vier Knoten wie RAID-Z1, fünf wie Z2, sechs wie Z3.

Mit einem Load Balancer bleibt der Cluster unter der ursprünglichen IP erreichbar wenn ein Knoten ausfällt;
ohne Load Balancer kann ein anderer Knoten über seine eigene IP angesprochen werden.

- Darüber hinaus unterstützen S3-Server Site-Replikation
— im Wesentlichen wie ein asynchrones Mirror-Setup zweier S3-Server.

S3-Objektspeicher stammt ursprünglich von Amazon AWS. Da die S3-API gut dokumentiert ist, hat sie sich als Standard für Cloud-basiertes Backup und Restore etabliert
— nicht nur bei Amazon, sondern auch bei vielen Cloud- und ISP-Anbietern zu günstigen Konditionen. Viele davon nutzten in der Vergangenheit das S3-kompatible MinIO, ebenso wie viele NAS-Systeme. MinIO als OpenSource-S3-Server ist jedoch keine Option mehr, daher wird eine Alternative benötigt.

Die vielversprechendste Alternative ist RustFS, als direkter 1:1-Ersatz für MinIO konzipiert. Der aktuelle Stand ist eine 1.0.0-Beta für erste Tests; eine stabile Version ist für Sommer 2026 angekündigt, aber noch nicht abschließend bestätigt. RustFS basiert auf Rust und kann daher auf nahezu jedem Betriebssystem gebaut werden. Vorgefertigte Binaries für Linux, macOS und Windows sind unter https://github.com/rustfs/rustfs/releases verfügbar.

Auf anderen Systemen muss RustFS selbst gebaut werden, was aufgrund einiger Abhängigkeiten aufwendig sein kann. Bei Problemen empfiehlt sich die Hilfe einer KI (ich habe Claude verwendet). Zum Bau von RustFS auf OmniOS — inklusive eines dokumentierten Shell-Scripts — siehe https://illumos.topicbox.com/groups/omnios-discuss/T3f99b32a3a89273b/rustfs-s3-object-storageserver

ps
wer noch Solaris hat kann zumindest restic nutzen (ältere Version als Binary, neuere muss man selber bauen)

Release restic 0.17.2 · restic/restic

Changelog for restic 0.17.2 (2024-10-27) The following sections list the changes in restic 0.17.2 relevant to restic users. The changes are ordered by importance. Summary Fix #4004: Support contai...

github.com

 

[asm@s24]

Die vielversprechendste Alternative ist RustFS, als direkter 1:1-Ersatz für MinIO konzipiert.

Hab das schon 'ne Weile im LXC als Repo für Veeam. Funktioniert gut. Sehr flüssig.
Für PBS mal angetestet, das ging (noch) nicht so gut. War noch mit 4.1 - jetzt in 4.2 ist S3 ja offiziell. Bin nur noch nicht wieder dazu gekommen.

 

[morph027]

Ich erinnere mich bei RustFS an irgendwelche kruden Vibe Coding Fehler und static Keys und dass der Umgang damit keine Glanzleistung des Entwicklers war. Alternative: https://github.com/deuxfleurs-org/garage