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.
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):
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.