[Sammelthread] ZFS Stammtisch

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.
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Bitte erstmal einen zpool list -v und einen zpool get autoexpand liefern
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.
 
Zuletzt bearbeitet:
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)
 
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"?
Code:
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 o_O

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 :unsure:
 
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?
 
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.
 
Interessantes Video - OpenZFS Horror Stories. Sehr aufschlussreich, mal zu hören was in produktiven Umgebungen in der Praxis schiefgeht / gegangen ist:
 
Interessantes Video - OpenZFS Horror Stories
Hat schon was, allerdings impliziert der Titel ja schon sehr stark dass es um ZFS Probleme geht, aber ich muss sagen, das waren doch alles eher Fehler die alles andere betreffen. Hardwarekonfigurationen, Netzwerkkonfig, Softwarekonfigs... Die nicht gegenprüfung von Shell Befehlen.... mit ZFS per se hat das ja nun wirklich nichts zu tun, außer dass diese Kunden ZFS als Dateisystem nutzen.


Oder habe ich mich da irgendwo verhört ?
 
Oder habe ich mich da irgendwo verhört ?
Nee, ich hatte auch anderes erwartet (clickbait halt), aber hier ist es dennoch mal interessant zu hören, wie ZFS im Enterprise Bereich eingesetzt wird und das man mit einem kleinen User-Fehler ziemlichen Schaden anrichten kann.
Besonders interessant fand ich die Erklärungen, wie die Daten dann (teilweise) auch wieder hergestellt wurden, darüber hätte ich gern mehr erfahren, aber das ist vermutlich ein Betriebsgeheimis.
 
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