[Sammelthread] ZFS Stammtisch

[Spliffsta]

Klar, über irgendwelche commands und linux Befehle oder einfach eine saubere WEB- GUI. Für mich als absoluten Anfänger sind diese ganzen Linux Befehle einfach nur nervige Kacke. Klar, mittlerweile bin ich da auch halbwegs firm mit und mit AI kann ich auch YAML´n. Aber bin froh und zufrieden über mein Truenas Datengrab

 

[besterino]

@zos: Ist halt etwas mehr Aufwand, als @pwnbert gewohnt ist / bereit ist, auf sich zu nehmen.

Ich selbst würde ja sofort ein cleanes OmniOS oder Solaris 11.4 nehmen. Meine Daten liegen seit ca. 10 Jahren auf Solaris 11, mein Archiv dürfte auch schon so knapp 6 Jahre auf dem Buckel haben. Und läuft. Und läuft. Und läuft.

 

[gea]

-Windows mit ReFS habe ich tatsächlich schon überlegt, aber da habe ich in der Vergangenheit schon einiges negative gelesen, über inkonsistentes Verhalten oder das Windows ein Array einfach direkt löscht statt zu degraden. Weiß nicht wie da der aktuelle Stand ist.
-Debian+ZNAS, ZNAS ist halt noch extrem Jung
-TrueNAS evtl zu aufgebläht und soll sich wohl in die falsche Richtung entwickeln.

Das Hauptproblem bei ReFS ist, dass noch wichtige Features fehlen und Microsoft das noch heftig weiterentwickelt. Ähnlich wie ZFS ist ReFS dann aber nur aufwärtskompatibel. Dämlich dabei ist dass Windows das teils automatisch updated,

Fehler kanns auch noch haben, aber auch nicht mehr als OpenZFS - so stabil wié Illumos ZFS sind halt beide nicht. Immerhin hat ReFS die zwei wichtigsten ZFS Features CopyonWrite und Echtzeit Datenprüfsummen, mit VSS unter Window Server (Essentials) auch Snaps.

 

[HansBohne]

Doch denke schon dass OpenZFS inzwischen stabiler ist als andere ZFS Implementationen einfach weil OpenZFS von allen am meisten genutzt wird und deshalb die "edge cases" auch gefunden werden im Idealfall bevor man selber drauf stösst.

Jede komplexere Software hat immer Fehler wichtig ist nur a) diese zu finden b) zeitnah gefixt werden a) geht nur mit Masse der Nutzer b) mit Masse der Entwickler

 

[morph027]

Schon. Auch wenn ich kein ausgewiesener KI Freund bin was Coding angeht, aber ich bin gespannt was die demnächst so alles findet. Die Kernel CVEs der letzten Woche waren da glaub ich ein guter Vorgeschmack 🙈

 

[HansBohne]

Naja aber ist doch gut wenn echte Schwachstellen so öffentlich werden, sonst nutzt die evtl jemand heimlich - und wenn von den 10 mMio Bugs die eine Software hat so 5 Mio zumindest auf die ToDo Liste kommen ist das ja auich nicht verkehrt, denke in vielen Fällen werden das einfache Fixes sein wie evtl mal ein Bufferoverflow in uraltem Code den niemand mehr wirklich angeschaut hat etc. oder sich was durch die Kernel APIs geändert hat

Je mehr Fehler auf einer Liste sind desto stabiler wird ja die Software - wenige Fehler heisst doch meist nur niemand kümmert sich wirklich drum.

Die Fixes in OpenZFS werden ja echt immer exotischer oder weniger "systemgefährlich" dass die Liste trotzdem so langh ist ist doch das beste Zeichen dass heist man kümmert sich um den Code - aber findet immer weniger "Todesfallen"

Ich schau mir immer die changelog bei OpenZFS an und es gibt immer weniger so das Gefühl ui da lohnt es sich aber das mal schnell kurz zu compilieren.... weil.....

Wäre die Liste der Fehler mal klein würde das nur heissen das Projekt stirbt denke ich.

 

[Tundor]

und soll sich wohl in die falsche Richtung entwickeln.

Kann das irgendwie (bis jetzt) nicht nachvollziehen. Die haben (ihren Angaben nach, kann man natürlich misstrauen) den Build Prozess Closed Source gemacht angeblich wg. irgendwelchen Zertifizierungen die sie brauchen? Selbst wenn die sich in 2 Jahren entscheiden irgend nen Dick Move zu machen, hat man doch ZFS Pools die man einfach in irgend ein anderes System hängen kann, ist ja kein Lock in.

 

[besterino]

Doch denke schon dass OpenZFS inzwischen stabiler ist als andere ZFS Implementationen einfach weil OpenZFS von allen am meisten genutzt wird und deshalb die "edge cases" auch gefunden werden im Idealfall bevor man selber drauf stösst.

Jede komplexere Software hat immer Fehler wichtig ist nur a) diese zu finden b) zeitnah gefixt werden a) geht nur mit Masse der Nutzer b) mit Masse der Entwickler

Ich denke, dass Oracle‘s Solaris immer noch das stabilste ist. Dafür weniger Features als OpenZFS.

 

[HansBohne]

Hmmmm aber der bisher gefährlichste Bug in ZFS den man vor so 1-2 Jahren(?) gefunden hatte war der nicht Jahrzehnte alt?

Die "Features" in ZFS sind doch meist nicht mehr lowlevel Features zumindest relativ selten - das sind ja eher so "Highlevel" features wie crypt dedup etc oder jetzt expansion - denke das ist sehr viel einfacher umzusetzen, weil das sind doch "abstraktere" Umsetzungen und damit sehr viel überschaubarer wenn die Basis steht. Crypt z.B. ist an einem Punkt ist einfach ein Stream IN/OUT da sehe ich nahezu 0 Probleme dass es da noch Implementierungsfehler gibt.

Wenn die Basis solide ist sind Features doch sehr viel einfacher zu implementieren, weil das selten was ist das es noch nie gab - und für das keine abstrakten Konzepte existieren. So wie die ZFS Expansion - da war auch das Hauptaugenmerkt ja die prinzipielle Sicherstellung der Datensicherheit/redundanz - und weniuger die technische Umsetzung, dafür ist fast alles eh schon dagewesen.

 

[gea]

Ich denke, dass Oracle‘s Solaris immer noch das stabilste ist. Dafür weniger Features als OpenZFS.

Der Unterschied ist halt:

Solaris, Illumos:
Genau eine Gruppe von Entwicklern kümmert sich um genau ein aktuelles OS Release das von Anfang an rund um ZFS und für ZFS entwickelt wurde, Neue Features werden extrem konservativ integriert. Es gibt kein "schauen wir mal wie gut es funktioniert" Code.

OpenZFS
Viele Firmen und Entwicklern integrieren neue Sachen die auf X Distributionen und Betriebssystemen laufen sollen. Jede Distribution hat dazu einen anderen ZFS release Stand, jeweils mit anderen Problemen. Folge: mehr Features, schnelle Entwicklung, weniger Stabilität

 

[Kreis]

Es gibt noch ZIma OS aber keine Ahnung ob das was taugt

bei einem reinem Filer kannst du eigentlich jedes OS nehmen und die zfs module dazu laden, der kernel ist danach tainted
und bereits erwaehnt jede distro hat eine andere Version
Debian 2.3.1 via Backports 2.4.1
Arch aktuell

Redhat und co weiss ich es nicht

 

[Trambahner]

ZimaOS macht standardmässig nur linux standard-softraid, ZFS ist aber mit dabei. Geht dann über die Shell.
Ist im Prinzip ein extrem runtergestriptes Debian-Derivat mit einfacher Oberfläche, mehr ist da vom ersten Augenschein nicht dahinter.

 

[gea]

Im Prinzip sind alle Linuxe bei ZFS gleich, kennst du eine, kennst du alle.
Hauptunterschied für mich ist, ob die Distribution OpenZFS out of the box mitbringt, aktuell hält und sauber pflegt.

Das ist neben der kompakten Distribution und den tollen Hypervisor Optionen für mich der Schlüsselaspekt für "wenn Linux, dann Proxmox" auch als NAS OS mit SAMBA oder dem schnelleren ksmbd als SMB Server.

 

[gea]

S3 Server wie bisher minIO und künftig RustFS mit Tools wie Restic ist für mich zunehmend "DIE" Option für plattformübergreifendes (OpenZFS, Illumos ZFS, Solaris ZFS, jedes andere Dateisystem) encrypted/dedup Backup/Restore mit optionalem hochverfügbarem Storage Cluster (4/6/8 nodes) und continuierlicher 1:1 Site Replication, quasi ein selbstorganisierender LAN Storage Mirror.

Geht mit jedem OS, unter Solaris/Illumos muss man eventuell selber bauen oder die Versionen nehmen in napp-it cs.. Go Tools wie rclone oder restic sind unproblematisch, mit Rust ist es teils schwieriger, für OmniOS habe ich ein build script hinterlegt siehe

Update: S3 on OmniOS with RustFS is working:

Topicbox

 

[gea]

ZFS vs Object Storage

ZFS ist perfekt als Basis für gemeinsam zu bearbeitende Dokumente im LAN, es hat Snaps, kann ACL mit SMB, multiuser Filelocking und all die netten Sachen rund um Hybrid Pools, Dedup, Compress, Sync Write oder Verschlüssellung, dazu perfektes Software Raid Handling, demnächst mit dem sensationellen Any Raid Ansatz.

Es fehlt Zugriff aus dem Internet, Cluster Modus, Netzwerk Replikation oder einfaches snap und filevergleich basiertes Sync als Ergänzung für das streambasierte ZFS send auf Basis gemeinsamer Snaps Hier kommt S3 Object Storage ins Spiel. Jede Datei ist da eine authenticated https url, es gibt Cluster Modes (ein oder mehrere Nodes dürfen ausfallen) dazu Site Replikation, quasi ein near realtime Mirror zwischen zwei S3 Servern.

Perfekt wird es, wenn man beide Storage Technologien kombiniert, ZFS lokal, für Raid mit Snaps und als SMB Share, dazu S3 für Backup/Restore/Migration, Internet access und Site Replication (high availability). ACL backup/restore läßt sich in S3 abbilden, ZFS snaps kann als source nehmen und Restic hat dazu backup snaps, deduplication und Verschlüssellung.

Meine Tools der Wahl sind RustFS (S3 Server), Rclone (rsync for the Cloud) und Restic (Backup mit Dedup, Snaps und Verschlüsselung). Gibts für fast jedes OS, löst auch das Backup/Migration Problem Solaris ZFS <-> Illumos/Open ZFS.

Anouncement: napp-it cs, any OS, 1/4/6/8 node management for RustFS on ZFS software raid · rustfs · Discussion #3389

We are pleased to announce the availability of napp-it cs rc9. This release focuses on comprehensive code refactoring, security audits, and enhanced AI-friendly capabilities for managing cross-plat...

github.com

 

[sandreas]

Meine Tools der Wahl sind RustFS

Sei damit lieber vorsichtig:

https://news.ycombinator.com/item?id=47759022

Zitat:

RustFS is the poster child in my mind for the worst kind of vibe-coded slop. it might be "simple" but it's not something I would ever trust with persistent data.
last year they had a security vulnerability where they allowed a hardcoded "rustfs rpc" token to bypass all authentication [0]

and even worse, if you read the resulting reddit thread [1] someone tracked down the culprit commits - it was introduced in July [2] and not even reviewed by another human before being merged.

then the fix 6 months later [3] mentions fixing a different security vulnerability, and seemingly only fixed the hardcoded token vulnerability by accident. that PR was also only reviewed by an LLM, not a human.

0: https://github.com/rustfs/rustfs/security/advisories/GHSA-h9...

1: https://www.reddit.com/r/selfhosted/comments/1q432iz/update_...

2: https://github.com/rustfs/rustfs/pull/163/

3: https://github.com/rustfs/rustfs/pull/1291

Hier noch eine recht interessante Diskussion über S3 Storage im Allgemeinen:

I just want simple S3 | Hacker News

news.ycombinator.com

 

[asm@s24]

Zitat:

... that PR was also only reviewed by an LLM, not a human.

Die LLM-Reviews sind ja mittlerweile besser als die humans, siehe 10-jährige Linux-Kernel-Löcher ...
Ok, sie argumentieren, wenn die RustFS-Leute früher schon solch krassen Dinger drin hatten, kann's ja jetzt nicht besser sein. Weiß man nicht.

Aber ...

Hier noch eine recht interessante Diskussion über S3 Storage im Allgemeinen:

I just want simple S3 | Hacker News

news.ycombinator.com

Das hier find ich interessant: ZFS+VersityGW
Für "uns" ZFSler womöglich die naheliegendste Lösung?

ZFS Use Case

A simple to deploy but feature rich S3 object storage server for your filesystem - versity/versitygw

github.com