[Sammelthread] ZNAS (ZFSNAS) Chezmoi

[o$$!ram]

ZFS ballert den RAM immer voll, sobald was auf den Pools läuft wird der ARC-Cache befüllt.
Das ist ja einer der Vorteile von ZFS.

Es geht einfach drum, dass die Anzeige in der ZFS-NAS WebUI falsch ist.
Bei mir läuft nur der iSCSI Dienst, Samba und das ZFS-NAS Portal - das können keine 14,4GB RAM sein.

EDIT: Natürlich sind die Werte an sich nicht falsch!
Allerdings werden sie falsch dargestellt - für mich heisst "App" dass Anwendungen/Dienste den RAM brauchen.
ZFS Arc-Cache ist für mich keine App.

 

[toscdesign]

Der arc Cache wird vom Betriebssystem verwaltet, lt. Abfrage ist bei Debian kein Limit gesetzt

Da hat er den bei mir einfach mal mit 11GB vollgeknallt. Werde wahrscheinlich ein Limit manuell per Configfile einstellen. 50% von RAM sollten passen.

 

[o$$!ram]

Wenn deine Dienste Speicher brauchen, bekommen die den trotzdem.
Wieso soll der Cache deinen RAM nicht benutzen dürfen?
Klar, wenn du ein Flash-Only NAS hast, brauchts den Cache nicht, aber bei nem "Spinning-Rust-NAS" (nicht negativ gemeint, hab ja selber "nur" 12TB HDs) ist der Cache Gold Wert.

 

[toscdesign]

Weil ja noch andere Dinge auf dem Ding laufen, die gerne RAM hätten 😉

 

[o$$!ram]

Ich sag ja, wenn die Dienste RAM brauchen, bekommen sie den doch.

 

[Kreis]

mal eine richtig bloede frage
wenn man dataset erstellt wie legt man den mountpoint fest?

 

[asm@s24]

Trotz das zfsutils-linux installiert ist, findet er beide Tools nicht:

Die wurden umbenannt: https://metadata.ftp-master.debian.org/changelogs//contrib/z/zfs-linux/zfs-linux_2.4.0-1_changelog
* New upstream version 2.4.0.
...
* Rename arcstat and arc_summary to zarcstat and zarcsummary.
- no longer conflicts with nordugrid-arc-client (closes: #1063457).
- d/copyright: fix patterns according to filename changes.

44 GB ist auch die Grenze, welche ich derzeit festgelegt hab.

Das schien mir jetzt doch etwas viel für den ARC. Bin mal runter auf 36, das reicht wohl auch. Ist ja nur eine Zeile cli.
root@.:~# echo "$[36 * 1024*1024*1024]" >/sys/module/zfs/parameters/zfs_arc_max

ZFS Arc-Cache ist für mich keine App.

Find ich schon, weil das ganze ZFS eine "App" ist. Also das ist jedenfalls kein integraler Bestandteil von Linux wie ext4.
Aber ist ja jetzt egal, der Entwickler hat gemerkt, worum es geht und wird es einbauen.

Hab ich da was nicht mitbekommen, wurden bei Euch die Performancedaten auch zurückgesetzt?

Na ja. Jetzt mal S3 testen ...

Beitrag automatisch zusammengeführt: 22.03.2026

wenn man dataset erstellt wie legt man den mountpoint fest?

zfsnas kann das (noch) nicht.
Vermutlich geht es über cli.
Sicher geht es mit ZFDash bei bestehenden datasets, grad getestet.
Ich hab beim Entwickler von zfsnas 'n feature request offen, ob er nicht Edit aller ZFS properties einbauen kann.

 

[you]

Hat jemand schon versucht, eine SAMBA Share mit einem User als Besitzer und weiteren Usern als Read-Only über UI anzulegen? Ich kriege es ned hin

EDIT
Encryption kann man nicht einfach manuell mit Passwort machen? Muss der Key unbedingt auf dem Server liegen. Ich habe keine Probleme damit, beim Neustart manuell einen Pool einzubinden.

 

[BobbyD]

wird der ARC-Cache befüllt.
Das ist ja einer der Vorteile von ZFS.

Sehe das eher als Nachteil von ZFS, weil der intransparente Umgang damit in der Realität öfters mal Probleme machen kann. Und der ARC-Cache ist auch kein Wundermittel für gute Performance, was soll da schon groß drin sein. Wer privat regelmäßig random auf irgendwas zugreifen muss, nutzt eh Flash-Speicher. Ich würde daher sagen, der ARC-Cache ist eher ein Dinosaurier aus Spinning-Rust-Zeiten, der gebändigt gehört. Aber wird ja dran gearbeitet.

 

[gea]

Ein Cache ist ein Hilfsmittel um schnelle und langsame IT Komponenten effektiv zu koppeln. RAM ist eine Größenordnung schneller als Flash und dieser ist eine Größenordnung schneller als hd. Da machen Caches dazwischen extrem viel Sinn. Im Schnitt kann ein ZFS System oft bis zu 80% der reads aus dem Arc bedienen.

Arc gilt mit seiner read most/read last Optimierung als sehr effektiv und beschleunigt vor allem Metadatenzugriffe und last random read. Er belegt per default bis zu 50% (Solaris mehr) des Ram und gibt den frei wenn andere Prozesse RAM anfordern. Das RAM freigeben dauert etwas, Benötigen andere Prozesse sehr schnell und dynamisch mehr RAM (VMs mit RAM Balloning), so sollte man den Wert auf Kosten der Storage Performance begrenzen. RAM Überbuchen bei VMs sollte man aber eh vermeiden.

L2Arc (flash read cache) ist was anderes. Das bringt viel weniger als ein special vdev das auch write bechleunigt.
Bei sehr schnellem NVMe Storage sollte man Arc deaktivieren das das Kopieren in den Cache auch Zeit kostet (ZFS direct io)

 

[toscdesign]

Er belegt per default bis zu 50%

Unter Debian leider nicht, denn 11GB sind etwas mehr als 50% von 16GB 😅

Ich werde mir mal das anschauen, wie das mit der Config auf 50% zu begrenzen ist und entsprechend einstellen.

 

[asm@s24]

Unter Debian leider nicht ...
Ich werde mir mal das anschauen, wie das mit der Config auf 50% zu begrenzen ist und entsprechend einstellen.

Also ... PVE basiert ja auch auf Debian ... und es geht hier immer um die "App" OpenZFS, welches dazuinstalliert wird, oder ...
Begrenzen auf 8GB z.B.:

root@.:~# echo "$[8 * 1024*1024*1024]" >/sys/module/zfs/parameters/zfs_arc_max

Wie anders sollte es daher gehen als so? (Also durch Edit dieser Datei)

Es könnte allenfalls sein, daß bei den verschiedenen Distributionen bei der Installation von Paketen verschiedene Defaults festgelegt werden.

 

[Kreis]

zfsnas kann das (noch) nicht.
Vermutlich geht es über cli.
Sicher geht es mit ZFDash bei bestehenden datasets, grad getestet.
Ich hab beim Entwickler von zfsnas 'n feature request offen, ob er nicht Edit aller ZFS properties einbauen kann.

Und ich dachte schon ich wäre doof, das zufinden.
Uber die cli geht das natürlich. Wäre natürlich hübscher es gibge über die software

 

[gea]

Es ist doch per cli ganz einfach:

zfs get (ohne Parameter) aufrufen. Dann werden alle Parameter mit deren Optionen gezeigt.
Mit zfs set kann man diese ändern.

Da man "exotische" Parameter nie oder sehr selten ändert, würde eine umfangreiche Editfunktion mit Kommentaren eine Gui unnötig aufblähen. In meiner napp-it web-gui biete ich z.B. auch nur ein Listing aller Properties in der Gui an mit der Option eine der verfügbaren Parameter zu setzen. Wer das macht, sollte allerdings wissen was er tut. Weiß er das, hätter er/sie auch zfs set auf der Console hinbekommen.

 

[o$$!ram]

Sehe das eher als Nachteil von ZFS, weil der intransparente Umgang damit in der Realität öfters mal Probleme machen kann. Und der ARC-Cache ist auch kein Wundermittel für gute Performance, was soll da schon groß drin sein. Wer privat regelmäßig random auf irgendwas zugreifen muss, nutzt eh Flash-Speicher. Ich würde daher sagen, der ARC-Cache ist eher ein Dinosaurier aus Spinning-Rust-Zeiten, der gebändigt gehört. Aber wird ja dran gearbeitet.

Hab ja auch geschrieben, dass wenn ein Flash-Only NAS läuft, der Cache eher zu vernachlässigen ist, aber wer hat schon daheim ein x-TB Flash-Only NAS stehen, daher würde ich den Cache eher nicht als Dinosaurier bezeichnen.

Und ich merke sehr wohl ob der Cache "geladen" ist oder nicht.
Alleine der Zugriff auf große Ordner geht mit Cache DEUTLICH schneller als ohne.

Beitrag automatisch zusammengeführt: 22.03.2026

Find ich schon, weil das ganze ZFS eine "App" ist. Also das ist jedenfalls kein integraler Bestandteil von Linux wie ext4.
Aber ist ja jetzt egal, der Entwickler hat gemerkt, worum es geht und wird es einbauen.

Hab ich da was nicht mitbekommen, wurden bei Euch die Performancedaten auch zurückgesetzt?

Mmmhm ... ja dass stimmt natürlich, allerdings ist es ein Dateisystem - klar, nicht direkt bei Debian mit installiert, aber trotzdem so gesehen keine App sondern Systemrelevant ...
Aber ja, eigentlich egal und er hats "fast" gecheckt :-D und bisher sauber umgesetzt.


Was mich ja echt interessiert ist, wie viel da wirklich selbst programmiert wird und wieviel von "wir" aka Claude kommt 🙃

 

[BobbyD]

Alleine der Zugriff auf große Ordner geht mit Cache DEUTLICH schneller als ohne.

Was genau meinst Du damit. Du kannst den ARC doch eh nicht vollständig abschalten. Wie viele Gigabyte muss dieser groß sein, damit du schneller auf Ordner zugreifen kannst...

 

[o$$!ram]

Bisher habe ich die größe nicht angepasst, daher kann ich das nicht sagen wie groß er für die Metadaten sein müsste.
Wobei ... doch kann ich, seit dem neuen Update gibts ja den tollen Viewer:

Man sieht auch recht gut das der Cache doch durchaus genutzt wird ... keine Ahnung mit was, aber, er ist in Benutzung 🙃
Allerdings, merke ich aktuell keinen Unterschied zwischen den 32GB mit TrueNAS und den 16GB jetzt mit der "ZNAS" Installation.

Was ich meine ist, nach einem Reboot ist der Cache leer und dann ist der Zugriff auf Ordner mit mehreren hundert Dateien und vielen unterordnen träge.
Sobald der Cache bereit ist und "beladen" ist, gibts da keine Wartezeiten mehr.

 

[BobbyD]

Wie jetzt, das ist schon drin? 🤯

 

[toscdesign]

Also so langsam glaube ich nicht mehr dran, daß es nur eine Person oder ein kleines Team ist, selbst mit Ki können die doch nicht so schnell sein

 

[asm@s24]

Bisher habe ich die größe nicht angepasst, daher kann ich das nicht sagen wie groß er für die Metadaten sein müsste.
Wobei ... doch kann ich, seit dem neuen Update gibts ja den tollen Viewer:

Bei mir hat es deutlich mehr Metadaten drin:

Und was bedeutet "kernel managed"? Ich fahr ja PVE und das hat einen eigenen Kernel. Frage mich, ob die da einen anderen Algorithmus drin haben.

 

[o$$!ram]

Ich würde ja sagen du hast mehr RAM, ich hab lediglich 16GB der VM zugwiesen, evtl. liegt es daran, oder die Metadaten beim PVE sind deutlich mehr als bei nem "klassischen" NAS?
Keine Ahnung 🙃

Laut Einstellung heisst "kernel managed" das der Kernel selbst entscheidet wieviel er für den ARC Cache (im maximum) hergeben kann.
Die default Einstellung bei Debian (zumindest bei mir, hab nichts geändert) sind die 95%.

 

[asm@s24]

Ich würde ja sagen du hast mehr RAM

Ja das schon. Ich frag mich nur, ob das auch was an der Nutzung ändert. Aktuell hab ich sogar 36% Metadaten im ARC. Es läuft grad ein S3-Test. Das haben die superst implementiert. Mußte erst wie immer bei S3 mit den credentials herumdoktern und nun hab ich es mit Veeam am Laufen. Es geht auch SOSAPI (blauer bucket) - ok, das ist, weil Minio das kann. Und Object Lock (immutable).

Hat jemand 'ne Idee, was in dem roten Bereich hier zu sehen sein soll? Bei mir ist da nie was erkennbar:

 

[o$$!ram]

Ich denke es ist einfach generell anders beim PVE - du hast da ja auch die einzelnen VM/LXCs "VHDs" als Datastores drin.
Könnte es sein das der ARC Cache auch die Metadaten aus den "VHDs" mit rein nimmt?

Im roten Bereich sollte eigentlich die Auslastung des Pools sein (Read/Write und "Last")

 

[asm@s24]

Und was machst du damit?

Es gibt immer mehr S/W welche S3 unterstützt. Oder geradezu erwartet. Ich persönlich empfinde es auch als eher vorteilhaft, in der S/W einen gesicherten Zugang zum Storage zu konfigurieren, als mit SMB, NFS, usw. hantieren zu müssen. Aber das ist vl. Geschmackssache.

Ich denke es ist einfach generell anders beim PVE - du hast da ja auch die einzelnen VM/LXCs "VHDs" als Datastores drin.

Ok, ja, es laufen insgesamt 20 VMs, LXCs, Docker-Cs ... 🌪️ Alles auf "nur" 'nem NAS. Schon irre, was da heut geht.

 

[BobbyD]

Jetzt weiß auch ich, warum er vermutlich ein Kanadier ist.
Von mir aus darf er jetzt gerne seine Software umbenennen, je früher, desto besser.

 

[o$$!ram]

Wegen Chezmoi? 🙃

 

[Haldi]

durchaus genutzt wird ... keine Ahnung mit was, aber, er ist in Benutzung 🙃

Ähhhhh
Die Hitrate wird auch unter Netdata angezeigt.
Aber die sagt ja nur "Ich wollte was, es war im Cache" also eigentlich müsste man den Cache bei normaler Benutzung so weit reduzieren bis die Cache Hitrate offensichtlich einbricht?
Dann hätte man den "brauchbaren minimalen cache"?

 

[BobbyD]

Also ARC Maximum gefällt mir noch nicht, da dort nur relativ großzügig eingestellt werden kann, muss ich ihm mal schreiben.

 

[toscdesign]

Jetzt weiß auch ich, warum er vermutlich ein Kanadier ist.
Von mir aus darf er jetzt gerne seine Software umbenennen, je früher, desto besser.

Wegen Chezmoi? 🙃

Hab ich was verpasst?

 

[BobbyD]

Hab ich was verpasst?

Denke nicht, Du wusstest das ja mit als erster.