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

@Bccc1: Hättest Du netterweise mal einen Link zu einem tauglichen Benchmark dafür?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Direct Storage = Direct io?
Nein, dieses Direct Storage. Kurz, eine neue API für Dateizugriffe die NVMe SSDs besser auslasten kann und dabei weniger CPU Last erzeugt, als die gute alte Win32 API.
Wenn ich das normal Benche, ist DirectStorage beir mir ~138% schneller als Win32. Wenn ich das im Hintergrund Benche, während ich ein Spiel zocke, also die CPU eine recht hohe Grundlast hat, komme ich auf ~620% Gewinn.

Prüfen ob das System die grundsätzlich unterstützt kann man in der Windows Game Bar (Win+G):
1740515907794.png



@besterino Klar. Ich kenne zwei, den BulkLoadDemo Benchmark, auf CB und hier die eigentliche Quelle.
Das vergleicht aber nicht mit klassischem Durchsatz, ist also nur begrenzt interessant.
Und dann gibts gegen Geld im 3D Mark den DirectStorage feature test. Nicht mit dem Storage Benchmark verwechseln! Das ist zwar Teil des Storage Benchmark DLC, aber ein seperater Test:
1740516308941.png


1740516267205.png
 
Massiver Cache-Effekt. 13,33 GB/s kann eine gen4 SSD gar nicht liefern. Oder irgendwelche komprimierten Daten, wo nicht die tatsächliche Rate am Bus gemessen wird, sondern die entpackten Daten pro Zeit.
Solche Werte müffeln schon wieder, wenn ein Benchmark die gegen unkomprimierte vergleicht.... weil dann werden schon wieder Äpfel mit Birnen verglichen.

Man kann natürlich argumentieren: "was kommt bei der Applikation an", true, aber dann misst man auch Dekomprimierungsrate und nicht nur SSD-Performance.
 
Zuletzt bearbeitet:
Ne, kein Cache Effekt, DirectStorage + GDeflate Kompression. Allerdings stimme ich zu, das die große Plakative Prozentzahl irreführend ist. Wie man ganz unten im Screenshot auch sehen kann sinds für "Storage to VRAM" 5,59GB/s ohne Direct Storage, 5,9GB/s mit Direct Storage ohne Kompression und 13,33GB/s mit Direct Storage und Kompression.
Unter hoher CPU Last werden daraus
11.50 GB/s · Bandwidth (DirectStorage on, GDeflate Compression)
5.78 GB/s · Bandwidth (DirectStorage on, Uncompressed)
1.58 GB/s · Bandwidth (DirectStorage off, Uncompressed)
 
Zuletzt bearbeitet:
Ok, habe mal angefangen, Games zu testen. Bisher funktionieren 50% der ausprobierten Games nicht... ok, das ist vielleicht nicht ganz fair, weil ich genau 2 Spiele ausprobiert habe. ;)

Konkret: Icarus (funktioniert) und Pax Dei (funktioniert nicht). Pax Dei ist allerdings auch erst Early Access und außerdem insgesamt noch recht buggy.

Es könnte auch an meiner Konfiguration liegen: habe einen Pool mit Laufwerksbuchstaben (F:) und darin ein Dataset, auf dem wiederum die Steam-Library sitzt, ohne eigenen Laufwerksbuchstaben. Evtl. klappt es, wenn man (nur?) dem Dataset einen Laufwerksbuchstaben zuweist.

Muss ich mir die Tage mal genauer anschauen.
 
Geschachtelte Dateisysteme würde ich nach Möglichkeit meiden weil die immer eigene Properties haben können, sogar inkompatible, Besser mit einfachen Dateiordnern arbeiten statt Dateisystemen.

Es kann aber ein Bug sein. In der aktuellen rc6g gibt es einen Issuereport mit Problemen bei großen Dateien.
 
:popcorn:
Am Ende hab ich mich so lange vor ZFS gedrückt, bis ich es auf Windows haben kann. :coolblue:
 
@gea: ich hab bisher nur ein Dateisystem. Direkt auf dem Pool will ich eigentlich keine Daten haben. Wie gesagt, vielleicht geht es, wenn man (auch) dem Dateisystem einen Laufwerksbuchstaben zuweist und es darüber anspricht und nicht "über den Laufwerksbuchstaben des Pools". Mounted man (nur) den Pool mit Laufwerksbuchstaben, erscheinen die Dateisysteme auch mit einem anderen Symbol als ein normaler Windows-Ordner.

Teste ich heute Abend mal.

Aktueller Eindruck:

Positiv 1:
Weiß nicht genau seit wann, aber inzwischen ist das ZFS-Dateisystem auch nach Reboot sofort wieder verfügbar (kein manuelles mounten/importen mehr nötig).

Positiv 2:
Weil ich leider zu blöd war, die Disks für den Pool über die Kommandozeile anzusprechen, habe ich spontan Napp-it CS ausprobiert. Das funktionierte auf Anhieb, auch wenn ich mich kurz über die ca. 5+ sich öffnenden Fenster erschrocken hatte. :d Habe noch nicht viel ausprobiert, aber Pool erstellen ging, Dataset erstellen ging, Kompression ausschalten ging, Möglichkeit für Setzen von Laufwerksbuchstaben vorhanden... gefällt soweit!

Zu untersuchen 1:
Potenzielle Inkompatibilität zu bisher einer Anwendung (s.o.).

Zu untersuchen 2:
Performance.
 
Napp-it cs startet 4 Fenster (minimiert, Fenster kann man aber zur Kontrolle öffnen)
- Apache Webserver als Frontend, web-gui geht nicht ohne Webserver. Unter Linux kann das auch mini_httpd sein.

Backend Dienste. Benötigt, wenn der Server Teil einer Servergruppe ist und lokal/remote gemanagt werden soll
- server.pl als Backend, diesen Dienst kann man auch remote in einer Servergruppe ansprechen
- monitor.pl als Monitoring Dienst, auch zum Refreshen von cashbaren Daten

Jobverarbeitung (nur auf dem OpenZFS Server der Frontend/web-gui Dienste anbietet)
- auto.pl für geplante jobs

Teil von OpenZFS ist jetzt der Monitordienst zed.exe der den zuletzt geöffneten Pool importiert.
Beim Start von napp-it werden zudem alle .vhdx virtual harddisks gemounted die in c:\vhdx oder v:\vhdx liegen und auto im Namen haben (für Testpools oder Network Cluster/Raid on LAN mit v:\vhdx als SMB Share)

In der aktuellen rc6g sind einige Bugs entdeckt worden. Da Jorgen Lundman seit 5 Tagen keine neue Zwischenversionversion oder die rc7 gebracht hat, scheint deren Behebung mehr Arbeit zu verursachen. Entwicklung geht aber zügig. Immerhin ist es erst knapp 2 Jahre Jahr her seit OpenZFS on Windows eher ein proof of concept war und erst ein knappes Jahr seit der komplett überarbeiteten 2.2. mit der man erstmals ernsthafte Tests machen konnte.

Daten direkt auf dem Pool z.B. tank ist eine schlechte Idee, immer ein ZFS Sub-Dateisytem z.B. tank/data für die Daten nehmen. Lediglch weitere Schachelungen wie tank/data/video sollte man vermeiden. Einen Laufwerksbuchstaben kann man auf den Pool (ZFS Sub Dateisysteme erscheinen dann als Ordner darunter, ist der Normalfall) oder auf einzelne ZFS Dateisysteme (der Laufwerksbuchstabe zeigt dann auf dieses Dateisystem) setzen.
 
Zuletzt bearbeitet:
Update: das Spiel, das zunächst nicht wollte, läuft tatsächlich auch auf ZFS, wenn man dem Dataset einen eigenen Laufwerksbuchstaben gibt! :banana:

Zur Klarstellung: ich habe nichts am Setup/Pool-Dataset-Layout geändert, sondern lediglich dem Pool den Laufwerksbuchstaben "weggenommen" und dem Dataset einen eigenen zugewiesen.

Für mich also vorläufige ZFSonWindows Best Practice:

1. Minimiere Datasets (insb. wie @gea schon schrieb, nested datasets vermeiden - galt aber ja gewissermaßen auch so schon unter Solaris)
2. Gib' jedem Dataset einen (eigenen) Laufwerksbuchstaben
 
Läßt darauf schließen, dass das Spiel einen Pfad wie y:\spiel fest kodiert hat und p:\dataset\spiel nicht mag.
 
Hmmm...

1. Nächstes Spiel was Ärger macht: Age of Empires IV startet schlicht nicht. Gegentest mit Installation auf einer Installation auf einem NTFS-Filesystem unproblematisch.

2. Wenn ich gleichzeitig ein Spiel update und ein anderes (Pax Dei) starte, gibt's einen Bluescreen mit "Unexepected Kernel Mode Trap". Gegentest mit Installation auf einem NTFS-Filesystem wieder ohne Probleme.
 
Einiges an Arbeit für Jorgen Lundman.

ps
Es ist hilfreich ein memory.dmp zur Verfügung zu stellen.
 
Das fiese ist, dass bisweilen ja noch Anti-Cheat Programme mitlaufen, von denen kein Mensch genau weiß, was sie eigentlich machen bzw. „erwarten“. Mal schauen, was mich da noch erwartet.
 
Erst müssen ein paar fiese Treiber Bugs unter Windows gefixt werden.
Ist aber gut dass immer mehr OpenZFS unter Windows testen und Fehler melden. Nur dadurch wird das final und man kann vorab im Issuereport sehen wo es noch hakt.
 
Puh, das macht so gerade wenig Freude. Wenn man in die minidumps reinschaut, liegt da wohl doch noch was im Argen:

Code:
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
BugCheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: ffffe28032dfde70
Arg3: fffff40df9111000
Arg4: fffff806e3ebe164

Debugging Details:
------------------


// SCHNIPP SCHNAPP GERKÜRZT



DUMP_FILE_ATTRIBUTES: 0x1808
  Kernel Generated Triage Dump

FAULTING_THREAD:  ffffc00d430af340

STACK_OVERFLOW: Stack Limit: fffff40df9111000. Use (kF) and (!stackusage) to investigate stack usage.

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

STACK_TEXT: 
fffff40d`f9111000 fffff806`e3eba979     : 00000000`00050005 00000000`00033411 fffff40d`f91113a0 fffff806`e3e1223c : nt!output_l+0x6c
fffff40d`f91112c0 fffff806`78aafba8     : 00000000`00000000 00000000`00007300 fffff806`78ab2a40 ffffc00d`430af340 : nt!snprintf+0x69
fffff40d`f9111350 00000000`00000000     : 00000000`00007300 fffff806`78ab2a40 ffffc00d`430af340 ffffc00d`5f200000 : OpenZFS+0x52fba8


SYMBOL_NAME:  OpenZFS+52fba8

MODULE_NAME: OpenZFS

IMAGE_NAME:  OpenZFS.sys

STACK_COMMAND:  .process /r /p 0xffffc00d1b572040; .thread 0xffffc00d430af340 ; kb

BUCKET_ID_FUNC_OFFSET:  52fba8

FAILURE_BUCKET_ID:  0x7f_8_OpenZFS!unknown_function

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {4fdb4ed0-b6d3-cb72-31fe-819f29cba343}

Followup:     MachineOwner
---------
 
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