[Sammelthread] ZFS Stammtisch

[Icenice]

Ich hätte da auch mal ein paar Fragen an die ZFS Profis hier, nachdem ich es nun endlich geschafft habe, einen TrueNAS Scale Server (zum Testen) aufzusetzen.
Bei Verzeichnissen - bzw. ist es das eine Dataset - mit sehr vielen Dateien, dauert die Anzeige des Inhalts im Windows Explorer doch recht lange.
War man einmal in einem Verzeichnis drin, geht es danach schneller. Alles nur bis zum nächsten Reboot, dann wieder warten...
Jetzt habe ich von zwei Sachen gelesen, die genau sowas enorm beschleunigen sollen:

1. special vdev für metadata. Was das macht ist mir inzwischen einigermaßen klar, aber auch, dass bei einem Totallausfall dieses vdevs der ganze Pool verloren ist.
2. L2ARC for metadata only. So wie ich das verstehe, werden die Metadaten darauf gecached um beim Lesen sofort zur Verfügung zu stehen. Also , dass das read only ist, ist mir auch klar.

Wären für Option 1 2xOptanes als Mirror einigermaßen "sicher", oder sollte man sich die lieber sparen und keinen zusätzlichen "point of failure" einbauen? Und wären z.B. Samsung SM883 auch dafür geeignet?
Es ist mir auch klar, dass man die nicht mehr aus dem Pool entfernen kann, wenn man sich irgendwann doch umentscheiden möchte. Also Daten umkopieren, Pool neu erstellen und alles wieder zurückspielen.

Bei Option 2 scheinen keine weiteren Gefahren zu lauern (außer dass es nicht funktionieren würde), da bei einem Defekt der Pool weiterhin funktioniert. L2ARC ist doch inzwischen persistent, oder?
Würde hier ein 2x Mirorr außer erhöhte Ausfallsicherheit was bringen? Braucht es hierfür besondere SSDs? Hätte ein paar Samsung SM/PM883 zur Verfügung. Optanes wären wohl Perlen vor die Säue.

P.S. Meinen jetzigen Server werde ich höchstens testweise um einen L2ARC erweitern. Da kann ich unmöglich einen Datenverlust riskieren Da habe ich ewig lange alten Platten umkopiert und etwas sortiert 🤦‍♂️
Weitere Experimente werde ich dann an einem Neuaufbau vornehmen. Da sollen 8x16TB Exos X16 als RaidZ2 betrieben werden und dann eben irgendwas, was das auflisten der Files beschleunigt.
Ferner wird das hier empfohlene Gigabyte MC12-LE0 mit einem Ryzen 5600 und (wenn nötig) 64GB RAM verwendet werden. Controller wird ein LSI3008 und dazu eine Connect-X3.

Dazu werfe ich noch ein Offtopic Frage ein, die nicht direkt mit ZFS zu tun hat und ich nicht so recht weiß, wohin damit.
Sagen wir mal ich habe zwei TrueNAS Server habe, die beide über Netzwerk mit meinem Hauptrechner verbunden sind: Gibt es eine Möglichkeit, Daten zwischen den beiden Geräte direkt mittels einer GUI hin und her zu kopieren? Ich kann natürlich beide als Laufwerke im Windows Explorer einbinden, aber dann laufen ja alle daten über einen dritten Rechner. Mir prinzipiell egal, aber gäbe das nicht Performanceeinbrüche?

 

[mrpasc]

Gibt es bezahlbare SSDs (1-2TB reichen), die trotzdem gute Schreibwerte mit aktiven copy on write liefern?

Wenn du mit „SSD“ klassische 2,5“ SATA SSDs meinst: Wunder kann man da leider von keinem Modell erwarten. Die beste Dauerleistung meiner Erfahrung nach bieten da Samsung SM883, Micron 5300 MAX, Micron 5400 MAX, Seagate Nytro 1551. Neu mittlerweile gnadenlos überteuert (da SATA im Enterprise mittlerweile Nische ist), aber gebraucht manchmal noch günstig zu finden.

Theoretisch könnte ich auch M2 in dem leeren Slot verbauen und das SLOG drauf legen.

Auf Amazon gibt es die Optane P1600X 58GB einigermaßen günstig (kommt von Amazon US, daher paar Tage Lieferzeit), die ist die einzige Optane im M.2 2280 Format und könnte einen Versuch Wert sein.

https://amzn.eu/d/bY1gwdx

 

[define]

Wo von ist die Größe des Laufwerks für den SLOG oder L2ARC abhängig? Von der Poolgröße oder der häufig verwendeten Dateigeröße?

Bei Amazon gibts ja die INTEL Optane HBRPEKNX0101A01 (256GB) für fast die Hälfte dan €.

 

[Icenice]

Bei Amazon gibts ja die INTEL Optane HBRPEKNX0101A01 (256GB) für fast die Hälfte dan €.

Vorsicht. Das ist eine kombinierte SSD + 16GB Optane Speicher. Nicht, was man sonst unter Optane versteht.

 

[gea]

Wo von ist die Größe des Laufwerks für den SLOG oder L2ARC abhängig? Von der Poolgröße oder der häufig verwendeten Dateigeröße?

Bei Amazon gibts ja die INTEL Optane HBRPEKNX0101A01 (256GB) für fast die Hälfte dan €.

Slog protokolliert bestätigte Schreibvorgänge. Da werden nicht mehr als 10GB benötigt/genutzt.
Slog darf ausfallen. Kein Datenverlust außer Inhalt des Schreibcaches wenn Rechner abstürzt und dabei das Slog kaputt geht. In den Lesecache gehen keine Dateien und auch nicht nur Metadaten sondern read last/most gelesene ZFS Datenblöcke.

L2Arc erweitert den RAM Lesecache. Ist langsamer als RAM und benötigt etwas RAM zum verwalten, ist dafür persistent. L2Arc darf ausfallen (kein Datenverlust). L2Arc sollte als Daumenregel nicht größer sein als 10x RAM

 

[Mac_leod]

Wenn du mit „SSD“ klassische 2,5“ SATA SSDs meinst: Wunder kann man da leider von keinem Modell erwarten. Die beste Dauerleistung meiner Erfahrung nach bieten da Samsung SM883, Micron 5300 MAX, Micron 5400 MAX, Seagate Nytro 1551. Neu mittlerweile gnadenlos überteuert (da SATA im Enterprise mittlerweile Nische ist), aber gebraucht manchmal noch günstig zu finden.


Auf Amazon gibt es die Optane P1600X 58GB einigermaßen günstig (kommt von Amazon US, daher paar Tage Lieferzeit), die ist die einzige Optane im M.2 2280 Format und könnte einen Versuch Wert sein.

https://amzn.eu/d/bY1gwdx

Hab Lust drauf, danke für den Tipp.

Gerade eben hab ich eine Toshiba XG6 KXG60ZNV256G eingebaut.
Nun gilt es herauszufinden, wie ich den Datastore als "SLOG + L2Arc Grab" verwenden kann.

Die beiden neuen Seagate IronWolf Pro 16TB stecken nun auch an Controller.
Zusätzlich noch den vorhandenen 2700X gegen eine 5700G getauscht und 32GB RAM nachgesteckt.
Die GPU ist somit raus und ein PCIe 2.0x4 frei, für weitere Späße.
Mehr wird aber heut nicht mehr.

 

[Zeitmangel]

Hmm...

Intel Optane as SLOG for SSD ZFS Pool

Hi friends, I'm new in the community and with TrueNas too. At the moment I want to build a storage server and I had been reading some blog posts of other friends telling their experience and so on, but I would like to clarify something that may be very simple. I have in mind to create a ZFS...

www.truenas.com

 

[hs_warez]

Ich hätte da auch mal ein paar Fragen an die ZFS Profis hier, nachdem ich es nun endlich geschafft habe, einen TrueNAS Scale Server (zum Testen) aufzusetzen.
Bei Verzeichnissen - bzw. ist es das eine Dataset - mit sehr vielen Dateien, dauert die Anzeige des Inhalts im Windows Explorer doch recht lange.
War man einmal in einem Verzeichnis drin, geht es danach schneller. Alles nur bis zum nächsten Reboot, dann wieder warten...
Jetzt habe ich von zwei Sachen gelesen, die genau sowas enorm beschleunigen sollen:

1. special vdev für metadata. Was das macht ist mir inzwischen einigermaßen klar, aber auch, dass bei einem Totallausfall dieses vdevs der ganze Pool verloren ist.
2. L2ARC for metadata only. So wie ich das verstehe, werden die Metadaten darauf gecached um beim Lesen sofort zur Verfügung zu stehen. Also , dass das read only ist, ist mir auch klar.

Wären für Option 1 2xOptanes als Mirror einigermaßen "sicher", oder sollte man sich die lieber sparen und keinen zusätzlichen "point of failure" einbauen? Und wären z.B. Samsung SM883 auch dafür geeignet?
Es ist mir auch klar, dass man die nicht mehr aus dem Pool entfernen kann, wenn man sich irgendwann doch umentscheiden möchte. Also Daten umkopieren, Pool neu erstellen und alles wieder zurückspielen.

Bei Option 2 scheinen keine weiteren Gefahren zu lauern (außer dass es nicht funktionieren würde), da bei einem Defekt der Pool weiterhin funktioniert. L2ARC ist doch inzwischen persistent, oder?
Würde hier ein 2x Mirorr außer erhöhte Ausfallsicherheit was bringen? Braucht es hierfür besondere SSDs? Hätte ein paar Samsung SM/PM883 zur Verfügung. Optanes wären wohl Perlen vor die Säue.

P.S. Meinen jetzigen Server werde ich höchstens testweise um einen L2ARC erweitern. Da kann ich unmöglich einen Datenverlust riskieren Da habe ich ewig lange alten Platten umkopiert und etwas sortiert 🤦‍♂️
Weitere Experimente werde ich dann an einem Neuaufbau vornehmen. Da sollen 8x16TB Exos X16 als RaidZ2 betrieben werden und dann eben irgendwas, was das auflisten der Files beschleunigt.
Ferner wird das hier empfohlene Gigabyte MC12-LE0 mit einem Ryzen 5600 und (wenn nötig) 64GB RAM verwendet werden. Controller wird ein LSI3008 und dazu eine Connect-X3.

Dazu werfe ich noch ein Offtopic Frage ein, die nicht direkt mit ZFS zu tun hat und ich nicht so recht weiß, wohin damit.
Sagen wir mal ich habe zwei TrueNAS Server habe, die beide über Netzwerk mit meinem Hauptrechner verbunden sind: Gibt es eine Möglichkeit, Daten zwischen den beiden Geräte direkt mittels einer GUI hin und her zu kopieren? Ich kann natürlich beide als Laufwerke im Windows Explorer einbinden, aber dann laufen ja alle daten über einen dritten Rechner. Mir prinzipiell egal, aber gäbe das nicht Performanceeinbrüche?

Geht es bei "vielen Dateien" ev. um Fotos?
Das war bei mir auch etwas zäh, bis die ganzen Miniaturansichten geladen wurden.

Damals hatte ich die Fotos auf Seagate IronWolfs - habe dann für die Fotos einen Pool mit gebrauchten/neuwertigen Intel DC-SSD's gemacht => Problem beseitigt.


LG

 

[Mac_leod]

naja, durch den Change hast du ja auch die Performance gefühlt verzehnfacht

 

[Icenice]

Geht es bei "vielen Dateien" ev. um Fotos?
Das war bei mir auch etwas zäh, bis die ganzen Miniaturansichten geladen wurden.

Nein, gemischte Dateien. Aber es dauert ja überhaupt lange, bis die Verzeichnisstruktur gelistet wird. Also nur ein Ordner mit zig anderen Unterordnern usw.
Das ganze Dataset reagiert so träge, wird aber schlagartig besser, sobald man ein paar mal in Ordner raus und wieder rein geht.
Daher auch der Gedanke mit L2ARC und metadata caching. Ich hatte gehofft ein paar Antworten/Erfahrungen zu dem Thema zu bekommen oder special vdev für Metadaten (scheint aber keiner zu benutzen)
Das SSDs um Längen schneller als Platten reagieren, ist mir klar, nur ist das bei bestimmten Datenmengen kein Thema (Die Diskussion will ich aber hier nicht führen)

 

[hs_warez]

Hm, bei "normalen" Dateien hatte ich das Problem nicht.

 

[gea]

Wenn der Zugriff beim wiederholten lesen deutlich schneller ist, kann ein persistentes L2Arc schon was bringen. Mehr RAM hilft ja auch nur für erneute Zugriffe. Sehr viel bringen könnte auch ein special vdev 2/3 way Mirror mit small blocksize 16-64K und recsize größer/gleich 128K.

Damit landen alle Dateien kleiner SBB und Metadaten auf dem schnellen special vdev, größere auf dem langsamen Pool.

 

[Icenice]

@gea
Danke für deine Erläuterung

kann ein persistentes L2Arc schon was bringen.

Sowas hatte ich schon irgendwo aufgeschnappt. Nur war das früher wohl auch nicht persistent. Weißt du ob da dann automatisch Metadaten gecached werden und es auch nach einem Reboot bleiben, oder sollte man doch diese option für metadata only nutzen? Reicht für ein L2ARC eine PM883 480GB? Oder doch lieber SM883 480GB? Nach meinem Verständnis wird ja bei metadata only nicht permanent auf dem L2ARC geschrieben.

Sehr viel bringen könnte auch ein special vdev 2/3 way Mirror mit small blocksize 16-64K und recsize größer/gleich 128K.

Das ist wohl die Königsklasse, weil auch Schreiboperationen beschleunigt werden. Aber wenn svdev weg, dann Pool weg Ja, Backup und so..
Auch hier wäre meine Frage, ob zumindest die SM883 480GB dafür ausreichend wären, da hier die Schreiblast wohl wesentlich höher liegt.
Ansonsten hätte ich noch zwei Optane 905P 380GB, die ich sehr ungern nur dafür hernehmen möchte. Da gibts bestimmt einen sinnvolleren Verwendungszweck dafür (VM?)
Interessant wären ansonsten auch die hier https://amzn.eu/d/040TzZE

Sorry für die vielen fragen 🙈

 

[gea]

@gea
Danke für deine Erläuterung

Sowas hatte ich schon irgendwo aufgeschnappt. Nur war das früher wohl auch nicht persistent. Weißt du ob da dann automatisch Metadaten gecached werden und es auch nach einem Reboot bleiben, oder sollte man doch diese option für metadata only nutzen? Reicht für ein L2ARC eine PM883 480GB? Oder doch lieber SM883 480GB? Nach meinem Verständnis wird ja bei metadata only nicht permanent auf dem L2ARC geschrieben.

ZFS Lesecaches zu deaktivieren sollte man lassen. Ist wie Autofahren mit angezogener Handbremse
Bei einem 500 GB L2Arc sollte man aber 64GB RAM haben, Dann ist der Server aber vermutich ohne L2Arc schneller ode rschnell genug, Bei weiger RAM würde ich mich nach einer kleineren Optane 58/118 GB umsehen, ev gebraucht. Die sind unschlagbar schnell.
Bei L2Arc kommt es aber mehr auf lesen an. Eine SM muss nicht sein.

Das ist wohl die Königsklasse, weil auch Schreiboperationen beschleunigt werden. Aber wenn svdev weg, dann Pool weg Ja,

Das gilt für jedes vdev, daher 2/3 way mirror

Ansonsten hätte ich noch zwei Optane 905P 380GB, die ich sehr ungern nur dafür hernehmen möchte. Da gibts bestimmt einen sinnvolleren Verwendungszweck dafür (VM?)
Interessant wären ansonsten auch die hier https://amzn.eu/d/040TzZE

Schließt sich ja nicht aus. Einfach ein special vdev Mirror daraus machen und SBB auf 64K setzen. Das VM Dateisystem dann auch auf 64K recisze. Damit landen generell alle writes bis 64K inkl Metadaten darauf und alle Daten des VM Dateisystems, egal wie groß. Man muss nur den Füllgrad im Auge behalten. 380 GB sind ja nicht soviel.

https://amzn.eu/d/040TzZE
wäre perfekt als Cache.

Schnellste Lösung wäre aber ein 2/3 way Optane special vdev, Hilft auch beim Schreiben und ist auch persistent,
Bei VM Storage sollte man aber sync zusätzlich nutzen wo wir bei Slog wären. Dafür bräuchte man auch was ultraschnelles ab 10GB. Die kleinen Optane 1600 58/118 wären dafür perfekt wenn man nicht zuviel schreibt. Slog darf aber ja ausfallen.

 

[Icenice]

Danke abermals für deine Antworten. Trotzdem noch ein paar Sachen, die mir durch den Kopf gehen

ZFS Lesecaches zu deaktivieren sollte man lassen. Ist wie Autofahren mit angezogener Handbremse

Also bedeutet metadata only ein Deaktivieren des Lesecache? Irgendwie ist mir das nicht so ganz klar. Würde eine SATA-SSD in dem Fall nicht das Lesen manchmal ausbremsen?
Wenn ich jetzt 2x PM883 als Mirror verwende, wäre die Read Performance doppelt so hoch? Die habe ich nun mal. Daher eigentlich auch meine Überlegung nur L2Arc nur für Metadaten.
Vielleicht habe ich das Konzept noch nicht kapiert. Kommt der L2Arc beim kopieren von Dateien überhaupt ins Spiel? Und werden Metadaten ohne weitere Einstellungen trotzdem im L2Arc gecached und behalten?

https://amzn.eu/d/040TzZE
wäre perfekt als Cache.

Für L2Arc nehme ich an. Da muss man ja fast zugreifen, so lange es die noch gibt.

Bei einem 500 GB L2Arc sollte man aber 64GB RAM haben, Dann ist der Server aber vermutich ohne L2Arc schneller ode rschnell genug,

64GB RAM ist kein Problem. Die Samsung auszuprobieren kostet mich ja erstmal gar nichts.

Vielleicht mache ich mir auch zu viele Gedanken Es geht erstmal um einen reinen Fileserver. Der Rest wird später dazukommen.
VMs oder andere Sachen werden bestimmt nicht auf dem fetten Fileserver laufen, da der Stromverbrauch da viel zu hoch ist.
Ich merke schon; ich komme um ein bisschen Rumprobieren nicht rum.

 

[asche77]

[Optane]
Für L2Arc nehme ich an. Da muss man ja fast zugreifen, so lange es die noch gibt.

Für SLOG oder special vdev. Für l2arc geht natürlich auch, aber da gilt: erst RAM maximieren.

Vielleicht mache ich mir auch zu viele Gedanken

Ja.

 

[Mac_leod]

Reicht man die komplette NVMe SSD (für SLOG + L2Arc Grab) an die TrueNAS VM per Passthrough durch, oder erstellt man einen VMFS Datastore und hängt diesen per extra virtuellen SCSI Controller als Disk mit in die VM?
Gefühlt ist Passthrough der sauberere Weg.

Also ich weiß gerade nicht, was den Boost verursacht hat, aber mit dem CPU Wechsel und dem Ausbau der GPU liegen die Leseraten auf einmal doppelt so hoch an. etwas Strange, ich hab noch nie eine Windows Krücke so schnell booten sehen.
Aktuell wird die NVMe noch nicht verwendet, ich hab nur den gleichen Test noch mal angeschmissen.

 

[pwnbert]

Nein, gemischte Dateien. Aber es dauert ja überhaupt lange, bis die Verzeichnisstruktur gelistet wird. Also nur ein Ordner mit zig anderen Unterordnern usw.
Das ganze Dataset reagiert so träge, wird aber schlagartig besser, sobald man ein paar mal in Ordner raus und wieder rein geht.
Daher auch der Gedanke mit L2ARC und metadata caching. Ich hatte gehofft ein paar Antworten/Erfahrungen zu dem Thema zu bekommen oder special vdev für Metadaten (scheint aber keiner zu benutzen)
Das SSDs um Längen schneller als Platten reagieren, ist mir klar, nur ist das bei bestimmten Datenmengen kein Thema (Die Diskussion will ich aber hier nicht führen)

Erzähl dann, ich hab ähnliche Probleme.

Hab vorn paar Seiten schon gepostet, dass ich ne Minimalgrenze für den Metadatencache angegeben hab, aber so wirklich funktioniert hat das dann auch nicht.
svdev mag ich aus unterschiedlichen Gründen nicht, is mir zu heikel, zu sehr mit Kanonen auf Spatzen.
Die Idee mitm l2arc für die Metadaten hatte ich auch schon, aber mh...

 

[mrpasc]

Reicht man die komplette NVMe SSD (für SLOG + L2Arc Grab) an die TrueNAS VM per Passthrough durch, oder erstellt man einen VMFS Datastore und hängt diesen per extra virtuellen SCSI Controller als Disk mit in die VM?
Gefühlt ist Passthrough der sauberere Weg.

Wenn du eine SSD für SLOG und L2ARC verwenden willst, dann NICHT durchreichen. TrueNAS bietet keine Möglichkeit (zumindest auf offiziellen Weg) auf einem Device zwei vDevs anzulegen.
Unkompliziert: auf der NVME in ESXi einen datastore anlegen, darin zwei virtuelle disks anlegen, diese der TrueNAS VM zuordnen und in TrueNAS dann eine für SLOG und eine für L2ARC verwenden. Falls auf ESXi 8: NICHT mit dem SCSI Controller sondern dem virtuellen NVME Controller an die VM binden!
Variante 2: Schauen ob die NVME Namespaces unterstützt, falls ja: Zwei Namespaces anlegen und die dann durchreichen.

 

[Mac_leod]

Danke,
Ich hoffe, die 58GB reichen für beides.

 

[mrpasc]

Wird knapp. SLOG braucht nicht viel, mit 16GB sollte reichen. Aber L2ARC mit den restlichen 40GB ist wenig, evtl. Reicht es für Metadata-only.

 

[HansBohne]

Hmm aber für den Heimgebauch bis so 5-10 Nutzer gleichzeitig lohnt sich das doch nicht wirklich mit den extra devices, finde ich

Zumindet meine Server können alle eigentlich problemlos mit vollen 10 Gbit Daten tauschen.... und für mehr müsste ich dann erst das Netzwerk upgraden, was aber jenseits der 10 Gbit dann doch eher teuer wird.

Den grössten Sprung bringt doch immer einfach viele HDDs parallel.

 

[Mac_leod]

Ja da hast du natürlich recht, hier geht mir eher um das testen und Messen und Geld verbrennen
Was nun wirklich was bringt und was eben nicht.

 

[HansBohne]

Hehe ja max optimieren ist ja auch ein valider Grund ist ja nix dabei - nur "brauchen" tut man es vermutlich im Heimbetrieb nicht - aber schaden tut es natürlich auch nicht

--------------------------

Hmm zum ZFS allgemein habe jetzt auch mal OpenZFSonWindows (Win11 - 64 bit) installiert und am Laufen - scheint von der Performance noch etwas ausbaufähig zu sein aber ansonsten ist das wohl immerhin Stand 2.2.2 - unter Win meldet sich das als NTFS.

Hehe am längsten hat gedauert das "dev-mapping" zu ermitteln - mit "dd für Windows" ging das dann.

 

[besterino]

Was meinst du mit dev-Mapping?

 

[Mac_leod]

Schauen wir mal ob es was bringt, beim migrieren von Files innerhalb ESX "fühlt" es sich schon mal schneller an.

Ohne

mit SLOG und L2ARC auf NVMe ausgelagert.
Der Unterschied ist schon beachtlich.

Mal sehen wie die Werte aussehen, wenn die 3 Consumer SSDs raus fliegen und Enterprise Ware getauscht wird.

 

[Luckysh0t]

Enterprise Ware getauscht

Ich schätze mal, vor allem wird die Geschwindigkeit länger gehalten, was man mit CDM eher nicht sieht.

 

[Mac_leod]

So die Hoffnung, die 4K Werte sehen leider immer noch grottig aus.

 

[mrpasc]

Ninja, man muss immer im Hinterkopf behalten: ZFS wurde für HDDs entwickelt, für viiieeeele HDDs. Und für Robusheit, viiiieeeeel Robusheit. Für Datensicherheit und -Integrität.
Aber nicht für maximale Performance. Und auch immer noch nicht wirklich auf NVME optimiert. Ist einfach so. Wer tolle Benchmark Ergebnisse haben will sollte NTFS, XFS, Ext4 bevorzugen.

 

[HansBohne]

Was meinst du mit dev-Mapping?

Naja man muss doch erst mal herausfinden wie die devs unter Windows heissen aus denen man ein ZFS (RAID) Container macht

es sind z.b. die "Device\Harddisk3\DR3"


Hehe da muss man doch erst mal drauf kommen. Mit dd (für Windows) konnte ich zumindest ein OpenZFS kompatibles Mapping herausfinden, gibt sicher auch andere Wege, aber der hat halt bei mir funktioniert.

C:\>dd --list


rawwrite dd for windows version 0.6beta3.
Written by John Newbigin <jn@it.swin.edu.au>
This program is covered by terms of the GPL Version 2.

Win32 Available Volume Information
\\.\Volume{000000db-90c0-a979-796b-da01b6010000}\
  link to \\?\Device\HarddiskVolume1
  fixed media
  Mounted on \\.\f:

\\.\Volume{50b17baa-c8df-42f0-905e-857fb39690ef}\
  link to \\?\Device\HarddiskVolume4
  fixed media
  Mounted on \\.\c:

\\.\Volume{49cf578b-66b1-4f18-9274-2ffcada17f00}\
  link to \\?\Device\HarddiskVolume2
  fixed media
  Not mounted

\\.\Volume{8c871983-d0d1-11ee-90df-806e6f6e6963}\
  link to \\?\Device\HarddiskVolume6
  removeable media
  Mounted on \\.\d:

\\.\Volume{bf7ec3f9-d5fe-11ee-90ed-00e04c316c4c}\
  link to \\?\Device\Volume{413cee64-9f5b-3f10-848f-b387fdedfcc9}
  removeable media
  Mounted on \\.\g:

\\.\Volume{bf7eb3aa-d5fe-11ee-90ed-00e04c316c4c}\
  link to \\?\Device\Volume{b01eba6d-a888-3b86-8c18-76d05995439e}
  removeable media
  Not mounted

\\.\Volume{617cbce9-b154-11ee-907d-00e04c316c4c}\
  link to \\?\Device\CdRom0
  CD-ROM
  Mounted on \\.\e:


NT Block Device Objects
\\?\Device\CdRom0
  size is 2147483647 bytes
\\?\Device\Harddisk0\Partition0
  link to \\?\Device\Harddisk0\DR0
  Fixed hard disk media. Block size = 512
  size is 4096805658624 bytes
\\?\Device\Harddisk0\Partition1
  link to \\?\Device\HarddiskVolume1
\\?\Device\Harddisk1\Partition0
  link to \\?\Device\Harddisk1\DR1
  Fixed hard disk media. Block size = 512
  size is 4000787030016 bytes
\\?\Device\Harddisk1\Partition1
  link to \\?\Device\HarddiskVolume2
\\?\Device\Harddisk1\Partition2
  link to \\?\Device\HarddiskVolume3
  Fixed hard disk media. Block size = 512
  size is 16777216 bytes
\\?\Device\Harddisk1\Partition3
  link to \\?\Device\HarddiskVolume4
\\?\Device\Harddisk2\Partition0
  link to \\?\Device\Harddisk2\DR2
  Fixed hard disk media. Block size = 512
  size is 2000398934016 bytes
\\?\Device\Harddisk2\Partition1
  link to \\?\Device\HarddiskVolume5
  Fixed hard disk media. Block size = 512
  size is 2000396747264 bytes
\\?\Device\Harddisk3\Partition0
  link to \\?\Device\Harddisk3\DR3
\\?\Device\Harddisk3\Partition1
  link to \\?\Device\HarddiskVolume6

Virtual input devices
 /dev/zero   (null data)
 /dev/random (pseudo-random data)
 -           (standard input)

Virtual output devices
 -           (standard output)
 /dev/null   (discard the data)