ZFS on OSX, nutz das jemand?

Aldo01

Aktives Mitglied
Thread Starter
Dabei seit
30.01.2010
Beiträge
635
Reaktionspunkte
135
Mittlerweile hat Apple mit APFS ja einen eigenen Klon von ZFS entwickelt.
Nutzt (außer mir) hier eigentlich noch jemand das "Original", nämlich OpenZFS on OSX?
Bietet ja ein paar Features die APFS nicht hat, wie Checksummen, Komprimierung, sowas wie "Fusion-Drive" (SSD als Cache), vernünftige (Reparatur)Tools, kompatibel (lesen/schreiben) mit Linux und *BSD und noch einiges mehr.
Hab hier mittlerweile einen gespiegelten und verschlüsselten 8-TB-Pool mit Cache und bin mehr als zufrieden.
Falls es jemanden interessiert, ich kann auch eine kleines How-To schreiben.

https://openzfsonosx.org
 
Apple wollte 2008 ZFS für OSX einführen ( https://www.heise.de/ix/meldung/Sun-ZFS-wird-neues-Dateisystem-in-Apples-Leopard-136733.html ), es kam aber aufgrund der Lizenz nicht dazu.
Also hat Apple APFS entwickelt, was aber wie BTRFS (Linux) und Hammer (OpenBSD) ZFS als Vorbild hat und versucht die selbe Funktionalität zu bieten.
Also Filesystem und VolumeManager in einem, Snapshots etc.
Die Parallelen sind doch mehr als deutlich, vor allem mit dem Hintergrund des geplatzten ZFS-Deals mit Sun, später Oracle.
 
Das ist nicht wirklich korrekt. Zum Einen: Man weiss nicht ob es an der Lizenz lag. Man weiss nur dass Apple ZFS sehr genau in Augenschein nahm und kein Deal zustande kam. Details sind nicht bekannt.

Zum Anderen: beide File Systeme haben moderne Features, ja. Andrerseits gibt es deutliche Unterschiede.
Von Klon kann definitiv nicht im Ansatz die Rede sein, zu unterschiedlich sind sie sowohl in Features, Entwicklungsgeschichte und Zielgruppe (Massive Server vs. Mobile Devices, Macs)
 
Nun gut, mag man sehen wie man will.
Da dies aber keine Diskussion "Klon oder kein Klon" werden soll: Zurück zur Kernfrage.
Nutzt (außer mir jemand ZFS auf dem Mac?
Denn (wie ich finde) hat ZFS doch einige deutliche Vorteile und mehr Features als APFS (Kompression, Checksummen, Deduplication, Cache bzw. FusionDrive-Funktionalität, bedeutend ausgereifter, nutzbar ab MountainLion, kompatibel mit Linux und FreeBSD etc.
Hervorzuheben sind die Reparaturmöglichkeiten.
Bei APFS bleibt nur das zurückspielen eines (wenn vorhanden) Snapshot oder Backups wenn das FS doch mal (wegen Stromausfall oder so) defekt geht.
 
ZFS ist schon interessant. Ist es denn stabil am Mac? Unter Linux (ZoL) scheint es so zu sein, dennoch gibt es Kontroversen.

Wie sind denn deine Erfahrungen?
 
Nein, soll keine Umfrage sein.
Ich schrieb ja auch, daß ich ein How-To bei Interesse veröffentlichen würde.
Wenn nicht, dann nicht, ich will niemanden zwingen oder auffordern ZFS zu nutzen. ;-)
Meine Erfahrungen sind sehr gut damit.
Nutze es schon über 1 Jahr und will es nicht mehr hergeben.
Habe weder Datenausfälle oder Probleme.
 
Ein How-To, mit einführenden Erläuterungen der Vorteile, schadet sicher nicht. Die meisten hier im Forum werden sich mit den verschiedenen Dateisystemen sowieso nicht auskennen (merkt man ja oft, daß es schon zu Problemen kommt, wenn sie von einem anderen Betriebssystem wechseln oder mit ihm Sticks oder Platten austauschen).
Persönlich bin ich skeptisch, weil man halt nicht von älteren (Reserve-)Rechnern/Systemen zugreifen kann auf externe Speicher mit neueren Formaten, auch der Target mode Probleme bereiten dürfte. Da müssten die Vorteile schon recht deutlich sein.
 
Richtig. Ich hadere mit ZFS weil es sich bei den Open Varianten um eine andere Codebasis handelt als bei Oracle. Oracle ZFS dürfte über jeden Zweifel erhaben sein - bei den anderen Varianten bin ich nicht überzeugt.

Zudem bin ich nicht sicher ob ZFS abseits vom Server wirklich das ist was ich brauche
 
Also dann los, ich beschreibe hier mal kurz und knackig wie ich ein verschlüsseltes Raid (Mirror) mit Cache eingerichtet hab.
Also ein verschlüsseltes, komprimierendes, gespiegeltes "Fusion-Drive".
Fetter Text bedeutet Eingabe im Terminal.
WARNUNG: Backup ist wichtig! Wir formatieren hier Festplatten, das heißt, alle Daten darauf sind dann weg!
Als erstes installieren wir uns ZFS von hier:
openzfsonosx.org
Dann brauchen wir noch einen Key, mit dem der Pool entschlüsselt wird.
Option ist die Eingabe eines Passworts im Terminal bei jedem Start oder ein Keyfile.
Aus Bequemlichkeit habe ich ein Keyfile genommen, daß auf die per FileVault verschlüsselte OSX-SSD gelegt wird.
Das heißt, man loggt sich beim Systemstart normal ein und erst dann ist das Keyfile lesbar bzw wird dann später geladen.
Ich habe eins mit Zufallsdaten erstellt:

sudo head -c 32 /dev/urandom > /sbin/enc4zfs

Dann schauen wir uns an wie die Festplatten heißen

diskutil list

Hier im Beispiel sind das:
disk0 -> Boot-SSD mit High Sierra
disk1 -> 1. 4TB-HD
disk2 -> 2. 4TB-HD
disk3 -> 3. 4TB-HD
disk4 -> 4. 4TB-HD
disk5 -> 120 GB-SSD

Nun legen mir den Pool an. Dabei sind vorhandene Partitionen auf den Platten egal, wir nutzen die kompletten Laufwerke.

sudo zpool create -f -o ashift=9 -O casesensitivity=insensitive -O normalization=formD -O encryption=on -O keylocation=file:///sbin/enc4zfs -O keyformat=raw Daten disk1 disk2 mirror disk3 disk4 cache disk5

Damit haben wir den Pool angelegt (der Name ist dann "Daten") incl. der Cache-SSD.
Wichtig ist -O casesensitivity=insensitive -O normalization=formD, sonst kann z.B. die iTunes-Mediathek nicht in den Pool kopiert und von dort genutzt werden.
Nun konfigurieren wir noch Kompression, Checksummen etc.

sudo zfs set checksum=fletcher4 atime=off compression=lz4 Daten

Dann die Berechtigungen setzen:

sudo chown -R username:admin /Volumes/Daten


Bei 'username' den eigenen Login-Name einsetzen.
Damit der Pool beim Start automatisch gemountet wird muss ein wenig getrickst werden. Ist nicht sehr elegant, aber funktioniert.
Wir legen ein Script /sbin/mount-ZFS.sh an:

sudo nano /sbin/mount-ZFS.sh


Inhalt wie folgt:

#!/bin/bash
sleep 2
/usr/local/bin/zfs load-key Daten
sleep 2
/usr/local/bin/zfs mount Daten


Mit Strg-X speichern wir das Script und machen es startfähig:

sudo chmod +x /sbin/mount-ZFS.sh


Dieses Skript lädt den Key und bindet den Pool ein.
Aufgerufen wird es über ein Applescript welches in die Anmeldeojekte gepackt wird.
Hier das Script:

delay 35
do shell script "sudo /sbin/mount-ZFS.sh"


Den Delay hab ich eingesetzt, damit OSX nach öffnen des Desktops genug Zeit hat die nötigen Treiber zu laden.
Da wir das Script aber mit 'sudo' aufrufen müssten wir nun bei jedem Start das Admin-Passwort eingeben.
Das können wir ändern wenn wir unserem User für das Mount-Script dauerhaft root-Rechte geben:

sudo visudo

Damit öffnen wir die sudoers-Datei und fügen folgende Zeile ein:

username ALL=NOPASSWD: /sbin/mount-ZFS.sh

wobei 'username' wieder unser Login-Name ist.
Wichtig ist, daß unser Script in /sbin liegt wo nur root Zugriff hat!
Liegt sie woanders könnte irgendwer der Zugriff auf den Mac hat die Datei ändern und somit beim Systemstart irgendwas mit Root-Rechten starten!

Das wars eigentlich schon...
Klingt ziemlich kompliziert, ist es aber nicht wenn man mal verstanden hat was da passiert.
Auf Openzfs.org gibt es auch ein Wiki welches das auch nochmal beschreibt.
Da hier das Interesse ja nicht besonders groß an ZFS ist nur eine Kurzanleitung...
 
  • Gefällt mir
Reaktionen: iToxi, troubadix2004, Hans-Ulrich und 2 andere
Ich nutze ZFS unter Solaris 11.3. Zählt das auch? Naja, eigentlich nutzt es mein Arbeitgeber. Privat würde ich es auch nutzen, wenn ich ein größeres NAS hätte. Der eingebaute Volume Manager und die snapshots sind schon tolle Features.
 
Leider haben ZFS auf Solaris und OpenZFS verschiedene Code Basen.

Ich hatte schon mal gefragt: wie sind eure Erfahrungen mit OpenZFS bzw. kennt jemand einen ernsthaften Vergleich?

ZFS on Linux wird ja - obwohl "stabil" - immer noch kontrovers gesehen. Ich bin nicht sicher was ich davon halten soll... ich hab auf meiner Linux - Maschine BtrFS laufen und schiele immer mal wieder auf ZFS ohne mich bisher darauf gestürzt zu haben.

Zur Info: Es handelt sich dabei eher um Datengräber, d.h. Backups meiner diversen Coding-Projekte, Mediendateien, alles was der gemeine Poweruser so hat.
 
Leider haben ZFS auf Solaris und OpenZFS verschiedene Code Basen.
Naja, OpenZFS bringt diese verschiedenen Code Basen ja wieder zusammen, so daß ZFS von Illumos, FreeBSD, Linux und OSX letztendlich die selbe Basis haben:
http://open-zfs.org/wiki/Main_Page
Ich hatte schon mal gefragt: wie sind eure Erfahrungen mit OpenZFS bzw. kennt jemand einen ernsthaften Vergleich?
Vergleich womit?
Meine Erfahrungen sind durchaus positiv, sowohl mit FreeBSD und OSX.
APFS kann da mMn noch lange nicht mithalten. Größter Vorteil ist, man kann den selben Pool auf Multiboot-Rechnern sowohl von Linux, FreeBSD und OSX nutzen.
Sogar mit älterem OSX (ab Mountain Lion). Besser als das mittlerweile 20 Jahre alte HFS+ ist es allemal.
ZFS on Linux wird ja - obwohl "stabil" - immer noch kontrovers gesehen. Ich bin nicht sicher was ich davon halten soll..-
Kommt drauf an "welches" ZFS du mit Linux nutz. Das "offizielle" per FUSE oder das andere direkt im Kernel.
Per FUSE ist das allerdings wirklich nicht alltagstauglich. Schon rein von der Performance her.
Und weil es eben im Userspace läuft, mit den üblichen Nachteilen...
 
...habe meine VMs als zvols in mehreren ZFS-Pools liegen, das klappt prima - mit massig ECC-RAM. Allerdings sollten die Platten schnell sein: Mit den WD Red komme ich nur auf ca. 2/3 der erwartbaren Lesegeschwindigkeit, im SSD-Pool rennt das Ding dagegen prima. Ich hab es bisher nur mit VM-Zvols ausprobiert, kann gut sein daß ‘normale‘ Datasets auch mit lahmen Platten schneller sind.
 
Interessant, das mit der Zusammenführung des Codes ist mir neu. Ich ging bisher davon aus daß Oracle da nicht mitspielt.

Wofür bzw. auf welcher Maschine hast du ZFS am laufen? APFS ist so schlecht nicht, nur eben nicht für den Einsatz auf Schwermetall geeicht, sondern für iOS/Notebooks/Desktop. Welche Vorteile hätte denn ZFS an einem Macbook?

Am Datengrab sieht die Sache natürlich anders aus, aber - und daher meine Fragerei - ich habe keine Datenbanken oder ähnliches am Laufen; einfach nur per Samba eingebundene Laufwerke, wo ich im Dateisystem meine Daten ablege. Macht ZFS da Sinn?

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?

NAS? Meine Vermutung: Ja, wegen Datensicherheit
Am Datenbankserver?

Andrerseits: Development Maschine (Stichwort Performance)?

wie @bowman angemerkt hat: Macht ZFS ohne ECC RAM überhaupt Sinn? Wenn ich mich recht entsinne meinen die Herren von iXSystems: Nein

Hoffe ihr bekommt eine Idee worauf ich raus will
 
Allerdings sollten die Platten schnell sein: Mit den WD Red komme ich nur auf ca. 2/3 der erwartbaren Lesegeschwindigkeit, im SSD-Pool rennt das Ding dagegen prima. Ich hab es bisher nur mit VM-Zvols ausprobiert, kann gut sein daß ‘normale‘ Datasets auch mit lahmen Platten schneller sind.
Schon mal versucht eine SSD wie in meinem HowTo als Cache einzubinden?
Damit legst du den L2ARC auf die SSD. Wie ich oben schon schrieb, ist quasi wie ein Fusion-Drive.
Ist hier schön beschrieben. Zwar für Linux, geht aber auch bei OSX und macht verdammt viel Speed!
Einfach mit 'zpool add mypool cache diskX' SSD zum bestehenden Pool packen.
https://anysrc.net/post/gnu-linux/zfs-ssd-cache-benchmark
 
Ich klinke mich hier mal aus Interesse mit ein, sehr schöne Diskussion. Mit ZFS hab ich bisher ausschließlich auf Solaris Erfahrung machen dürfen und kann zumindest hiervon nichts negatives berichten. Leider hat es uns damals einen unserer großen Pools aufgrund eines low-level Fehlers im RAID-Treiber von Solaris zerschossen (Überlauf in der CRC-Prüfsummenberechnung der anschließend statt konsistenter Daten Schotter auf die Platten geschrieben hat), so dass das ganze Projekt einen eher negativen Beigeschmack bekommen hab obwohl ZFS selber dafür gar nichts konnte. Unter Linux bin ich seit eh und je extrem konservativ und vorsichtig was Dateisysteme angeht: da traue Btrfs auch noch nicht und setze bei großen Datengräbern (16TB+) seit Jahren auf XFS. Im Labor habe ich bereits erste Gehversuche mit RHEL7 und Btrfs unternommen, allerdings hat sich Btrfs in allen Tests erstaunlicherweise als langsamer herausgestellt als XFS, was mich dann doch überrascht hat. Bei OpenZFS bin ich mindestens genauso vorsichtig, das hat für mich ähnlich wie Btrfs noch den Stempel "experimental". Da bin ich wohl ähnlich veranlagt wie Loki Mephisto: ich weiß nicht, was ich davon halten soll. Allerdings würde ich dem FS keinerlei geschäftskritische Daten anvertrauen. Bis ich einem Dateisystem so weit traue vergehen Äonen...

Ist übrigens auch einer der Gründe, warum ich APFS sehr vorsichtig und der Zwangsbeglückung mit High Sierra extremst kritisch gegenüberstehe. Ich musste mein MacBook Pro wegen eines Kunden kürzlich leider umstellen und auf High Sierra aktualisieren, seitdem schlafe ich irgendwie sehr sehr unruhig :rolleyes:
 
Leider hat es uns damals einen unserer großen Pools aufgrund eines low-level Fehlers im RAID-Treiber von Solaris zerschossen (Überlauf in der CRC-Prüfsummenberechnung der anschließend statt konsistenter Daten Schotter auf die Platten geschrieben hat), so dass das ganze Projekt einen eher negativen Beigeschmack bekommen hab obwohl ZFS selber dafür gar nichts konnte.

...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.
 
Schon mal versucht eine SSD wie in meinem HowTo als Cache einzubinden?
Damit legst du den L2ARC auf die SSD. Wie ich oben schon schrieb, ist quasi wie ein Fusion-Drive.
Ist hier schön beschrieben. Zwar für Linux, geht aber auch bei OSX und macht verdammt viel Speed!
Einfach mit 'zpool add mypool cache diskX' SSD zum bestehenden Pool packen.
https://anysrc.net/post/gnu-linux/zfs-ssd-cache-benchmark

...ein L2ARC kann als Lesecache enorm beschleunigen, wenn man es mit 'heissen' Daten zu tun hat, die häufig gelesen werden und aufgrund ihrer Grösse nicht mehr ins RAM passen. Bei Rechenzentrumsanwendungen ist das sinnvoll, bei mir Zuhause reicht mir für das übliche 'Kleinzeugs' das vorhandene RAM. Die Reschwindigkeitsprobleme treten auch eigentlich nur bei sehr grossen Dateien auf, auf die selten zugegriffen wird. Ähnliches gilt für das Schreiben: Auch hier kann man ein SLOG auf SSD auslagern, das bringts allerdings nur bei synchronen IOs (z.B. Datenbanken oder NFS-Shares) die in meinem Anwendungsfall auch kaum relevant sind.

PS: Der von dir zitierete Geschwindigkeitstest ist ziemlich für die Füsse: Mit dd kriege ich auch ein enormes Tempo hin, einfach weil das extensive Caching von ZFS im Hostsystem (das Script flusht zwar den Cache, aber innerhalb der VM) das meiste noch im RAM vorhält, hinzu kommt das das genannte Script nur Nullen schreibt, die von ZFS eh komprimiert werden. Sinnvollere Tests macht man eher mit fio und iostat, indem man z.B. eine 4G-Datei mit Zufallsdaten über 5 Minuten schreibt

fio --rw=write --name=test --size=4000M --refill_buffers --runtime=300 --time_based

und sich währenddessen die IOs in 30s-Intervallen anzeigen lässt:

zpool iostat -v 30

Selbst die damit ermittelten Werte sehen bei mir noch gut aus, ich vermute daher, daß die Ursache eher mit der KVM-Virtualisierung oder der Firmware des MB zu tun hat. Ich rede allerdings von Linux, das ist hier also ein bisschen OT... ;-)
 
Zurück
Oben Unten