Ein paar dedup-Erfahrungen möchte ich hier mitteilen…
Dedup ist ein feature im zfs, welches Daten auf Blocklevel-Ebene dedupliziert. Wird also eine Datei zweimal in zfs-Volume kopiert, wird sie nur einmal ihren Speicherplatz beanspruchen. Aktuell habe ich in meinem Serverchen 2 zpools, einen Raid1-basierten (2x4TB) mit aktiviertem dedup und einen mit Raid5 (4x6TB).
Da dedup sehr viel memory für die Verwaltung benötigt (die sogenannten ddt-tables), wurde auf einer nvme für jeden zpool neben einem 1GB großes ZIL (zfs intent log; Pufferung von metadaten im synchronen IO) ein 29GB großer cache für den L2ARC (hier werden die ddt-Tabellen verwaltet).
[maulwurf@alpina ~]$ zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
WD14TB 12.7T 10.5T 2.24T - - 12% 82% 1.11x ONLINE -
archiv 21.8T 16.8T 5.01T - - 24% 77% 1.14x ONLINE -
backup3G 2.72T 497G 2.23T - - 0% 17% 1.00x ONLINE -
raid1 3.62T 3.45T 180G - - 47% 95% 1.17x ONLINE -
root 382G 257G 125G - - 40% 67% 1.03x ONLINE -Im zpool raid1 liegt ein zfs Volume „backup“, in welches regelmäßig eine WordPress-Seite gesichert wird, sowie eines für Musik-Dateien…
Im zpool archiv befindet sich ein Time Machine-Volume (zusätzlich ein Archiv für große files), auf welches 2 High-Sierra Systeme sowie 2 Big Sur Systeme (macOS) Installationen gesichert werden.
Die Idee ist einfach: Da fallen einige „Dubletten“ an, welche hervorragend dedupliziert werden können… leider gibt aber die zpool-Statistik nur Infos aus, welche den pool als Ganzes betreffen. Im Zuge einer Optimierung der zpool device Verwaltung, muss der zpool archiv noch neu eingerichtet werden.
Für die Reorganisierung wurde eine externe Backup-Festplatte mit 14TB angeschafft, das Kopieren des zfs mit den Backupdaten (9TB/~27,000 files) via zfs send/receive geschah recht zügig mit rund 150MB/s. Danach erfolgte das gleiche Verfahren mit dem Time Machine-Volume (3.75TB/~190,000 files), welches eine Woche brauchte, anfänglich mit rund 30MB/s, letztlich bei knapp 7.6MB/s im Schnitt landete für transferierte 4.14TB (Ausgabe vom Transfer mit -v Option). Was mich verwundert, warum ~400GB mehr transferiert wurden, als vom Urpsrungsvolume angegeben wurden – die Verwunderung wird dann vom Ärger verdrängt, wenn man feststellen darf, daß beim Ziel-zpool keine compression aktiviert war…
Nunja, die Backup-Platte hat keinen L2ARC-cache, was ich als mögliche Ursache für den langsamen Transfer sehe (hat sich beim Wiederherstellen mehr oder minder bestätigt)…
Der Restore war wesentlich erfreulicher, hat er das DatenVolume beim Backup noch um rund 400GB erhöht, behielt der Prozess es diesmal bei und die Datentransferrate lag bei beachtlichen 63MB/s für das dedup-Volume.
Jetzt kommt die Frage, hat der L2ARC cache ausgereicht?, hierzu ist folgende Ausgabe als Ergebnis interessant, beim monitoring hat man die Nutzung prima verfolgen können:
maulwurf@alpina /raid5]# zpool iostat -v raid5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
raid5 4.93T 16.9T 177 2.77K 5.32M 72.4M
raidz1 4.93T 16.9T 177 2.77K 5.32M 72.4M
ada0p1 - - 46 532 1.30M 26.3M
ada1p1 - - 43 531 1.28M 25.7M
ada2p1 - - 43 531 1.44M 26.3M
ada4p1 - - 44 532 1.42M 25.6M
nvd0p6 128K 960M 0 0 1 24.9K
cache - - - - - -
nvd0p7 19.5G 9.52G 504 41 1.20M 3.09M
---------- ----- ----- ----- ----- ----- -----von den zur Verfügung stehenden 29GB (L2ARC cache) werden in etwa 2/3 genutzt, für dieses Volume also ausreichend (?)- der ZIL wird fast gar nicht verwendet (mehr oder minder logisch)…
Jetzt kopier ich noch das rund 300GB große Backup-Volume vom raid1 pool in den raid5 –
11:08:51 303G raid1/backup@backup
received 303GB stream in 5217 seconds (59.5MB/sec)
[root@alpina /raid5]# zpool iostat -v raid5
capacity operations bandwidth
pool alloc free read write read write
---------- ----- ----- ----- ----- ----- -----
raid5 5.31T 16.5T 176 2.76K 5.02M 71.2M
raidz1 5.31T 16.5T 176 2.76K 5.02M 71.2M
ada0p1 - - 46 532 1.22M 25.9M
ada1p1 - - 43 531 1.21M 25.2M
ada2p1 - - 43 531 1.35M 25.9M
ada4p1 - - 44 532 1.33M 25.2M
nvd0p6 256K 960M 0 0 1 48.2K
cache - - - - - -
nvd0p7 18.6G 10.4G 515 41 1.22M 3.05M
---------- ----- ----- ----- ----- ----- -----Man sieht hier sogar noch eine Abnahme der cache (L2ARC) Nutzung.
Interessant zur Berechnung benötigter Ressourcen ist der Artikel „dedup or not dedup„, in welchem auch beschrieben wird, wieviel voraussichtlich an ARC-Speicher benötigt wird, in meinem hier betrachteten Falle (vor Umstellung):
[root@alpina ~]# zdb -b raid1
Traversing all blocks to verify nothing leaked ...
loading concrete vdev 1, metaslab 14 of 15 .....
3.87T completed (3323MB/s) estimated time remaining: 277098hr 45min 20sec
No leaks (block sum matches space maps exactly)
bp count: 35419785
ganged count: 0
bp logical: 4477203583488 avg: 126404
bp physical: 4252535812096 avg: 120061 compression: 1.05
bp allocated: 4270123028480 avg: 120557 compression: 1.05
bp deduped: 463651233792 ref>1: 1992696 deduplication: 1.11
Normal class: 3806470971392 used: 95.50%
additional, non-pointer bps of type 0: 132437
Dittoed blocks on same vdev: 1466474
[root@alpina ~]# zdb -b archiv
Traversing all blocks to verify nothing leaked ...
loading concrete vdev 1, metaslab 14 of 15 .....
17.5T completed (14304MB/s) estimated time remaining: 341616hr 56min 05sec
No leaks (block sum matches space maps exactly)
bp count: 111509014
ganged count: 0
bp logical: 14381112954368 avg: 128968
bp physical: 13922814364672 avg: 124858 compression: 1.03
bp allocated: 19192156401664 avg: 172113 compression: 0.75
bp deduped: 710846349312 ref>1: 3355041 deduplication: 1.04
Normal class: 18481309908992 used: 77.06%
additional, non-pointer bps of type 0: 197376
Dittoed blocks on same vdev: 1664068
Rechnet man den Speicherbedarf für den pool raid1 aus (bp count: 35419785 x 320bytes), kommt man auf ~10GB; bei knapp 32GB Ram und der Kausalität, daß für dedup nur ca 25% vom ARC genutzt werden, ist der Hauptspeicher definitiv zu klein.
Der pool archiv mit seinem Time Machine-Volume würde um die 33GB beanspruchen wollen.
Somit habe ich mittlerweile den Entschluss gefasst, auf dem RAID1 keine Deduplikation mehr zu verwenden und das backup-zfs auf das archiv umzuziehen, sowie den L2ARC für archiv auf 96GB zu erweitern.
Das „Ende“ aktuell vom Lied:
[maulwurf@alpina ~]# zpool list
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup3G 2.72T 497G 2.23T - - 0% 17% 1.00x ONLINE -
raid1 3.62T 3.19T 443G - - 41% 88% 1.19x ONLINE -
raid5 21.8T 17.2T 4.60T - - 6% 78% 1.16x ONLINE -
root 382G 259G 123G - - 41% 67% 1.03x ONLINE -References:
zfs dedup or not dedup
zfs, arc overview
memory requirements dedup/L2ARC