[Sammelthread] ZFS Stammtisch

ZFS Pools bestehen aus vdevs, vdevs aus Platten.
In napp-it cs unter Windows ermittle ich die Platten in der Powershell mit
Get-PhysicalDisk | Select DeviceID,UniqueId,Manufacturer,Model,CanPool,OperationalStatus,HealthStatus,Serialnumber,size

Platten heißen z.B. physicaldisk1 (1 ist die deviceID aus dem powershell Listing)


btw
There is a new Open-ZFS 2.2 rc.13 for Windows

Jorgen Lundman: " I threw in some code that looks up ashift to use instead of 512. If you can, check out OpenZFSOnWindows-debug-2.2.99-13-gfddfb6aeb5.exe. I did the most obvious places, but there are quite a few ways to query that.

*** Please update, the trim bug might be corrupting pools! ***

Now trim is disabled by default, to check it works (on test pools right?) change
HLM/System/ControlSet001/Services/OpenZFS
windows_enable_trim to 1. "

Care: ashift is not a pool but a vdev property. Different ashift in a pool is bad but can happen if you add vdevs without forcing ashift manually.

 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das doch kein Unterschied denke ich nach einem export und import ändert sich das eh oft spätestens - man braucht halt nur beim Einrichten einen OS-Link zum BaseDev. von dem gibt es sicher einige Varianten und nicht nur den einen Pfad - wie der später dann heisst und was ZFS intern draus macht ist doch egal. dd ist halt recht einfach, weil eine fertige exe.

Inzwischen ist aus obigen nach export / import das device bei mir geworden

ZFS hängt bei mir aktuell - weil in Testphase unter Win - nur am USB Port.

Code:
C:\>zpool status tank
 

pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:03:01 with 0 errors on Wed Feb 28 09:59:42 2024
config:

        NAME                   STATE     READ WRITE CKSUM
        tank                   ONLINE       0     0     0
          Harddisk2Partition0  ONLINE       0     0     0


Wenn Du ZFS unter Windows schon etwas länger hast dann hab ich ne Frage, evtl kannst Du mir da helfen - ich habe ein verschlüsseltes sub Volume erzeugt "tank/encrypted" ich kann das zwar mounten und Dateien draufkopieren und sehe auch das was kopiert wird - aber nicht in Unterverzeichnisse wechseln.

Programme wie Portable Appes, die ich draufkopiere und im Hauptverzeichnis des verschlüsselten Volumes sind werden aber ausgeführt....

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

Gerade getestet das ist auch bei nicht verschlüsselten Sub Volumes so bei mir.

Downloads ist ein normales Unterverezcnis auf tank das andere sind Tank/SubVolumes

Also alle die <JUNCTION> heissen da geht nur das Hauptverzeichnis bei mir

Code:
C:\Windows\System32>dir g:
 Datenträger in Laufwerk G: ist tank
 Volumeseriennummer: 1983-1116

 Verzeichnis von G:\

29.02.2024  12:35    <DIR>          .
29.02.2024  12:35    <DIR>          ..
29.02.2024  12:35    <JUNCTION>     testsub [tank/testsub]
29.02.2024  12:34    <JUNCTION>     abc [tank/abc]
28.02.2024  09:09    <DIR>          Downloads
28.02.2024  15:41    <JUNCTION>     encrypted [tank/encrypted]
               0 Datei(en),              0 Bytes
               6 Verzeichnis(se), 1.831.242.071.552 Bytes frei
 
Zuletzt bearbeitet:
@HansBohne Danke für die Erläuterung. Ich arbeite da auch immer nur mit „physicaldisk#“. Passt bisher für mich.

@gea: wie cool ist bitte der Lundman, dass der so schnell auf eine solche Trivialität reagiert! Vor allem kann ich jetzt direkt mal Performance-Vergleiche anstellen. Wäre ja der Hammer, wenn dann die Performance auch bei 4K random Zugriffen zumindest an ReFS rankäme.

So‘n Mist, dass ich erst frühestens morgen wieder damit herumspielen kann!
 
@HansBohne

@gea: wie cool ist bitte der Lundman, dass der so schnell auf eine solche Trivialität reagiert! Vor allem kann ich jetzt direkt mal Performance-Vergleiche anstellen. Wäre ja der Hammer, wenn dann die Performance auch bei 4K random Zugriffen zumindest an ReFS rankäme.

Alles ene Frage der Einstellung.

Jorg Lundman ist soviel ich weiß Schwede und arbeitet als ZFS kernel dev in Tokyo.
Ich war gerade erst zwei Wochen in Japan und war schwer beeindruckt von deren Arbeitsmoral.
 
Ich war gerade erst zwei Wochen in Japan und war schwer beeindruckt von deren Arbeitsmoral.
Warum es eher abschrecken und wenig positives bedeutet für alle Akteure bedeutet:
 
<off topic>
Es gibt da auch Auswüchse, Ausbeutung und strukturelle Fehlentwicklungen.
Das ist aber etwas anderes als das persönliche Bestreben nach Perfektion und 100% Einsatz.
 
Ich seh es ziemlich simpel: ich bin immer bereit, 110% zu geben, aber nicht bereit, immer 110% zu geben. :d

So, jetzt erstmal pennen.
 
Ich bin noch relativ neu in dem Bereich, aber ich habe mich ein bisschen eingelesen und man kann wohl keine weiteren Platten zu einem VDev hinzufügen. Allerdings ist eine weitere Disk als Mirrow möglich.
Ich würde in Zukunft gerne meine Pools "sicherer" machen und alles auf Mirrow Basis haben. Wie mache ich das am besten um keinen Datenverlust zu haben und die Spiegelung zu erreichen?


1709381899540.png


1709381876988.png
 
Man kann im aktuellen Open-ZFS 2.2 eine Platte zu einem Raid-Z hinzufügen (z.B. z1 mit 3 Platten -> z1 mit 4 Platten):
Man kann aus einer einzelnen Platte einen Mirror machen
Man kann einen Pool durch weitere vdevs z.B. Mirrors erweitern
 
So, mal sehen wie sich die kleine Optane schlägt, wenn nur SLOG drauf gelegt wird. Bin ich gespannt :coffee3:
 
Ich hab ja die 118 GB Version, und den rpool (pve, mirror) auf always bei sync, beim Anlegen etc. von VMs merke ich keine Gedenkpausen ^^.
Sollten Benches von der shell gewünscht werden, Bescheid sagen, mit welchen Parametern der Test gewünscht wird.
 
Hey @gea. Versuche gerade napp-it auf proxmox zum laufen zu kriegen. Habe da Deine ESXi .ova genommen, und die nach der Anleitung konvertiert:


Leider habe ich einen Bootloop:


Kannst Du da was dazu sagen? Und ist die Idee von napp-it unter Proxmox überhaupt sinnvoll? Oder soll ich das lieber lassen?

Edit: habe Openindiana und napp-it manuell installiert, jetzt läuft es.
 
Zuletzt bearbeitet:
falls du Lust hast dann mit diskspd.exe --> https://github.com/microsoft/diskspd
diskspd.exe -t2 -o32 -b4k -r4k -w50 -d120 -Sh -D -L -c5G C:\tmp\IO.dat > C:\tmp\test-un-w0-10.txt
und nen crystaldisk Screenshot Option.
Ob das so Aussagekräftig ist über Gbit Lan auf den proxmox host ? ^^

Hab ja eine Windows 10 VM. Ist dann innerhalb der VM, die auf dem Storage liegt. Allerdings zu beachten ist, dass meine beiden 2 TB nvme SSDs auf der Qnap Karte sind und sich mit der verbunden Nic einen PCIe x4 Slot teilen. Die Optane ist im m.2 Slot direkt auf dem Board. Wie man sieht, macht sie Ihren Dienst als slog Device.

Bei diskspd sagt er mir : parameters(-D) must come before targets on command line, wenn ich deine Zeile nehme
 

Anhänge

  • sync off.PNG
    sync off.PNG
    24,9 KB · Aufrufe: 38
  • syncalwaysoslog.PNG
    syncalwaysoslog.PNG
    23,8 KB · Aufrufe: 37
  • syncalwaysmslog.PNG
    syncalwaysmslog.PNG
    24,2 KB · Aufrufe: 39
Zuletzt bearbeitet:
Hey @gea.

Kannst Du da was dazu sagen? Und ist die Idee von napp-it unter Proxmox überhaupt sinnvoll? Oder soll ich das lieber lassen?

Prinzipiell ist es sinnvoll, vor allem da OmniOS resourcenschonender ist als eine Linux Storage VM und update/downgrade ein Traum ist. Auch ist der Solaris SMB Server was besonderes. Ich ziehe den einem Linux SAMBA mit Posix ACL allemal vor. Ich habe mich aber um das Thema Solaris unter Proxmox auch noch nicht gekümmert da napp-it cs (unterstützt ja auch BSD/Linux/Proxmox etc) gerade meine volle Aufmerksamkeit hat. Auch sehe ich selber noch keinen Grund von ESXi wegzugehen. Das hat noch etwas Zeit bis das wirklich notwendig ist.
 
Ich hab die Optane auch irgendwo drin und könnte evtl. heute Abend mal nen lokalen Test machen.
 
@Mac_leod:

1709585079859.png


Diskspd:
Code:
Command Line: diskspd.exe -t2 -o32 -b4k -r4k -w50 -d120 -Sh -D -L -c5G D:\IO.dat

Input parameters:

    timespan:   1
    -------------
    duration: 120s
    warm up time: 5s
    cool down time: 0s
    measuring latency
    gathering IOPS at intervals of 1000ms
    random seed: 0
    path: 'D:\IO.dat'
        think time: 0ms
        burst size: 0
        software cache disabled
        hardware write cache disabled, writethrough on
        performing mix test (read/write ratio: 50/50)
        block size: 4KiB
        using random I/O (alignment: 4KiB)
        number of outstanding I/O operations per thread: 32
        threads per file: 2
        using I/O Completion Ports
        IO priority: normal

System information:

    computer name: 3960X
    start time: 2024/03/04 21:00:00 UTC

Results for timespan 1:
*******************************************************************************

actual test time:    120.00s
thread count:        2
proc count:        48

CPU |  Usage |  User  |  Kernel |  Idle
-------------------------------------------
   0|  99.90%|   4.65%|   95.25%|   0.10%
   1|  99.95%|   3.89%|   96.05%|   0.05%
   2|   0.01%|   0.01%|    0.00%|  99.99%
   3|   0.01%|   0.00%|    0.01%|  99.99%
   4|   0.01%|   0.01%|    0.00%|  99.99%
   5|   0.00%|   0.00%|    0.00%| 100.00%
   6|   0.01%|   0.01%|    0.00%|  99.99%
   7|   0.01%|   0.01%|    0.00%|  99.99%
   8|   0.01%|   0.01%|    0.00%|  99.99%
   9|   0.00%|   0.00%|    0.00%| 100.00%
  10|   0.01%|   0.01%|    0.00%|  99.99%
  11|   0.00%|   0.00%|    0.00%| 100.00%
  12|   0.00%|   0.00%|    0.00%| 100.00%
  13|   0.01%|   0.01%|    0.00%|  99.99%
  14|   0.01%|   0.01%|    0.00%|  99.99%
  15|   0.01%|   0.00%|    0.01%|  99.99%
  16|   0.00%|   0.00%|    0.00%| 100.00%
  17|   0.00%|   0.00%|    0.00%| 100.00%
  18|   0.01%|   0.00%|    0.01%|  99.99%
  19|   0.00%|   0.00%|    0.00%| 100.00%
  20|   0.01%|   0.01%|    0.00%|  99.99%
  21|   0.01%|   0.00%|    0.01%|  99.99%
  22|   0.01%|   0.00%|    0.01%|  99.99%
  23|   0.00%|   0.00%|    0.00%| 100.00%
  24|   0.04%|   0.03%|    0.01%|  99.96%
  25|   0.08%|   0.04%|    0.04%|  99.92%
  26|   0.01%|   0.01%|    0.00%|  99.99%
  27|   0.07%|   0.00%|    0.07%|  99.93%
  28|   0.29%|   0.12%|    0.17%|  99.71%
  29|   0.29%|   0.10%|    0.18%|  99.71%
  30|   0.01%|   0.00%|    0.01%|  99.99%
  31|   0.01%|   0.01%|    0.00%|  99.99%
  32|   0.00%|   0.00%|    0.00%| 100.00%
  33|   0.00%|   0.00%|    0.00%| 100.00%
  34|   0.00%|   0.00%|    0.00%| 100.00%
  35|   0.00%|   0.00%|    0.00%| 100.00%
  36|   0.00%|   0.00%|    0.00%| 100.00%
  37|   0.00%|   0.00%|    0.00%| 100.00%
  38|   0.00%|   0.00%|    0.00%| 100.00%
  39|   0.00%|   0.00%|    0.00%| 100.00%
  40|   0.00%|   0.00%|    0.00%| 100.00%
  41|   0.00%|   0.00%|    0.00%| 100.00%
  42|   0.01%|   0.01%|    0.00%|  99.99%
  43|   0.00%|   0.00%|    0.00%| 100.00%
  44|   0.00%|   0.00%|    0.00%| 100.00%
  45|   0.00%|   0.00%|    0.00%| 100.00%
  46|   0.00%|   0.00%|    0.00%| 100.00%
  47|   0.00%|   0.00%|    0.00%| 100.00%
-------------------------------------------
avg.|   4.18%|   0.19%|    4.00%|  95.82%

Total IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | IopsStdDev | LatStdDev |  file
------------------------------------------------------------------------------------------------------------------
     0 |     40879734784 |      9980404 |     324.87 |   83167.43 |    0.372 |     211.27 |     0.030 | D:\IO.dat (5GiB)
     1 |     22555398144 |      5506689 |     179.25 |   45887.64 |    0.675 |     152.34 |     0.037 | D:\IO.dat (5GiB)
------------------------------------------------------------------------------------------------------------------
total:       63435132928 |     15487093 |     504.12 |  129055.06 |    0.480 |     300.78 |     0.149

Read IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | IopsStdDev | LatStdDev |  file
------------------------------------------------------------------------------------------------------------------
     0 |     20423778304 |      4986274 |     162.31 |   41550.98 |    0.368 |     199.52 |     0.028 | D:\IO.dat (5GiB)
     1 |     11277627392 |      2753327 |      89.62 |   22943.67 |    0.670 |     141.52 |     0.037 | D:\IO.dat (5GiB)
------------------------------------------------------------------------------------------------------------------
total:       31701405696 |      7739601 |     251.93 |   64494.65 |    0.476 |     250.44 |     0.148

Write IO
thread |       bytes     |     I/Os     |    MiB/s   |  I/O per s |  AvgLat  | IopsStdDev | LatStdDev |  file
------------------------------------------------------------------------------------------------------------------
     0 |     20455956480 |      4994130 |     162.56 |   41616.45 |    0.377 |     148.25 |     0.032 | D:\IO.dat (5GiB)
     1 |     11277770752 |      2753362 |      89.62 |   22943.96 |    0.680 |     117.61 |     0.037 | D:\IO.dat (5GiB)
------------------------------------------------------------------------------------------------------------------
total:       31733727232 |      7747492 |     252.19 |   64560.41 |    0.485 |     205.63 |     0.149



total:
  %-ile |  Read (ms) | Write (ms) | Total (ms)
----------------------------------------------
    min |      0.193 |      0.182 |      0.182
   25th |      0.363 |      0.371 |      0.367
   50th |      0.383 |      0.391 |      0.387
   75th |      0.650 |      0.660 |      0.655
   90th |      0.689 |      0.699 |      0.695
   95th |      0.708 |      0.718 |      0.713
   99th |      0.745 |      0.755 |      0.751
3-nines |      0.800 |      0.810 |      0.806
4-nines |      0.841 |      0.850 |      0.846
5-nines |      0.881 |      0.894 |      0.890
6-nines |     12.628 |     12.660 |     12.641
7-nines |     12.669 |     12.689 |     12.686
8-nines |     12.669 |     12.689 |     12.689
9-nines |     12.669 |     12.689 |     12.689
    max |     12.669 |     12.689 |     12.689
 
nice, ich würde mal ne Tabelle baseln, mit user, disks, verwendete Z Variante usw.
 
Moin, ich brauche mal Eure Hilfe / best practice / Empfehlung für meine aktuellen/neuen ZFS-Pools. Da hat sich ja auch mit special-vdev und metadata-vdef anscheinen einiges getan seit "meinem letzten Mal".

Was ich habe:

ESXI 8 mit Napp-it-allinone
128GB RAM max.
4x Samsung PPM863 1,96TB
8x WD SATA 12 TB
beides an einem durchgereichten Controller.
Netzwerk ist in weiten Teilen 10GBit
Aktuell max. 3 Nutzer + ESXI als "Last"

Geplant:
32GB RAM für die VM
2x2 Mirror mit den SSD
eigtentlich 1x RaidZ2 mit den WD

Aber ich stelle mit die Frage ob es sinnvoller ist mit den HDDs 2x RaidZ1 zu erstellen.

Die HDD sind für max. Platz gedacht, das übliche was man so sammelt, Backups evtl. von Clients etc.
Nur würde ich die gerne "beschleunigen", wie macht es am meisten Sinn? Ob ein L2ARC hilft wird sich sicherlich erst später zeigen, wenn die Kiste in Betrieb ist.

Vielen Dank vorab wenn Ihr Idee / Erfahrungen teilen mögt.
 
Ich würde das Z2 lassen weil da zwei beliebige Platten ausfallen dürfen. 2xZ1 hat zwar doppelt soviel iops aber ob man nun 100 iops hat oder 200 macht den Kohl nicht fett weil SSD mehrere 1000 iops haben und sowas wie Optane soger mehrere 100000. L2Arc als persistenten Cache wird in dem Anwendungsfall absolut nichts bringen. Da VM Storage sync nutzen sollte, würde ich mir eine kleine Optane 1600 als Slog überlegen.

Meine einzige Überlegung wäre einen NVMe mirror für VMs und einen zweiten als special vdev mit small blocksize 32 oder 64K bei einer im Vergleich dazu größeren recsize von 64 oder 128K Damit arbeitet VM Storage generell noch effizient und alle Metadaten (lesend und schreibend) landen auf dem special vdev, dazu alle kleineren Dateien bis zur sbb Größe. Dazu kann man per Dateisystem die recsize <= small blocksize stellen. Das hat zur Folge dass alle Dateien dieses Dateisystems auf der SSD und nicht auf dem Plattenpool landen. Man muss halt dann den Füllgrad im Auge behalten. Sind die special vdev voll geht alles auf den langsameren Pool.

Man könnte auch zwei special vdev mirrors haben weil man halt flexibel einstellen kann was auf den Plattenpool soll und was auf die SSD.
Beachte dass ein special vdev kein Cache ist der ausfallen darf wie L2Arc sondern alleiniger Speicherort. Special vdev lost = Pool lost.

Ich würde wohl
- Einen Z2 Pool mit 2 x special vdev Mirror machen, dazu ein Optane Slog
Das ergibt einen ZFS Tiering Pool mit 4 TB schnellem und 12 TB langsamen Platz
- Disaster Backup auf einen weiteren externen (Mirror) Pool
 
Zuletzt bearbeitet:
Open-ZFS for BSD, Linux and OSX (rc) is now at 2.2.3 with improvements around trim and many bugfixes.

Open-ZFS for Windows is 2.2.2 but as far as I know Jorgen Lundman
2.2.3 on Windows (rc) will be out soon

OpenZFS on Illumos is separate as it has its own repository
with integration of Open-ZFS improvements after an additional review
 
guten Abend,

die 3 Samsung 512GB 850 sind nun gegen 4 Enterprise SSD (Intel S4610, S4510, Micron 5100 Pro, Micron 5200) getauscht.
Die kleine NVMe Optane läuft als SLOG.
L2ARC hab ich aktuell nicht extra laufen, da die Optane dafür zu klein ist.
So sehen die Werte am Ende aus:
1709766498203.png

Damit kann ich arbeiten.
Die Tabelle leg ich noch an.
 
Ich würde das Z2 lassen weil da zwei beliebige Platten ausfallen dürfen. 2xZ1 hat zwar doppelt soviel iops aber ob man nun 100 iops hat oder 200 macht den Kohl nicht fett weil SSD mehrere 1000 iops haben und sowas wie Optane soger mehrere 100000. L2Arc als persistenten Cache wird in dem Anwendungsfall absolut nichts bringen. Da VM Storage sync nutzen sollte, würde ich mir eine kleine Optane 1600 als Slog überlegen.

Meine einzige Überlegung wäre einen NVMe mirror für VMs und einen zweiten als special vdev mit small blocksize 32 oder 64K bei einer im Vergleich dazu größeren recsize von 64 oder 128K Damit arbeitet VM Storage generell noch effizient und alle Metadaten (lesend und schreibend) landen auf dem special vdev, dazu alle kleineren Dateien bis zur sbb Größe. Dazu kann man per Dateisystem die recsize <= small blocksize stellen. Das hat zur Folge dass alle Dateien dieses Dateisystems auf der SSD und nicht auf dem Plattenpool landen. Man muss halt dann den Füllgrad im Auge behalten. Sind die special vdev voll geht alles auf den langsameren Pool.

Man könnte auch zwei special vdev mirrors haben weil man halt flexibel einstellen kann was auf den Plattenpool soll und was auf die SSD.
Beachte dass ein special vdev kein Cache ist der ausfallen darf wie L2Arc sondern alleiniger Speicherort. Special vdev lost = Pool lost.

Ich würde wohl
- Einen Z2 Pool mit 2 x special vdev Mirror machen, dazu ein Optane Slog
Das ergibt einen ZFS Tiering Pool mit 4 TB schnellem und 12 TB langsamen Platz
- Disaster Backup auf einen weiteren externen (Mirror) Pool
Ich habe mich einmal daran versucht, das Ding anzulegen (ich hoffe soweit erstmal richtig)



pool: HDD_TANK
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
HDD_TANK ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
c0t5000CCA26FEEE831d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 8CKA5VEF S:0 H:0 T:0 -
c0t5000CCA26FF01FBAd0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 8CKDVV3E S:0 H:0 T:0 -
c0t5000CCA28DDC4F9Cd0 ONLINE 0 0 0 12 TB WDC WD120EMFZ-11 Z2J08P7T S:0 H:0 T:0 -
c0t5000CCA291C12264d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PG2HB2F S:0 H:0 T:0 -
c0t5000CCA291C27C7Fd0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PG5GK7F S:0 H:2 T:135 -
c0t5000CCA291D7E169d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PHPJJYF S:0 H:0 T:0 -
c0t5000CCA291DCD255d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PJ1DHSD S:0 H:0 T:0 -
c0t5000CCA291DF5A42d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PJ6Z3BE S:0 H:0 T:0 -
special vdev 100.13 TB used: 99%
mirror-1 ONLINE 0 0 0
c0t5002538E09600344d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M613917 S:0 H:0 T:0 -
c0t5002538E0992D242d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M913210 S:0 H:0 T:0 -
mirror-2 ONLINE 0 0 0
c0t5002538E0996DC8Bd0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M922467 S:0 H:0 T:0 -
c0t5002538E19B1FC90d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0MB43894 S:0 H:0 T:0 -



Was mich wundert ist der Füllstand von 99%, ist das so gewünscht?
Und just als ich die Kiste mal wieder benutze meldet eine HDD S:0 H:2 T:135 Wofür standen die Werte bitte noch einmal?

Ich habe die Platte mit zpool online erstmal wieder zum Dienst verdonnert.

Das Thema sbs und recsize muss ich noch verstehen und einrichten.
 
Ich habe mich einmal daran versucht, das Ding anzulegen (ich hoffe soweit erstmal richtig)



pool: HDD_TANK
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
HDD_TANK ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
c0t5000CCA26FEEE831d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 8CKA5VEF S:0 H:0 T:0 -
c0t5000CCA26FF01FBAd0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 8CKDVV3E S:0 H:0 T:0 -
c0t5000CCA28DDC4F9Cd0 ONLINE 0 0 0 12 TB WDC WD120EMFZ-11 Z2J08P7T S:0 H:0 T:0 -
c0t5000CCA291C12264d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PG2HB2F S:0 H:0 T:0 -
c0t5000CCA291C27C7Fd0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PG5GK7F S:0 H:2 T:135 -
c0t5000CCA291D7E169d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PHPJJYF S:0 H:0 T:0 -
c0t5000CCA291DCD255d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PJ1DHSD S:0 H:0 T:0 -
c0t5000CCA291DF5A42d0 ONLINE 0 0 0 12 TB WDC WD120EDAZ-11 5PJ6Z3BE S:0 H:0 T:0 -
special vdev 100.13 TB used: 99%
mirror-1 ONLINE 0 0 0
c0t5002538E09600344d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M613917 S:0 H:0 T:0 -
c0t5002538E0992D242d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M913210 S:0 H:0 T:0 -
mirror-2 ONLINE 0 0 0
c0t5002538E0996DC8Bd0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0M922467 S:0 H:0 T:0 -
c0t5002538E19B1FC90d0 ONLINE 0 0 0 1.92 TB SAMSUNG MZ7LH1T9 S455NY0MB43894 S:0 H:0 T:0 -



Was mich wundert ist der Füllstand von 99%, ist das so gewünscht?

Nein, denn dann landen weitere small io auf dem langamen Pool
- > mehr special vdev bereitstellen und sbb auf einen kleineren Wert setzen, damit nicht soviele Daten darauf landen
.
Und just als ich die Kiste mal wieder benutze meldet eine HDD S:0 H:2 T:135 Wofür standen die Werte bitte noch einmal?
Soft error : A disk sector fails the CRC check and needs to be re-read
Hard error : Re-read fails several times for CRC check
Transport error : Errors reported by I/O bus
Total errors : Soft error + Hard error + Transport errors
Ich habe die Platte mit zpool online erstmal wieder zum Dienst verdonnert.
Das beseitigt die Meldung nicht die Ursache.
Vermutlich hat die Platte ein Problem (Intensivtest und/oder tauschen)
Problem kann aber auch ein Kabel sein.

Das Thema sbs und recsize muss ich noch verstehen und einrichten.
Eigentlich ganz einfach:
Alle Datenbläcke <=sbb landen auf dem special vdev, alle größeren auf dem Plattenpool.

ZFS nutzt bis auf draid dynamisch Bloockgrößen. Recsize ist nur eine Vorgabe wie große Daten aufzuteilen sind (in Blöcken in recsiceze). Kleinere Daten nutzen automatisch kleinere Blöcke, Dadurch landen kleinere Daten (small io) automatisch auf dem special vdev. Setzt man eine recsize <=sbb so landet alles auf dem special vredv.
 
so erst Mal letzte Update:
Von nfs z2 auf iscsi z1 gewechselt und schon sehen die Werte komplett anders aus.
Mit testen bin ich erst mal durch.
1709929145799.png
 
...
Eigentlich ganz einfach:
Alle Datenbläcke <=sbb landen auf dem special vdev, alle größeren auf dem Plattenpool.

ZFS nutzt bis auf draid dynamisch Bloockgrößen. Recsize ist nur eine Vorgabe wie große Daten aufzuteilen sind (in Blöcken in recsiceze). Kleinere Daten nutzen automatisch kleinere Blöcke, Dadurch landen kleinere Daten (small io) automatisch auf dem special vdev. Setzt man eine recsize <=sbb so landet alles auf dem special vredv.
Kleine Anmerkung: Datenblöcke eines zvols landen nie auf einem special device.
 
Habe jetzt mal testweise mit dem MC12-LE0 was aufgebaut:
8x ExosX16 16TB als RAID-Z2 mit (erstmal) 2x 480GB SATA-SSDs Mirror als metadata special vdev.
Jetzt stellt sich die Frage, ob die Geschwindigkeit im erwartbaren Rahmen liegt, oder ob 2xOptane 1600X anstatt 2xSATA-SSD noch eine Steigerung bewirken würden?
Kopieren auf SMB Share über Windows liegt bei großen Dateien bei irgendwas um die 730 MB/s (zumindest noch bei kleinem Füllgrad) Lesen so knapp 1GB/s

Ohne viel zu verstehen 🙈 habe ich mal einen fio Benchmark gemacht. Was meint ihr?
Zuerst Caching deaktiviert um das Ergebnis nicht zu verfälschen
Code:
zfs set primarycache=metadata Exos-01

Code:
fio --name=seqread --rw=read --ioengine=posixaio --bs=1M --numjobs=1 --size=10G --runtime=60 --end_fsync=1 --filename=/mnt/Exos-01/Test/seqread  --group_reporting
seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
fio-3.33
Starting 1 process
seqread: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [R(1)][94.1%][r=663MiB/s][r=663 IOPS][eta 00m:01s]
seqread: (groupid=0, jobs=1): err= 0: pid=21054: Sat Mar 16 08:22:43 2024
read: IOPS=642, BW=642MiB/s (673MB/s)(10.0GiB/15946msec)
slat (nsec): min=471, max=86815, avg=1330.66, stdev=942.16
clat (usec): min=333, max=123902, avg=1553.78, stdev=3374.38
lat (usec): min=334, max=123904, avg=1555.11, stdev=3374.46
clat percentiles (usec):
| 1.00th=[ 429], 5.00th=[ 570], 10.00th=[ 660], 20.00th=[ 668],
| 30.00th=[ 685], 40.00th=[ 701], 50.00th=[ 725], 60.00th=[ 758],
| 70.00th=[ 865], 80.00th=[ 938], 90.00th=[ 4359], 95.00th=[ 5211],
| 99.00th=[10945], 99.50th=[13960], 99.90th=[52167], 99.95th=[63701],
| 99.99th=[79168]
bw ( KiB/s): min=342016, max=774144, per=99.91%, avg=657011.61, stdev=93442.71, samples=31
iops : min= 334, max= 756, avg=641.61, stdev=91.25, samples=31
lat (usec) : 500=1.91%, 750=56.77%, 1000=25.05%
lat (msec) : 2=0.69%, 4=3.48%, 10=11.04%, 20=0.63%, 50=0.31%
lat (msec) : 100=0.10%, 250=0.01%
cpu : usr=0.24%, sys=0.21%, ctx=10460, majf=0, minf=24
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=10240,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
READ: bw=642MiB/s (673MB/s), 642MiB/s-642MiB/s (673MB/s-673MB/s), io=10.0GiB (10.7GB), run=15946-15946msec
Code:
fio --name=seqwrite --rw=write --ioengine=posixaio --bs=1M --numjobs=1 --size=10G --runtime=60 --end_fsync=1 --filename=/mnt/Exos-01/Test/seqwrite  --group_reporting
seqwrite: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
fio-3.33
Starting 1 process
seqwrite: Laying out IO file (1 file / 10240MiB)
Jobs: 1 (f=1): [F(1)][100.0%][eta 00m:00s]
seqwrite: (groupid=0, jobs=1): err= 0: pid=21407: Sat Mar 16 08:35:23 2024
write: IOPS=495, BW=495MiB/s (519MB/s)(10.0GiB/20683msec); 0 zone resets
slat (usec): min=2, max=192, avg= 7.94, stdev= 4.28
clat (usec): min=92, max=7131, avg=1150.05, stdev=874.66
lat (usec): min=96, max=7142, avg=1157.99, stdev=875.85
clat percentiles (usec):
| 1.00th=[ 102], 5.00th=[ 119], 10.00th=[ 124], 20.00th=[ 135],
| 30.00th=[ 396], 40.00th=[ 963], 50.00th=[ 1434], 60.00th=[ 1483],
| 70.00th=[ 1549], 80.00th=[ 1647], 90.00th=[ 1942], 95.00th=[ 2245],
| 99.00th=[ 4146], 99.50th=[ 5080], 99.90th=[ 6652], 99.95th=[ 6849],
| 99.99th=[ 7111]
bw ( KiB/s): min=192512, max=6264832, per=100.00%, avg=890078.61, stdev=1204574.11, samples=23
iops : min= 188, max= 6118, avg=869.22, stdev=1176.34, samples=23
lat (usec) : 100=0.39%, 250=25.74%, 500=6.22%, 750=3.89%, 1000=4.42%
lat (msec) : 2=51.13%, 4=7.07%, 10=1.13%
cpu : usr=0.60%, sys=0.04%, ctx=10313, majf=0, minf=26
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,10240,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1

Run status group 0 (all jobs):
WRITE: bw=495MiB/s (519MB/s), 495MiB/s-495MiB/s (519MB/s-519MB/s), io=10.0GiB (10.7GB), run=20683-20683msec
 
Zuletzt bearbeitet:
Hmm ich komme auf meinen Xeon auf (ohne Cache devs etc) 32 GB ECC DDR3

Code:
fio --name=seqread --rw=read --ioengine=posixaio --bs=1M --numjobs=1 --size=10G --runtime=60 --end_fsync=1 --filename=/tank/notcrypted/seqread  --group_reporting
seqread: (g=0): rw=read, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
fio-3.36
Starting 1 process
.... [ENTFERNT] da vermutlich unwichtig?
Run status group 0 (all jobs):
   READ: bw=4402MiB/s (4616MB/s), 4402MiB/s-4402MiB/s (4616MB/s-4616MB/s), io=10.0GiB (10.7GB), run=2326-2326msec



Code:
seqwrite: (g=0): rw=write, bs=(R) 1024KiB-1024KiB, (W) 1024KiB-1024KiB, (T) 1024KiB-1024KiB, ioengine=posixaio, iodepth=1
.....[ENTFERNT] da vermutlich unwichtig?
Run status group 0 (all jobs):
  WRITE: bw=4299MiB/s (4508MB/s), 4299MiB/s-4299MiB/s (4508MB/s-4508MB/s), io=10.0GiB (10.7GB), run=2382-2382msec
 
Zuletzt bearbeitet:
Welche Konfiguration an Platten hast du?

Ganz vergessen zu erwähnen: Vor dem Benchen Caching deaktivieren. Habe das irgendwo auf einer Website aufgeschnappt

If you want to do any read benchmarks you also need to disable caching for your VMs and temporarily forbid your ARC to cache (zfs set primarycache=metadata YourPoolName and later zfs set primarycache=any YourPoolName to restore it) or you will only benchmark your RAM and not your drives read performance.
 
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