[Sammelthread] ZFS Stammtisch

[asm@s24]

ZFS NAS liegt seit dem Wochenende in Version 4.0 vor.

Version 5.0 ist in Entwicklung, gibt jetzt schon eine Demo bei YouTube zur neuen Version:

Youtube DEMO - Version 5.0.0 with ZFS Encryption Support and a lot more ! · macgaver zfsnas-chezmoi · Discussion #8

https://youtu.be/usFcZ15AyOs?si=yTsC6OvpX8LF_uXZ Since everyone was asking for a more precise video format, we started a fresh youtube channel for our video demo Comments are welcome !

github.com

Da wird richtig Gas gegeben!
Wobei ich mal ne Frage habe, ist das ein 1-Mann Projekt?

Sind nicht die meisten guten Projekte auf GitHub One-Man-Shows...?

 

[BobbyD]

Wobei ich mal ne Frage habe, ist das ein 1-Mann Projekt?

Sieht schon verdammt gut aus, aber ist es vertrauenswürdig? Scheint ein Franzose zu sein, er spricht öfter mal von "wir", aber lt. Github ist er der einzige Entwickler. Wie viel RAM schluckt seine Software, hat das wer gemessen?
Wenn sich das nahtlos neben Proxmox einfügen würde, das wär super. Aber auch Stand-Alone scheint es eine gute Figur zu machen.

 

[asm@s24]

Wie viel RAM schluckt seine Software, hat das wer gemessen?

Wenn Du mir 'n Tipp gibst, wie ich das mach, dann mach ich das.

 

[BobbyD]

Irgendwas mit top?
Sry, absoluter Linux-Noob.

 

[toscdesign]

Ich hab mal nen Sammler angelegt, ist besser wenn wir uns dort dazu unterhalten:

[Sammelthread] - ZFS NAS Chezmoi

https://github.com/macgaver/zfsnas-chezmoi Da es aktuell in aller Munde ist, habe ich mal den passenden Sammler angelegt.

www.hardwareluxx.de

 

[gea]

Ich hab hier ein großes Z1 aus 4 Platten, welches über die Zeit erweitert wurde um einen SVDEV Mirror und später nochmal um eine weitere HDD auf 5 Platten im Z1.

Eigentlich müssen die Daten ja neu geschrieben werden, um a) ihre Metadaten am SVDEV zu haben und auch um "den richtigen Speicherplatz" zu verbrauchen, da wohl schon geschriebene Daten am Z1 weiterhin auf den 4 Platten liegen und nicht über 5 verteilt sind.

Gibts da eine Art "rewrite" Befehl, ähnlich wie ein Scrub oder so?
Ne elegante Lösung?

zfs-rewrite.8 — OpenZFS documentation

openzfs.github.io

 

[gea]

OmniOS r151056t (2026-03-14)
Weekly release

Release Notes

illumos based server OS with ZFS, Bhyve, DTrace, Crossbow, SMF and Linux zone support

omnios.org

reboot erforderlich

Security Fixes
hauptsächlich zu SSL and CPU microcode

Für napp-it mit TLS email, rerun TLS setup:

napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana and Solaris : Downloads

napp-it.org - ZFS NAS SAN Server with user editable web-gui // All In One server = virtualized ready to run ZFS-Server

www.napp-it.org

 

[toscdesign]

wenn du das nur entschlüsseln willst kannste einfach

echo "$PASSWORD" | zfs load-key "$ENCRYPTED_VOLUME"

also z.B.

in der CLI eingeben und anschliessend evtl noch mounten mit

zfs mount "$ENCRYPTED_VOLUME"



also z.B.
echo "geheimespwd" | zfs load-key "tank/cryptomatic"
zfs mount "tank/cryptomatic"


der mountpoint ist im ZFS (Sub)Volume definiert.

Das hat so 50% funktioniert 😅
Ich habe für "pve_data" das Passwort eingegeben und gemounted.



Das Dataset das nach "backup" folgt sehe ich gar nicht:



Edit:
Ok ich muss also auch "pbs_data" extra mounten.
Muss ich das bei jedem Subdataset machen einzeln machen?

 

[Bzzz]

1. zpool import Pool1
2. echo "geheimespwd" | zfs load-key "Pool1/cryptomatic"
3. zfs mount "Pool1/cryptomatic"

Das ist, und wir werden ja alle nicht jünger, stets eine gute Idee. Dann hat man sein hochgeheimes Passwort noch in der Bash-Historie stehen, wenn mans mal vergessen hat

 

[toscdesign]

@Bzzz
Danke für den Tipp, hab die History gleich mal gelöscht.
Ist aber in dem Fall nicht weiter schlimm, da lagen keine wichtigen Daten drauf.

Wie würdest du das dann lösen?
In einem Script?

So wie hier, beispielsweise?

#!/bin/bash

echo -e "\e[94m Please enter password\e[0m"
read -s PW
echo ""



## command for opening the encrypted device
# example for hdd: "echo $PW | cryptsetup luksOpen /dev/sda sda-crypt"
# example for ssd: "echo $PW | cryptsetup luksOpen /dev/nvme0n1p3 nvme-crypt"
echo $PW | cryptsetup luksOpen /dev/nvme0n1p3 appcrypt

 

[Tundor]

Genau, du musst halt ne explizite Secretabfrage nutzen, und es nicht plain als bash command eingeben.

 

[Bzzz]

Was spricht gegen die direkte Eingabe? Das Skript hält ja dafür an, so ists ja nicht.
Ich mounte und unmounte mein verschlüsseltes NVMe-Masterarray so:

#!/bin/bash
set -x
sudo sysctl kernel.task_delayacct=1
sudo zfs unmount blablubb/12drölf
...
sudo zfs unmount blablubb
sudo zfs unload-key blablubb
sudo zpool export blablubb
sudo zpool status
sleep 5
sudo zpool import blablubb
sudo zfs load-key -r blablubb
sudo zpool list
sudo zpool status
sudo zfs mount -a

Beim Unmount einfach innerhalb der fünf Sekunden den USB-C abziehen (sofern nix fehlschlägt, offene Konsole oder so)

 

[toscdesign]

Genau, du musst halt ne explizite Secretabfrage nutzen, und es nicht plain als bash command eingeben.

Also passt das mit dem von mir geposteten Script?
Oder sollte ich am Script Ende die Variable mit Zufallsdaten überschreiben?

Dann wurde ich das Script nun an ZFS anpassen und verwenden.

 

[morph027]

Ich mach das mit einem Workaround: https://github.com/morph027/zfs-boottime-encryption

Damit wird das LUKS beim start via Kernel prompt abgefragt, dann gemountet und die Datasets mit dem Keyfile entsperrt.

 

[Tundor]

@toscdesign Wenn du das so als script ausführst also ./scriptname dann führt es den Inhalt in ner Subshell aus d.h. sobald das script durch ist, ist auch $PW wieder weg. Solltest du den inhalt mit copy paste ausführen, bleibt $PW halt in der aktuellen Shell die du offen hast bestehen bis du diese schließt. Großes Sicherheitsrisiko sehe ich keins, beim script überlebt das wie gesagt nur zur Laufzeit und ein Überschreiben mit Randomdaten ist unnötig.

 

[toscdesign]

Ich mach das mit einem Workaround: https://github.com/morph027/zfs-boottime-encryption

Damit wird das LUKS beim start via Kernel prompt abgefragt, dann gemountet und die Datasets mit dem Keyfile entsperrt.

Es soll ja nicht beim Booteen abgesfragt werden, sondern optimal in der Shell des Webintasfaces oder per SSH.
Ich möchte das Passwort auf jeden Fall manuell eingeben, notfalls auch von unterwegs (per VPN).

ZFS NAS CHEZMOI hat aktuell nur die Funktionalität für Keyfiles, aber dafür eine Shell im Webinterface.
Dort würde ich dann das Script einfach aufrufen.

Beitrag automatisch zusammengeführt: 17.03.2026

So mein Script läuft soweit, das Passwort wird übernommen und die Datasets entsperrt.

Nur beim Mounten habe ich noch ein Problem.
Soweit ich verstanden habe kann ich mit "zfs mount -a pool/dataset" das entsprechende Dataset + alle enthaltenen Subdatatest (Childs) mounten.

Das macht er aber nicht, sondern wirft mir folgende Fehlermeldung:

too many arguments
usage:
        mount [-j]
        mount [-flvO] [-o opts] <-a|-R filesystem|filesystem>

For the property list, run: zfs set|get

For the delegated permission list, run: zfs allow|unallow

For further help on a command or topic, run: zfs help [<topic>]

 

[toscdesign]

@gea
Sorry, wenn ich schon wieder bei dir nachfrage, aber du kennst dich eben sehr gut aus mit zfs.
Wie oben geschrieben würde ich gerne mehrere Datasets auf einmal entsprerren, und zwar folgendermaßen.

Aktuell entsperre ich jedes Dataset einzeln:

zfs load-key pool/dataset
zfs mount pool/dataset

zfs load-key pool/dataset/subdataset
zfs mount pool/dataset/subdataset
...

Das Dataset und alle darin enthaltenen Subdatsets zusammen zu mounten, sollte lt. meiner Recherche so funktionieren:

zfs mount -a pool/dataset

Leider klappt das nicht, da kommt eben immer "too many arguments"

Was könnte hier der Fehler sein?

 

[Tundor]

Da mich das Problem auch interessiert, hab ich claude befragt und ne gute Erklärung bekommen.

Das Problem ist, dass -a bei zfs mount ein Flag ist, das alle ZFS-Datasets mountet – es akzeptiert daher kein zusätzliches Argument. Du kannst also nicht zfs mount -a pool/dataset schreiben; das ergibt syntaktisch keinen Sinn für den Befehl, daher der Fehler „too many arguments".


Das eigentliche Problem: zfs load-key lädt standardmäßig nur den Key für ein Dataset, nicht für Subdatasets. Du musst -r (recursive) verwenden.


Die korrekte Lösung für dein Vorhaben:




bash
# Keys für Dataset UND alle Subdatasets laden
zfs load-key -r pool/dataset

# Danach rekursiv mounten
zfs mount -R pool/dataset

Kurzübersicht der Flags:

Befehl	Flag	Bedeutung
zfs load-key	-r	Rekursiv – lädt Keys für Dataset + alle Subdatasets
zfs mount	-R	Rekursiv – mountet Dataset + alle Subdatasets
zfs mount	-a	Alle ZFS-Datasets mounten (kein Argument möglich)

 

[toscdesign]

Super, das funktioniert

 

[gea]

Man muss sich entscheiden, -a mounted alle mountbaren datasets oder man mounted nur ein bestimmtes optional mit dessen child datasets (-R)

zfs-mount.8 — OpenZFS documentation

openzfs.github.io

 

[toscdesign]

Ja, ich will selektiv mounten können inkl. Childs.
Daher ist "-R" die für mich richtige Option

 

[gea]

In diversen Threads wird gerade diskutiert, ob man bei ZFS einen Arc Lesecache braucht, wie groß der sein sollte und wie man das ändert.
Je nach OS (Free-BSD, Linux, OSX, Windows (Registry) oder Illumos/Solaris gibt es dafür Textdateien für dauerhafte Einstellungen oder Verfahren das temporär zu ändern. KI hilft da gerne weiter.

Insgesamt sehe ich das so.
ZFS muss als Copy on Write Dateisystem sehr viel häufiger Metadaten lesen als ältere Dateisysteme und erzeugt eine höhere Fragmentierung. Insbesondere bei hd ein Problem. Hier ist ohne Arc keine vernünftige Performance möglich. Arc sollte man da niemals deaktivieren und es gilt, je mehr Arc desto schneller. Man muss nur beachten dass Arc keine Files cacht sondern ZFS Datenblöcke (Metadaten + read last + read most Optimierung). Der Cache bringt umsomehr je mehr User und je mehr random read. In einer Multiuser Umgebung mit vielen Dateien kann ein Arc > 80% der Reads abdecken. Für single user und wenig Dateien muss auch der Arc nicht so groß sein.

Ganz anders sieht es bei schnellen NVMe aus. Da muss man den Performancegewinn des RAM Caches gegen den Performanceverlust durch das Kopieren der Daten von NVMe in den Cache und das Abgleichen der Datei (ist das schon im Cache was ich gerade lese) abwägen. Da kann es oft so sein dass das Deaktivieren des Arc schneller ist (ZFS Direct io, je Dateisystem einstellbar).

Als Arc Daumenregel sehe ich: 1GB min, 4GB ok, 12GB+ bei vielen User und Dateien, 64GB+ bei einem Uni Mailserver

zum RAM
Da ein 64bit OS min 2 GB RAM haben möchte, ist ein 64bit ZFS System mit 2GB RAM nicht so toll, ab 4GB gut machbar. Nicht Illumos/Solaris Systeme brauchen in der Regel 1-2GB mehr da ZFS Speichermanagement nur da = OS Speicher ist. Dann kommt noch der Speicherbedarf einer web-gui dazu. Mein napp-it cs als client server System braucht ca 50K auf dem ZFS Server den man managen möchte (das Frontend auf einem anderen Server mit Apache Webserver braucht mehr), eine TrueNAS Gui eher 5GB, daher sind da gerne 12-16GB für einen ZFS Server angemessen um ähnlich schnell zu sein wie ein OmniOS System mit 4-8GB.

z.B. Arc Settings Proxmox

Host System Administration

 

[pwnbert]

Ich bitte die HDD Erfahrenen Leute hier um Hilfe bzw. eine Einschätzung folgender Situation:

Ich habe ein z1 aus 20tb Platten, 4x HC560 + 1x MG10 + 2x M.2 4tb Mirror als SVDEV.
Jetzt habe ich überlegt dieses zu erweitern, die HDD Preise sind ja abartig, und obs so schnell besser wird, ist fraglich.
Es gab externe 20tb Platten von WD um ca. 350€, hab mal 2 gekauft, um sie evtl. "zu schlachten", sind ja mechanisch wie die HC560.
Ich wollte das z1 nun zum z2 aus 7 Platten erweitern mit 2 dieser Platten.

Posts mit Benchmarks dieser "White Label" Platten sind hier:

[Kaufberatung] - Festplatten + Diskussion (keine SSDs)

https://geizhals.at/western-digital-wd-elements-desktop-schwarz-20tb-wdbwlg0200hbk-a2694729.html Western Digital WD Elements Desktop, schwarz, 20TB, USB 3.0 Micro-B Mh, ist da eine Ultrastar HC560 drin? Könnte man ja direkt machen um 350€... Nachtrag: Hm, wohl ein klein wenig langsamer...

www.hardwareluxx.de

Kurzfassung:
Offenbar sind die Platten in ihrer Firmware etwas "eingeschärnkt" (keine Ahnung obs auch um einen leiseren Betrieb geht oder obs nur darum geht, keine Marktkanniblaisierung zuzulassen).
Die Sequentielle Transferrate ist geringer, 235 mb/s vs. 275 mb/s auf der leeren HDD sequentiel.

Massiver aber:
RND4k Q32T1 READ - hier hab ich mit diesen Platten nur 180 IOPS statt 700-800 IOPS auf den Datacenterplatten (wobei ich da selber gerade keine Bechmarks habe oder gemacht habe, ich kann hier nur auf Benchmarks zurückgreifen, welche ich im Internet finde oder von euch beigesteuert bekomme). Das Schreiben ist gleich.
RND4k Q1T1 ist wohl gleich.

Jetzt ist die Frage, ob diese Einschränkungen mein Raid ausbremsen oder in diesem ZFS z1/2 Usecase einfach egal sind.

Ich verwende das großteils als Singleuser-Datenspeicher, und mach Backups von ein paar Maschinen drauf.
Das Lesen davon sollte halbwegs fix gehen und nicht langsamer werden.

Die Frage ist nun, wie sich das seq. Lesen wohl auswirkt (speziell ob der Geschwindigkeitsverlust bei größerer Fragmentierung linear ist oder sich dann "egalisiert").
Und speziell wie sich die kleinen Q32T1 IOPS auswirken.

Wann hab ich realistisch hohe "Q" Zugriffe bei so einer Anwendung?

 

[gea]

Haben die Platten denn den gleichen Cache?

ps
Eine mechanische Platte hat ca 100 physikalische iops. Das wird begrenzt durch upm und Durchmesser und damit Zeit bis zum Neu Positionieren der Köpfe auf einen beliebigen anderen Sektor. "Mehr" iops gibts nur wenn man Neu Positionieren vermeidet, z.B. mit Cache oder pro io mehr Daten (am Stück) schreibt.

Sequentiell ist auch Cache wichtig weil man dann auch Neu Positionierung verringert.
Sequentiell kommt es darauf an, ob man Daten "fortlaufend" schreiben kann oder dauernd Köpfe z.B. wegen kleiner Datenblöcke oder Multi User neu positionieren muss. Je nachdem schwankt sequentielle Performance zwischen vielleicht 100 und knapp 300 MB/s.

 

[pwnbert]

Haben die Platten denn den gleichen Cache?

Hm, gute Frage, ich meine ja.
Beim Schreiben ists ja gleich, beim Lesen anders.
Ich gehe von einer künstlichen Kastration aus bzw. einer "Optimierung" für den Einsatzzweck als externes Laufwerk.

Ich hab allerdings über USB gebencht, ohne sie auszubauen, das steht noch aus, evtl. liegts daran... wollte aber erstmal checken wie die Sache ist, ob ich den Kram evtl. zurück sende... geht ja schwer, wenns mal zerlegt ist.

Ich mag mir halt das Pool nicht "vergiften" indem ich in die starke Kette ein schwaches Glied setze. Davor habe ich "Angst".

 

[bbott]

@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

 

[gea]

@pwnbert

Reads: Acht HDDs × 100 IOPS = ~800 IOPS

Aber nur wenn die 8 Platten im Raid-0 arbeiten.

In einem Raid-Z aus 8 Platten hat man per vdev die iops einer einzelnen Platte (ca 100 iops)
(weil für jedes io müssen die Köpfe jeder einzelnen Platte positioniert werden)