ZFS on OSX, nutz das jemand?

Loki Mephisto schrieb:
Ich bin nicht der Dateisystem-Guru; eines sollte man halt immer bedenken: es kommt darauf an, für welche Aufgabe ein Werkzeug gedacht ist; in diesem Zusammenhang stellt sich mir die Frage: was wäre der optimale Einsatzzweck für ZFS?
Zum Vergrößern anklicken....

Prinzipiell lässt sich ZFS für alles nutzen, wofür sich 'klassische' Filesysteme auch eignen - die Hardwareanforderungen (RAM-Grösse, ECC) sind halt höher. Einer der Hauptvorteile als Copy-on-Write-Filesystem ist die Dateisystem-Integrität: Du kannst prinzipiell jederzeit den Stecker ziehen, ohne korrupte Dateisystemstrukturen fürchten zu müssen (ohne ZFS würde man Raidcontroller mit batteriegepufferten Caches verwenden). ZFS eignet sich durch seine Prüfsummen auch als Prävention gegen Bit-Rot (mit steigendem Datenvolumen statistisch höherer Wahrscheinlichkeit auftretende 'kippende' Bits): Bei klassischen Raids hat man zwar Redundanz bei ausfallenden Platten, diese können aber in einem Bit-Rot-Fall z.B. bei Raid10 nicht erkennen, welche Datei, die sich von ihrem 'Spiegelbild' unterscheidet, eigentlich die 'richtige' ist. Aber auch hier gibt es andere Dateisysteme mit Prüfsummen, ZFS vereint halt viele Funktionen (Dateisystem, LVM, Raid) in Einem und ist sehr flexibel: Datasets oder ZVols (als virtuelle Blockdevices) ersetzen 'klassische' Partitionen etc. Ich nutze es hauptsächlich wegen seiner Resilienz und Snapshot-Funktionalität, aber die bekäme ich auch z.B. per LVM. Bei ZFS hat man halt alles in einem 'Paket'...
 
bowman schrieb:
...der Witz bei ZFS ist doch gerade, daß man auf Raid-Karten bzw. -Treiber verzichten kann. ZFS vereint ja die gesammelte Funktionalität von Raid, LVM und Filesystem und braucht direkten Plattenzugriff. Aufgrund des COW-Filesystems benötigt man auch keine gepufferten Caches - die ja eigentlich eines der der Hauptvorteile bei Raids mit 'klassischen' Dateisystemen sind.
Zum Vergrößern anklicken....
Das ist mir schon klar, aber auch ein RAID-Controller im JBOD-Modus benötigt einen Treiber um angesprochen zu werden. Und wenn dieser in Kombination mit einer bestimmten Chiprevision des Controllers fehlerhaft ist und Gülle auf die Platten schreibt ist nicht mehr viel zu retten ;)
 
ZFS ist schon "ne coole Sau", für mich ist das aber eher was für Server - vor allem mit dem RAM Verbrauch. Da allerdings macht das richtig Spaß - hab es mal auf nem Ubuntu-Server laufen gehabt. Für Desktops würde ich mal auf ein rocksolid BetterFS warten.
 
Nicht zu vergessen: ohne ECC RAM auch nur die halbe Miete
 
Loki Mephisto schrieb:
Nicht zu vergessen: ohne ECC RAM auch nur die halbe Miete
Zum Vergrößern anklicken....
Ach naja. ECC RAM hat doch nur den Vorteil des es Bitdreher korrigieren kann. Größere Fehler auch nicht und da ist es nur ein besseres Analysetool für defekte DIMMs. ECC halte ich für überbewertet.
 
Im Prinzip ja. Es wird jedoch von den FreeNAS und iXSystems Leuten darauf hingewiesen, dass ZFS mit ECC betrieben werden sollte
 
  • Gefällt mir
Reaktionen: wegus
Keineswegs. Gerade FreeNAS ist unabhängig.
Es scheint es ist wenig sinnvoll bit rot Features herauszustellen wenn der RAM da nicht mitmacht
 
ZFS bringt für den Desktop IMHO keinen Mehrwert. Auf unseren Servern mit FreeNAS und Linux nutzen wir ZFS, wobei es nur unter FreeBSD und Verwandten Sinn macht. Unter Linux kann schon mal der als Cache benutzte Speicher nicht wieder freigegeben werden, da hilft dann nur ein Neustart. Linux und FreeBSD verwalten den realen und virtuellen Arbeitsspeicher unterschiedlich.

ZFS Alleinstellungs-Features wie Deduplizierung und ZFS-Replikation braucht man nicht auf dem Desktop.
 
Ich nutze ZFS am NAS unter Freenas. Von den Features habe ich aber noch keinen Gebrauch gemacht. Datenverlust hatte ich noch keinen, laeuft seit Jahren problemlos.
 
Wie auch immer. Ob ECC RAM oder Standard... macht das Kraut nicht fett.

Davon abgesehen: wenn man bedenkt worum es bei bit rot geht ist man geneigt zu akzeptieren daß ZFS ohne ECC ... nicht optimal ist und ein guter Teil des Potentials verschenkt wird
 
ZFS dürfte ohne ECC aber immer noch wertvoller sein, als ein Dateisystem ohne Checksummen, egal, ob das System dann ECC hat oder nicht. Ich verstehe daher dieses herumgereite auf dem ECC-RAM nicht. Klar ist es mit ECC dann noch besser. Aber es ist halt ohne ECC auch noch besser als bisher.
 
Schon richtig. Aber wenn schon die coolste Sau im Stall, dann aber ohne Kompromisse. :cool:
 
In der Praxis ist der ECC der Harddisks relevanter als ECC-RAM.
Ich habe in 20 Jahren RZ-Administration nur einmal Bit Flip / Bit Rot oder wie immer man das nennen will erlebt und das war bei einem Kopiervorgang von 23TB zwischen zwei HP Proliant mit FreeBSD und ZFS und ECC-RAM. Eine Datei sah korrekt kopiert aus, hatte korrekte Größe, war aber nicht lesbar. ZFS hat das beim nächsten Scrub festgestellt, konnte es aber nicht beheben. Datei neu kopiert, alles ok.

Hier ein kontroverser Artikel, ich sehe das eigentlich genauso. Ist aber eher eine Glaubensfrage, es gibt selbst von den ZFS-Entwicklern nur wenige belastbare Infos zu dem Thema.
Hard drives already do this, the risks of loss are astronomically low, ZFS is useless for many common data loss scenarios, start backing your data up you lazy bastards, and RAID-5 is not as bad as you think.
 
kyxh2o schrieb:
Unter Linux kann schon mal der als Cache benutzte Speicher nicht wieder freigegeben werden, da hilft dann nur ein Neustart.
Zum Vergrößern anklicken....

...das muss aber schon länger her sein - derartige Probleme hatte ich noch nie.
 
In der Tat... deswegen läuft bei mir eben kein ZFS. Meine Daten werden (unter anderem) auf einer Linux-Maschine (mit BtrFS) gesichert, und somit sind alle Daten 3x vorhanden (Macbook Pro - mein Hauptrechner, der Linux Maschine und einem Mac Mini Server).

Wichtige Daten bzw. Projektdateien nochmal online.

ZFS würde in diesem meinem Szenario wenig bis nichts bringen, insbesondere da ZoL nicht auf dem Level von ZFS auf FreeBSD zu sein scheint.

In meinem Fall wäre es ein absolutes Nerd-Ding eine ZFS Maschine aufzubauen. Und da würde ich halt Nägel mit Köpfen machen wollen. Auch wenn das natürlich technisch gesehen nicht zwingen notwendig und/oder sinnvoll wäre
 
bowman schrieb:
...das muss aber schon länger her sein - derartige Probleme hatte ich noch nie.
Zum Vergrößern anklicken....
Das gibt es immer noch, das merkst Du allerdings erst beim Hin- und Herkopieren von echten Datenmassen, so >10TB, das hat man im Alltag eher selten.
Ist z.B. hier beschrieben:

https://wiki.ubuntuusers.de/ZFS_on_Linux/
  • options zfs zfs_arc_max=2147483648
    in der Datei /etc/modprobe.d/zfs.conf zu einer Beschränkung auf 2 GiB RAM für ARC (Anm: Aufgrund von RAM-Fragmentierung kann dennoch Speicher bis zum Doppelten dieses Wertes benötigt werden!). Die Angabe erfolgt in Bytes, weitere mögliche Werte wären 17179869184 für 16 GiB, 8589934592 für 8 GiB, 4294967296 für 4 GiB oder 1073741824 für 1 GiB. Da der ARC beim Laden des Kernelmoduls gesetzt wird, wird anschließend ein Neustart empfohlen.
Trotz Maximalwert für ARC kann es zu Speicherproblemen kommen. Da ZFS aus seiner Ursprungsumgebung (Solaris) portiert wurde, mussten Anpassungen vorgenommen werden, die speziell Unterschiede in der Behandlung von virtuellem Speicher im Kernel betreffen. Die Unterschiede zwischen der "Solaris-Sicht" und der "Linux-Realität" verursachen u.a. unerwünschte Speicherverschwendung, für die es kein einfaches Heilmittel gibt.
 
kyxh2o schrieb:
Ich habe in 20 Jahren RZ-Administration nur einmal Bit Flip / Bit Rot oder wie immer man das nennen will erlebt und das war bei einem Kopiervorgang von 23TB zwischen zwei HP Proliant mit FreeBSD und ZFS und ECC-RAM. Eine Datei sah korrekt kopiert aus, hatte korrekte Größe, war aber nicht lesbar. ZFS hat das beim nächsten Scrub festgestellt, konnte es aber nicht beheben. Datei neu kopiert, alles ok.
Zum Vergrößern anklicken....
Wenn es Bitrot in der Quelldatei war, hätte ZFS das ja schon beim Kopieren merken müssen. Und zwar sobald es den defekten Block gelesen hat. So zumindest mein Verständnis davon. Und wenn der Bitflip erst durch das Kopieren passierte, hätte der ECC ja schon was merken müssen. Klingt es nicht eher so, als wenn die Zieldatei erst den Bitrot bekommen hat? Denn sonst hätte es nicht erst beim Scrub auffallen dürfen. Oder irre ich mich da?
 
agrajag schrieb:
Wenn es Bitrot in der Quelldatei war, hätte ZFS das ja schon beim Kopieren merken müssen. Und zwar sobald es den defekten Block gelesen hat. So zumindest mein Verständnis davon. Und wenn der Bitflip erst durch das Kopieren passierte, hätte der ECC ja schon was merken müssen. Klingt es nicht eher so, als wenn die Zieldatei erst den Bitrot bekommen hat? Denn sonst hätte es nicht erst beim Scrub auffallen dürfen. Oder irre ich mich da?
Zum Vergrößern anklicken....

Gut mitgedacht. BitRot entdeckt ZFS durch Scrub. Auf dem Quellsystem wurde jahrelang kein Scrub durchgeführt, von daher vermuteten wir da das Problem.
Mir wurde das so erklärt: Quelle hat defekte Dateien, weiß das aber nicht durch fehlenden Scrub. Quell-ZFS bemerkt beim ersten kopieren den Fehler und repariert ihn, der zweite Kopiervorgang klappt dann.

Aber ob das so ist, kann man nur vermuten, das ist alles nicht wirklich dokumentiert. Auch von den Solaris-Leuten kam dazu wenig belastbares.
Aber BitRot ist im wirklichen Leben eben auch so selten, kaum einer hatte wirklich schon damit zu tun.
 
  • Gefällt mir
Reaktionen: Loki M
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten