• Hallo Gast!
    Noch bis zum 10.05. kannst Du an unserer Hardwareluxx Hardware-Umfrage 2026 teilnehmen! Als Gewinn verlosen wir unter allen Teilnehmern dieses Mal ein Notebook für bis zu 1.800 EUR - über eine Teilnahme würden wir uns sehr freuen!

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

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Aus noch nicht wirklich von mir nachvollziehbaren Gründen haben mir heute mehre VMs Probleme gemacht, deren VHDX auf ZFSonWin liegen. Bei Problemen mit einer VM denke ich an die VM, bei gleich zweien hakt was "Größeres", vor allem wenn bei beiden Fehler auftauchen, die mit dem Filesystem/Storage in Verbindung stehen (beide mit korrupten Dateisystemen - der Server selbst lief aber die ganze Zeit sauber durch). Ob noch weitere VMs betroffen sind, weiss ich noch nicht.

Nach einem Reboot des Servers waren die ZFS Pools / Datasets zwar im Explorer sichtbar, aber es konnte nicht darauf zugegriffen werden. Nach einem Pool Export/Import ging es wieder, aber eine Windows-VM hängt seitdem in einer "Autorepair" Schleife. Letztes Backup gerade von dieser VM ist natürlich auch schon lange her, also muss ich mal schauen, ob ich die manuell gefixed bekomme.

Ich bin noch auf 2.3.1rc14 unterwegs, zfs version
zfswin-2.3.1rc14
zfs-kmod-zfswin-2.3.1rc14

Ich lass das hier nur mal als abstrakte Warnung da, kann halt evtl. auch was ganz anderes sein.
 
Könnte eventuell daran liegen (Problem mit Win10 vermutlich auch Server 2022 mit MultiCore Systemen)
Fix thread priority BSOD on large multicore systems in KiAddThreadToPrcbQueue, behoben in 2.4.1

Vor Update wird ein uninstall empfohlen

zfs-windows-2.4.1rc9 Latest

** rc9
  • Fix uninstall process. Recommended to remove previous version, reboot, before install rc9
  • Remove UAC requirement
  • Attempt elevation on some commands
  • Add "zfs allow" feature
** rc8
  • Fix thread priority BSOD on large multicore systems in KiAddThreadToPrcbQueue()
  • Correct potential arm64 disk IO race in completion.
  • Speedup dirlisting, avoid memory fragmentation
  • OpenZVOL driver unload fix
  • Fix double free of MDL in write path (CrystalDiskMark)
c3ac00aebfe121b78a7806f608a58e76 *OpenZFSOnWindows-debug-2.4.1rc8.exe

wenn Problem bleibt: Issue erstellen damit das Problem bekannt wird
 
Nervt mich.

Eigentlich trauere ich immer noch beim Storage Solaris 11.4 hinterher und will auch von Hyper-V als Hypervisor weg. Bin eh noch auf Server 2022 und der ist ja nun auch nicht mehr so richtig taufrisch.

Aber ESXi mag ich wegen Lizenzkäse in der Vergangenheit nicht mehr und mit Proxmox bin ich bisher auch noch nicht so richtig warm geworden. Werde aber wohl Proxmox nochmal eine Chance geben…
 
So stabil wie natives Solaris ZFS oder Illumos (kompatibel zu OpenZFS) ist aktuelles OpenZFS beileibe nicht, siehe

Soviele offene Probleme hatte Solaris oder Illumos ZFS in 10 Jahren nicht. Dem steht halt entgegen, dass OpenZFS sehr interessante neue Features bringt. Die schnelle Integration dieser Features ist sicher eines der Probleme und der Grund warum OmniOS so stabil ist - ohne allerneueste Features.

Bei Windows kommt dazu, dass es soviele Varianten gibt, im OS, in der Hardware und in der Kombination mit anderen Programmen und Treibern. Diese Vielfalt an Distributionen und Systemen ist auch eines der Probleme von OpenZFS.
 
Ich brauch halt keine besonderen Features, mir reicht Poolerweiterung zur Not mit neuen Platten / vdevs, bisserl Replikation, Komprimierung, ab und an mal Dedup, Verschlüsselung und simpelste SMB/NFS Freigaben. Das gibts alles schon quasi von Anfang an.

Ich will eigentlich nur „läuft“ 24/7 über Jahre hinweg, ohne mich drum kümmern zu müssen. ;)

Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…
 
Tut einfach, jahrelang. Dafür ist Solaris und Illumos unerreicht.

Dedup2 bei Solaris ist auch ok, bei OmniOS hat man halt nur klassisches Dedup, kein moderneres OpenZFS Fast Dedup. Raid-Z Expansion gibts auch nur bei neuestem OpenZFS, genau wie Hybrid Pools mit special vdev auch für slog, dedup und zvol.
 
Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…

Windows hat einen Patchday pro Monat (bis auf unerwartetes), bedeutet 12x Neustart pro Jahr.
Windows Server 2025 führt "Hot Patching" ein, soll Neustart auf 4x pro Jahr reduzieren.

Man kann Updates auch verzögern oder aussetzen wenn Windows nur Server ist und kein Desktop mit viel Internet Nutzung.

ps
Wenn man bei Linux auch alle Patches einspielt, sieht das ähnlich aus. Ist ja nicht so, dass es für Linux/Unix keine Security/Bugfixes gibt mit Reboot.
 
Ich will eigentlich nur „läuft“ 24/7 über Jahre hinweg, ohne mich drum kümmern zu müssen. ;)

Hyper-V musste ja schon gefühlt mindestens einmal pro Woche wg. Updates rebooten…
Naja, also mein W2k12 hat ne Uptime, die ich gar nicht kenne.
Warum? Naja, der läuft einfach. Reboots gibt es durch Spannungsausfall beim EVU und das ist sehr selten.
Patchen? Hä?
Also gehen tut das schon. :fresse:

Ansonsten, wenn du 24/7 brauchst, nimm DOS 6.22, das kennt kein Schwein (mehr) und die, die es noch kennen, gehen alle langsam in Rente.
Sonst musst du, wenn man es "richtig" machen will, jedes OS patchen. Linux ist schon seit 20 Jahren kein "läuft immer" System.
Läuft immer ist Mainframe, aber das willst du nicht haben.

Die Software, angefangen beim OS, ist viel zu komplex geworden, als dass die "fertig" ist.
Gab erst letztens wieder irgendso nen Supergau in ner Bibliothek und deswegen die gesamte IT der Welt gepatcht werden muss.
Das gilt btw. auch für Switche. Dein geliebtes Webinterface ist das Hauptgrund, warum man Switche patchen muss.
Das sind aber auch nur noch PCs mit nem angeschlossenen SwitchASIC.
 
Zuletzt bearbeitet:
Immer müsst Ihr mir meine Illusionen kaputt machen! ;)
 
Neuer release candidate 10 for OpenZFS on Windows 2.4.1


** rc10
  • Add FileCompressionInformation to enable query of on-disk compressed size
  • Do some performance fixes to make things faster
  • Hardlink deletion would hide all other hardlinks
  • Fix deadlock in write path
  • Prioritise HarddiskXPartitionY paths over hack path
  • Add import --fix-gpt to correct NumPartitions=9 to NumPartitions=128.
  • Fix up condvar and mutex
  • Use User credentials, enabling zfs allow to work. Mix Unix and Windows permissions and hope for the best
  • OpenZVOL unload bug fixes
  • Fix spl_panic() call print and stack
So with Unix created GPT partitions, they use gpt.NumPartitions=9, this Windows does not accept, and Windows
computes gpt.checksum "as if" gpt.Numpartitions==128. So checksum mismatches, and partition table is ignored.
This is why OpenZFS uses path encoding of #partition_offset#partition_length#/path/to/device, saved into vdev->vdev_physpath.
This continues to work.
We added a new zpool import --fix-gpt which will rewrite gpt.NumPartitions=128, and recompute gpt.checksum. Since libefi already reads in the full GPT partition, we need not change anything else, and write it back out. This is left as a user option, as there could be partition usage I am unaware of. Who know if some legacy archs can only use fewer partitions? Or store microcode in the backhalf.
If GPT is written with gpt.NumPartitions=128, Windows will recognise the partitions, and create //?/HarddiskXPartitionY device objects, so we can import those directly, no need for special path. Success. We prioritise //?/HarddiskXPartitionY over #partition_offset#partition_length#/path/to/device - but it will try both.
Let's check for regression in this release.

Evaluate and report issues
 
Pools sollen ja zwischen Free-BSD, Illumos, Linux/Unix, OSX und Windows verschiebbar sein.
Das hat zur Folge dass sich der Windows OpenZFS Treiber um unterschiedliches Verhalten bei Permissions, Partitionen, Mounts, Locking, Links etc kümmern muss. Alles in ZFS kommt halt ursprünglich aus der Unix/Solaris Welt.

Da es zudem bei Windows viel mehr Variationen in der Hardware, Software und Treiberumgebung als bei Unix gibt, dauert es mit dem Release State unter Windows ja so lange, da immer noch etwas berichtet wird was noch gefixt werden sollte, jedesmal mit der Gefahr dass etwas was schon funktionierte erneut Probleme bereitet. Software lebt halt. OpenZFS selber entwickelt sich auch schnell weiter, 2.4 kann deutlich mehr als 2.3 oder 2.2 und wenn man sich da den Issue Tracker anschaut, ist das auch nicht ohne, sicher der Grund warum Illumos oder Solaris ZFS ohne diese sehr schnellen Weiterentwicklungen so viel stabiler ist.

Das Dateisystem OpenZFS selber unter Windows ist aber schon sehr gut, wegen dem Debug Code noch etwas langsamer, aber da sollte der aktuelle Build bereits etwas besser geworden sein. BlueScreens bei Inkompatibilitäten wie bei frühen Versionen von OpenZFS unter Windows sind sehr selten geworden, sind wegen Copy on Write auch eher unkritisch.
 
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