[Sammelthread] ZNAS (ZFSNAS) Chezmoi

Und was machst du damit?
Backup. In der Firma nutzen wir das überall. Privat geht ja auch. Stellst irgendwo bei F&F ein NAS hin mit gesichertem Zugang und dann kannst Deine PVE-Umgebung mittels PBS dahin sichern. Nice to have. :bigok:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bitte, bin da auch kein Profi 😅
Die meisten Tipps kamen hier im Forum. Kannst dir ja mal die ganzen Posts durchlesen.
Macht ja nix :-) Hätte ich nochmal suchen müssen, so hab ich deine Befehle einfach copy-pasted - Danke!

Hab gerade meinen Pool von TrueNAS auf Debian 13 mit "ZFS NAS" umgebaut - läuft problemlos!


EDIT:
Wie ist den so die Erfahrung mit RAM-Balloning bei ZFS unter Debian?
Wird da generell abgeraten oder ist das auch so ein TrueNAS Ding? 🙃
(ich vermute ja es ist generell, da TrueNAS ja auch ein Debian ist)
 
Zuletzt bearbeitet:
Ich hab meine "NAS" in ner VM am laufen - mit durchreichung des SATA-Controllers.
D.h. der PVE selbst sieht die HDs nach dem starten der VM gar nicht mehr.

Das hatte ich mit TrueNAS auch schon.
Da hatte ich irgendwo gelesen das man die VM dann ohne Balloning laufen lassen soll - also der RAM soll immer fest zugewiesen sein.
 
Ich hab meine "NAS" in ner VM am laufen - mit durchreichung des SATA-Controllers.
Aha ok, bei mir ist PVE das NAS (schon länger und jetzt erst recht mit zfsnas), also kann ich zu der Konstruktion gar nichts sagen. :unsure:
 
Ja, wäre auch ne variante gewesen :-)

Ich lass es einfach ohne Balloning - hab ja genug RAM ... das waren noch Zeiten wo RAM rum lag 🙃
 
Ich nutze zfs Nas direkt auf Debian, wie auch Docker. Ist schön schlank und macht alles was ich brauch.

Proxmox läuft sowieso auf einem anderen Host.
 
Zuletzt bearbeitet:
Wollte mir auch ZFSNAS anschauen, weiß nur noch nicht wo?
Auf dem PVE Host mir laufen lassen oder in eine VM stecken.
Neben dem PVE hat den Vorteil, dass man Bulk Storage noch schon an VMs und LXC durchreichen kann.
In einem LXC Container
 
1774040487666.png


Wow ... der macht ja richtig schnell ...
 
laeuft auch auf einen Raspbeery 5 mit ubuntu 24.04 LTS

mal testen, such schon laenger etwas einfaches zum verwaltet von smb shares, cockpit und co sind ja meist hoffnunglos ueberfrachtet fuer normal user
 
such schon laenger etwas einfaches zum verwaltet von smb shares, cockpit und co sind ja meist hoffnunglos ueberfrachtet
Das geht mir auch so. Hab es bisher mit Webmin gemacht, aber ZNAS (so womöglich bald der neue Name) kann das alles viel einfacher und übersichtlicher.

Fände den neuen Namen auf jeden Fall wesentlich einfacher.
Solange er es nicht X-NAS nennt ... :sneaky:
 
Es knallt mir ordentlich den RAM zu, bzw. reserviert zu viel!?
Das haben wir ja hier schon mal gerätselt: wieviel braucht's denn tatsächlich?
Werde aus Deinem Issue leider auch nicht so ganz schlau... welche Werte sind denn da "hoch"?
 
Ok, es scheint der zfs arc cache zu sein, nur keines der Tools aus den zfsutils-linux scheint bei Debian zu funktionieren.
Weder "arcstat" noch "arc_summary" findet das System.

Hätte das gerne mal geprüft


Edit.
Trotz das zfsutils-linux installiert ist, findet er beide Tools nicht:
Code:
ls: Zugriff auf '/usr/bin/arc_summary' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/usr/bin/arcstat' nicht möglich: Datei oder Verzeichnis nicht gefunden

ls: Zugriff auf '/usr/sbin/arc_summary' nicht möglich: Datei oder Verzeichnis nicht gefunden
ls: Zugriff auf '/usr/sbin/arcstat' nicht möglich: Datei oder Verzeichnis nicht gefunden
Beitrag automatisch zusammengeführt:

Ok, es ist der arc cache, heißt aber auch die Darstellung in zfsnas ist falsch:

Code:
root@ciel:~# awk '/^size/ { print $1 " " $3 / 1048576 " MB" }' /proc/spl/kstat/zfs/arcstats
size 11775.1 MB
 
Zuletzt bearbeitet:
Deswegen sag ich ja, es braucht eine GUI-Möglichkeit, den einzustellen. Das Teil ist sowieso recht nutzlos IMHO.
 
Man kann nicht besser lesen als jemand schreibt... 🤷‍♂️
Beitrag automatisch zusammengeführt:

Ok, es ist der arc cache, heißt aber auch die Darstellung in zfsnas ist falsch:
Wieso... "APP: Memory held by processes." Der dröselt das halt nicht auf. Anders als z.B. PVE:
1774104435992.png

44 GB ist auch die Grenze, welche ich derzeit festegelegt hab.
 
Zuletzt bearbeitet:
Neue Version inkl. S3 Storage ist draußen:
 
also mein Raspi5 hat nur 2GB ram, dedup und co sind deaktiviert
zum testen ist das fuer mich ideal.

OS: Ubuntu 24.04.4 LTS (Noble Numbat) aarch64
Host: Raspberry Pi 5 Model B Rev 1.0
Kernel: Linux 6.8.0-1048-raspi
Uptime: 30 mins
Packages: 739 (dpkg)
Shell: bash 5.2.21
Display (PL2474H): 1920x1080 in 23", 60 Hz [External]
Terminal: /dev/pts/0
CPU: BCM2712 (4) @ 2.40 GHz
GPU: Broadcom bcm2712d0-vc6 [Integrated]
Memory: 792.27 MiB / 1.93 GiB (40%)
Swap: 0 B / 8.00 GiB (0%)
Disk (/): 2.20 GiB / 220.32 GiB (1%) - zfs
Local IP (wlan0): 192.168.0.202/24
Locale: C.UTF-8

das mit dem ram verbrauch kann ich nicht bestaetigen, in einen anderem Thread wurde aber erwaehnt das wenn scrub oder andere arbeiten ausgefuehrt wurden, der ram fuer kuerze sehr belastet wurde
 
Hatte es ja schon geschrieben. Es war der zfs arc-cache und das Verhalten ist bei zfs normal.

Wenn kein Limit konfiguriert ist, kann der schon mal 90% vom RAM belegen.

Ich lag falsch und habe mein Issue ja auch gleich zu gemacht.
 
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