NAS UGreen DXP4800 Plus

Wozu überhaupt NFS wenn WindowsClient?
Was sind denn die üblichen Anwendungsszenarien, dass du so viel "Power" brauchst?

Vielleicht nochmal in Ruhe das eigene Vorhaben skizzieren und dann loslegen - nur so ein Tip:)
 
Last edited:
Meine Frage ist: Was mache ich am besten aus meiner neuen UGreen-NAS, die eine ältere Synology ablösen soll. Sie soll in einer nicht produktiven HomeLab-Umgebung zwei Aufgaben erfüllen: Ca. 6 TB Backup-Dateien aufnehmen und als Datastore für verschiedene Virtualisierungslösungen dienen.
Das klingt auch wirklich nicht praxisnah - wenn es nicht produktiv ist, wozu dann Backup?

Außerdem nutzt du ja nun TrueNAS auf dem Ugreen oder? Daher hätte das hier ja nix mehr mit Proxmox zu tun
 
wozu dann Backup
Für den Rest der IT im Haushalt (Daten, Fotos, Videos, MP3s, Veeam Agent Images u.v.a.m.).

Daher hätte das hier ja nix mehr mit Proxmox zu tun
Ja, das ist korrekt. Also danke für jede Antwort. Wobei TrueNAS und Proxmox mit ZFS eine wichtige Gemeinsamkeit haben.
 
  • Like
Reactions: Browbeat
Ich vermute du hast write amplification wie Sau
Wird immer wieder behauptet, Zahlen hab ich noch nie gesehen. Deshalb hab ich's mal selbst gemessen. Ergebnis (Windows VM auf local ZFS 4-disk raidz1): es spielt kaum eine Rolle. Ob nun RAW, VMDK, QCOW2, ZVOL. Tatsächlich ist ZVOL am besten, dann RAW, dann QCOW2, dann VMDK.
Bei ZVOL könnte noch die VolBlockSize 'ne (kleine) Rolle spielen. Ich hab mit 64 KB gemessen und NTFS auch so formatiert.
Via NFS ist es noch egaler. Da fällt halt ZVOL weg. Aber RAW hat keine Snapshots, also ja, da nimmt man dann eben QCOW2.
Nee aber mal ernsthaft, du hast ext4 VMs deren QEMU2 disks auf einen NFS share sind und dieses NFS share nutzt ZFS?
Also nein, NTFS-VMs. Aber sonst ja. Und das ist nur 'ne Test-VM. Eigentlich laufen hier VMs auf zwei PVE local.
... weil richtig geil ist die ausgesuchte Hardware jetzt nicht als Hypervisor ...
Ein Grund, warum ich eben auf das N5 gewechselt bin.
... bei diesem Ugreen ist die QVL wichtig, es läuft nicht jeder beliebige RAM laut Userberichten ...
Ich hatte die von Crucial, die gingen gut (und jetzt sind sie im N5 auch tipptopp).
Die UGreen ist auf 16 GB RAM aufgerüstet (mehr ist im Moment nicht bezahlbar, 64 GB kosten ja mehr als die ganze NAS ohne Platten).
Ja, das ist schon krass. Leider sind 16 GB echt wenig für ZFS und 'n paar Container. Ich hab 80 GB und davon allein gut die Hälfte für den ARC. Ich kann verstehen, wenn man lieber TN hat wegen Storage-Features, aber m.E. ist eben PVE deutlich genügsamer. Ja nu.
Dann wäre interessant, ob mit nfs3 oder nfs4 zugegriffen wird ...
Hat bei meinen Tests keinen Unterschied gezeigt.
 
Wird immer wieder behauptet, Zahlen hab ich noch nie gesehen.
Naja, wenn du ein 4k file in einem 64k volblock änderst, ist die write Amplifikation nun mal 16 fach.
Wenn du ein 64k file in einem einem 64k volblock änderst, hast du gar keine.

Wie NTFS selbst formatiert ist, ist nochmals ein Komplexitätslayer im Test. Der default ist glaube ich für Windows 4k, für ext4 512.

Wer misst, misst Mist.
Ob nun RAW, VMDK, QCOW2, ZVOL. Tatsächlich ist ZVOL am besten, dann RAW, dann QCOW2, dann VMDK.
Was meinst du mit RAW oder ZVOL. RAW kann ja nur in einem ZVOL liegen wenn auf ZFS.
Verstehe darum die Unterscheidung nicht ganz.
Aber RAW hat keine Snapshots,
Ja doch. Sogar die viel schnelleren Snapshots als QCOW2.
 
Leider sind 16 GB echt wenig für ZFS
Ich glaube mittlerweile, dass das mein Hauptproblem ist. Würde gern mit mehr RAM testen, aber der ist im Moment einfach zu teuer. Werde mal OMV ohne ZFS testen. Soll auch einfacher zu administrieren sein.
 
Leider sind 16 GB echt wenig für ZFS und 'n paar Container. Ich hab 80 GB und davon allein gut die Hälfte für den ARC. Ich kann verstehen, wenn man lieber TN hat wegen Storage-Features, aber m.E. ist eben PVE deutlich genügsamer.
Warum sollte PVE genügsamer sein als TrueNAS?
Wer das behauptet, hat ARC nicht verstanden.

ARC ist adaptive replacement cache.
ARC ist read cache.
ARC beinhaltet aber auch einen dirty write cache, die 5s goal async TXGs writes.
Der reach cache kann jederzeit geschrumpft werden. Die dirty writes nicht.

Ich schüttle mir das mal aus dem Ärmel, bitte mit Vorsicht geniessen, ich glaube es kann zu folgenden Situationen kommen:

Du hast ein TrueNAS System mit 64GB RAM:
Davon werden 32GB für VMs und TrueNAS verwendet.
32GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 8GB konsumiert.
Kein Problem, ARC wird einfach um 8GB geschrumpft.

Du hast ein Proxmox System mit 64GB RAM:
Davon werden 56GB für VMs und Proxmox verwendet.
8GB sind für ARC.
Davon sind (10Gbit * 5 Sekunden =6,25) nicht schrumpfbar, weil dirty write data des 10GBit NIC.
Jetzt starten wir eine weitere VM die 4GB konsumiert.
ARC kann aber nur um ca. 2GB geschrumpft werden.
Wir laufen in eine out of memory Situation.

Das erklärt auch warum unterschiedliche OS, unterschiedliche defaults haben.

TrueNAS hatte früher unter BSD die ARC auf 80% des RAMs limitiert.
Mit TrueNAS SCALE wurde dann der Linux default von max 50% des totalen RAM übernommen.
Weil bei Proxmox der genutzte RAM tendenziell weniger schrumpfbar ist, wurde neu die Limite 10% and max 16GB eingeführt um eine oom Situation zu verhindern. Sehr konservativ.

Das sind aber nur defaults und problemlos anpassbar.
Proxmox nutzt also nicht weniger RAM als TrueNAS. Es hat nur andere Defaults.


TrueNAS empfahl früher min 16GB und 1GB pro TB.
Gab wohl exotische Crashes mit 8GB Systemen und niemand hatte Lust sich diese anzuschauen, weil
"ZFS ist ein Server FS und ein Server hat nicht nur 8GB RAM"
Später korrigierten sie es auf min 8GB, egal wie viel TB.

Proxmox empfiehlt 2GB plus 1GB pro 1TB storage.
Ich glaube das 1GB pro 1TB ist einfach noch ein altes Überbleibsel.

Ich wüsste keinen Grund, warum ich nicht 5TB storage mit 2GB ARC betreiben könnte.
 
Last edited:
  • Like
Reactions: Johannes S