[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

 

[gea]

RustFS ist ja jetzt gerade 1.0.0 beta preview, alles bisherige war früher alpha code. Da dürfen Fehler sein.

ps
Das Tolle an RustFS ist neben der Einfachheit in der Konfiguration die Option es als 1:1 Ersatz für MinIO einzusetzen. Fast alles was bisher mit S3 komptiblen Servern gemacht wurde, nutzte MinIO. Das macht den Wechsel so einfach.

 

[asm@s24]

Fast alles was bisher mit S3 komptiblen Servern gemacht wurde, nutzte MinIO. Das macht den Wechsel so einfach.

So ist halt auch meine Erfahrung bei Veeam. Deploy RustFS im LXC, Bucket, credentials ... läuft.

Alternative: https://github.com/deuxfleurs-org/garage

Da schaff ich es noch nicht mal, "Quick Start" zu lesen.

 

[morph027]

Ja, ich suche auch noch weil noch ein Minio läuft 🙈

Fehler bei Daten sind halt doof, wenn dann alles corrupted ist. Fehler in der Sicherheit sind ein no-go. Und hardcoded credentials dabei ganz weit oben. AI coding brauch ich auch nicht. Leider gibt es tatsächlich aktuell keine andere besser Alternative. Echt ärgerlich, diese Minio enshittification.

 

[gea]

Mit der 1.0.0 beta preview sollte man nur Tests machen.
RustFS plant zumindest ein erstes Release 3 Monate nach der Beta, das wäre August.

RustFS Roadmap Update: Focusing on Stability and the Road to GA 🚀 · rustfs · Discussion #1098

Ref: #1097 To our friends across the globe: Thank you. We are incredibly grateful for the love you’ve shown RustFS. Thanks to your code contributions, forks, and stars, RustFS has become the fastes...

github.com

 

[zos]

Bevor es vor lauter Linux und Windows ZFS-Derivaten nur noch dahindämmert sei noch mal auf OmniOS und die tolle Arbeit die das kleine Team dahinter leistet hingewiesen:

OmniOS r151058 released (Release Notes)

 

[gea]

Da schlagen zwei Herzen in meiner Brust.
OmniOS (und Solaris) haben eine Stabilität, von der OpenZFS nur träumen kann. Nicht X Firmen die entwickeln und das für 20 Distributionen sondern ein Produkt einer Entwicklermannschaft für eine Distribution. Dazu bei OmniOS ein OS dessen Installer noch auf eine CD passt und in unter 1min installiert..

Der Preis ist halt, dass es tolle neue Sachen in OpenZFS gibt, die es (noch) nicht in Illumos ZFS geschafft haben

 

[you]

:  -Job Alert-
 
-disk errors: none
 
 
---------
Job Alert
---------
Active Job 1633247585 error:
error; time: 2026.05.07.02.25.01 line: 199; timeout check, error is set as default for job not finished correctly, remote timeout or other reason

Backup-Jobs in napp-it zeigen immer das hier per Mail. Muss ich mir da Sorgen machen @gea ?

Die Backups werden in der Job Übersicht als OK und erledigt angezeigt. Daten sind auf dem Ziel auch angekommen. Die Mail kommt zu Beginn der jeweiligen Jobs. Nicht immer, nicht immer bei den Selben Jobs.

 

[gea]

Prinzipiell sind zwei Sachen denkbar für ein job error

1. Tatsächlicher Timeout, z.b. wegen zu vieler snaps oder instabilem Netz
2. Timing Problem. Wenn ein Job startet setzt er einen Error im Log damit ein nicht durchlaufender Job immer einen Error meldet. Läuft der Job durch, wird ok oder der finale Error protokolliert. Das erkennt man daran, dass trotz Error der nachse Destination Snap erstellt wurde. Vermeiden kann man das indem man den Alert Job nicht zur gleichen Zeit startet wie den Replikations Job.

 

[you]

Danke @gea

Ich habe den Alert Job mal auf "immer 15 Minuten nach" eingestellt. Meine Backups starten immer um 0 oder 30. Werde es die nächste Nacht wissen.

Ich habe pro Quelle rollierend 6 Snapshots. Auf dem Ziel liegen Snapshots der letzten 30 Tage, ebenfalls rollierend. Das sollten m.E. nicht "zu viel" sein, oder?

 

[gea]

napp-it
Konzeptstudie
RustFS / MinIO · restic · rclone

ZFS ist das Beste was man für seine Daten lokal machen kann.

- absturzsicher mit Copy on Write.
- schützt Dateisystm und ZFS Raid vor bitrot mit Prüfsummen
- Snap Versionierung, Quotas und Reservierungen
- sehr viele Features zu Platten, Raid, Datenmanagement und -Haltung
- lokale SMB Multisuer Nutzung mit flexiblen ACL Dateirechten nach Anmeldung


Und im Internet?

- Up/Download mit https nach Anmeldung, so wie bei Cloud Anbietern üblich?
- ZFS Backup/Restore via Internet?
- Replikation der Daten zwischen regionalen oder überregionalen Servern im Internet?
- Hochverfügbarkeit (Raid über mehrere Server statt nur lokales Raid über Platten)

Dafür hat Amazon S3 entwickelt und sehr gut dokumentiert

- sehr schnell, egal ob 1TB oder 100PB
- jede Datei hat eigene url https://..
- S3 kompatible OpenSource Server (MinIO, RustFS etc)
- inhouse oder günstige S3 Filehoster
- Raid über Server mit Zugriff auf Cluster ip oder ip der Einzelserver
- autonome Site Replikation S3 <-> S3

Für ein rundes Konzept braucht man
- lokaler ZFS Server
- S3 Server als Einzelnode oder HA Multinode konfiguriert z.B. RustFS
- Programm für S3 Backup Repository, verschlüsselt mit Deduplizierung z.B. Restic
- Sync/Kopierprogramm um Daten von/zu/zwischen S3 zu kopieren z.B. rclone oder webconsole

mein Konzeptvorschlag:

https://www.napp-it.org/pdf/s3_storage_guide_de.pdf

Mehrsprachig in Englisch mit anderen Dokumenten

Downloads — napp-it