[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.

 

[sandreas]

Interessantes Video - OpenZFS Horror Stories. Sehr aufschlussreich, mal zu hören was in produktiven Umgebungen in der Praxis schiefgeht / gegangen ist:

Datenschutzhinweis für Youtube

An dieser Stelle möchten wir Ihnen ein Youtube-Video zeigen. Ihre Daten zu schützen, liegt uns aber am Herzen: Youtube setzt durch das Einbinden und Abspielen Cookies auf ihrem Rechner, mit welchen sie eventuell getracked werden können. Wenn Sie dies zulassen möchten, klicken Sie einfach auf den Play-Button. Das Video wird anschließend geladen und danach abgespielt.

Youtube Videos ab jetzt direkt anzeigen

Video anzeigen

 

[Luckysh0t]

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 ?

 

[sandreas]

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.

 

[gea]

Würde man nach Horrostories mit ext4+LVM oder Windows + Storage Spaces oder Hardwareraid mit irgendwas fragen, so kämen sicher noch viel mehr Berichte. Eine größere Storageinstallation ist mit ZFS im Vergleich einfach deutlich übersichtlicher und besser zu verstehen und zu managen. Gegen Probleme zwischen den Ohren eines Nutzers, wegen Stress, fehlender Erfahrung oder suboptimalen Setups hilft das natürlich auch nicht immer.

 

[Luckysh0t]

@gea
Ist dein Windowsnutzer ein Admin oder Standardnutzer? Mein eigentliches Konto ist ein Standardnutzer, das Adminkonto ist dediziert, mit entsprechendem Kennwort, leider scheint so die "übergabe" der Adminrechte von der Bat an xampp nicht zu funktionieren, da es mangels Rechte nicht starten kann. Wollte gerade mal mit meinem PVE napp-it testen.

 

[gea]

Um napp-it als normaler Nutzer mit Adminrechten zu starten, muss der in der Administratorgruppe sein.

Alternativ
Das Startscript als geplanten Task beim Hochfahren mit Adminrechten starten.

 

[AliManali]

Hi

Gibt es für die LSI 2008i irgendwie eine Standardfirmware, die bei allen OEM Karten geht? Kumpel hat irgend was gebrandetes, wo wir den genauen Typ nicht kennen. Bei meinem Perc hatte ich die DELL Firmware geflasht.

Danke

 

[Luckysh0t]

Moin,

ich bin am Überlegen von Solaris zu OmniOS zu migrieren, die primäre Frage, die ich mir stelle, ist, ob und wie ich da meine Snapshots (verschlüsselte DS) mit umziehen kann. Hat da jemand eine Idee? Ist beides eigenständige Hardware.

 

[gea]

Solaris mit native ZFS ist inkompatibel mit OpenZFS. Zum Umzug der Daten muss man kopieren z.B. via rsync oder SMB. Die Snapshots kann man nicht mit umziehen außer durch weitere Kopien.

 

[Luckysh0t]

Das weiß ich. Ich hatte mir gedanklich das so zurechtgelegt, dass ich in OmniOS eine kompatible zpool version nehme und dann so mein Glück mit HDD umbauen/kopieren etc versuche. Allerdings wären das recht viele Schritte, ohne zu wissen ob es klappt. Daher mache ich nun eine klassische Kopie übers Netzwerk. Bei den Snaps muss ich dann mal schauen ob sich wo was wie viel geändert hat, ein Großteil ist statisch udn fällt nicht ins Gewicht.

 

[gea]

Die einzig kompatible ZFS Variante ist 28v5. Solaris wird eine viel höhere Variante v6 nutzen. Man bekommt da nur den Datenstand per copy migriert. Zfs send mit snaps ist keine Option. Händisch ginge das aber schon, ist aber etwas aufwändiger (ältesten snap kopieren, auf Ziel snap erstellen, mit neuerem Snap syncronisieren usw). Wenn man die alten Platten nicht braucht und die Snaps eventuell benötigt, kann man auch den Solaris Pool als offline Backup aufheben zusammen mit der Bootplatte.

Sofern man ausreichend Platten hat, geht die Migration problemfrei entweder mit rsync daemon mode oder robocopy sync via Windows und SMB (jeweils log machen und zumindest Anzahl Dateien überprüfen). Robocopy hat den Vorteil dass es Windows ntfs artige ACL aus Solaris mitnehmen kann.

 

[Luckysh0t]

Wenn man die alten Platten nicht braucht und die Snaps eventuell benötigt, kann man auch den Solaris Pool als offline Backup aufheben zusammen mit der Bootplatte.

Ja, das hatte ich vor. Bzw wenn ich dann die Daten komplett migriert habe und abgeglichen, denn dann auch auf OmniOS gewechselt und dann per zfs send die Daten nochmal rüber.
Auf der anderen Seite hätte ich so eine ZFS Version die was zumindest durch neue Funktionen verursachte Bugs defintiv verschont bleibt - was ja auch nicht das falscheste ist.
Wirklich etwas "verlieren" tue ich ja nicht, wenn das System bei Solaris bleibt.

 

[Luckysh0t]

Ich habe bei meiner OmniOS/napp-it Neuinstallation ein interessantes/seltsames Verhalten festgestellt.
Ich habe mehrere Datasets erstellt, diese werden im Standard mit "every@=full" angelegt, außer ich gebe ihm den Namen Erotik, wo ich entsprechendes Aktmaterial dediziert speichere, dann wird "special" ausgewählt. Ich habe das Dataset nun mehrmals gelöscht und neu angelegt habe - mit demselben Ergebnis. Schreibe ich hingegen Er0tik, oder z. B. porn (um weitläufig im selben Thema zu sein) wird wiederum "every@=full" gesetzt.

Auf meinem alten Solarisserver hab eich "every@=full", kann mich aber nicht erinnern, ob ich das selbst ändern musste, da der Umzug noch läuft, kann ich es da aktuell nicht spontan testen.

Habt ihr auch solche Erfahrungen schon gemacht, ggf mit anderen DS Namen ?


Was mir jetzt noch auffällt, wenn ich das DS mit dem gleichen Namen/Kennwort nach dem löschen erneut erstelle, sind die ursprünglich schon kopierten Daten immer noch enthalten... ist das so "gewollt"...? Aber Zugriffsrechte etc, kann ich auf napp-it nicht ändern... öhm ja.. da ist gewaltig was schief würde ich sagen..

Grüße

Lucky

 

[gea]

Ich vermute dass bei der Migration per Copy die Daten die ursprünglich in ZFS Dateisystemen waren, jetzt in normalen Dateiordnern gelandet sind. Ein Copy kann ja nicht zwischen beidem unterscheiden oder ZFS Dateisysteme anlegen.

Wenn man jetzt den Pool exportiert z.B. tank, so verschwinden der Ordner /tank mit Inhalt. Ist /tank immer noch da, so ist /tank kein ZFS Pool sondern ein simpler Ordner im Dateisystem.

Im Zweifel nach Pool Export die Ordner löschen oder umbenennen, dann zuerst die ursprüngliche oder gewünschte ZFS Struktur (Pool + ZFS Dateisysteme) anlegen und nochmal kopieren.

 

[Luckysh0t]

Ja, so ist es wohl gewesen, hab mal alles neu gemacht und getestet, jetzt passt es.

Was ich allerdings interessant finde, ist das Unterschiedliche verhalten vom Solaris zu OmniOS Server. Wenn ich auf dem OmniOS in ein cifs share gehe, mit vielen Unterordnern etc., habe ich im Windows Explorer kurz den Ladekreis, auf dem Solaris System nicht.

Kopieren von einer 18,5 GB VMDK zum W10 PC
Solaris: 97-115 MB/s
OmniOS: 85-93 MB/s

Kopieren von einer 18,5 GB VMDK vom W10 PC
Solaris: 106-118 MB/s
OmniOS: 80-95 MB/s

Keine Ahnung wie die Differenz wäre, wenn ich nun mehr als Gbit LAN hätte - und schnelleres Storage als ein mirror HDD Pool, oder mit TrueNAS.
Kernelintegration vom CIFS bringt halt was

 

[gea]

Ja, so ist es wohl gewesen, hab mal alles neu gemacht und getestet, jetzt passt es.

Was ich allerdings interessant finde, ist das Unterschiedliche verhalten vom Solaris zu OmniOS Server. Wenn ich auf dem OmniOS in ein cifs share gehe, mit vielen Unterordnern etc., habe ich im Windows Explorer kurz den Ladekreis, auf dem Solaris System nicht.

Der Unterschied wird eventuell daher rühren dass Illumos einen Wechsel in nested ZFS Dateisysteme via SMB unterstützt, Solaris nicht. Das bedeutet mehr Rechenarbeit.

Kopieren von einer 18,5 GB VMDK zum W10 PC
Solaris: 97-115 MB/s
OmniOS: 85-93 MB/s

Kopieren von einer 18,5 GB VMDK vom W10 PC
Solaris: 106-118 MB/s
OmniOS: 80-95 MB/s

Solaris war schon immer der schnellste SMB Server
(bis auf SMB Direct mit Windows Server)

Keine Ahnung wie die Differenz wäre, wenn ich nun mehr als Gbit LAN hätte - und schnelleres Storage als ein mirror HDD Pool, oder mit TrueNAS.

Mit hoher CPU Last kommt man durchaus in Bereiche von mehreren GB/s.
Lediglich SMB Direkt geht auf 3-10GB/s mit geringster Latenz und CPU Last.

Kernelintegration vom CIFS bringt halt was

Sowohl der Illumos wie der Solaris SMB sind Kerneldienste. (Illumos ist ja ein Solaris Fork)
Oracle hat den Solaris SMB Server aber durchaus verbessert, auch könnte es daran liegen dass Solaris mit native ZFS Vorteile hat.

SAMBA ist auf jeden Fall meist langsamer, egal ob unter Solaris oder Linux. Ksmbd (kernelsmb) unter Linux ist auch schneller als SAMBA.

 

[VirtuGuy]

Man sollte schon dazu sagen das ksmbd ganz nett für Benchmarks ist, aber für den täglichen Betrieb noch viele Features fehlen. Gerade im NAS Betrieb verschenkt man ohne SMB Compression nicht unerheblich Performance und Bandbreite.

 

[besterino]

Jo, ksmbd ist vielleicht nett für Schmalspur Setups wo man sehr genau weiß, was ksmbd kann (und was auch nicht). Ausgereift / Production-ready ist das m.E. jedenfalls noch nicht so wirklich.

 

[gea]

ksmbd ist relativ neu.
Bis es die Reife und Features von SAMBA oder dem kernelSMB von Illumos/Solaris erreicht, kann es noch dauern. Es geht mit ksmbd jedoch in die richtige Richtung wenn man schnelleres SMB unter Linux möchte. Leider haben sie das einfache ACL Handling des Illumos/Solaris SMB nicht übernommen sondern die Plagerei von SAMBA.

 

[Techlogi]

Kann ich zwei verschiedene SSDs (Crucial M4 + Samsung 840) als Mirror (TrueNAS boot) laufen lassen oder gibt das Probleme?

 

[gea]

ZFS beschreibt jede Platte eigenständig und könnte damit sogar Mirror SSD-HD

 

[Luckysh0t]

Moin,

hat jemand von euch schonmal mit fswatch unter omnios/napp-it gearbeitet?

Nachdem ich in napp-it die entsprechenden Pfade auf Änderungen überwache, stellt sich mir nun die Frage, wie ich diese am besten nutzen kann, um dann bei Änderungen automatisiert Snapshots von den betreffenden Dateisystemen zu erstellen.

Nach einer Unterhaltung mit ChatGPT müsste ich somit

fswatch -o /hdd/Backup | while read; do /root/snap.sh; done1

das ganze zumindest händisch starten können, allerdings kennt omniOS den Befehl fswatch nicht, und was ich sonst zu dem Thema finden konnte, hat mir nicht wirklich weitergeholfen.

Kann aber auch sein, dass chatgpt nur wiederum halbgare antworten gebracht hat, weil ich unwissende Fragen gestellt habe.

 

[gea]

Wenn man im napp-it Menü Services fswatch als Dienst startet, werden in /var/web-gui/_log/monitor/ logs der Zugriffe erstellt. Die könnte man per script auslesen um snaps zu erstellen. Das Script (bash, Perl etc) kann man als "other job" starten.

Einfacher wäre es ein oder mehrere autosnap jobs (stündlich, täglich, wöchentlicj etc) mit "delzero" zu erstellen. Gibt es keine Änderungen, hat ein snap used=0 und wird gelöscht. Spart den ganzen Aufwand.

 

[Wesumat]

Guten Morgen zusammen,

ich hege mich mit dem Gedanken meinen filer von Solaris 11.4CBE auf OmniOS umzustellen. Hintergrund ist ein eh geplanter Hardwarewechsel. Das die ZFS Varianten nicht kompatibel sind ist mir bekannt, frage mich jetzt was im späteren Verlauf der einfachste und sinnvollste Weg der Datenmigration wäre. Läuf es auf einen schnöden bspws. rsync vom alten auf den neuen pool heraus oder gibt es noch irgendeinen Kniff den ich vielleicht nicht im Auge habe?

Zudem würde mich noch interessieren ob man mit dem Wechsel irgendwas wesentliches im Vergleich zu Solaris „verliert“. Im Hinblick auf smb und nfs Version und features? Bietet OmniOs da ähnliches und features wie vorherige Versionen beim Verwenden von Speicherplatz unter Microsoft Systemen?

Gruß
Pascal