[Sammelthread] OpenZFSonWindows: HowTos, Performance, wasauchimmer...
- Ersteller besterino
- Erstellt am
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):
@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:
Trambahner
Urgestein
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.
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)
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:
besterino
Legende
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.
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.
Es kann aber ein Bug sein. In der aktuellen rc6g gibt es einen Issuereport mit Problemen bei großen Dateien.
besterino
Legende
@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.
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.
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.
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.
- 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:
besterino
Legende
Update: das Spiel, das zunächst nicht wollte, läuft tatsächlich auch auf ZFS, wenn man dem Dataset einen eigenen Laufwerksbuchstaben gibt! 
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
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