War nicht die automatische Defragmentierung (Durch neu schreiben beim öffnen) einer Vorteile von HFS+ alias macos journaled?

Ich frag mich ja immer noch warum man die ZFS Unterstützung eingestellt hat. Immerhin ist es kern ein BSD 🧐🤔

F. Flor
Besser dass sie es getan haben, Oracle hat das ganze bereits 2010 De-Open-Sourced:

Nach meiner Erinnerung ist man mit Oracle (aka sun) nicht einig geworden.
Aber was Offizielles hab ich nie gelesen. Kann also auch ein Gerücht sein.
So wie Oracle mit Kunden umspringt, würd' ich von denen aber auch nix kaufen.

Außerdem war einer der (mit)entscheidenden Gründe *gegen* ZFS die schlechte Skalierbarkeit ‚nach unten‘ (sprich Apple Watch, iOS-Geräte etc.).

ZFS ist mit viiiiieeel RAM sicher toll, ohne diesen aber nicht verlässlich und performant genug.

Das Problem an ZFS ist, dass es ein 128bit Dateisystem ist. Das verwendet man nur, wenn man es wirklich braucht. Der Overhead auf 64bit Systemen ist enorm.
Deswegen wurden 64bit Alternativen mit ähnlichem Funktionsumfang entwickelt. Für Linux (auch wegen der ZFS Lizenz) btrfs, und für macOS eben APFS.

Fragt sich ein enttäuschter Adam Leventhal (der nah am Geschehen dran war) auch und erklärt und erläutert's aus seiner Sicht und mit seinem Insider- und Hintergrundwissen in diesem Blogeintrag:

Adam Leventhal's blog (15.06.2016): ZFS: Apple’s New Filesystem That Wasn’t

ZFS ist einfach nur geil, nix anderes. Für NAS SAN etc. für ein Arbeitssystem benötigt es einfach zuviel Speicher. Kleines Beispiel. Selbstbau NAS mit 8 GB RAM schaffte rd. Lesen Schreiben 70 MB Sec im Netz, mit 16 GB Speicher sind’s auf sonst der gleichen HW immerhin 90 MB/s. Der Aufbau in einzelnen Pools und ne Redundanzstufe mit bis zu drei Platten, Ist einfach Klasse, setzt man ein NAS mit ECC Speicher ein kann man recht sicher sein das die Daten auch in 20 Jahren noch valide sind (vorausgesetzt man startet zwischendurch das Scrubbing) aber nicht als System Filesystem.

Apples letzter ZFS Code, Open Source (rübergerettet, kurz bevor Apple es vom Netz nahm von opensource.apple.com zu Google Code: maczfs, als Google Code schloss (ist nur noch read-only), rüberverfrachtet zu GitHub: mac-zfs (MacZFS) – Continuing where Apple left off with ZFS. und daran weiterentwickelt innerhalb der Community inkl. Apple-Entwicklern). Gleichzeitig entstand vom ehemaligen Apple'schen ZFS-Chef-Entwickler, der sich aus Apple rausgelöst hatte, ein kommerzieller ZFS-Port, ZEVO (ZFS for Mac OS X), den er unter dem Dach der Firma Tens Complements kommerziell vermarktete, diese Firma wurde dann von Greenbytes aufgekauft, welche diesen ZEVO-Code dann wiederum für die Allgemeinheit freigab, GreenBytes wurde dann später von Oracle aufgekauft, weshalb der vorhe....

Desweiteren gibt es OpenZFS mit vielen verschiedenen Portierungen für alle möglichen Unix-Be... und als integraler Bestandteil davon eine Portierung von OpenZFS auf macOS namens OpenZFS on OSX, OpenZFSOnOSX. MacZFS ist inzwischen in OpenZFS aufgegangen, ebenso auch der ZEVO-Code von Tens Complements/Greenbytes. Sprich: Apples ZFS-Code, also Apples eigene Anpassungen für macOS sowie der Code von Apples ehemaligem ZFS-Chefentwickler, der in ZEVO gesteckt hat, existieren und leben weiter, sind Bestandteil von OpenZFS bzw. von OpenZFS on OSX. Das Community-Projekt OpenZFS vereint und bündelt alle ZFS-Stränge unter einem Dach-Projekt, u.a. ehemalige Sun-/Oracle/Apple-Entwicker sind Teil von dessen Community.

Apple hätte einfach den Faden wieder aufnehmen können, an ihren eigenen Portierungs-Code für die Mac-Plattform wieder anknüpfen müssen, der ja weiterhin existiert und in OpenZFS weiterlebt. Apple hätte sich in OpenZFS einbringen und engagieren können, wichtiger Teilnehmer und Träger dieses Projektes werden können, den Mac-Port, der ja Apples eigenen bisherigen Mac-Pattform-Code bereits enthält, ihre frühere Arbeit in dem Rahmen unter diesem neuen Dach aus erster Hand weiterformen und optimieren und OpenZFS mitgestalten können, so dass es für ihre Plattform optimal passt, auch vom Speicherverbrauch her, auch was die Ausrichtung hin zu SSDs angeht.

Apple wolte aber wohl nicht, hat sich dagegen und anders entschieden, hat sich gegen diese eigentlich naheliegende und durchaus sinnhafte Möglichkeit entschieden, selbst dann, als die Patent-Klage von NetApp endgültig vom Tisch und von Oracle beigelegt war, Apple wollte diesen Faden, den sie mal angefangen hatten und fast bis zur Serienreife gebracht hatten (immerhin wurde MacOS Leopard damit offiziell beworben, bei den Leopard Server Developer Previews war's bereits drin, ist dann in der Release Version urplötzlich nicht mehr drin gewesen und folglich dann auch in Leopard Desktop und allen nachfolgenden Versionen nicht), wohl nicht wieder aufnehmen, wollte mit APFS lieber wieder bei Null anfangen und stattdessen lieber was Eigenes machen. Ob APFS wirklich besser sein wird als wenn sie die Energie dafür reingesteckt hätten in das im Gegensatz dazu über Jahre maturierte und in der Praxis bereits durch alle nur denkbaren Herausforderungen gegangene OpenZFS bzw. dessen Mac-Port, OpenZFS for OSX, welcher ja bereits ihren eigenen Gehirnschmalz und Entwickler-Zeit beinhaltet und sie das nur hätten forführen und auf die Bedarfe von heute anpassen müssen, das ist eine rein hypothetische Frage, die wohl niemand wird je beantworten können, weil es eben nie dazu kam.

Ich denke aber, Apple hätte das ohnehin maturierte und stabile OpenZFS mit relativ wenig Aufwand genügsamer bekommen und auch für ihre Embedded Systems wie Smartphones/Tablets/Uhren bzw. SSDs anpassen und optimieren können, ich denke, das hätten sie hinbekommen, das wäre kein Ding der Unmöglichkeit gewesen und von überschaubarem Aufwand und Zeitaufwand und dabei rock-solid. Aber: "Hätte, hätte, Fahrradkette." Es ist nicht, es hat nicht sollen sein. Es ist schade, aber so isses.

Die Lizenz, die CDDL, unter der ZFS immer stand und immer noch steht, ist für Apple jedenfalls kein Problem gewesen, für Apple erst recht nicht – auch Leventhal hat darauf hingewiesen, schließlich steht DTrace ebenfalls unter derselben CDDL-Lizenz, und Apple hatte keine Schwierigkeiten, Sun/Oracles DTrace aus Solaris zu übernehmen und in Xcode zu integrieren (nennt sich dort: Instruments).

Das bekommt man mit btrfs auch hin, ohne den Overhead von ZFS.

Aber nicht so schön wie mit ZFS, außerdem ist ZFS schon seit vielen Jahren stable, BTRFS ist seit wann stable?

athlonet:
don.redhorse:

Außerdem steht BTRFS lizenzmäßig unter der GPL (GPL 2), und die mag Apple sicher nicht so gerne, meidet/umgeht sie zugunsten BSD-artiger-Lizenzen wo es nur geht und mag sie damit sicher weniger als die von der Mozilla Public License abgeleitete BSD-artige CDDL-Lizenz unter der ZFS steht. Sun hatte, bevor sie von Oracle übernommen wurden, fest vor, unter der Führung von Suns damaligem Open-Source-Chef Simon Phipps – heute ist er seit Jahren der Document Foundation/LibreOffice vorständig, sitzt dort im Board of Directors und bringt sich dort seit Jahren ein, ZFS unter die GPL 2 – sogar die GPL 3 – zu stellen, scheiterte damals aber an internen Widerständen – die mittlerweile so nicht mehr existieren – einzelner Sun-Entwickler, die dazu damals ihr OK verweigerten.

Oracle als Suns Rechtsnachfolger und selber Anbieter nicht nur von Solaris, sondern mit noch viel mehr Engagement auch von einer eigenen Red-Hat-basierten eigenen Linux-Distribution, ließ letztes Jahr im Oktober 2017 durchblicken, dass diesbzgl. die letzte Messe noch nicht gesungen sei, dass man diesen Faden evtl. wieder aufnehmen wird, dass man genau das, also die Überführung zu GPL-Lizenz evtl. in naher Zukunft doch nachholen könnte/würde bzw. zumindest nicht abgeneigt sei, sich auf jeden Fall weiter öffnen wird diesbzgl. und ZFS unter Linux zu einem First Class Citizen[/url] machen (naheliegend zuungunsten des von ihnen selbst aus der Taufe gehobenen und immer mehr vernachlässigten BTRFS – u.a. ist dessen Chef-Entwickler Steve Mason von Oracle weggegangen und zu Facebook gewechselt, seitdem tut sich seitens Oracle da nicht mehr viel, andere Distributionen entwicken an BTRFS mittlerweile weiter) wird mit dem Weg: sie integrieren ZFS fest in ihre eigene Linux-Distribution, machen es dort zu ihrem Haupt- und Standard-Dateisystem und pushen das dann upstream in die allgemeinen Linux-Kernel-Quellen, stellen es also der Allgemeinheit zur Verfügung, andere Distributionen können es dann von dort ggf. nehmen und dem Beispiel folgen, wenn sie wollen).

Danke sierkb, sehr ausführlich erläutert 👍

Nö, schon lange nicht mehr. Die automatische Defragmentierung greift nur bei (sehr) kleinen Dateien und nur wenn wirklich lächerlich viele Fragmente vorhanden sind. Hab' die genauen Zahlen gerade nicht auswendig parat. In der Praxis heißt das aber, dass die automatische Defragmentierung nahezu nie läuft und man sinnvollerweise hin und wieder per Defragmentier-Programm nachhelfen sollte - wie bei Windows halt auch.
Wär gut, wenn Apple das endlich in den Griff kriegt...

mdopp das passiert nur wenn man die Platten quasi immer voll hat. Wenn über 10% frei sind klappt es sehr gut, bei mehr frei richtig gut. Habe schon seit Ewigkeiten keine Tools dieser Art mehr eingesetzt, ist einfach unnütz und macht eher Probleme als das es hilft.