[Sammelthread] ZFS Stammtisch

[gea]

Da ich die Daten aber so schnell nicht neu schreibe würde ich gerne das Rebalacing durchführen, bevor ich weitere Daten hinzufüge. Damit dürfte auch die Fragmentierung niedriger ausfallen. Wenn ich nun neue draufkopiere dürfte die Fragmentierung deutlich(er) steigen.

Die Fragmentierung ist abhängig von Füllrate und geringer bei einer größeren Recsize, Vor allem in einem HD Pool mit Raid-Z würde ich daher tendenziell immer zu einer größeren Recsize z.B. 1M neigen, Negative Effekte auf Resourcenbedarf hat das wegen der dynamischen Recsizegröße bei kleinen Dateien nur bei mittelgroßen Dateien 1-2M oder bei Anwendungen wie VMs oder Datenbanken die kleine Blöcke verarbeiten und man dann unnötigerweise immer große Blöcke lesen muss. Dann ist aber ein HD Pool mit Raid-Z eh langsam.

Da in einem unbalanced Pool neue Datenblöcke vor allem auf dem leeren vdev landen, sehe ich eine gesteigerte Fragmentierung ohne manuelles Rebalancing eher als nicht gegeben..

Außerdem dürfe die Performance danach steigen.

Eine bessere sequentiuelle Leseperformance beim Zugriff als Altdaten ergibt sich in der Tat.

Macht man das Rebalancing über Replikation, so braucht man jeweils die Kapazität des replizierten ZFS Dateisystems zusätzlich. Man muss ja nicht rekursiv alles auf einmal machen.

 

[bbott]

Bitte erstmal einen zpool list -v und einen zpool get autoexpand liefern

Spoiler: zpool list -v und zpool get autoexpand

root@truenas[~]# zpool list -v
NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
boot-pool 222G 10.2G 212G - 16G 0% 4% 1.00x ONLINE -
nvme0n1p2 222G 10.2G 212G - 16G 0% 4.60% - ONLINE
pool_86 86T 68T 18.5T - 16G 2% 78% 1.00x ONLINE /mnt
raidz3-0 86T 68T 18.5T - 16G 2% 78.6% - ONLINE
sdb2 7.2T - - - - - - - ONLINE
sdj2 7.2T - - - - - - - ONLINE
sdf2 7.2T - - - - - - - ONLINE
sdl2 7.2T - - - - - - - ONLINE
sde2 7.2T - - - - - - - ONLINE
sdi2 7.2T - - - - - - - ONLINE
sdg2 7.2T - - - - - - - ONLINE
sdc2 7.2T - - - - - - - ONLINE
sdm2 7.2T - - - - - - - ONLINE
ce9104f7-2ef1-43c2-bedd-f86b25cf830c 7.2T - - - - - - - ONLINE
10f70fc0-7aba-434a-9d2a-796d59820131 7.2T - - - - - - - ONLINE
1100ac92-68d7-487b-b2bd-efb4c0a3f2f7 7.2T - - - - - - - ONLINE

root@truenas[~]# zpool get autoexpand
NAME PROPERTY VALUE SOURCE
boot-pool autoexpand off default
pool_86 autoexpand on local

Die Fragmentierung ist abhängig von Füllrate und geringer bei einer größeren Recsize, Vor allem in einem HD Pool mit Raid-Z würde ich daher tendenziell immer zu einer größeren Recsize z.B. 1M neigen, Negative Effekte auf Resourcenbedarf hat das wegen der dynamischen Recsizegröße bei kleinen Dateien nur bei mittelgroßen Dateien 1-2M oder bei Anwendungen wie VMs oder Datenbanken die kleine Blöcke verarbeiten und man dann unnötigerweise immer große Blöcke lesen muss. Dann ist aber ein HD Pool mit Raid-Z eh langsam.

Die Record Size ist aktuell 128k, da wäre was mit 1-4M besser. Würde das bei einem Rebalancing ebenfalls geändert (wenn man die Config anpasst)?

Da in einem unbalanced Pool neue Datenblöcke vor allem auf dem leeren vdev landen, sehe ich eine gesteigerte Fragmentierung ohne manuelles Rebalancing eher als nicht gegeben..

hört sich gut an

Eine bessere sequentiuelle Leseperformance beim Zugriff als Altdaten ergibt sich in der Tat.

Macht man das Rebalancing über Replikation, so braucht man jeweils die Kapazität des replizierten ZFS Dateisystems zusätzlich. Man muss ja nicht rekursiv alles auf einmal machen.

Er hat schon mal die doppelte Kapazität schon zur Verfügung? Das habe ich auch schon überlegt auf einen kleineren (USB) Pool kopieren und dann wieder zurück, das aber auch sehr lange dauert und einiges an manueller Arbeit mit potenziellen Fehlern.

 

[gea]

Die Record Size ist aktuell 128k, da wäre was mit 1-4M besser. Würde das bei einem Rebalancing ebenfalls geändert (wenn man die Config anpasst)?

Die Recsize Einstellung verändert keine Daten auf dem Pool sondern wirkt nur für neu zu schreibende Datenblöcke

Er hat schon mal die doppelte Kapazität schon zur Verfügung? Das habe ich auch schon überlegt auf einen kleineren (USB) Pool kopieren und dann wieder zurück, das aber auch sehr lange dauert und einiges an manueller Arbeit mit potenziellen Fehlern.

Der schnellere Weg wäre Replikation z.B. von tank/data -> tank/data.neu
Bei Erfolg tank/data löschen und tank/data.neu umbenennen in data

Mit dem USB Pool müsste man ja alles zweimal umkopieren.

Für ausgewählte Ordner könnte man diesen auch umbenennen, leeren Ordner mit dem Namen neu anlegen und Daten reinkopieren (cp oder midnight commander)

 

[bbott]

Die Recsize Einstellung verändert keine Daten auf dem Pool sondern wirkt nur für neu zu schreibende Datenblöcke

So hatte ich es verstanden

Der schnellere Weg wäre Replikation z.B. von tank/data -> tank/data.neu
Bei Erfolg tank/data löschen und tank/data.neu umbenennen in data

Das benötigt aber den doppelten Speicherplatz., würde also nur gehen wenn <50% belegt wären? Oder geht das auch mit "verschieben"?

zfs send -R pool_86/DataSet@rebalancing | zfs receive pool_86/DataSet_neu

Mit dem USB Pool müsste man ja alles zweimal umkopieren.

Das ist bis jetzt (leider) die aktuell beste Option

Für ausgewählte Ordner könnte man diesen auch umbenennen, leeren Ordner mit dem Namen neu anlegen und Daten reinkopieren (cp oder midnight commander)

Ich habe es grob verstanden, aber das klingt mir (ähnlich) nach dem Skript nur manuell

 

[bbott]

Wie sähe es eigentlich aus, wenn man die Daten des ZFS verschlüsselt bzw. neu verschlüsselt, dann müssten die Daten doch auch alle neu geschrieben werden?

 

[gea]

Verschieben innerhalb eines ZFS Dateisystems ändert Daten nicht, nur den Verweis darauf. Verschieben zwischen ZFS Dateisystemen macht copy + delete.

ZFS Verschlüssellung geht nicht "in place" sondern man legt ein verschlüsseltes ZFS Dateisystem an und kopiert die Daten da rein um sie zu verschlüsseln.