[Sammelthread] ZFS Stammtisch

Wenn der Pool 1 GB Daten pro s unkomprimiert liefert, ist die Performance 1GB/s

Wird das GB auf 500 MB komprimiert so können in der Sekunde 2GB Daten gelesen werden.
Die 2 GB/s Datenrate ist dann nicht die Poolperformance, die ist ja nur 1 GB/s.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenn der Pool 1 GB Daten pro s unkomprimiert liefert, ist die Performance 1GB/s

Wird das GB auf 500 MB komprimiert so können in der Sekunde 2GB Daten gelesen werden.
Die 2 GB/s Datenrate ist dann nicht die Poolperformance, die ist ja nur 1 GB/s
Das wäre valide, wenn die Performance besser wäre, ja.

Aber sie ist ja **deutlich** schlechter als bei compression=off. Obwohl ja grade lz4 als default eigentlich kaum einen Einfluss haben sollte, wenns nicht komprimierbar ist. Vor allem nicht bei 64 Milan Kernen.

Bei fio kann nicht viel kompromiert werden, das sind ja pseudozufällige Daten.


Ein anderer Punkt war, dass beim 3x RAIDZ-2 die Performance bei compression=on mit Q8 schlechter war als bei Q1, und das nur bei einem Thread (CPU war also nicht am Limit oder sowas)
Dass ne höhere Queue Depth (von Q1 auf Q8) beim Lesne schlechter wird sollte eigentlich nicht der Fall sein.
 
Ändert am Prinzip nichts.
Wenn man wissen will wie schnell der Pool ist: ohne Compress
Wenn man wissen will ob compress etwas verbessert oder verschlechtert: Mit aktiviertem compress vergleichen.

ps
wie ist recsize des Testdateisystems?
 
Wenn man wissen will wie schnell der Pool ist: ohne Compress
Wollte ich nicht wissen. In anderen Tests ja, aber die muss ich noch aufarbeiten.

Wenn man wissen will ob compress etwas verbessert oder verschlechtert: Mit aktiviertem compress vergleichen.
Wollte ich wissen.

Festgestellt:

3x RAIDZ-2:
seq-1m-q8-t1-r: 4355MB/s
seq-1m-q1-t1-r: 6518MB/s
Was ziemlich traurig ist. Warum ist bei compression=on tiefere queue depth bei T1 schlechter? Das sollte NICHT sein.

Ein Stripe auf 24 der SSDs, compression=on vs compression=off

compression=on:
-52% seq-1m-q8-t32-w
-52% seq-1m-q1-t32-w
-29% seq-1m-q8-t1-rw read
-14% seq-1m-q8-t1-rw write
-12% seq-1m-q8-t32-rw read / seq-1m-q8-t32-rw write / seq-1m-q1-t32-rw read / seq-1m-q1-t32-rw write / seq-1m-q1-t1-w
Auch hier ist die Schreibperformance sehr enttäuschend. So viel einfluss sollte default algorithmus (=on=lz4) nicht haben.

ps
wie ist recsize des Testdateisystems?
128k
 
Auch wenn es nichts zu komprimieren gibt, wird LZ4 es ja trotzdem erst mal für ein paar Blöcke versuchen. Das ist auf jeden Fall Overhead.
Testest du auf Solarish oder Linux, das hab ich nirgends gefunden? Also welches Betriebssystem genau?
Mich irritieren deine Aussagen zu den SAS Treibern oben, ich hoffe doch, du hast alle Controlelr im IT-mode?
 
Testest du auf Solarish oder Linux, das hab ich nirgends gefunden? Also welches Betriebssystem genau?
Code:
EPYC 7713 @ Supermicro H12SSL-NT (BIOS 2.7, Microcode 0xa0011d1)
**proxmox-ve: 8.1.0 (running kernel: 6.5.11-7-pve)**
zfs version: 2.2.2-pve1
fio version: fio-3.33

Drives: 24x Micron 5300 PRO 1.92TB (Alle Firmware D3MU001, 512b logical sector size - reformat auf 4096 nicht supported)

Controller:  Broadcom 9600-24i (Firmware 8.7.1.0-00000-00003)
Treiber: Proprietär 8.7.1.0.0
Backplanes: Direct Attach Supermicro BPN-SAS3-216A-N4

SSD writecache: On

Mich irritieren deine Aussagen zu den SAS Treibern oben, ich hoffe doch, du hast alle Controlelr im IT-mode?
Was genau? Aber ja, natürlich sind die im IT Mode. Der 9600 ist auch mit 9600 firmware geflasht und nicht 9670-24i (mal abgesehen davon, dass da kein Crossflash möglich ist)

Das Problem beim 9600 ist, dass er die drives automatisch als JBOD anlegt. Dass es mit TRIM selbst bei älteren HBAs (9300) Probleme geb, wenn deterministic read zero nicht supported war, ist bekannt.

Auch wenn es nichts zu komprimieren gibt, wird LZ4 es ja trotzdem erst mal für ein paar Blöcke versuchen. Das ist auf jeden Fall Overhead.
Vollkommen richtig. Aber nicht 50% overhead...
 
Release Notes for OmniOS v11 r151048
r151048m (2024-02-02)

Weekly release for w/c 29th of January 2024.
This is a non-reboot update
Security Fixes
  • openssl has been updated to version 3.1.5. Security fixes have beenback-ported to the legacy 1.1 and 1.0 openssl packages.
  • unzip has been updated with a number of security fixes.
  • OpenJDK packages have been updated to 1.8.402-06, 11.0.22+7 and 17.0.10+7.
Other Changes
  • unzip now supports newer compression versions by virtue of being linkedto libbz2.
  • The virtio-scsi driver is now included in installation media and images tosupport installation in virtual environments with virtio-scsi boot disks.
  • The zlib package has been updated to version 1.3.1.
Eventuell könnte der virtio Treiber unter Proxmox hilfreich sein.
 
Hallo zusammen,

ich benötige mal einen Tipp. Ausgangslage omniOS r151046 + napp-it
Problem: Zugriff von Android auf eine SMB Freigabe zwecks Backup/Sync. Klappt seit längerem nicht mehr. Ich komme immer in eine Endlosschleife beim browsen der directories. SMB der Fritzbox geht.

Nun möchte ich als Workaround den Zugriff per SFTP machen. Nur kann ich mich, mit den über napp-it angelegten Benutzern, nicht auf der Console anmelden, geschweige denn mit WinSCP o.ä.
Was muss da noch tun, damit sie einen vollwertigen Account bekommen?
Danke!
 
Hallo zusammen,

ich benötige mal einen Tipp. Ausgangslage omniOS r151046 + napp-it
Problem: Zugriff von Android auf eine SMB Freigabe zwecks Backup/Sync. Klappt seit längerem nicht mehr. Ich komme immer in eine Endlosschleife beim browsen der directories. SMB der Fritzbox geht.

Nun möchte ich als Workaround den Zugriff per SFTP machen. Nur kann ich mich, mit den über napp-it angelegten Benutzern, nicht auf der Console anmelden, geschweige denn mit WinSCP o.ä.
Was muss da noch tun, damit sie einen vollwertigen Account bekommen?
Danke!

In napp-it angelegte Nutzer können sich nur per SMB, nicht aber an der Console anmelden.
Entweder die ssh config Datei editieren und User manuell anlegen oder Root aktivueren und nutzen (Service > SSH)

Ich würde es aber mit SMB und SMBsync2 auf Android probieren.
 
Viele Android Apps konnten nur SMB1 und scheitern an SMB2. Daran könnte es (wie gea andeutet) liegen..
Bei mir funktioniert X-Plore gut.
 
SMBsync2 mag mein S23 nicht. Zu hohe android-Version.
X-Plore funktioniert sogar mit SMBv2. Automatisierte Synchronisierung habe ich dort aber nicht gefunden. Solid explorer und FolderSync funktionieren beide nicht. Egal welche SMB-Version ich einstelle.
Zu diesem Thema suche ich schon seit längerem eine Lösung. Man findet aber wenig. Ich weiß noch nicht einmal ob es nun an OmniOS oder Android liegt.

--> SSH scheint mir eine gute Lösung.
Mit root möchte ich ungern arbeiten. Für jedes Familienmitglied gibt es einen Sync des Smartphones. Nun habe ich vor einiger Zeit endlich eine ordentliche Rechteverwaltung eingezogen (das hatten wir hier vor gut einem Jahr diskutiert :-) ) und möchte die nicht gleich wieder umgehen.

Wie migriere ich meine existierenden Benutzer am besten? In napp-it löschen und mit gleichem Namen auf der Konsole anlegen? Oder geht's auch ohne Löschen?
Die ACL's neu anzulegen wäre jetzt nicht mein Traum, aber machbar. Sag ich mal...
 
Zuletzt bearbeitet:
Man müsste nur den Usern aus napp-it eine Shell zuweisen damit sie sich anmelden können. SMB (Windows ACL Rechte) und SSH Rechte (Unix Permissions) wird man aber nicht syncron bekommen. Da bleibt nur ein eigener SSH Ordner je Person.

SMB unter Android ist zickig. SMBsync2 war eins von denen die keine Probleme machen. Wenn das nicht geht, würde ich erstmal alle verfügbaren SMB Clients durchprobieren.
 
Zuletzt bearbeitet:
Ich hab jetzt mal (bei Scale) per pre-init command einen minimal Wert für den zfs arc meta Cache vergeben (8gb, ist default auf 0).
Code:
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_meta_min
Per GUI gings irgendwie nicht, bei Core gehts offenbar.

Ich hab nämlich festgestellt, dass wenn ich erstmals (an einem Tag) auf einen Order zugreife, das alles irgendwie "langsam" lät - zu langsam für meinen Geschmack :d... beim wiederholten Zugriff passts dann, aber offenbar fällt das über Nacht wieder ausm arc.
Mal sehn, obs so besser wird. In ein paar Foren hier oder da, wenn man etwas googelt, wird diese Sache als "eines der großen Tunings" hingestellt. Könnte ich mir schon vorstellen.


Jetzt überleg ich gerade, obs irgend eine elegante Möglichkeit gibt, hier einen "preload" zu machen. Gibts da was?
 
Arc speichert ZFS Datenblöcke (read last/read most) Man könnte also Daten durch umkopieren in den Cache laden. Macht aber wenig Sinn. Ein L2Arc (vergisst bei Reboot nichts) wäre dann effektiver. Noch besser wäre ein schnelles special vdev das auch Schreiben beschleunigt - für Metadaten und alle Dateien die kleiner sind als die eingestellte Small Block Size.
 
SMBsync2 mag mein S23 nicht. Zu hohe android-Version.
X-Plore funktioniert sogar mit SMBv2. Automatisierte Synchronisierung habe ich dort aber nicht gefunden. Solid explorer und FolderSync funktionieren beide nicht. Egal welche SMB-Version ich einstelle.
Zu diesem Thema suche ich schon seit längerem eine Lösung. Man findet aber wenig. Ich weiß noch nicht einmal ob es nun an OmniOS oder Android liegt.
Also hier kann ich sagen, keine Probleme, omnios 151046 und foldersync pro um Z fold 5 auf Server zu sichern. 0 Probleme, aber auch keine besonderen Settings, lief Out of the Box
 
Ich hab jetzt mal (bei Scale) per pre-init command einen minimal Wert für den zfs arc meta Cache vergeben (8gb, ist default auf 0).
Code:
echo 8589934592 > /sys/module/zfs/parameters/zfs_arc_meta_min
Per GUI gings irgendwie nicht, bei Core gehts offenbar.
...
Hm okay, war nicht so erfolgreich. Wieder nicht so "schnell" wies nach Verwendung ist...
 
Also hier kann ich sagen, keine Probleme, omnios 151046 und foldersync pro um Z fold 5 auf Server zu sichern. 0 Probleme, aber auch keine besonderen Settings, lief Out of the Box

Hmm, sehr interessant. Bei mir klappt keine SMB-Version.
Ich habe nun auf r151048 upgedated - keine Veränderung.

Man müsste nur den Usern aus napp-it eine Shell zuweisen damit sie sich anmelden können. SMB (Windows ACL Rechte) und SSH Rechte (Unix Permissions) wird man aber nicht syncron bekommen. Da bleibt nur ein eigener SSH Ordner je Person.

SMB unter Android ist zickig. SMBsync2 war eins von denen die keine Probleme machen. Wenn das nicht geht, würde ich erstmal alle verfügbaren SMB Clients durchprobieren.

Aah ok, ich verstehe. Dann wohl doch root.
Danke.
 
Man kann mit idmapping einen Windows user auf einen Unix User mappen
Windows:hans=Unix;klaus
 
(entspricht nur meinem "groben" aktuellen Wissensstand)
Im Bezug auf https://www.hardwareluxx.de/community/threads/napp-it-für-zfs-on-windows.1349039/page-2#post-30266110

Es gibt an paar Stellen ja das Narrativ, daß jetzt wo eine ganze Horde überschwänglich dran rumfummelt, das nicht unbedingt das ist was einem Dateisystem gut tut. Allgemein stimme ich dem erstmal zu.
Auch Linus meinte mal, daß er bei Dateisystemen am wenigsten vorbeischaut, weil die sehr hohe Wahrscheinlichkeit bei einem einzigen falschen Wort sofort angeschrien zu werden ihm zu stressig ist. Er sich aber darüber freut :sneaky: Ich halte das für die einzige richtige Einstellung, beim Dateisystem. Allerdings...

...allerdings macht es wohl einen Unterschied, ob man die Situation jetzt konservativ oder objektiv betrachtet. Das Gefummel und die Testerei (eine äußerst fähige übrigens) eben am BlockCloning hat dazu geführt, daß man nicht nur den Problemen damit auf die Schliche kam, sondern auch endlich denen mit BlockCaching (!) Etwas was es sozusagen schon immer in jeder Implementierung gab und - ACHTUNG - im Frühling 2021 schon allgemein thematisiert wurde.
Und - NOCHMAL ACHTUNG - man nicht verschweigen sollte, daß auch jenes den Linuxern zuerst auffiel. Es war nur bis dato extrem schwer (erstmal so garnicht) nachzustellen.

Mit dem Gefummel an 2.2 und BlockCloning fiel auch das mit BlockCaching plötzlich viel klarer auf (!) Ein Problem welches man anscheinend seit spätestens 2006 mitschleppt... Und auch für FreeBSD (!) mit 2.1.34 behoben wurde. Ich bin daher geneigt das also eher doch positiv zu sehen.

Was mir weniger gefiel ist die andere Überschwänglichkeit, mit der man Versionen als...ähmm...Final (oder eine Art, produktiv) absegnet. Da nehme ich an und hoffe, daß wir mit 2.2.0 ein Glück hatten und das jetzt verstärkt zur mehr Selbstreflektion führen wird...

Der Ruf, daß jedwede Art von absoluter Zuverlässigkeit des ZFS zu den physikalischen Konstanten des Universums gehört :giggle: darf niemals gefährdet werden.

Diesbezüglich scheint sich aber nicht nur TrueNAS vordergründig aufgerichtet zu haben :sneaky: , sondern hintergründig auch die dicken Fische welche allgemein die FreeBSD-Foundation füttern. Ich nehme daher einfach an, daß ZFS wieder recht schnell in sehr geregelte Bahnen gelenkt wird.
 
Zuletzt bearbeitet:
Ich suche für meinen Proxmox Server eine zuverlässige M.2 SSD, vorzugsweise für "Server" mit PLP. Von Kingston gibt es da die "DC" Reihe. Ist diese zu empfehlen?
Ich habe ein MicroPC welcher leider nur 1einmal Sata und einmal M.2 hat. Bringt es etwas im Sinne von Verfügbarkeit ein ZFS Mirror zu machen auch wenn die Platten dann einmal über M.2 und einmal per SATA angebunden sind?

Auf der Platte ist Proxmox selbst und die VMs drauf. Würde gern einen Mirror haben falls im Fall der Fälle das Teil dennoch weiterlaufen kann. Ich logge dort Sensoren von meinem Smarthome und schreibe es in eine Influxdb. Grundsätzlich sind auf dem Server aber keine Daten groß gespeichert sondern da laufen eher Dienste. Die "Archvdaten" der Datenbank ist später geplant in regelmäßigen Abständen auf einen anderen Server zu kopieren
 
Zuletzt bearbeitet:
Die Micron 7400 braucht richtig viel Strom für eine M.2... wird schön heiß.

Ich würd beim nächsten Mal entweder Samsung PM oder eben diese Kingston DC probieren.
Die Kingston sind mir auch schon aufgefallen, sind vom P/L offenbar nicht so schlecht, auch in SATA oder U.2 die größeren...
 
@gea : hast Du Dir schon überlegt, was aus der napp-it AiO Lösung mit ESXi wird? Denke, die meisten werden auf einen anderen Hypervisor umsteigen. Werde dieses Jahr eh mein Netzwerk umbauen und auf Proxmox wechseln. Meinst Du, macht es Sinn, napp-it mitzunehmen? Da dran hängt nur ein HBA. Oder soll ich die ZFS Platten besser einfach nativ an den PVE Host klemmen? napp-it könnte ich ja wahrscheinlich nicht mal neu importieren, PVE wird wohl nichts mit .ova Dateien anfangen können. Der Filer sieht eigentlich so gut wie nie Updates. Habe den bislang meist neu importiert mit dem letzten Release. Oder allenfalls mal wurde napp-it mal temporär das telefonieren nach aussen erlaubt.

Habt Ihr napp-it mit PVE schon am laufen gehabt? Mir ging es bei napp-it vor allem um SMB und dem schnellem kopieren auf dem Storage.
 
Ich habe durchaus überlegt, die Template Idee auf Proxmox umzusetzen. Im Moment bin ich an der Portierung von napp-it auf Windows/Hyper-V. OmniOS hat auch in der aktuellen Version virtio-scsi Treiber integriert, Wie gut Solaris Unix damit unter Proxmox arbeitet oder optimiert werden kann muss ich mir aber selber noch anschauen. Der Solaris/OmniOS ZFS Server mit Comstar iSCSI, kernelbsierem NFS und SMB mit NFS4 ACL, Windows SID als Dateiattribut und lokalen SMB Gruppen wäre auch unter ProXmox eine Bereicherung gegenüber SAMBA ohne dies Extras.

Da der kosenlose Windows 2019 Server aber auch ausläuft, geht es wohl bei kostenlosen Lösungen Richtung Proxmox. Firmen werden eher bei ESXi bleiben.
 
Zuletzt bearbeitet:
Es gibt zwar Bestrebungen, Xen und Illumos zusammenzubringen. Ich halte das aber für viel zu speziell und hat viel zuwenig User. Der Zug ist wohl abgefahren auch wenn XCP-NG was geringen Resourcenverbrauch angeht ESXi am nächsten wäre.
 
Würde an dieser Stelle ja gerne mal ne Lanze für SmartOS + Bhyve brechen, damit kann man sich das ganze gedöns mit passthrough sparen und trotzdem voll auf ZFS aufbauen.

cu
 
SmartOS (Solarisfork auf Illumosbasis) ist als Virtualisierer eine ernstzunehmende Alternative zu ESXi/Proxmox, kann sogar einiges was die nicht können wie die Unterstützung von Linux/LX Containern (Docker soll auch gehen), Solaris Zonen, Bhyve und KVM. ZFS unter Solaris ist zudem sehr resourcenschonend. SmartOS ist ähnlich kompakt und effizient wie ESXi, basiert aber auf ZFS. Ein ZFS Storageserver direkt unter SmartOS hätte aber das Problem, dass dies nicht dem Konzept von SmartOS entspricht. SmartOS bootet ein Minimal Illumos vom USB Stick bei dem dann alle wichtigen Ordner auf den Datenpool umgebogen werden. Ein Ansatz der viel intelligenter und robuster ist als lediglich ein MinimalOS auf den Stick zu packen. SmartOS möchte dann Dienste in Zonen virtualisieren. Die Nutzung der globalen Zone ist eingeschränkt bzw Einstellungen gelten nur temporär zur Laufzeit. Braucht man die globale Zone wie häufig bei Storagediensten so wird es aufwändig da manches nicht geht, anders konfiguriert wird oder man die Einstellungen sichern und beim Booten wiederherstellen muss.

Die Idee mit SmartOS + virtualisiertem ZFS Storageserver mit einem minimalen OmniOS wäre aber eine Überlegung die gut funktionieren könnte, sehr effizient und kompakt ist und per zfs send einfach gesichert und schnell wiederhergestellt werden könnte. Man hätte dann auch eine saubere Trennung von VM Diensten und Storagediensten was der Verfügbarkeit, schnellen Wiederherstellbarkeit und Sicherheit entgegenkommt, aber wieder die Frage aufwirft wie man Platten oder HBA effizient bereitstellt oder ob und wie effizient SmartOS zvols oder Platten an VMs bereitstellen kann (Hab das bisher nur unter Linux LX Zonen probiert. Da ist der Zugriff auf ZFS Pools ohne NFS schon fein)
 
Zuletzt bearbeitet:
NFS und SMB in Zonen sollte gehen. Die Konfiguration geht teils anders als ich es unter OmniOS mache. Comstar iSCSI könnte ein Problem sein. Mein Hauptproblem wäre damit dass eine Komfortlösung mit napp-it als web-gui nicht ohne größere Anpassungen laufen würde was ich persönlich vermeiden will.

Wenn man mit der cli und ein paar Basis-scripten für zfs, nfs und smb klarkommt, geht das natürlich und ist vermutlich insgesamt viel kompakter als Proxmox +zfs da man nur einen kleinen USB stick mit SmartOS braucht.

Ich habe das aber selber inkl. sichern/wiederherstellung der Einstellungen für smb, nfs, user etc nach reboot nicht ausprobiert.
 
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