[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

 

[fallenguru]

OpenZFS Master ist aber definitiv beta Software und nicht production ready.

Man muss aber auch sagen, dass das niemand behauptet. Master branches sind nicht beta, nicht alpha, die sind schlicht der aktuelle Stand der gemeinsamen Entwicklung, Marke "schön, wenn sich's kompileren lässt". Releases sollten natürlich prinzipiell stabil sein, ja, aber sie sind nicht dazu gedacht, dass man sie in einer Produktionsumgebung händisch herunterlädt, kompiliert und installiert. Für production ready ist ggf. der jeweilige Downstream, also die Distro, zuständig. Muss man sich halt eine suchen, due den eigenen Anforderungen für production ready entspricht. Bei Illumos ist halt die Distro und die ZFS-Entwicklung aus einer Hand.

Das ist bei sehr viel Linuxsoftware so. Kein Mensch verwendet, wenn's um was geht, Software direkt vom Upstream-Repo.

tl;dr: Da geht's weniger um die Stabilität von OpenZFS als um unterschiedliche Entwicklungsmodelle und Erwartungen.

 

[ludwinator]

Nur leider wird bei openZFS der Master an irgendeinem Punkt zum RC oder Release und mir ist vollkommen schleierhaft, nach welchen Kriterien und wie gut das dann getestet worden ist. Dazu kommen dann noch Kernel Abhängigkeiten und hinterher gibts dann Datenverlust (Issue 16631).
Diese Fälle sind ja schon Rufschädigung von ZFS.
Das ist der fette Unterschied zu Illumos und deswegen glaube ich nicht dran, das die beiden Forks wieder zusammengeführt werden.

 

[fallenguru]

Nur leider wird bei openZFS der Master an irgendeinem Punkt zum RC oder Release und mir ist vollkommen schleierhaft, nach welchen Kriterien und wie gut das dann getestet worden ist.

Ohne irgendetwas zu wissen: Vor dem commit wird üblicherweise geprüft, ob das Zeug noch kompiliert; dann gibt's auch noch eine Testsuite, die mit Glück zumindest für RC-Builds läuft. Ansonsten verlässt man sich drauf, dass genug Leute, die an ZFS mitentwickeln oder sonst an der bleeding edge interessiert sind, das auf Testsystemen laufen haben, und etwaige Bugs hoffentlich jemanden von denen beissen, bevor das released wird. Die schreien dann auf der ML und/oder auf GitHub. Und wenn nicht, gibt's halt dann einen Hotfix.

Dann gibt's mehr Tests (und mehr Abwarterei) eben Downstream. In TrueNAS RCs, in Proxmox Testing und No-Subscription, in Ubuntu Server, ... Versionen, die da dann grünes Licht bekommen, sollten, in Verbindung mit den dort verwendeten Kernels, etc., production ready sein.

Dazu kommen dann noch Kernel Abhängigkeiten

Noch einmal, der Code auf Github ist nicht für normale Anwender gedacht, und schon gar nicht für irgendwas Wichtiges. Dafür gibt's Distros. Die kümmern sich dann auch drum, dass Kernel und ZFS zueinander passen.

und hinterher gibts dann Datenverlust (Issue 16631).

Spannender Bug, keine Frage. Nur, was hätten die OpenZFS-Leute wie testen sollen, um den im Vorfeld zu finden? Damit das triggert, muss man scheint's die falsche Kernelversion mit der falschen ZFS-Version kombinieren, LUKS2 im Spiel haben, bestimmte Workloads, und eine Menge Pech. Das ist der Grund, warum Enterprise-Distros nur ganz bestimmte Versionen und Konfigurationen supporten – weil man wirklich testen nur ein Gesamtsystem kann. (Proxmox z. B. unterstützt offiziell gar kein LUKS(2).)

Nicht, dass es nichts zu kritisieren gäbe. Z. B., dass die OpenZFS-eigene Verschlüsselung voller unintuitiver und schlecht dokumentierter Fallen ist.

 

[ludwinator]

Nur noch kurz zum Thema "da kümmern sich die Distros drum":

zfs fails to detect ZFS-8000-8A corruption: Reading file causes ZFS-8000-8A, scrub claims OK, repeat · Issue #16520 · openzfs/zfs

System information Type Version/Name Distribution Name Ubuntu Distribution Version 22.04.4 LTS jammy Kernel Version 6.5.0-45-generic Architecture x86_64 OpenZFS Version zfs-2.1.5-1ubuntu6~22.04.4 z...

github.com

cu

 

[gea]

Die Distributionen können sich um garnichts kümmern. Da sitzen ja normalerweise keine ZFS developper die Fehler beheben. Die Distributionen können eigentlich aus dem Angebot von

Releases · openzfs/zfs

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

github.com

lediglich eine aussuchen und bei Problemen auf die nächst höhere oder auf latest (die neueste als stabil geltende Release) wechseln falls das Problem da behoben ist. Das Verweilen auf einer älteren Release in der Hoffnung besonderer Stabilität ist trügerisch.

Das Hauptproblem sind aber tatsächlich die vielen Releases in den vielen Linux Distributionen ohne dass irgend jemand einen wirklichen Überblick hat, welche Distribution/Release Kombination besonders zuverlässig ist oder bei welchem neu entdeckten Problem gerade diese Kombination toxisch wird.

Und mas macht man dann als Nutzer?
Hoffen dass nichts passiert, oder auf eine andere/neuere Distribution/ZFS Release Kombination wechseln?

Wohl eher ersteres.
Glücklicherweise ist ZFS im Kern sehr solide und ausgereift. Wenn man die Probleme in Relation zu den Nutzerzahlen setzt, ist die Wahrscheinlichkeit eines Datenverlusts wegen Bugs gering. Backup auf einen Backup Pool mit deaktivierten Features und ohne Luks oder unter Illumos ist eine Methode das Risiko nochmal zu verringern.

 

[fallenguru]

Die Distributionen können sich um garnichts kümmern. Da sitzen ja normalerweise keine ZFS developper die Fehler beheben.

Naja, wenn man das mit dem "production ready" ernst meint, wird man ja hoffentlich eine entsprechende Distro mit Support verwenden, so à la RHEL oder SLES. Die haben meistens schon Leute bei den Projekten, die ihnen wichtig sind bzw. die sie supporten. K. A., ob jetzt irgendwelche von denen OpenZFS offiziell anbieten. Proxmox tut, und die mischen durchaus upstrem mit. Sind halt im Vergleich winzig. Oder wenn in TrueNAS Scale ein ZFS-Bug auftritt, tun die auch was.

Letztlich geht's darum aber auch nicht. Eine stable/enterprise Distro bietet ein Gesamtsystem, das über einen längeren Zeitraum fix auf bestimmte Softwareversionen baut und bestimmte Features (offiziell) unterstützt. Sodass es, in Grenzen, eine gemeinsame Basis gibt, die man überhaupt erst testen kann.

Die Distributionen können eigentlich aus dem Angebot von [Versionen] lediglich eine aussuchen

Exakt. Und wenn's dann mit dieser Kombination von Versionen etwas hat, kriegt Upstream einen Bug Report, und am Ende wird der Fix rückportiert (oder, grad pre-release, notfalls doch noch die Version geändert).

Das Verweilen auf einer älteren Release in der Hoffnung besonderer Stabilität ist trügerisch.

Ich verwende Linux seit den späten 1990er Jahren. Seit es "production ready" Distros gibt, ist das Verweilen auf einer älteren Release Version Distro-übergreifend das Mittel der Wahl, um Stabilität zu erreichen. Wie soll das auch sonst gehen? Natürlich wird die ältere Version davon nicht per se bugfreier, wohl aber dadurch, dass man die Bugs, die mit der Zeit auftauchen ganz gezielt fixt (und sonst eben nix angreift). Und wenn das nicht geht, dann dokumentiert man sie eben samt Workaround.

Illumos macht ja nichts anderes. Die erreichen ihre Stabilität ja auch nur dadurch, dass sie die alte ausgereifte Codebasis praktisch nicht mehr angreifen. Was ist das, wenn nicht "Verweilen auf einer älteren Release in der Hoffnung besonderer Stabilität"?
Interessant wär, wie die Nutzerbasis aussieht. Also Anzahl Illumos-ZFS-Nutzer vs OpenZFS-Nutzer. Weil die Anzahl der gefundenen Bugs natürlich zwangsläufig steigt, wenn mehr Nutzer da sind. Wahrscheinlich kann man auch davon ausgehen, dass bei Illumos der Anteil an IT-Profis, die sich generell im Rahmen von dem bewegen, was offiziell unterstützt wird, deutlich höher ist als unter Linux. Sprich, die Chanche, dass wer in irgendeine ungetestete Nische tappt, ist bei OpenZFS deutlich höher.

Und mas macht man dann als Nutzer?

Eine Distro verwenden, die ZFS first-class supported. Momentan also wohl am ehesten Proxmox oder TrueNAS Scale. Ubuntu weniger, bei Canonical ist ZFS seit Jahren eher ein Stiefkind. Ich tippe darauf, dass der, dessen Baby das war, inzwischen dort weg is.

Wobei ich sagen muss, ich bin auf Debian stable, und das hat mich auch noch nie gebissen. Aber ich hab halt auch ein Auge auf zfs-devel und update nicht(s) ohne guten Grund, schon gar nicht gleich nach Release.

 

[gea]

Bei den Distributionen stimme iich voll zu. Da ist es besser "konservativ" zu sein. Wenn man dazu ZFS möchte sehe ich es auch so, eine Distribution nehmen bei der ZFS fest integriert ist, also entweder TrueNAS Scale oder Proxmox, für mich Proxmox. Bei TNS sollte man tunlichst nichts auf der Console außerhalb der TNS Gui machen. Schon ein Wechsel von SAMBA auf dem schnelleren ksmbd ist ein Problem. Man kann zudem per Einzelfall entscheiden ob man etwas virtualisieren oder unter Proxmox direkt installieren möchte. Letzteres empfehle ich immer mit den SMB und NFS Kernel Serverdiensten ksmbd oder kernel-nfs. Sonstiges eher als VM.

Bei ZFS ist es schwieriger weil da die Entwicklung neuer Features schnell geht und damit die Bugrate deutlich höher ist und man innerhalb einer Distribution ZFS nicht so einfach updaten kann wie eine Applikation z.B. OpenSSH oder SAMBA wo ja regelmäßig Sicherheits und Bugfixupdates anstehen. Ein ZFS Update ist meist erst im nächsten Distributions-Update.

 

[gea]

OpenZFS developer summit

OpenZFS Developer Summit - OpenZFS

openzfs.org

Livestream in a few hours

OpenZFS

openzfs.org

 

[gea]

openzfs-dedup-is-good-dont-use-it

OpenZFS deduplication is good now and you shouldn't use it

OpenZFS 2.3.0 will be released any day now, and it includes the new “Fast Dedup” feature. My team at Klara spent many months in 2023 and 2024 working on it, and we reckon its pretty good, a huge step up from the old dedup as well as being a solid base for further improvements.

despairlabs.com

Im Kern::
-Das neue fast dedup behebt die bisherigen Probleme von dedup
-Sofern man eine akzeptable dedup Rate erwarten kann, spricht nichts dagegen es mit einer passenden Quota einzuschalten. Erwartet man keine Datendupletten, dann braucht man es nicht weil es dann nur Resourcen verbraucht ohne einen Nutzen zu bringen.

Nicht gleich nutzen, wenn es in den Distributionen erscheint, etwas zuwarten ob es noch Bugs hat. Hat man bisher dedup aktiviert, muss man den Pool neu anlegen um fast dedup zu nutzen.

 

[gea]

Wäre wünschenswert, wenn OSX und Windows weitere offizielle OpenZFS Plattformen werden