[Sammelthread] OpenZFSonWindows: HowTos, Performance, wasauchimmer...

Wenn man den 2.3.1 rc13 Treiber installiert, kann Windows den Pool importieren und im Dateiexplorer anzeigen. Das Slog wird auch benötigt, sonst muss man die Importoption -m (ohne Slog) verwenden.

Das war recht schmerzfrei und hat funktioniert. Bzw. bin gerade am kopieren.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich wage nun seit ca. 2 Wochen ZFSonWindows "produktiv" auf meinem Haupt-Server. Irgendjemand muss das ja mal auf Herz und Nieren im Alltag prüfen. :d

Server Stats:
AMD 5600X
MC12-LE0
64GB RAM
Dual 10GBit SFP+ NIC
1x 250GB NVME OS (PCIe3 x1)
2x 2TB NVME Storage (PCIe3 x4)
2x 10TB HDD Backup (nur temporär verbunden)
OS: WinServer 2022
ZFS version: 2.3.1rc14

ZFS Setup:
Haupt-Pool aus den 2x 2TB NVME im mirror.
Backup Pool aus den 2x 10TB HDD ebenfalls im mirror (HDDs werden nur bei Bedarf manuell physisch verbunden).

Haupt-Pool dient als Storage für SMB-Shares im Netzwerk und lokale Hyper-V VMs.
Backup-Pool ist wie der Name schon sagt das Backup vom Haupt-Pool.

Erkenntnisse bis hierher:

1.
Beim Syntax für das Erstellen eines Mirror-Pools muss man genau auf die Reihenfolge achten: :
zpool.exe create [OPTIONS] [POOLNAME] [TYP "mirror"] [DISKS]

Zum Beispiel:
Code:
zpool.exe create  -O casesensitivity=insensitive -O normalization=formD -O compression=lz4 -O atime=off -o ashift=12 tank mirror '\\?\PHYSICALDRIVE0' '\\?\PHYSICALDRIVE1'

2.
Performance (Pool ca. 80% voll, 2 VMs laufen darauf):
1767966340460.png



3. Was funzt (einfach so):
Dedup
Replication

4. Sharing-Besonderheiten
SMB-Freigaben überleben einen Reboot (nur) wenn Freigabe eines ganzen Datasets erfolgt, Freigabe eines Unterordnen in einem Dataset ist nach Reboot weg. Keine Ahnung warum.

NFS-Freigaben funktionieren nur, wenn dem Dataset auf dem die Freigabe erfolgen soll (entweder insgesamt oder in einem Unterordner) ein eigener Laufwerks-Buchstabe zugewiesen wird. Scheint aber ein Windows-Ding zu sein, hat wohl nichts mit ZFS zu tun (gleiches Phänomen, wenn man auf/in einer VHDX eine NFS-Freigabe.

5.
Napp-it fühlt sich irgendwie deutlich zäher an als auf meinem Solaris-Host. Ist allerding kein fairer Vergleich, weil die Solaris-Kiste deutlich potenter ist (mehr RAM, mehr Kerne) und dort auch nicht die cs-Version läuft.
Ein ~1.5TB Replikation-Job ist mir unter Napp-it wiederholt abgestürzt, manuell über die CMD lief der auf Anhieb durch.
Auch konnte ich meinen Pool unter napp-it nicht anlegen, im UI wurde mir zu einer Disk bei "can pool" "no" angezeigt. Über die CMD ging es hingegen.

6.
Wenn sich nach Pool-Erstellung die Windows-Zuordnung "PHYSICALDRIVE#" der Datenträger ändert (was sehr schnell mal passieren kann), also z.B. Datenträger1 nicht mehr PHYSICALDRIVE1 ist, sondern PHYSICALDRIVE2, bekommt ZFS bzw. zpool.exe das nicht mit und zeigt entsprechend falsche (oder nicht mehr existierende) Datenträger an.


Vorläufiges Zwischenfazit: Das Ganze hat noch Kinderkrankheiten, mit denen man aber umgehen kann / für mich keine Dealbreaker.
 
Ich wage nun seit ca. 2 Wochen ZFSonWindows "produktiv" auf meinem Haupt-Server. Irgendjemand muss das ja mal auf Herz und Nieren im Alltag prüfen.
danke!

:d

Erkenntnisse bis hierher:

1.
Beim Syntax für das Erstellen eines Mirror-Pools muss man genau auf die Reihenfolge achten: :
zpool.exe create [OPTIONS] [POOLNAME] [TYP "mirror"] [DISKS]

Zum Beispiel:
Code:
zpool.exe create  -O casesensitivity=insensitive -O normalization=formD -O compression=lz4 -O atime=off -o ashift=12 tank mirror '\\?\PHYSICALDRIVE0' '\\?\PHYSICALDRIVE1'

sollte identisch zu OpenZFS sein

2.
Performance (Pool ca. 80% voll, 2 VMs laufen darauf):
Anhang anzeigen 1174066

sieht ja gut aus

3. Was funzt (einfach so):
Dedup
Replication

Alle OpenZFS 2.3.1 Features sollten funktionieren.

4. Sharing-Besonderheiten
SMB-Freigaben überleben einen Reboot (nur) wenn Freigabe eines ganzen Datasets erfolgt, Freigabe eines Unterordnen in einem Dataset ist nach Reboot weg. Keine Ahnung warum.

Wird das Sharing über Windows konfiguriert?
Unabhängig davon, man sollte ausschließlich ZFS Dateisysteme freigeben und eher keine normalen Unterordner und niemals nested ZFS Dateisysteme weil da kann durch unterschiedliche ZFS Eigenschaften Chaos entstehen.

NFS-Freigaben funktionieren nur, wenn dem Dataset auf dem die Freigabe erfolgen soll (entweder insgesamt oder in einem Unterordner) ein eigener Laufwerks-Buchstabe zugewiesen wird. Scheint aber ein Windows-Ding zu sein, hat wohl nichts mit ZFS zu tun (gleiches Phänomen, wenn man auf/in einer VHDX eine NFS-Freigabe.

Kann man mit leben wenn man NFS braucht, ist ja auch mit ntfs so,
SMB ist wichtiger und leistungsfähiger (ACL, Performance)

5.
Napp-it fühlt sich irgendwie deutlich zäher an als auf meinem Solaris-Host. Ist allerding kein fairer Vergleich, weil die Solaris-Kiste deutlich potenter ist (mehr RAM, mehr Kerne) und dort auch nicht die cs-Version läuft.
Ein ~1.5TB Replikation-Job ist mir unter Napp-it wiederholt abgestürzt, manuell über die CMD lief der auf Anhieb durch.
Auch konnte ich meinen Pool unter napp-it nicht anlegen, im UI wurde mir zu einer Disk bei "can pool" "no" angezeigt. Über die CMD ging es hingegen.

Canpool ist die Meinung von Powershell und bezieht sich zunächst primär auf Storage Spaces. Napp-it möchte hier auch für ZFS canpool=yes haben
War der manauelle Transfer auch mit netcat over lan oder local?.

Ansonst ist napp-it cs unter Windows deutlich langsamer als unter Free-BSD, Linux oder OSX, sowohl via web-gui wie auch mit Powershell auf Console vs Shell cmd. Mit einer der Gründe warum ich Command Caching eingebaut habe um wiederholte Abfragen zu beschleunigen.

Wenn eine Replokation in napp-it gestartet ist, macht sie ein cmd (lokal) oder zwei (netcat) mit send/receive auf.


6.
Wenn sich nach Pool-Erstellung die Windows-Zuordnung "PHYSICALDRIVE#" der Datenträger ändert (was sehr schnell mal passieren kann), also z.B. Datenträger1 nicht mehr PHYSICALDRIVE1 ist, sondern PHYSICALDRIVE2, bekommt ZFS bzw. zpool.exe das nicht mit und zeigt entsprechend falsche (oder nicht mehr existierende) Datenträger an.

Ähnlich wie bei Linux mit sda, sdb werden die Platten beim Booten durchnummeriert. Ändert sich da was bei den Platten, kann sich die Nummerierung ändern. Das Windows Verhalten ist inzwischen deutlich besser geworden, wenn sich Platten ändern. Solaris/Illumos mit WWN Plattennamen ist da natürlich deutlich überlegen. Auch Linux mit by-id Plattennamen bietet einen akzeptables Verhalten. Windows kann hier noch was lernen. Hat aber nichts mit ZFS zu tun.

Zur Not muss man halt den Pool neu importieren wenn sich Platten geändert haben.

Vorläufiges Zwischenfazit: Das Ganze hat noch Kinderkrankheiten, mit denen man aber umgehen kann / für mich keine Dealbreaker.

Mein Eindruck ist, dass OpenZFS unter Windows schon richtig gut ist. Probleme macht das unterschiedliche mount/locking/volume Verhalten von Windows mit einem Unix Dateisystem. Sieht man daran dass manche Programme, vor allem Systemnahe oder Spiele noch Probleme mit ZFS haben können.

Wenn man OpenZFS Issues den Windows Issues gegenüberstellt, meint man schnell dass nacktes OpenZFS on Linux mehr beta ist als mit Windows Dateisystemtreiber zusätzlich.

Entwicklung geht aber rasend schnell mit einem neuen release alle ca 4 Wochen der entdeckte Probleme behebt. Da Windows so viel mehr Variationen als ein normales Linux/Unix System aufweisen kann, sind Tests (und Issue reports) so wichtig.
 
Wird das Sharing über Windows konfiguriert?
Unabhängig davon, man sollte ausschließlich ZFS Dateisysteme freigeben und eher keine normalen Unterordner und niemals nested ZFS Dateisysteme weil da kann durch unterschiedliche ZFS Eigenschaften Chaos entstehen.
Ja SMB-Shares werden wohl immer letztendlich über Windows konfiguriert. Die ZFS smb-share Option called auch nur die entsprechende Windows-Funktion (so Lundman in einem der Posts auf Github). Dementsprechend dürfte es grds. auch nicht die üblichen ZFS-Probleme mit Freigabe in Ordnern / nested Datasets geben, weil ja bei ZFSonWindows das keine entsprechenden ZFS-Eigenschaften sind.

Canpool ist die Meinung von Powershell und bezieht sich zunächst primär auf Storage Spaces. Napp-it möchte hier auch für ZFS canpool=yes haben
In einer früheren Version war es nach meiner Erinnerung auch so, dass es mit canpool=no auch über die Konsole nicht ging. Scheint sich geändert zu haben.


War der manauelle Transfer auch mit netcat over lan oder local?.
Rein local von lokalem Pool1 zu lokalem Pool2.
 
Ja SMB-Shares werden wohl immer letztendlich über Windows konfiguriert. Die ZFS smb-share Option called auch nur die entsprechende Windows-Funktion (so Lundman in einem der Posts auf Github). Dementsprechend dürfte es grds. auch nicht die üblichen ZFS-Probleme mit Freigabe in Ordnern / nested Datasets geben, weil ja bei ZFSonWindows das keine entsprechenden ZFS-Eigenschaften sind.

Im Gegensatz zu Solaris/Illumos wo ein Share eine strikte ZFS Eigenschaft ist, ist bei Linux (SAMBA) oder Windows ein Share ein beliebiger Ordner. Der SMB Server weiß nichts von ZFS und geht deshalb nicht davon aus, dass ein "Unterordner" (ZFS Dateisystem) plötzlich anderes casesensitiviy, locking oder ACL behaviour hat.

In einer früheren Version war es nach meiner Erinnerung auch so, dass es mit canpool=no auch über die Konsole nicht ging. Scheint sich geändert zu haben.

ZFS kann manchmal auch eine Platte nutzen mit canpool=no. Eine Platte mit canpool=yes geht immer.

Rein local von lokalem Pool1 zu lokalem Pool2.

Eine Replikation die in napp-it angestoßen wird macht da auch nur zfs send | zfs receive als Hintergrund Task. "Sollte" sich daher gleich verhalten.
 
Tat es aber in meinem Fall nicht. ;) Ich schau die Tage nach einem Reboot nochmal, ob der Job dann per napp-it durchgeht.

Reboot sollte egal sein. Die Replikation wird als Admin Hintergrundtask im Backend server.pl gestartet.
Kontrollieren kann man Remote Hintergrundprozesse indem man im napp-it cs cmd Feld rl (remotelog) eingibt.

1768047016655.png
 
Windows Server hat ja doch eine ganze Reihe von Vorteilen wie SMB Direkt (für nics > 10G), Active Directory mit weltweit eindeutigen ntfs ACL mit Gruppen in Gruppen, diverse Serverdienste, besseres Storage Spaces Management, Usability und einiges mehr.

Für Soho, Windows Server Essentials ist die bevorzugte Wahl für bis zu 25 user und 50 devices bei max 1 Server je Nutzer
RAM, CPU/Core Anzahl ist auch limitiert, bei 2019/2022/2025 unterschiedlich.

günstiges Angebot z.B.

https://www.trustpilot.com/review/digitlogs.com
https://digitlogs.com/product/windows-server-2019-essentials/

hat jemand Erfahrung mit digitlogs?
 
Monster-Performance unter Windows mit 25-100G nics..
 
@gea Wenn ich seh, dass diese Firma Win Server 2025 Datacenter für knapp 25 Euro anbietet (was normal ein paar Tausender kostet !), bekomme ich größte Zweifel...
 
Kommerziell ist das keine sichere Option, zumal auch keine Cals angeboten werden. Die machen es ja dann nochmal teuer. Bei einer alten günstigen 2019 Essentials Version inkl. 25 User für Privatnutzung kann man zumindest argumentieren, dass einem nicht nur der Key sondern eine Lizenz von einem Microsoft Partner aus London verkauft wurde und der zumindest funktionieren soll. Sollte der Key dennoch jemals gesperrt werden, sind auch keine hohen Summen damit verbunden.
 
Ich habe nun auch mal ein wenig angefangen mit ZFS on Windows zu basteln, einfach mal schauen, wie gut sich das als Storage für Hyper-V eignet und werfe mal meine Ergebisse und Fragen hier rein. Bisher nutze ich nur TrueNAS als NFS Storage für ESXi, was seit Jahren wunderbar läuft.

Zum Server:
Dell PowerEdge R440
Dual Xeon Silver 4110
512GB RAM
Dual 25GBit SFP+ NIC
4x Seagate Nytro 1351 960GB SATA SSDs
Windows Server 2022
zfswin-2.3.1rc14

Besonderheiten: Für den Test wurde die Backplane direkt ans Mainboard angeschlossen. Das Betriebssystem wird über iSCSI von einem der anderen Server gebootet

Aus den vier SSDs wurde ein Raidz1 Pool mit folgenden Parametern erstellt:
Code:
zpool create -O casesensitivity=insensitive -O compression=lz4 -O atime=off -o ashift=12 SSD-Pool raidz1 PHYSICALDRIVE0 PHYSICALDRIVE1 PHYSICALDRIVE2 PHYSICALDRIVE3

Sowie ein normales Dataset (Laufwerk D)
Code:
zfs create SSD-Pool/SSD-Dataset

Und zum Vergleich auch ein verschlüsseltes (Laufwerk E)
Code:
zfs create -o encryption=aes-256-gcm -o keyformat=passphrase SSD-Pool/SSD-Dataset-Encrypted

Auf dem normalen Dataset sieht die Performance und auch die Auslastung des Systems OK aus.
Gut, die Lesewerte sind übertrieben und vermutlich komplett aus dem RAM gelesen, da keine aktivität der Aktivitäts-LEDs zu beobachten war.

SSD-Pool.JPG


Anders siehts aus, wenn Verschlüsselung zum Einsatz kommt.
Schon bei der Vorbereitung geht die CPU auf nahezu Volllast.

SSD-E-Create.JPG


Nur um einen Bruchteil der Leistung zu liefern.
SSD-E-Finish.JPG


OK, das Blech ist jetzt nicht das flotteste, aber da ist selbst mein HDD-Pool auf nem TrueNAS mit vier Kernen eines E5-2680 v2 schneller.
Ist hier was bekannt oder wo kann optimiert werden?

Soweit ich das sehen konnte, tauchen Laufwerksauslastungen weder im Taskmanager noch im Ressourcenmonitor auf. Ist da noch was geplant oder ist die einzige Möglichkeit
Code:
zpool iostat -v
?

Kommt mir das nur so vor, oder wird hier mehrfach binär und dezimal umgerechnet? Das aus den 960GB unter Windows etwa 894GiB werden ist ja nichts untypisches. Auch das Windows diese als Gigabyte bezeichnet ist ja nichts neues.
Aber irgendwie komme ich bei einem vierfachen davon weder auf die 3.48T des Pools, die mir
Code:
zpool get all SSD-Pool
ausgeben noch bei einem dreifachen auf die 2.45T / 2512GiB des Datasets. Oder ist hier einfach der Overhead so groß?

ZFS liebt ja RAM für seinen ARC. Falls es sich ähnlich wie unter TrueNAS Scale verhält und bis zu 50% RAM in Beschlag nimmt, ist das für ein reines Storage zwar OK, aber vielleicht nicht so gut für einen Hyper-V Host. Wie kann ich die RAM Nutzung manuell anpassen?

Ich habe mir napp-it auch mal via xampp auf die Kiste gepackt (vorher noch nie benutzt), sehe für mein Szenario grade aber nicht den Mehrwert und habe es damit leider vor ein paar Tagen auch schon geschafft, den Server zu bluescreenen. Hab leider vergessen wie, war mitten in der Nacht :fresse:
 
Vorab
OpenZFS on Windows ist was ZFS angeht, praktisch ein normales (das gleiche wie unter Linux) OpenZFS. Der Dateisystemtreiber kümmert sich um die Kommunikation von Windows und Anwendungen mit ZFS. Dabei gehts darum dass Windows vieles anders macht als das Unix Dateisystem ZFS. Das sind in erster Linie Fragen um Partitionen, Volumes, Locking,Rechte oder mount/unmount das es so unter Windows gar nicht gibt. Das kostet etwas Performance zumal im Dateiystemtreiber noch Debug Code ist. Der ist auch nicht trivial, insbesondere da es in Windows sehr viel mehr Hard- und Software gibt als unter Linux/Unix. Man sieht ja bei den Issues dass es immer noch Programme gibt, die Probleme bereiten. Auch mount/unmount kann Probleme machen, aber meist genügt dann ein extra unmount/mount.

Ob es mit Verschlüssellung noch ein besonderes Performanceproblem gibt, kann ich nicht sagen. Wenn allerdings sync mit Verschlüssellung kombiniert wird, ist OpenZFS generell sehr langsam.

OpenZFS on Windows ist schon sehr stabil. Es kann aber immer noch vereinzelt Probleme mit BSOD geben. Dann ein Issue Report mit memory.dmp erstellen, gilt auch für Probleme mit einzelnen vor allem systemnahen Anwendungen. Jorgen Lundman ist sehr aktiv, diese Issues zu bearbeiten um wie unter OSX ein release edition zu haben.

ZFS settings sind in der Registry z.B.
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\OpenZFS\zfs_arc

Windows weiss nichts von ZFS
daher zpool iostat nehmen

ZFS zeigt immer T (TiB) statt TB
 
Zuletzt bearbeitet:
Bestimmte ZFS Settings kannst (musst) Du über die Registry setzen, u.a. auch, wie groß der ARK sein darf:

Allgemeiner Ort für die ZFS Einstellungen:
\HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\OpenZFS

Beispiel ARK auf 2GB begrenzen:
"zfs_arc_max" REG_QWORD "0x80000000"

Quelle
 
Beispiel ARK auf 2GB begrenzen:
"zfs_arc_max" REG_QWORD "0x80000000"
Hast du das selbst auch mal gemacht?

Sobald ich dort irgendeinen Wert setze, springt der sofort wieder auf den ursprünglichen Wert zurück, sobald ich F5 drücke. Das passiert auch bei anderen Parametern innerhalb des Schlüssels, auch direkt nach einem Reboot und ohne das ein Dataset gemountet ist.

Ob es mit Verschlüssellung noch ein besonderes Performanceproblem gibt, kann ich nicht sagen. Wenn allerdings sync mit Verschlüssellung kombiniert wird, ist OpenZFS generell sehr langsam.
Deswegen werf ich meine Ergebnisse einfach mal hier rein. Vielleicht testet es ja noch jemand und kann dieses Verhalten bestätigen.
Sync steht übrigens auf Standard und eine Änderung in disabled brachte keine Veränderung.

Es kann aber immer noch vereinzelt Probleme mit BSOD geben. Dann ein Issue Report mit memory.dmp erstellen, gilt auch für Probleme mit einzelnen vor allem systemnahen Anwendungen.
Was ja kein Problem ist, ist ja schließlich noch in Entwicklung. Leider hat der Server keinen Dump erstellt. Weiß grade nicht, ob es an der Art des Absturzes lag, oder an möglichen Besonderheiten aufgrund der Tatsache, dass die Systemplatte via iSCSI eingebunden ist.

ZFS zeigt immer T (TiB) statt TB
Das hab ich mir schon gedacht, war nur verwundert, da 3x 894GiB = 2682GiB oder auch 2,619141TiB sind. Also knapp 170GiB mehr als die Größe des Datasets.

Windows weiss nichts von ZFS
daher zpool iostat nehmen
Hätte jetzt erwartet, dass sich ZFS ähnlich tief ins System verankert, wie die Windows eigenen Dateisystemtreiber. Aber nun gut. Was nicht ist, kann ja noch werden
 
- Ich konnte problemlos arc_max setzen und die Einstellung bleibt erhalten (Win 11 25H2)
- Die tiefe Integration von ZFS in Windows ist nicht so einfach. Ganz im Gegenteil, ZFS arbeitet strukturell anders als eine Windows Partition = Dateisystem. Manches geht sogar nur indem ZFS lügt, es sei ntfs.

- Windows macht ein memory.dmp nur wenn man das aktiviert (Gemini)

1. Systemeinstellungen öffnen
Drücke die Windows-Taste + R, gib sysdm.cpl ein und bestätige mit Enter.

Gehe im Fenster "Systemeigenschaften" oben auf den Reiter Erweitert.

Klicke im Bereich "Starten und Wiederherstellen" auf die Schaltfläche Einstellungen....

2. Abbild-Optionen konfigurieren
Im neuen Fenster "Starten und Wiederherstellen" nimmst du folgende Einstellungen vor:

Ereignis in das Systemprotokoll eintragen: Aktiviere dieses Häkchen.

Debuginformationen speichern: Wähle aus dem Dropdown-Menü Kernelspeicherabbild (reicht meist für Analysen aus) oder Vollständiges Speicherabbild (benötigt viel Platz, enthält aber alles).

Sicherungsdatei: Hier sollte standardmäßig %SystemRoot%\MEMORY.DMP stehen (entspricht meist C:\Windows\MEMORY.DMP).

Vorhandene Datei überschreiben: Aktiviere dies, wenn du nur den jeweils letzten Absturz speichern möchtest.
 
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