[Sammelthread] ZFS Stammtisch

[CommanderBond]

Mal eine Verständnisfrage: Wenn ich Replicationen nutze und den verschlüsselten Stream übertrage welche Relevanz hat dann die zfs eigenschaft compression auf dem Zieldateisystem? Wenn die Daten verschlüsselt sind kann der Zielserver die Daten doch eh nicht weiter komprimieren weil Komprimierung doch über Verschlüsselung ansetzt.
Wenn meine Quelle also compression=off hat und ich dann den verschlüsselten Stream übertrage und am zielort ist compression=on dann würde faktisch doch nichts komprimiert werden oder sehe ich das falsch?

 

[gea]

Ich seh das so
Wenn das Dateisystem "raw" übertragen wird (Open-ZFS, Solaris mit native ZFS macht das anders),
dann bleiben die Eigenschaften des Quelldateisystems (Enc, Key, Compress etc) erhalten.

Wenn das Dateisystem "normal" übertragen wird, so wird das Dateisystem vor der
Übertragung entschlüsselt und dekomprimiert. Auf dem Zieldateisystem erbt es die
Eigenschaften (Verschlüssellung, Compress etc) des dortigen Eltern-Dateisystems falls
man nicht bei der Übertragung etwas anderes manuell einstellt.

 

[chicken]

Ich frag mal den Maintainer nach dem Stand der Dinge.

Habe eine nicht zu knappe Antwort erhalten:

- Aktuell unterstützt der vmxnet3 Treiber nur Checksummen-Offloading für ipv4 und LSO.
- Illumos hat keinen Mechanismus für VLAN HW-Offload, welches der Treiber unterstützen würde
- Aktuell steht eine Codeüberprüfung an, die LRO-Unterstützung hinzufügt, womit die Verarbeitung kleiner Pakete und Jumboframes verbessert werden soll
- Anmerkung zu vorigem Punkt: Aktuell kann die Verwendung von Jumboframes bei Verwendung von vmxnet3 zu Problemen führen, weil der Treiber beim Empfang von Jumbo-Frames übermäßig streng irgendwelche Dinge prüft. Das kann zu einer übermäßigen CPU-Auslastung führen.
- Der Code vom Treiber wird / soll überarbeitet werden, dass zukünftig auch Multiring-Puffer hinzugefügt werden können (senden und empfangen mehrerer Streams gleichzeitig)
- Er hat bestätigt, dass man die Ringgröße verändern kann, aber wenn man diesen Puffer zu groß macht, verbraucht er zu viel Kernel-Speicher, was sich wiederum negativ auf die Performance auswirken kann, wenn mans übertreibt.
- Linux (und wahrscheinlich auch Windows) haben zusätzliche Funktionen im vmnet3 implementiert, die weder FreeBSD noch Illumos beinhalten. Darum sind die schneller.
- Die Sourcen vom Windowstreiber sind nicht zugänglich
- Die Sourcen vom Linuxtreiber schon, aber da diese für GPLv2 lizenziert sind, ist es wohl lizenztechnisch nicht so einfach, auf Illomos zu portieren. Er orientiert sich daher eher am FreeBSD Treiber.
- Er würde gerne auch einfach den vorhandenen Linux Treiber mehr kopieren /nachahmen, bräuchte von VMware aber die Zusage, dass es ihnen egal ist, wenn er so vorgeht. Leider weiß er nicht an wen er sich da wenden soll um eine verbindliche Zusage zu bekommen.

Er hat angeboten, ein aktuelles pkg mit dem aktuellen Entwicklungsstand zum testen zu erstellen und mir zukommen zu lassen. Ich würde das mal annehmen und fragen ob es OK ist, wenn ich das hier verteile.

 

[AliManali]

Hi

Angenommen ich kaufe ein paar gebrauchte Enterprise 1.92 TB SSD von verschiedenen Herstellern, bzw. unterschiedliche Typen. Kann ich damit problemlos ein Software RAID machen mit napp-it, oder ist das eine schlechte Idee?

Im Moment liegen alle VM's auf einer einzelnen 2 TB SM883. Drei 1.92 TB hätten noch Platz im Hotswap Cage an napp-it. Was wäre da für ein Software RAID mit drei SSD zu empfehlen, falls das überhaupt Sinn macht?

 

[gea]

ZFS nimmt alles was nach Platte "riecht", egal ob Datei, HD, SSD oder Target - auch im Mix.
Das einzige was passiert ist dass das langsamste/kleinste Device die Performance/Kapazität bestimmt.

Mit 3 Platten kann man einen 3way Mirror machen (schnell, max Zuverlässigkeit). Mit SSD macht man ein Z1.

 

[gea]

Multithreaded Solaris/Illumos SMB-Server mit NFS4 ACL und Windows SID vs SAMBA

ZFS
Solaris Unix ist der Ursprung von ZFS und bietet immer noch die beste Integration in das Betriebssystem mit dem geringsten Ressourcenbedarf für ZFS. Während ZFS unter Linux nur ein weiteres Dateisystem unter vielen anderen ist, hat Sun OpenSolaris zusammen mit ZFS als primäres Dateisystem entwickelt (Oracle Solaris 11.4 und Illumos/OI/OmniOS sind Nachkommen) mit vielen erweiterten Funktionen wie Drace, Service Management oder Container-basierten VMs . Alle diese Funktionen und Ideen fanden Eingang in BSD oder Linux, ohne dass NFS oder SMB so tief in ZFS integriert wurde. Insbesondere der Multithread-SMB-Server, der Teil von Solaris-basierten Systemen ist der häufigste Grund für die Verwendung dieses Unix.

SMB und ACL
Der wichtigste Anwendungsfall von Storage ist SMB, das File-Sharing-Protokoll von Microsoft. Dadurch wurden überlegene, feingranulare ACL-Berechtigungen mit Vererbung in das NTFS-Dateisystem und in SMB-Freigaben eingeführt. Während herkömmliche Linux/Unix-Berechtigungen oder Posix-ACL nur einfaches Lesen/Schreiben/Ausführen auf einer Benutzer-ID wie 101 zu bieten hat, erlauben die NTFS-ACL zusätzliche Berechtigungen zum Erstellen/Erweitern von Dateien oder Ordnern, zum Ändern oder Lesen von Attributen oder zum Übernehmen von Eigentümer Rechten basierend auf einer eindeutigen Windows SID wie S-1-5-21-3623811015-3361044348-30300820-1013

NFS4-Berechtigungen
Der Kernel-basierte Solaris/Illumos-SMB-Server ist der einzige, der NFS4-ACL (eine Obermenge von Windows NTFS-ACL, Posix ACL und einfachen Unix-Berechtigungen) vollständig in das OS uns SMB integriert hat mit Windows-SID (Eigentümer-/Benutzerreferenz) als ZFS-Attribut - dies obwohl das Unix-ZFS-Dateisystem normalerweise nur Unix-UID/GID als Benutzer-/Eigentümerreferenz akzeptiert. Der Hauptvorteil besteht darin, dass man ein ZFS-Dateisystem mit intakten Windows-Berechtigungen verschieben/wiederherstellen kann. Wenn man stattdessen SAMBA verwendet, das nur auf Unix-UID/GID basiert, muss man komplizierte ID-Zuordnungen verwenden, um einer Windows-SID eine Unix-UID zuzuweisen, die dazu von Server zu Server unterschiedlich ist.

New Solaris ACL Model - Oracle Solaris Administration: ZFS File Systems

This book is intended for anyone responsible for setting up and administering Oracle ZFS file systems. Topics are described for both SPARC and x86 based systems, where appropriate.

docs.oracle.com

Access-control list - Wikipedia

en.wikipedia.org

Security Identifier - Wikipedia

en.wikipedia.org

ACLs - Linux NFS

wiki.linux-nfs.org

NFS4 ACL overview - SambaWiki

wiki.samba.org

SMB-Gruppen
Der Kernel-basierte Solaris/Illumos-SMB-Server ist der einzige, der zusätzliche lokale SMB-Gruppen bietet. Im Gegensatz zu Unix-Gruppen erlauben Windows-artige SMB-Gruppen in den ACL-Einstellungen die Verwendung von Gruppen in Gruppen. Die Gruppen-ID ist eine Windows-SID, genau wie eine Benutzer-ID.

Vorherige-Versionen
Der Kernel-basierte Solaris/Illumos SMB-Server ist der einzige mit einer strikten Beziehung zwischen einem ZFS-Dateisystem und einer Freigabe. Dies ist wichtig, wenn Sie ZFS-Snaps als Windows-„Vorgängerversionen“ verwenden möchten. Da ZFS-Snaps einem Dateisystem zugewiesen sind, kann es ziemlich verwirrend sein, wenn man stattdessen SAMBA verwendet. Da SAMBA nur Datenordner sieht und nichts über ZFS weiß, muss man Freigaben sorgfältig konfigurieren und organisieren, damit dies insbesondere mit verschachtelten ZFS-Dateisystemen funktioniert, während unter Solaris „frühere Versionen“ einfach ohne weitere Einstellungen funktionieren.

Einrichtung
Im Allgemeinen ist der Solaris/Illumos-SMB-Server viel einfacher zu konfigurieren und einzurichten als SAMBA, das auch unter Solaris eine Option ist. Keine smb.conf mit Servereinstellungen, einfach smb share eines ZFS-Dateisystems aktivieren. SMB-Serververhalten kann mit dem Admin-Tool smbadm, smbadm – Manpages Abschnitt 1M: Systemadministrationsbefehle festgelegt oder angezeigt werden oder es sind ZFS-Eigenschaften wie aclmode, aclinherit oder NFS4-Datei- oder Freigabe-ACL im Allgemeinen.

Multithreaded
Während der Singlethreaded SMB Server SAMBA die beste Singlecore-CPU-Leistung benötigt, ist der Kernel-basierte SMB-Server besser für Multicore-CPUs und viele parallele Anforderungen optimiert.

Nachteile
Der Kernel-basierte SMB-Server bietet weniger Optionen als SAMBA und unterstützt nur den Windows AD-Membermodus (standardmäßig).

 

[CommanderBond]

Während der Singlethreaded SMB Server SAMBA die beste Singlecore-CPU-Leistung benötigt, ist der Kernel-basierte SMB-Server besser für Multicore-CPUs und viele parallele Anforderungen optimiert.

Ist das denn noch aktuell?

 

[gea]

Nach meinem Kenntnisstand kann SAMBA zwar SMB Multichannel, arbeitet aber singlethreaded.
Die Auswirkungen sollten meist aber überschaubar sein. Bei der Auswahl einer CPU sollte man das eventuell beachten (Takt vs Cores)

 

[VirtuGuy]

ist mit io_uring heute kein Thema mehr.

 

[bbott]

Scheinbar immer noch nicht fertig, wenn man nach Github geht
Qnap scheint da mit "QuTS Hero" ein wenig bleeding edge zu gehen (oder sind die da schon weiter?)

QuTS hero h5.2

QuTS hero h5.2 bietet eine ausgezeichnete Leistung und überragende Speicherverwaltung für robuste und zuverlässige Speicherlösungen.

www.qnap.com

Erhöht das die Chance das es in zfs vorangetrieben wird? Qnap habe ich leider nicht :-/

 

[CommanderBond]

was genau denn?

 

[gea]

Erhöht das die Chance das es in zfs vorangetrieben wird? Qnap habe ich leider nicht :-/

Eher Nein.
Qnap nutzt einfach ZFS on Linux so wie es ist und packt webbasiertes Management dazu. Ich wüßte nicht dass Qnap ZFS Entwickler hat. Beiträge bei den Open-ZFS Entwicklerkonferenzen gab es jedenfalls noch nie.

Wobei ZFS nach fast 20 Jahren Entwicklung sehr ausgereift ist. Es gibt nur ganz wenig was vorangetrieben werden sollte wie Erweiterbares Raid-Z (praktisch fertig, eher was für Heimuser, Stabilität ist aber noch nicht ganz klar- würde ich eher abwarten bis das eine Zeitlang eingesetzt wird) oder Direkt IO (Schreiben ohne den Schreibcache, in Entwicklung), prinzipiell schnelleres Dedup oder Nutzung von Cloud Storage z.B. S3 als device, Clustering (jeweils erste Ideen) etc.

ps
Wenn man wissen will wer was zu ZFS beiträgt und was gerade entwickelt wird:

OpenZFS Developer Summit - OpenZFS

openzfs.org

 

[gea]

Welches Slog statt Intel Optane zum Schutz des ZFS-RAM-basierten Schreibcaches?

In den letzten Jahren war die Situation recht einfach. Wenn man Daten im rambasierten ZFS-Schreibcache bei Datenbanken oder VM-Speicher schützen wollte, musste man lediglich „sync write“ aktivieren. Um den Leistungsabfall bei festplattenbasierten Pools zu begrenzen, gab es erschwingliche Intel Optane mit geringerer Kapazität aus der 800-, 90x-, 1600- oder 4801-Serie um es als Slog hinzuzufügen. Die Modelle unterscheiden sich hauptsächlich im garantierten Powerloss Protection (bezüglich PLP ist jede Optane völlig in Ordnung) und der maximalen Schreibmenge/ Endurance.

Heutzutage wird es immer schwieriger, günstige Optane zu finden. Was also tun?

Festplattenbasierte Pools:
Wenn man immer noch festplattenbasierte Pools für VMs oder Datenbanken verwendet, benötigt man unbedingt ein Slog. Ohne Slog bietet ein ZFS-Pool kaum mehr als vielleicht 10–50 MB/s sync-Schreibleistung. In einer solchen Situation würde ich versuchen, eine der kleineren Optane entweder neu oder gebraucht zu bekommen. Da ein Slog eine minimale Größe von nur etwa 8 GB hat, kann man auch nach einem gebrauchten DRAM-basierten RMS-200 oder RMS-300 von Radian Memory Systems suchen – mehr oder weniger die einzige echte Alternative zu Intel Optane.

Was ich machen würde:
Einen großen festplattenbasierten Pool nur für die Filer-Nutzung oder Backups nutzen, da man da sync-write nicht unbedingt braucht. Der ZFS-Pool ist dann für die meisten Anwendungsfälle schnell genug. Dazu einen zweiten kleineren/schnellen Pool mit NVME/SSDs für VM-Speicher oder Datenbanken und da einfach sync-write ohne einen zusätzlichen dedizierten Slog aktivieren. Der ZIL des Pools (ein schneller Poolbereich ohne Fragmentierung) schützt dann sync Schreibvorgänge. Wichtig ist NVMe/SSD-Powerloss Protection (ein Muss für synchrones Schreiben), niedrige Latenz und hohe 4K-Schreib-IOPS. Als Faustregel gilt: Man sucht nach NVMe/SSD mit plp und mehr als sagen wir mal 80.000 Schreib-IOPS bei 4k. ZU bevorzugen sind NVMe gegenüber SSD und 2x 12G/24G SAS wie WD SS 530/540 oder Seagate Nitro (fast so schnell wie NVMe) gegenüber 6G Sata SSD.

Alternativ zu dem zweiten Pool kann man auch einen special vdev Mirror einsetzen
Ein special vdev ist eine Tiering Option für einen Hybrid Pool aus Platten und SSD/NVME. Dabei werden Daten aufgrund Ihrer physikalischen Dateneigenschaften entweder auf dem langsamen Plattenpool oder den schnellen SSD gespeichert. Small IO, Metadaten, Dedupdaten oder ein komplettes ZFS Dateisystem mit Datenbanken oder VMs mit einer recsize <= eines einstellbaren Schwellwerts landen dann auf dem schnellen Bereich des Pools.

 

[CommanderBond]

Ich habe das Problem dass ich bei den SMB Freigaben auf meinem Server die ich per Netzwerklaufwerk angebunden habe manche Aktionen nicht durchführen kann. zB versuche ich über das Kontextmenü ein HEIC (Bild) zu drehen was aber mit einer Fehlermeldung quittiert wird mit der Begründung die Datei sei anders wo geöffnet oder die Freigabe sei Readonly.
Die Rechte sind allerdings "modify". Wenn ich das Bild öffne in dem Windowstool kann ich es hingegen drehen und es wird dann auch direkt gespeichert/überschrieben.
Benutze ein aktuelle OmniOS+Nappit

 

[gea]

Es gibt eigentlich drei mögliche Gründe für ein derartiges Verhalten einzelner Programme
(meist benutzen die eigene/besondere File-Locking Optionen)

1. nbmand (ZFS Eigenschaft, eher unwahrscheinlich)
Nbmand kann man im Menü ZFS Dateisysteme umschalten. Wenn es nichts ändert zurückschalten.

2. oplock (Eigenschaft eines SMB Servers)
oplock kann man bei den SMB Servereigenschaften in Services > SMB > Properties umschalten. Wenn es nichts ändert zurückschalten.

3. Ein Bug wie z.B. https://www.illumos.org/issues/15738 oder https://www.illumos.org/issues/15992
In diesen Fällen zuerst auf das neueste OmniOS unter Support wie 151046x updaten. Behebt das das Problem nicht, dann entweder das Problem in https://illumos.topicbox.com/groups/omnios-discuss beschreiben und/oder auf das nächste OmniOS stable 151048 warten (Anfang November). Da werden vermutlich die aktuellen SMB Verbesserungen drin sein die gerade anstehen, https://illumos.topicbox.com/groups/developer/T60e709b92e1768d4/review-patch-queue-for-smb-service

Bleibt ein Problem nachvollziehbar bestehen, kann man schauen ob es einen Bug gibt oder auch ein Bug Issue in Illumos-gate erstellen, https://www.illumos.org/issues

 

[chicken]

[...]

Er hat angeboten, ein aktuelles pkg mit dem aktuellen Entwicklungsstand zum testen zu erstellen und mir zukommen zu lassen. Ich würde das mal annehmen und fragen ob es OK ist, wenn ich das hier verteile.

Bisher noch keine weitere Reaktion erhaltne. Ich frag nächste Woche mal nach.

Eher Nein.
Qnap nutzt einfach ZFS on Linux so wie es ist und packt webbasiertes Management dazu. Ich wüßte nicht dass Qnap ZFS Entwickler hat. Beiträge bei den Open-ZFS Entwicklerkonferenzen gab es jedenfalls noch nie.

Wobei ZFS nach fast 20 Jahren Entwicklung sehr ausgereift ist. Es gibt nur ganz wenig was vorangetrieben werden sollte wie Erweiterbares Raid-Z (praktisch fertig, eher was für Heimuser, Stabilität ist aber noch nicht ganz klar- würde ich eher abwarten bis das eine Zeitlang eingesetzt wird) oder Direkt IO (Schreiben ohne den Schreibcache, in Entwicklung), prinzipiell schnelleres Dedup oder Nutzung von Cloud Storage z.B. S3 als device, Clustering (jeweils erste Ideen) etc.

ps
Wenn man wissen will wer was zu ZFS beiträgt und was gerade entwickelt wird:

OpenZFS Developer Summit - OpenZFS

openzfs.org

Ich würde hier noch hinzufügen wollen, dass die Performance von ZFS recht mies ist, wenn man seine Pools verschlüsselt und Sync Write aktiviert hat. Ich hab meine VMs auf ner NVME liegen und meine Daten auf nem HDD pool. Alles verschlüsselt und Sync Write aktiviert, weil ich kein SLOG hab. Da darf gern noch einiges an Optimierung reinfliesen, weil es da wohl irgend ein Bottleneck im Code gibt.


Völlig andere Frage:

Hat schon mal jemand ein ZFS über NVME over IP nachgedacht oder versucht zu realisieren?

NVMEoIP erfordert nicht zwingend spezielle Hardware und kann allein in Software implementiert werden. Daher wäre die Vorstellung:

Günstigen NVME basierten Storage aufbauen, der keine besonderen Ansprüche an die CPU stellt. Die CPU muss lediglich in der lage sein, die Rohdaten von den SSDs schnell genug zu schreiben und zu lesen und übers Netz zu schieben. Ideal geeignet für sowas wäre z.B. der Asustor Flashstor 6 oder 12 Pro für jeweils 6 oder 12 NVMe SSDs: https://geizhals.de/asustor-fs6712x-flashstor-12-pro-a2949046.html

Laut Benchmarks und Tests erreicht das Teil schon ganz passable Datenraten (natürlich unverschlüsselt) und das nette ist, dass der Hersteller die Installation alternativer Betriebssysteme unterstützt.

Auf der anderen Seite hat man dann Napp-IT in einer VM laufen und bindet dann über NVME over IP an. Die VM hat dann genug Performance für den Umgang mit ZFS und eventuelle Verschlüsselung. Ein lokales SLOG auf dem Host auf dem die VM läuft, sorgt dann für geringe latenzen.

 

[Luckysh0t]

Ich würde hier noch hinzufügen wollen, dass die Performance von ZFS recht mies ist, wenn man seine Pools verschlüsselt

Diese Erfahrung habe ich auch gemacht, aber nur mit openZFS. Ich nutze auf meinem Filer daheim Solaris 11.4 bare metal. Als ich mal auf einem anderen System True Nas, omni OS etc getestet habe. war die Geschwindigkeit mit verschlüsselung - ohne sync. unterirdisch, also ich rede hier von max 50 MB/s ggü den 100+ MB/s bei meinem Solaris mit Gbit Lan...

Aber das Problem hatte auch schon ein Freund vor 3 Jahren.. mein test war letztes Jahr...scheint nicht wirklich beachtet zu werden oder aufm Schirm kp. Ich bleibe daher Solaris+ napp it treu.

Die Flashtor wären interessant.. da ich mir ein neuen Filer bauen möchte....hmm das mit Solaris ? Hätte was ^^

 

[ludwinator]

@chicken
"...Sync Write aktiviert, weil ich kein SLOG hab"?
hier scheint ein ganz großes Missverständnis vorzuliegen ...


cu

 

[gea]

Ich würde hier noch hinzufügen wollen, dass die Performance von ZFS recht mies ist, wenn man seine Pools verschlüsselt und Sync Write aktiviert hat. Ich hab meine VMs auf ner NVME liegen und meine Daten auf nem HDD pool. Alles verschlüsselt und Sync Write aktiviert, weil ich kein SLOG hab. Da darf gern noch einiges an Optimierung reinfliesen, weil es da wohl irgend ein Bottleneck im Code gibt.

Das stimmt zwar, das Problem ist aber sync write mit sehr kleinen verschlüsselten Blöcken bis herunter zu 4k. Das zu verschlüsseln ist extrem ineffektiv im Vergleich zu async write wo die zu verschlüsselnden Blöcke eher 128k-1M groß sind oder im Vergleich zu Verschlüssellung des Datenstroms zur Platte (Luks etc). Da ist wenig Raum für Optimierung. Es kann gut sein dass künftiges direct i/o (Schreiben ohne RAM Schreibcache) eine deutliche Verbesserung mit enc bringt, vgl https://www.napp-it.org/doc/downloads/epyc_performance.pdf
und https://www.phoronix.com/news/OpenZFS-DirectIO-Performance

Völlig andere Frage:

Hat schon mal jemand ein ZFS über NVME over IP nachgedacht oder versucht zu realisieren?

NVMEoIP erfordert nicht zwingend spezielle Hardware und kann allein in Software implementiert werden. Daher wäre die Vorstellung:

Günstigen NVME basierten Storage aufbauen, der keine besonderen Ansprüche an die CPU stellt. Die CPU muss lediglich in der lage sein, die Rohdaten von den SSDs schnell genug zu schreiben und zu lesen und übers Netz zu schieben. Ideal geeignet für sowas wäre z.B. der Asustor Flashstor 6 oder 12 Pro für jeweils 6 oder 12 NVMe SSDs: https://geizhals.de/asustor-fs6712x-flashstor-12-pro-a2949046.html

Laut Benchmarks und Tests erreicht das Teil schon ganz passable Datenraten (natürlich unverschlüsselt) und das nette ist, dass der Hersteller die Installation alternativer Betriebssysteme unterstützt.

Auf der anderen Seite hat man dann Napp-IT in einer VM laufen und bindet dann über NVME over IP an. Die VM hat dann genug Performance für den Umgang mit ZFS und eventuelle Verschlüsselung. Ein lokales SLOG auf dem Host auf dem die VM läuft, sorgt dann für geringe latenzen.

Irgendwas over IP beingt immer Netzwerkoverhead, deutlich mehr als z.B. FC ohne ip. Ob es schneller geht als iSCSI via ip würde ich bis zum Beweis des Gegenteils bezweifeln. Blockstorage via iSCSI geht problemlos, ich habe damit schon Versuche mit HA und Network Mirrors gemacht. Ist halt spürbar langsamer als local Storage z.B. via SAS multipath.

Beitrag automatisch zusammengeführt: 22.10.2023

@chicken
"...Sync Write aktiviert, weil ich kein SLOG hab"?
hier scheint ein ganz großes Missverständnis vorzuliegen ...


cu

Für sync brauchts kein Slog. Wenn man sync aktiviert findet das Logging auf dem ZIL (schneller Bereich eines Pools ohne Fragmentierung) statt. Wenn einem das zu langsam ist kann ein Slog für das Logging helfen. Enc + sync bleibt trotzdem langsam.

 

[chicken]

@chicken
"...Sync Write aktiviert, weil ich kein SLOG hab"?
hier scheint ein ganz großes Missverständnis vorzuliegen ...


cu

Ich meinte ZIL.

Irgendwas over IP beingt immer Netzwerkoverhead, deutlich mehr als z.B. FC ohne ip. Ob es schneller geht als iSCSI via ip würde ich bis zum Beweis des Gegenteils bezweifeln. Blockstorage via iSCSI geht problemlos, ich habe damit schon Versuche mit HA und Network Mirrors gemacht. Ist halt spürbar langsamer als local Storage z.B. via SAS multipath.

Schon klar, dass übers Netz nie so schnell sein kann wie direct attached.

Aber es scheint nicht schlechter zu sein als iscsi, in vielen Bereichen sogar besser.

PROXMOX: ISCSI and NVMe/TCP SHARED STORAGE COMPARISON | Blockbridge Knowledgebase

This technote presents a performance comparison of iSCSI and NVMe/TCP shared storage in a Proxmox/QEMU virtual environment.

kb.blockbridge.com

Hier gibt's das passenden Reddit topic dazu. In den Kommentaren gibt's noch wertvolle Zusatzinformationen wieso NVMe over IP besser abschneidet als iscsi.

Reddit - Dive into anything

www.reddit.com

 

[gea]

Dann bleibt nur abzuwarten ob NVMe over ip sich besser verbreitet als Ata over ip, Das war bereits vor Jahren die schnellste Option eine Platte übers Netz anzubieten, setzte sich aber gegen iSCSI oder FC nicht durch.

 

[Luckysh0t]

Guten Abend,

hat hier noch jemand Probleme damit seine Solaris ggf auch OmniOS smb shares in Debian/Ubuntu LXC einzubinden ?
Ich weis nicht genau seit wann, aber ich vermute seit dem ich auf PVE 8 aka Debian 12 bin. Mit einem frischen debian 12 LXC funktioniert es auch nicht. Ist das nun ein Linux oder ein Solaris Problem.. mein Win10 kommt mit smb 3.1.1 ohen Probleme drauf, meine Linuxkisten musste ich immer auf 2.0 pinnen, alles andere hat nicht funktioniert. Aber nun geht auch das nicht

Grüße

Lucky

 

[chicken]

Dann bleibt nur abzuwarten ob NVMe over ip sich besser verbreitet als Ata over ip, Das war bereits vor Jahren die schnellste Option eine Platte übers Netz anzubieten, setzte sich aber gegen iSCSI oder FC nicht durch.

Laut einigen Herstellern soll ähnliche Leistung wie mit FC möglich sein.

Nativen Support in Illumos hab ich noch nicht ergooglen können, aber ESXi kann es seit v7.

 

[gea]

Ein aktueller Server der nur Storage macht ist eh meist nicht ausgelastet.
Per Virtualisierung kann man da viel mehr machen. Mit ausreichend RAM ist die Performance fast wie Barebone Storage.

Ein NAS das virtualisiert macht bei den vielen Sicherheitsupdates bei NAS und VMs viel zu oft Probleme.

Einen extrem minimalistischen Typ-1 Virtualisierer wie ESXi der eher eine Firmware mit Web-UI ist als ein OS unter allen VMs finde ich eh optimal. Werde es mal bei Gelegenheit probieren,

https://docs.vmware.com/de/VMware-vSphere/8.0/vsphere-storage/GUID-5F776E6E-62B1-445D-854C-BEA689DD4C92.html

 

[sch4kal]

@gea kann es sein, das die Seriennummer in napp-it abgeschnitten wird ? Da fehlen in diesem Fall die letzten beiden Zeichen/Ziffern.

 

[gea]

Napp-it bezieht seine Daten aus dem Befehl iostat -Ensr oder über Smart.
Einfach mal 'iostat -Ensr' aufrufen und mit Menü Disk > Smartinfo vergleichen.

Ich hatte es aber auch schon gesehen, dass Seriennummern nicht immer konsistent sind. Die Erkennung von Platten über die Seriennummer ist daher nicht so eindeutig wie die genormte WWN Nummer die auch vom Hersteller einer Platte vergeben wird.

 

[sch4kal]

Napp-it bezieht seine Daten aus dem Befehl iostat -Ensr oder über Smart.
Einfach mal 'iostat -Ensr' aufrufen und mit Menü Disk > Smartinfo vergleichen.

Ich hatte es aber auch schon gesehen, dass Seriennummern nicht immer konsistent sind. Die Erkennung von Platten über die Seriennummer ist daher nicht so eindeutig wie die genormte WWN Nummer die auch vom Hersteller einer Platte vergeben wird.

Hast Recht, da tauchen sie auch abgeschnitten auf.

Mit

# prtpicl -c block -v | grep inquiry-serial-no
  :inquiry-serial-no     xxx
  :inquiry-serial-no     xxx
  :inquiry-serial-no     xxx
  :inquiry-serial-no     S64FNJ0T613479
  :inquiry-serial-no     xxx
  :inquiry-serial-no     S64FNE0R701642
  :inquiry-serial-no     xxx
  :inquiry-serial-no     xxx
  :inquiry-serial-no     S64FNJ0T613470
  :inquiry-serial-no     S64FNS0T906795

sehe ich die vollständigen Seriennummern. WWN wollte er mir gar keine Anzeigen.

 

[gea]

Wer noch einen ZFS Pool mit Festplatten hat und sync write benötigt,
der braucht ein gutes Slog wie eine Intel Optane.

Die sind immer schwerer zu bekommen, hier gibts noch welche,

https://www.amazon.de/dp/B09MSB59SK/?smid=A3OJWAJQNSBARP&th=1

 

[pwnbert]

Hab gerade überlegt, wo ich fragen könnte...

Ein Kumpel mag etwas SSD Speicher in einen seiner Server stecken (irgend so ein refurbished "Müll" mit zu vielen zu langsamen Cores, dafür satt RAM), er meint er hat kein U.2 drauf und eigentlich nur massig SAS(SATA), mag den PCIe nicht unbedingt verwenden (weil frei halten für anderes Zeug).
Sollen wohl in erster Linie KI Models geladen werden von dort und so kram, im Detail weiss ichs auch nicht, also mehr lese als Schreiblast.
Also erstmal RAM maxxen für den Lesecache, schon klar soweit.

Drive-Config wären 3-4 SSDs im Z1 angedacht (mit je 8 TB).
SATA: Kingston DC600M 8tb scheint mir soweit brauchbar und vom P/L her sinnvoll.
U2: Kingston DC1500M 8tb ...

Ich weiss jetzt nicht welches Board das ist, müsste ich in Erfahrung bringen, ob die Lanes der PCIe Slots auf 4x4 geteilt werden können für eine schöne U2 Adapterkarte, wäre bestimmt die bessere Lösung... wenns geht.

Am Papier ist die U2 halt 5x so schnell wie die SATA... ist das in der Realität ähnlich zu bemerken?
Mir würde das etwas weh tun hier für ~2k SATA Drives zu kaufen, wenn ich billiger viel schnellere U2 bekomm. Aber wenn nur SATA frei ist? Hm.

 

[java4ever]

Hat hier jemand Praxiserfahrung mit Windows und ZFS?

Ich würde in der neuen Workstation gerne komplett alles (bis auf /root vom Main Linux - Root on ZFS ist immer noch n bisschen viel Bastelei) auf ZFS umstellen, muss aber im Dual Boot Betrieb arbeiten und brauche gemeinsame Datenplatten.

Gibt ja mittlerweile native Treiber für ZFS... Taugen die? Oder lieber mit WSL?