[Sammelthread] ZFS Stammtisch

[fallenguru]

Mir geht's bei sowas mehr um Metadaten-intensive

Eine Reservierung für Metadaten bedeutet eine Verringerung des Cache für normale Daten.

Beim tunable, das is jetzt im Kopf hab, geht's doch eher um eine Obergrenze für den Platz, den die Metadaten im ARC einnehmen dürfen? Sprich, der Cache steht für Daten nur dann nicht zur Verfügung, wenn er für Metadaten gebraucht wird. Hab mich aber, zugegeben, seit Jahren nicht mehr beschäftigt – läuft ja, wie's is.

Hängt natürlich vom Use-Case ab, aber ich mag selbst als Heimanwender mit ein paar Usern und wenigen Dateien möglichst viel Metadaten im Cache haben. Sonst dauert's Sekunden, bis ich auf meiner Samba-Share ein Verzeichnislisting krieg, und durchsuchen kann ich ganz vergessen. Beim Backup mit rsync/restic macht's auch einiges aus. Und, eben, so viele Metadaten hab ich ja gar nicht, also kostet das auch nicht so viel RAM. Dafür bei Bedarf insta find / ... – das isses mir wert.

 

[pwnbert]

Eine Reservierung für Metadaten bedeutet eine Verringerung des Cache für normale Daten.

... aber nur, wenn die Metadaten auch da sind, oder? Der vom ARC benutzte RAM wird dadurch nämlich nicht weniger. Also ich meine, dass der ARC nicht verkleinert wird, sondern bloß den Metas ein gewisses Kontingent zugesichert wird (solang z.B. nur 2 GB Meta drin sind in den 8 reservierten GB könnten die restlichen 6 trotzdem von "normalen" Dateien im ARC verwendet werden).
=> Ich glaube, dass das so ist - liege ich denn falsch?

Mir gehts eher darum, im Netzlaufwerk schneller suchen zu können bzw. bei großen Ordnern die Listungen schneller darstellen zu können, daher dachte ich, dass das evtl. eine sinnvolle Sache sein könnte.

 

[gea]

Wenn man die für Metadaten zugesicherte Menge nicht ausnützt, hätte man keinen Nachteil wenn man da nichts gesetzt hätte. Nutzt man das Kontingent aus, so hat man weniger Cache für normale Datenblöcke als ohne diese Einstellung was ja auch Performancenachteile hat. Read last/most sorgt ohnehin dafür dass Einträge laufend aus dem Cache fallen und nur das aktuellste/ häufigste im Cache liegt.

Wenn man wirklich viele Ordner mit vielen Dateien hat und das beschleunigen möchte, so ist das ein Ansatz der minimal was bringen kann, anderes minimal verschlechtern kann. Andere Maßnahmen können drastische Verbesserungen bringen, nicht nur minimal die Balance verändern. Will man konstant hohe Performance für Metadaten und kleine io: Special Vdev.

ps
Ich hab halt häufig den Eindruck dass man meint dass die Defaults bei ZFS schlecht sind und man nur etwas dran drehen muss damit es flutscht. Ist aber oft wie Feintuning beim Auto. Bringt schon was z.B. 185 kmh statt 180 kmh. Will man wirklich was bewegen hilft aber nur rohe Gewalt, z.B. 300PS statt 200PS. So isses auch mit Computern und ZFS. Im Alltag merkt man nur einen Leistungsunterschied von 30% oder mehr oder wenn die Einstellungen für einen Anwendungszweck grob falsch waren.

Bleibt das Bastelvergnügen...

 

[pwnbert]

So sieht das aus bei mir.
Die 20g frei, weil ich TrueNAS als V-Host nutze (genutzt habe), wenn da nur 15 frei wären, könnte ich eine 16gb VM erstellen (bzw. wie das mit dem ballooning hinhaut, hätte ich noch prüfen müssen).

Nachdem ich aber eh auf Proxmox wechseln werde... ist das jetzt nicht so das Thema.

Beitrag automatisch zusammengeführt: 16.10.2024

Wenn man wirklich viele Ordner mit vielen Dateien hat und das beschleunigen möchte, so ist das ein Ansatz der minimal was bringen kann, anderes minimal verschlechtern kann. Andere Maßnahmen können drastische Verbesserungen bringen, nicht nur minimal die Balance verändern. Will man konstant hohe Performance für Metadaten und kleine io: Special Vdev.

Jo, aber der Preis für diese Veränderung ist ein Einziler, der jederzeit ohne Aufwand wieder rausgenommen werden kann, insofern wars mir den Versuch halt mal wert.

Ich hab halt häufig den Eindruck dass man meint dass die Defaults bei ZFS schlecht sind

Ach, ich finde so wie das auf TrueNAS default ist, funktioniert das eig. wunderbar.

 

[fallenguru]

Read last/most sorgt ohnehin dafür dass Einträge laufend aus dem Cache fallen und nur das aktuellste/ häufigste im Cache liegt.

Eh. Bringt halt wenig für, z. B. ein rsync, das einmal am Tag läuft. "Einmal am Tag" ist nicht oft, und "vor 24 h" ist nicht aktuell. Auch nicht, wenn ich alle paar Tage einmal was im Archiv such. Beides dauert mehrere Minuten statt wenigen Sekunden, wenn die Metadaten gerade nicht mehr oder weniger vollzählig im Cache versammelt sind. Sind ja dann lauter winzige Einzelzugriffe auch noch.

Andere Maßnahmen können drastische Verbesserungen bringen, nicht nur minimal die Balance verändern.

Wie gesagt, is nicht minimal bei mir. Aber wenn's was Eleganteres gibt, gerne. Was bringt denn z. B. "drastische Verbesserungen"? (Das Problem mit Hardware bewerfen gilt nicht.)

man meint dass die Defaults bei ZFS schlecht sind

Schlecht? Nö. Aber halt auch überhaupt nicht auf rundherum untermotorisierte (Heim-)Server ausgerichtet, die lediglich eine handvoll Clients haben, und noch weniger gleichzeitige Clients.

Wenn ich mir das bei mir so anschau, mein hot set ist vielleicht ein paar GB groß (passt also locker in den RAM), aber so viele/häufige Zugriffe darauf, dass der ARC das von selber so einstuft, bring ich nicht zusammen. Und von der Zeit, die's braucht, ein ODT aufzumachen, entfällt nur ein sehr geringer Teil auf den Diskzugriff, das meiste ist Netzwerk, Samba, GVFS. Die restlichen TB sind Videos, Photos, Spiele – große Dateien, die ich selten brauche, und wenn, dann nur einmal. Also auch nix für den Cache. Für mich sind Metadaten relativ zum Platzbedarf ziemlich das Wertvollste, was im Cache sein kann, und ich glaube, dass das bei vielen Heimanwendern, die ZFS für ihr NAS verwenden, genauso ist. Das ist alles. Wenn Datenbanken drauf rennen, VMs, Videoschnitt ... schaut's wieder anders aus.

 

[asche77]

Für mich sind Metadaten relativ zum Platzbedarf ziemlich das Wertvollste, was im Cache sein kann, und ich glaube, dass das bei vielen Heimanwendern, die ZFS für ihr NAS verwenden, genauso ist. Das ist alles. Wenn Datenbanken drauf rennen, VMs, Videoschnitt ... schaut's wieder anders aus.

Denke ich auch -- Arbeit mit dem nur sehr sporadisch laufenden backup-server macht keinen Spass, weil suchen, Auflisten der ZFS snapshots, etc. pp. laaaaaangsam geht.

u.a. deshalb bin ich beim Haupt-NAS damals (vdevs gabs noch nicht) auch direkt auf einen Datenpool aus gebrauchten enterprise SSD gegangen. Obwohl da überwiegend Musik, Filme etc. liegen, auf die selten zugegriffen wird.

Der andere Grund war, dass die HDD nie schnell genug aus dem Schlummer aufwachten, um die Veeam agent backup-jobs rechtzeitig entgegennehmen zu können.

Heutzutage würde es vermutlich auch consumer SSD + vdev aus enterprise NVME tun.

 

[gea]

Mir gings nur darum:
Meiner Meinung nach (mit halbwegs ausreichend RAM) ist der Performancegewinn durch Arc Feintuning im Vergleich zu "Defaults" vernachlässigbar. Will man Zugriffe inkl. Ordnerlistings und Suche im Plattenpool wirklich deutlich spürbar verbessern so geht kein Weg an Hardware vorbei z.B. über ein special vdev. Ein L2Arc bei halbwegs RAM, wenig Usern und Dateien bringt nichts.

 

[pwnbert]

Ein L2Arc bei halbwegs RAM, wenig Usern und Dateien bringt nichts.

Das meine ich auch.

Die Sache dürfte ja die sein, dass in den L2arc nur Zeug kommt, das aus dem ARC "geschoben" wird.
Wenn ich jetzt im ARC für die Metadaten aber den Platz "freihalte", so kommen diese nie in den L2arc und somit bringt mir der L2arc am Ende auch nichts (die Metadaten betreffend).
Wenn ich herunterfahre wird der ARC wohl auch nicht in den L2arc "gedumpt", wodurch ich von der Persistenz auch nichts habe.

 

[gea]

Es gibt durchaus Entwicklungen zu dem Thema

L2ARC with metadata and MFU only · Issue #16343 · openzfs/zfs

Describe the feature would like to see added to OpenZFS Option to store only metadata (all metadata) and MFU (both metadata and data) in L2ARC How will this feature improve OpenZFS? This feature sh...

github.com

sowie failsafe special vdev der ausfallen darf

Special failsafe feature by tonyhutter · Pull Request #16185 · openzfs/zfs

Motivation and Context Allow your special allocation class vdevs ('special' and 'dedup') to fail without data loss. Description Special failsafe is a new feature that allows your sp...

github.com

Damit kann ein basic special vdev ein basic l2arc ersetzen

ps
In ZFS on Windows enthalten<

Enable L2 cache of all (MRU+MFU) metadata but MFU data only · openzfsonwindows/openzfs@4835c86

`l2arc_mfuonly` was added to avoid wasting L2 ARC on read-once MRU data and metadata. However it can be useful to cache as much metadata as possible while, at the same time, restricting data cac...

github.com

 

[ludwinator]

Musste mich ja früher schon mal rechtfertigen, warum mir OpenZFS nicht auf die Platte kommt und ich bei Íllumos (auch mit reduziertem Featureset) bleiben werde:

Today's update to ca0141f325ec706d38a06f9aeb8e5eb6c6a8d09a (almost identical to current 2.3.0 RC) caused permanent pool corruption · Issue #16631 · openzfs/zfs

One of my machines (FC40) recently received a kernel update from kernel-6.8.11-300.fc40.x86_64 to kernel-6.10.12-200.fc40.x86_64, and from ZFS+DKMS+Dracut master lineage, from commit 02c5aa9 to ca0...

github.com

Man sieht an dem Faden, das sich hier inzwischen alles, was Rang und Namen hat, daran abarbeitet das Problem zu isolieren.
Ich bleibe dabei, das ist einfach nicht production ready.

cu

 

[Luckysh0t]

Musste mich ja früher schon mal rechtfertigen, warum mir OpenZFS nicht auf die Platte kommt und ich bei Íllumos (auch mit reduziertem Featureset) bleiben werde:

Nutzt Illumos nicht auch OpenZFS ? Halt eher nach der "Debian" Philosophie, um mal eine Analogie zu finden.

 

[gea]

Illumos ist auch OpenZFS, allerdings mit unabhängigem Entwicklungszweig zu BSD und Linux OpenZFS das ja Illumos als Ursprung hat. Illumos, das sind die Eltern aller OpenZFS Zweige. Es gibt aber schon Unterschiede in der Philosophie und im Konzept. Während es bei Linux sehr viele Entwickler(firmen) gibt, die Neuerungen sehr schnell integrieren können, sind es bei Illumos nur sehr wenige die Neuerungen nur nach einem aufwendigen Freigabeprozess integrieren können.

Bei einer Diskussion zur schnelleren Übernahme von neuen OpenZFS Feautures das ich kürzlich in illumos-discuss angestoßen habe, meinte ein Illumos Entwickler dass neue Features ganz schnell in Open-ZFS Master erscheinen. Fehler die zwangsläufig noch bestehen werden dann erst auf dem Weg in die Distributionen gefixt, wobei jede BSD oder Linux Distribution einen eigenen Release Stand hat. Diese Feautures reifen dann erst beim Kunden. Nahezu unmöglich schnell zu entscheiden welches Problem wo bereits behoben ist. Illumos geht da anders vor. Jede Änderung in ZFS geht erst nach einem umfangreichen Freigabeprozess ins Illumos. Da gibt es keine Beta wie die OpenZFS Master oder beta release candidates. Was in Illumos integriert ist hat als stabil zu gelten so gut es eben bei Software geht.

Hinzukommt dass jede Illumos Distribution aktuelles Illumos nutzt. Lediglich OmniOS unterscheidet zwischen bloody (tagesaktuelles Illumos), stable (ein Freeze alle 6 Monate) und long term stable (freeze alle 2 Jahre). Das hat aber den Grund dass nicht unbeabsichtigt neue Verhaltensweisen in einem Server auftauchen sondern bis zur nächsten main release nur Bug oder Security Fixes.

Illumos ist für mich nach Oracle Solaris (das nutzen nur noch Großfirmen) das stabilste ZFS mit Unix statt Linux. Für einen SMB Server und das ist ja defintiv die Hauptanwendung von Storage hat man zudem da die beste ACL Unterstützung ohne das Linux/SAMBA Gewürge.

Ich habe bisher zu 100% Illumos genutzt und empfohlen, sehe aber dennoch Linux OpenZFS zunehmend als Option. Ursache sind neuere Features die man eben doch manchmal aus nachvollziehbaren Gründen möchte wie draid, raid-z expansion, direct io oder fast dedup, die so schnell nicht in Illumos erscheinen. Auslöser war ausgerechnet ZFS on Windows. Da ist OpenZFS zwar noch beta, weniger wegen ZFS sondern eher weil die Integration eines "Windows fremden" Dateisystem das nicht auf klassischen Volume und Partitionen besteht an vielen Stellen auf Problemen stößt.

ZFS on Windows bot mir die Möglichkeit diese neuen Features zu testen und manche sind mehr als nice to have sondern must have bei manchen Anwendungen. Bei Windows kommt hinzu, dass es der Ursprung von SMB ist mit einer einzigartigen Integration von AD ntfs ACL ins Dateisystem, für mich von daher die logische Alternative zu Illumos wenn SMB das Thema ist. Ich habe es in Jahren nicht geschaft, moderne ntfs artige ACL mit Linux und SAMBA sauber umzusetzen.

ZFS Pool Performance ist auf allen Plattformen ähnlich, mit leichten Vorteilen von Illumos was Resourcenbedarf angeht und leichten Nachteilen noch bei Windows. Das ist aber nicht entscheidend. Viel gravierender ist dass man die Pool Performance nicht zum Arbeitsplatz oder Backupsystem bekommt. Ein Voll Backup eines für heutige Verhältnisse eher mittleren ZFS Pools kann gerne Tage dauern und 4K/8K Video vom Server geht auch nicht wenn man nicht gerade eine neuere 20G+ RDMA Netzwerkkarten mit SMB direct nutzt.

Da bin ich wieder bei OpenZFS on Windows. Hoffentlich wird das bald stable, dann nicht mehr mit neuestem Master sondern dem stabileren, latest Stand.

Brauche ich diese neuen Features nicht, bleibt OpenZFS mit Illumos für mich eindeutig die erste Wahl, tut halt einfach ohne viel Geschraube und bugs mit Datenverlust. Ich erinnere mich nur an einen Vorfall in 10 Jahren mit einem Bug in persistent L2Arc der innerhalb von 2 Tagen behoben wurde.

OpenZFS Master ist aber definitiv beta Software und nicht production ready. Erreicht es einen Release Stand dann bedingt. Die konservative successive Integration in Distributionen hat also nicht nur Nachteile, wüsste man denn welche der vielen Varianten stabiler ist als andere. Im Zweifel dann doch immer die latest wie aktuell 2.2.6 oder demnächst 3.x (ohne rc)

Releases · openzfs/zfs

OpenZFS on Linux and FreeBSD. Contribute to openzfs/zfs development by creating an account on GitHub.

github.com