ZFS Fragen

[snkb]

Hallo Zusammen,

Frage an die ZFS-Experten.

Es gibt ja den L2ARC, der ist ja die Erweiterung des ARC, der Wiederrum ist ja exklusiv im RAM.

Bedeutet ein L2ARC macht nur in Umgebungen Sinn, in denen es nicht ausreichend RAM für den ARC gibt.
Korrekt?

Nächste Frage:

LOG ist der Schreibcache und ist üblicherweise 16GB groß.
Ich habe zwei Enterprise SSD mit 480GB als Mirror im LOG laufen, ich konnte jedoch nicht definieren wie viel Platz davon er als LOG nehmen soll.
Es sieht so aus als ob er die gesamten 480GB nutzt.
Es handelt sich um Micron 5400 MAX.

Wie kann ich festlegen das er wirklich nur 16GB für LOG nutzt und den Rest fürs provisioning später, wenn der wearlevel mal steigt?


Letzte Frage:

Datenträger die ich als Cache hinzufüge sind reine READ Speicher, korrekt?
Muss ich für Metadaten explizit angeben das er mir eine SSD dafür nutzt?
Ich habe aktuell zwei WD SN850 als Cache laufen.

Wenn mir der Cache verreckt, ist mein ZFS dann defekt?

Nur bei LOG würde ich von einem Defekt ausgehen.
Dahinter sind aktuell 8 12TB HDD im RaidZ2.

Anmerkungen und Hinweise sind erwünscht.
Ich möchte lediglich nicht vergessen haben und maximale Performance bei hoher Sicherheit.

 

[news]

Zum Special Device, dass muss in Fachkreise die selbe Ausfallsicherheit, wie dein VDEV haben.

Das Special Device kann man nur einmalig hinzufügen, und ist dann daran gebunden.
Dort werden ab diesem Zeitpunkt alle Meta-Daten gespeichert.

Z.B. kann man mit einem Special Device als ZFS Mirror mit 2x SSD starten und dann noch eine Special Device als ZFS Mirror mit 3x SSD einfach erweitern.
Der benötigte Speicherbedarf ist i.A. nicht sehr groß. er muss nur IMMER Verfügbar sein!
Dort werden die verketteten Listen der belegen Speichers Blöcke (i.a. 128 kByte groß) verwaltet.
Wenn man dann auf eine Datei, die aus einige Blöcken bestehen kann, zugreifen will, wird diese verkettete Liste benötigt.
Aber merke es gibt auch noch die Checksummen für die Blöcke und viele andere Meta-Daten die da anfallen.
Einen merklichen unterschied kann man bei einem einfachen $ tree . oder $ du -sh . schon feststellen.

 

[news]

Hmm,

ich nutze smartmontools:
$ apt list smartmontools

mit smartclt -a <device> sehe ich die "Abnutzung", bzw. kann sie mir über den TBW Wert und die geschriebenen Blöcke, je nach SSD 512B oder 4096B, ausrechnen.

 

[Dunuin]

Bedeutet ein L2ARC macht nur in Umgebungen Sinn, in denen es nicht ausreichend RAM für den ARC gibt.
Korrekt?

Genau. Erst RAM maximal ausbauen, dann über L2ARC nachdenken, wenn man trotzdem noch mehr Readcache braucht. Außerdem benötigt der L2ARC RAM der dann für den ARC fehlt. Also dein Readcache wird größer aber dafür langsamer.

Wenn mir der Cache verreckt, ist mein ZFS dann defekt?

Beim L2ARC nicht da nur Cache wo die Daten ja weiterhin auf den Datenplatten liegt.
Beim SLOG können deine Writes weg sein, wenn die einzelne Disks beim Stromausfall (also zusammen mit dem RAM) ausfällt. Weil die Sync Writes werden parallel im ZIL auf den Disks sowie im RAM gehalten.

 

[Dunuin]

Muss ich für Metadaten explizit angeben das er mir eine SSD dafür nutzt?

Du kannst über "primarycache/secondarycache=none/metadata/all" sagen was im ARC und L2ARC gecacht werden soll.
Würde für Metadaten aver lieber gleich ein "special" Vdev nehmen. Das hilft dann auch wenn du Metadaten schreibst.

 

[snkb]

Du kannst über "primarycache/secondarycache=none/metadata/all" sagen was im ARC und L2ARC gecacht werden soll.
Würde für Metadaten aver lieber gleich ein "special" Vdev nehmen. Das hilft dann auch wenn du Metadaten schreibst.

Kannst du da nochmal ein wenig ausholen?

Ich habe aktuell 4 Micron 5400Max 480GB, zwei davon sind als LOG eingebunden. -> 2 davon noch nicht genutzt, weil ich überlege wie ich Sie nutzen will.
Dann habe ich 2 WD 850NVME 2TB als Cache.
Dann zwei Samsung QVO 2TB für Proxmox und für Iso-Images und so kram.

Und 8 12TB im RaidZ2 für die Daten.

Außerdem sind noch 11 4TB Platten zwar eingesteckt, aber aktuell noch ohne echten Einsatz.

Ich glaube nichts vergessen zu haben.
Sind 128GB Ram dahinter und ein 5950X als CPU.

 

[Dunuin]

Ich habe aktuell 4 Micron 5400Max 480GB, zwei davon sind als LOG eingebunden. -> 2 davon noch nicht genutzt, weil ich überlege wie ich Sie nutzen will.

Da hätte ich dann lieber 3 der Microns in ein Dreifach-Mirror als Special Device gepackt und eine kleine Optane als SLOG statt der zweiten L2ARC SSD.

Kannst du da nochmal ein wenig ausholen?

In addition, a dedicated cache device (typically a SSD) can be added to the pool, with zpool add POOLNAME cache DEVICENAME. The cache device is managed by the L2ARC, which scans entries that are next to be evicted and writes them to the cache device. The data stored in ARC and L2ARC can be controlled via the primarycache and secondarycache zfs properties respectively, which can be set on both zvols and datasets. Possible settings are all, none and metadata. It is possible to improve performance when a zvol or dataset hosts an application that does its own caching by caching only metadata. One example would be a virtual machine using ZFS. Another would be a database system which manages its own cache (Oracle for instance). PostgreSQL, by contrast, depends on the OS-level file cache for the majority of cache.

primarycache=all|none|metadata
Controls what is cached in the primary cache (ARC). If this property is set to all, then both user data and metadata is cached. If this property is set to none, then neither user data nor metadata is cached. If this property is set to metadata, then only metadata is cached. The default value is all.

secondarycache=all|none|metadata
Controls what is cached in the secondary cache (L2ARC). If this property is set to all, then both user data and metadata is cached. If this property is set to none, then neither user data nor metadata is cached. If this property is set to metadata, then only metadata is cached. The default value is all.

 

[snkb]

Das Specialdevice würde dann was tun in deinem Konzept?

Gibt es die Optane als 2,5" Device mit SAS oder Sata Port?

Ich habe 24 x. 3,5/2,5 SAS12G über 2 HBA9400-16i und 8 SATA-Ports und 2 NVME Ports über das Mainboard.

 

[Dunuin]

Das Specialdevice würde dann was tun in deinem Konzept?

Alles an neuen Metadaten von den lahmen HDDs auf die schnelleren SSDs auslagern, dass da weder Metadata Writes noch Reads überhaupt die HDDs treffen.

Gibt es die Optane als 2,5" Device mit SAS oder Sata Port?

Nein, das würde auch nicht viel Sinn machen sich die schnellsten SSDs überhaupt zu holen und die dann an ein langsames SATA/SAS zu hängen.

 

[snkb]

Wenn es ein 2230 optane Modul geben würde, könnte ich das wlan/bt Modul damit tauschen.

 

[snkb]

Wenn ich jetzt die beiden SN850 nvme als cache nutze, sind ja metadaten und alles drin. Quasi cache all.
Bedeutet zwei SATA SSDS machen gerade mein LOG Cache.
Zwei nvme den read cache.

bleiben zwei SATA SSDS übrig die ich noch einbauen könnte.

root@pve:~# zpool status
  pool: rpool
 state: ONLINE
  scan: scrub repaired 0B in 00:02:03 with 0 errors on Tue Nov  7 15:58:59 2023
config:

    NAME        STATE     READ WRITE CKSUM
    rpool       ONLINE       0     0     0
      sda       ONLINE       0     0     0  (non-allocating)
      sdb       ONLINE       0     0     0  (non-allocating)

errors: No known data errors

  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 00:15:08 with 0 errors on Tue Nov  7 16:12:05 2023
config:

    NAME        STATE     READ WRITE CKSUM
    tank        ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        sds     ONLINE       0     0     0  (non-allocating)
        sdt     ONLINE       0     0     0  (non-allocating)
        sdq     ONLINE       0     0     0  (non-allocating)
        sdr     ONLINE       0     0     0  (non-allocating)
        sdo     ONLINE       0     0     0  (non-allocating)
        sdp     ONLINE       0     0     0  (non-allocating)
        sdm     ONLINE       0     0     0  (non-allocating)
        sdn     ONLINE       0     0     0  (non-allocating)
    logs
      mirror-1  ONLINE       0     0     0
        sdv     ONLINE       0     0     0  (non-allocating)
        sdu     ONLINE       0     0     0  (non-allocating)
    cache
      nvme0n1   ONLINE       0     0     0  (non-allocating)
      nvme1n1   ONLINE       0     0     0  (non-allocating)

errors: No known data errors

 

[Dunuin]

Bedeutet zwei SATA SSDS machen gerade mein LOG Cache.

Ja, aber auch nur Sync Write Cache. Vmtl. hast du 99% Async Writes und da machen die SSDs dann Null.

Wenn ich jetzt die beiden SN850 nvme als cache nutze, sind ja metadaten und alles drin. Quasi cache all.

Ja, ist aber halt nur Read Cache. Hilft dir nicht beim schreiben von Metadata. Die gehen ungecacht direkt auf die HDDs.

bleiben zwei SATA SSDS übrig die ich noch einbauen könnte.

Für Special Devices bräuchtest du aber schon 3, weil das kein Cache ist. Sterben dir die weg ist alles auf den HDDs ebenfalls verloren. Das müsste dann schon ein Tripple-Mirror sein, damit du gleiche Redundanz wie für dein Raidz2 hast.

 

[snkb]

Sind die Metadaten aber nicht auch im nvme read cache schon drin?

 

[Dunuin]

Sind die Metadaten aber nicht auch im nvme read cache schon drin?

Ja, aber es ist eben ein Read Cache. Hilft also nur beim Lesen von Metadaten, Null wenn du die Schreiben musst.

Metadaten Schreiben -> RAM -> HDD

Metadaten Lesen <- ARC <- L2ARC <- HDD

Das Beste zum Boosten von HDD Performance sind immer noch SSDs als Special Devices + viel viel RAM. SLOG optional, falls du viele Sync Writes durch DBs und Co hast.

Hauptproblem bei HDDs ist ja die schreckliche IOPS Performance also echt übel bei vielen kleinen Random Reads/Writes. Und Metadaten sind halt genau das. Entlastet dann die HDDs enorm, wenn die ganzen IO durch die Metadaten nicht auf die HDDs gehen, da auf den HDDs erst garkeine Metadaten gespeichert werden.

 

[snkb]

Heißt mein LOG Cache macht so gar nicht so viel Sinn? Weil lesen ist ja meist wichtiger, korrekt?

Also sollte ich den LOG wieder auflösen und dann aus den SATA SSDs ein Metadata Cache machen.
Und für den Log überleg ich mir was anderes.

EDIT:

Also ich hab jetzt den LOG wieder rausgeschmissen. Erst mit detach auf ein device reduziert und dann mit remove entfernt.
Ging butterweich.

Jetzt würde ich gerne alle 4 SATA SSDs für Metadaten nutzen.

Wie geb ich dem das jetzt richtig mit?

ich würde jetzt sowas machen wie

zpool add tank cache secondarycache=metadata mirror sdX sdX sdX sdX

Bin mir nur mit dem secondarycache nicht sicher.

 

[Dunuin]

Heißt mein LOG Cache macht so gar nicht so viel Sinn? Weil lesen ist ja meist wichtiger, korrekt?

Lesen und Schreiben ist wichtig. Aber ja, falls du nicht viele Sync Writes in deiner Workload hast machen die LOG SSDs nicht viel Sinn. Da musst du halt deine Workload analysieren, ob dss lohnt oder nicht.
Und besser als Metadaten im L2ARC auf einer SSD sind immer noch Metadaten im ARC im RAM.

ich würde jetzt sowas machen wie

zpool add tank cache secondarycache=metadata mirror sdX sdX sdX sdX

Bin mir nur mit dem secondarycache nicht sicher.

Damit machst du wieder nur einen Read Cache, heißt Metadaten werden dann trotzdem auf die HDDs geschrieben und dann nur fürs lesen als extra Kopie auf den SSD vorgehalten.

Für Special Devices siehe:
https://forum.level1techs.com/t/zfs-metadata-special-device-z/159954

PS: Überleg das gut, weil Special Devices bekommst du nicht mehr weg.

 

[snkb]

root@pve:~# zdb -Lbbbs tank

Traversing all blocks ...

 804G completed (45573MB/s) estimated time remaining: 0hr 00min 00sec
    bp count:               4873095
    ganged count:                 0
    bp logical:        638681145344      avg: 131062
    bp physical:       637706996736      avg: 130862     compression:   1.00
    bp allocated:      897246412800      avg: 184122     compression:   0.71
    bp deduped:                   0    ref>1:      0   deduplication:   1.00
    bp cloned:                    0    count:      0
    Normal class:      897246253056     used:  2.80%
    Embedded log class              0     used:  0.00%

    additional, non-pointer bps of type 0:         40
     number of (compressed) bytes:  number of bps
             28:     14 **************
             29:      8 ********
             30:      0
             31:      0
             32:      1 *
             33:      0
             34:      0
             35:      0
             36:      0
             37:      0
             38:      0
             39:      0
             40:      4 ****
             41:      0
             42:      0
             43:      0
             44:      0
             45:      0
             46:      0
             47:      0
             48:      0
             49:      0
             50:      1 *
             51:      0
             52:      0
             53:      0
             54:      0
             55:      0
             56:      0
             57:      0
             58:      0
             59:      0
             60:      0
             61:      0
             62:      0
             63:      0
             64:      4 ****
             65:      2 **
             66:      1 *
             67:      0
             68:      0
             69:      0
             70:      0
             71:      0
             72:      0
             73:      0
             74:      0
             75:      1 *
             76:      0
             77:      2 **
             78:      0
             79:      0
             80:      0
             81:      0
             82:      0
             83:      0
             84:      0
             85:      0
             86:      0
             87:      0
             88:      0
             89:      0
             90:      1 *
             91:      0
             92:      0
             93:      0
             94:      0
             95:      0
             96:      0
             97:      0
             98:      0
             99:      0
            100:      0
            101:      0
            102:      0
            103:      0
            104:      0
            105:      0
            106:      0
            107:      0
            108:      0
            109:      0
            110:      0
            111:      1 *
    Dittoed blocks on same vdev: 9694

Blocks    LSIZE    PSIZE    ASIZE      avg     comp    %Total    Type
     -        -        -        -        -        -         -    unallocated
     2      32K    4.50K      72K      36K     7.11      0.00    object directory
     1     128K    1.50K      36K      36K    85.33      0.00        L1 object array
     9    4.50K    4.50K     324K      36K     1.00      0.00        L0 object array
    10     132K       6K     360K      36K    22.08      0.00    object array
     2      32K       2K      36K      18K    16.00      0.00    packed nvlist
     -        -        -        -        -        -         -    packed nvlist size
     -        -        -        -        -        -         -    bpobj
     -        -        -        -        -        -         -    bpobj header
     -        -        -        -        -        -         -    SPA space map header
   142    2.22M     242K    4.99M      36K     9.37      0.00        L1 SPA space map
   754    94.2M    27.9M     130M     177K     3.38      0.02        L0 SPA space map
   896    96.5M    28.1M     135M     155K     3.43      0.02    SPA space map
     1      36K      36K      60K      60K     1.00      0.00    ZIL intent log
     1     128K       1K      24K      24K    128.00      0.00        L5 DMU dnode
     1     128K       1K      24K      24K    128.00      0.00        L4 DMU dnode
     1     128K       1K      24K      24K    128.00      0.00        L3 DMU dnode
     1     128K       1K      24K      24K    128.00      0.00        L2 DMU dnode
     4     512K      28K     240K      60K    18.29      0.00        L1 DMU dnode
   175    2.73M     313K    6.22M    36.4K     8.95      0.00        L0 DMU dnode
   183    3.73M     345K    6.55M    36.7K    11.08      0.00    DMU dnode
     2       8K       1K      60K      30K     8.00      0.00    DMU objset
     -        -        -        -        -        -         -    DSL directory
     -        -        -        -        -        -         -    DSL directory child map
     -        -        -        -        -        -         -    DSL dataset snap map
     -        -        -        -        -        -         -    DSL props
     -        -        -        -        -        -         -    DSL dataset
     -        -        -        -        -        -         -    ZFS znode
     -        -        -        -        -        -         -    ZFS V0 ACL
     1     128K       2K      24K      24K    64.00      0.00        L3 ZFS plain file
    20    2.50M     476K    1.48M    75.6K     5.37      0.00        L2 ZFS plain file
 8.36K    1.05G     216M     649M    77.6K     4.96      0.08        L1 ZFS plain file
 4.64M     594G     594G     835G     180K     1.00     99.91        L0 ZFS plain file
 4.65M     595G     594G     835G     180K     1.00     99.98    ZFS plain file
    11    5.50K       1K      48K    4.36K     5.50      0.00    ZFS directory
     1      512      512      24K      24K     1.00      0.00    ZFS master node
     -        -        -        -        -        -         -    ZFS delete queue
     -        -        -        -        -        -         -    zvol object
     -        -        -        -        -        -         -    zvol prop
     -        -        -        -        -        -         -    other uint8[]
     -        -        -        -        -        -         -    other uint64[]
     -        -        -        -        -        -         -    other ZAP
     -        -        -        -        -        -         -    persistent error log
     1     128K    4.50K      72K      72K    28.44      0.00    SPA history
     -        -        -        -        -        -         -    SPA history offsets
     -        -        -        -        -        -         -    Pool properties
     -        -        -        -        -        -         -    DSL permissions
     -        -        -        -        -        -         -    ZFS ACL
     -        -        -        -        -        -         -    ZFS SYSACL
     -        -        -        -        -        -         -    FUID table
     -        -        -        -        -        -         -    FUID table size
     -        -        -        -        -        -         -    DSL dataset next clones
     -        -        -        -        -        -         -    scan work queue
     -        -        -        -        -        -         -    ZFS user/group/project used
     -        -        -        -        -        -         -    ZFS user/group/project quota
     -        -        -        -        -        -         -    snapshot refcount tags
     -        -        -        -        -        -         -    DDT ZAP algorithm
     -        -        -        -        -        -         -    DDT statistics
     -        -        -        -        -        -         -    System attributes
     -        -        -        -        -        -         -    SA master node
     1    1.50K    1.50K      24K      24K     1.00      0.00    SA attr registration
     2      32K       8K      48K      24K     4.00      0.00    SA attr layouts
     -        -        -        -        -        -         -    scan translations
     -        -        -        -        -        -         -    deduplicated block
     -        -        -        -        -        -         -    DSL deadlist map
     -        -        -        -        -        -         -    DSL deadlist map hdr
     -        -        -        -        -        -         -    DSL dir clones
     -        -        -        -        -        -         -    bpobj subobj
     -        -        -        -        -        -         -    deferred free
     -        -        -        -        -        -         -    dedup ditto
    18     182K    18.5K     324K      18K     9.81      0.00    other
     1     128K       1K      24K      24K    128.00      0.00        L5 Total
     1     128K       1K      24K      24K    128.00      0.00        L4 Total
     2     256K       3K      48K      24K    85.33      0.00        L3 Total
    21    2.62M     478K    1.50M    73.1K     5.63      0.00        L2 Total
 8.51K    1.05G     216M     654M    76.9K     4.97      0.08        L1 Total
 4.64M     594G     594G     835G     180K     1.00     99.92        L0 Total
 4.65M     595G     594G     836G     180K     1.00    100.00    Total
 9.47K    1.15G     245M     793M    83.8K     4.79      0.09    Metadata Total

Block Size Histogram

  block   psize                lsize                asize
   size   Count   Size   Cum.  Count   Size   Cum.  Count   Size   Cum.
    512:    205   102K   102K     12     6K     6K      0      0      0
     1K:     44    55K   158K      4  5.50K  11.5K      0      0      0
     2K:     11    24K   182K      1     2K  13.5K      0      0      0
     4K:  3.70K  14.8M  15.0M      2     8K  21.5K      0      0      0
     8K:    195  1.91M  16.9M      1  10.5K    32K      0      0      0
    16K:    481  10.6M  27.5M    325  5.08M  5.11M  3.49K  83.7M  83.7M
    32K:  4.64K   199M   227M      1    36K  5.15M    570  21.4M   105M
    64K:    224  18.2M   245M      0      0  5.15M  5.05K   581M   686M
   128K:  4.64M   594G   594G  4.65M   595G   595G  4.64M   835G   836G
   256K:      0      0   594G      0      0   595G    226  78.2M   836G
   512K:      0      0   594G      0      0   595G      0      0   836G
     1M:      0      0   594G      0      0   595G      0      0   836G
     2M:      0      0   594G      0      0   595G      0      0   836G
     4M:      0      0   594G      0      0   595G      0      0   836G
     8M:      0      0   594G      0      0   595G      0      0   836G
    16M:      0      0   594G      0      0   595G      0      0   836G

                            capacity   operations   bandwidth  ---- errors ----
description                used avail  read write  read write  read write cksum
tank                       836G 28.3T 1.48K     0 12.2M     0     0     0     0
  raidz2                   836G 28.3T 1.48K     0 12.2M     0     0     0     0
    /dev/sds1                           189     0 1.50M     0     0     0     0
    /dev/sdt1                           187     0 1.51M     0     0     0     0
    /dev/sdq1                           186     0 1.51M     0     0     0     0
    /dev/sdr1                           188     0 1.52M     0     0     0     0
    /dev/sdo1                           190     0 1.56M     0     0     0     0
    /dev/sdp1                           190     0 1.55M     0     0     0     0
    /dev/sdm1                           192     0 1.50M     0     0     0     0
    /dev/sdn1                           192     0 1.50M     0     0     0     0
  hole                                    0     0     0     0     0     0     0

Unheimlich viel Info, ich versuch mal zu interpretieren.

Es laufen ein paar wenige Datenbanken, aber das ist absolut kein Highperformance Thema. Ich möchte nur mit den Mitteln die ich eben hier habe, das maximale und sinnvollste dabei herausholen.

Das ich die Metadaten jetzt nicht wieder zurück auf die hdds ziehen kann verunsichert mich ein stückweit hier einfach weiter zu machen.
Den Vorteil möchte ich schon gerne haben.

 

[snkb]

Kann ich die hier nehmen?

https://geizhals.de/samsung-ssd-pm1735-1-6tb-mzplj1t6hbjr-00007-a2213016.html
Hat genausoviel MTBF wie die Optane 900, hat aber 1,6TB statt 480Gb und die I/O sind doppelt so hoch.

Ich kann leider nicht wirklich einschätzen wie heftig das mit dem LOG nachher ist, also die Belastung.

 

[JensF]

Wir haben zwei von den Teilen seit Juni als Main Storage ZFS-Spiegel am laufen. Sind OEM-Artikel, also keine Extra-Herstellergarantie. Das sei mal noch erwähnt und sie sind tatsächlich zur Zeit knappe 20% teurer als im Juni...
Laufen super schnell und problemlos in unseren alten Dell R720. Ausgeliefert werden die mit 512b Sektorgröße. Performanter sind die wenn man sie vorher auf 4k low level formatiert.

 

[Dunuin]

Hat genausoviel MTBF wie die Optane 900, hat aber 1,6TB statt 480Gb und die I/O sind doppelt so hoch.

LOG muss eh nicht mehr Kapazität haben als was dein Pool in 5 Sekunden schreiben kann. Da würden es auch schon 16 oder 32GB Kapazität tun. Alles dadrüber ist höchstens nützlich als Reserve-Zellen für mehr Haltbarkeit.
Und Optane ist halt SLC statt TLC NAND und hat daher nicht nur super Haltbarkeit sonder auch die beste Latenz. Musst du mal nach Benchmarks gucken, aber würde mich wundern, wenn da die Samsung bei Sync Writes mithalten kann.