Pro-Linux.de (18.09.2013): OpenZFS startet
Das Projekt OpenZFS hat seine Existenz bekannt gegeben. Das von Sun initiierte Dateisystem soll nun ein gemeinschaftlich entwickeltes offenes Projekt für Linux, FreeBSD, Illumos und OS X werden.

OpenZFS (17.09.2013): OpenZFS launch announcement

OpenZFS

Hoffentlich wird das diesmal was (für OSX, bei den anderen scheint ZFS ja schon brauchbar zu sein).

Unter Solaris habe ich auch ZFS laufen und es macht was es soll, für den Endnutzer nicht zu spüren, bietet aber viele Features im Vergleich zu betagten HFS+

Danke für die Links.
Ohne mich jetzt einzulesen, was bringt OpenZFS für Vorteile gegenüber HFS+?

Interessant ist es eigentlich eher im Server Bereich. Für den Endverbraucher, also den normalen Nutzer oder den "Pro" Nutzer gibt es momentan keine Nennenswerten Vorteile. Deswegen halte ich eine Notwendigkeit diese System als Standard zu implementieren für überflüssig.

Die Management und Skalierungsvorteile braucht man als Privatanwender sicherlich kaum, aber Checksummen und Auto-Repair (sofern man RAID 1 oder RAID-Z einsetzt) wären auch für Privat-Anwender ein sinnvoller Fortschritt.

Ich finde, gerade die Blockchecksummen sollten AUCH für den Enduser relevant sein. Und die Snapshots klingen interessant.

Auf Wikipedia dürfte das Relevante stehen:

ZEVO Silver edition hat schon wirklich gut funktioniert.
Der Support von Ten's compliment war damals ausgezeichnet und Don Brady kennt sich mit Mac Dateisystemen eben aus.

Hier gibt es jetzt eine Community-Edition:


Ich finde es immer noch schade, dass Apple die offiziellen Pläne für ZFS über den Haufen geworfen hat.
In manchen Bereichen merkt man HFS(+) das Alter schon an.

Schön, dass jetzt mit OpenZFS wieder ein bisschen Schwung in die Sache kommt.

Aber sicher doch gibt es auch für den Endanwender Vorteile. Immense sogar. Zum Beispiel in Bezug auf TimeMachine, das würde unter ZFS nämlich erst so richtig zur Hochform auflaufen und dem normlen Anwender ganz erhebliche Geschwindigkeitsvorteile bringen. Warum? Weil das betagte HFS+ nicht atomar (sprich: bitweise) speichern kann, sondern nur dateiweise. Ändert sich eine Datei, so wird unter HFS+ dann die ganze Datei kopiert/geschrieben. Besonders bei großen Dateien (z.B. große Photoshop-Dateien oder auch Images einer zum Einsatz kommenden virtuellen Maschine, in der z.B. Windows oder Linux läuft) ist das dann bemerkbar, es muss dann unter HFS+ immer die komplette Datei auf dem TimeMachine-Backup gesichert werden, selbst wenn es nur minimalste Änderungen gab. Unter ZFS, das Dateiänderungen atomar, also bitweise vornehmen kann, werden vom Dateisystem eben nur die tatsächlich differierenden Bits einer Datei übertragen und geschrieben. Das beschleunigt einen Backup-Vorgang enorm und reduziert ihn auf das Wesentliche.

In der Praxis bedeutet dies zum Beispiel bei einer 30GB angelegten Windows-VM-Datei: selbst wenn die VM mit Windows nur gestartet worden ist und gleich wieder beendet worden ist, also kaum Dateiänderungen stattefunden haben, wird unter HFS+, weil's ein dateiorientiertes Dateisystem ist, die 30GB große VM-Datei komplett neu geschrieben auf dem TimeMachine-Speichermedium. Ein Vorgang, der, je nach Größe der Datei und je nach Leitungsanbindung des TimeMachine-Speichermediums, durchaus ein paar Minuten in Anspruch nehmen kann.
Unter ZFS, das atomar und bitweise arbeitet, werden bei demselben Vorgang lediglich die Bits der 30GB-großen VM-Datei auf das Backup-Medium gesichert, die sich tatsächlich geändert haben. Dadurch ist der Sicherungsvorgang ungleich schneller, dauert nur wenige Sekunden, wenn überhaupt. ZFS arbeitet da also wie ein modernes Versionsverwaltungs-System (VCS), wie z.B. Subversion, Git oder Mercurial welche sind.

Auch die unter Lion eingeführte Versionsverwaltung von Dateien, die auf Systemen, die noch keine SSD-Festplatte ihr eigen nennen, die Festplatte ganz schön auslasten und ausbremsen kann, könnte auf diese Weise ungemein in puncto Schnelligkeit und weniger Auslastung der Festplatte davon profitieren, indem Dateiänderungen atomar, also bitweise, vorgenommen würden, statt jedes Mal, wie is unter HFS+ bisher der Fall ist, die ganze Datei anzupacken und zu sichern, selbst wenn sich an dieser Datei nur wenige Bits geändet haben.

Ich glaube schon, dass der normale Anwender angesichts dieser zuweilen und erst recht in der Summe doch sehr spürbaren Geschwindigkeitsvorteile sehr erfreut und dankar wäre, davon profitieren zu können (zumal als angenehmem Nebeneffekt ein Weniger an Lese- und Schreibzugriffen auf die Festplatte mit Sicherheit auch eine längere Lebensdauer derselben bedeutet, was sowohl für die klassische Festplatte gilt als auch für die modernen SSD- bzw. Hybridfestplatten, und gerade solche Dinge wie die im Hintergrund automatisch ablaufende Versionsverwaltung, internes bzw. externes TimeMachine-Backup und auch Spotlight-Indizierungen bedeuten in der Praxis ganz schön viele Festplattenzugriffe und Datei- Hin- und Hergesichere, die da regelmäßig stattfinden). ZFS oder ein ZFS-ähnliches Dateisystem (z.B. das von Oracle vor allem für Linux entwickelte Btrfs-Dateisystem) als standardmäßiges Dateisystem unter OSX könnte alledem im normalen Alltag für den normalen Anwender neue Höhenflüge bescheren in Bezug auf eine bisher nicht gekannte "Smoothigkeit" und Unmittelbarkeit des Betriebssystems selber und seiner angebotenen Dienste.

Danke für die ausführliche Erklärung.
Wenn das wirklich so ist und auch grundlegend so umgesetzt wird, dann macht es mehr Sinn als bei HFS+.

Hat ZFS denn auch irgendwelche Nachteile (z.B. gegenüber HFS+)?
Ist es schon länger erprobt? Warum hat Apple ZFS (vorübergehend?) über den Haufen geworfen?

Das stimmt aber einiges nicht an deinen Ausführungen.
Sowohl HFS+ als auch ZFS schreiben blockweise.
"Atomares Schreiben" bei ZFS bedeutet, dass der Schreibvorgang einer Datei entweder ganz oder gar nicht stattfindet. Wenn du also den Stecker ziehst, hast du entweder den alten oder den neuen Zustand, aber keinen inkonsistenten Datenmüll.
In Bezug auf Backups ist die Snapshot-Funktion von ZFS durchaus sinnvoll. Dabei wird der Snapshot aber erstmal lokal gesichert (in Sekunden/-bruchteilen)... Änderungen überschreiben dann nicht die alten Blöcke, sondern werden auf neue, freie Blöcke geschrieben.
Beim Backup auf den Server darfst du dann nicht vergessen, dass es sich dabei um ein Backup auf FS-Ebene handelt. Eine einzelne Datei zu restoren, wie bei Timemachine ist dann für den Laien nicht mehr so trivial, geschweige denn, danach zu browsen.

Möglicherweise ist es etwas weniger performant, vor allem auf nur einer Platte. Zumindest ist das im Vergleich zu FFS auf FreeBSD erfahrungsgemäß der Fall. Einige Features (wie z.B. Deduplication) sind auch relativ Performance-/Speicherhungrig.
Das FS existiert seit 2006 und hat seine Verbreitung vor allem in größeren Rechenzentren; Ich denke entsprechend erprobt wird es sein.
Warum Apple es über den Haufen geworfen hat - keine Ahnung. Vielleicht konnten sie es einerseits nicht simpel genug für Endanwender umsetzen, andererseits ist es bekannt, dass Apple die Server-Sparte eher stiefmütterlich behandelt.

Kleiner Nachtrag:
durch den 128Bit-Adressraum geht auch einiges an Performance und Plattenplatz verloren.

Vielen Dank für deine Erklärungen!

Timmeyy:

FH Wedel: Funktionen von ZFS , Durchführung von Schreiboperationen

Weil Sun Microsystems, der damalige Inhaber und Erfinder von ZFS, sich aus heiterem Himmel und nachdem sich Apple von Sun eine Lizenz bzw. Zusammenarbeit für MacOSX Leopard gesichert hatte (Apple kündigte werbewirksam ZFS-Support für Leopard an, hatte es sogar schon in den Developer Previews drin, es konnte händisch aktiviert werden) mit einer Patentklage seitens der Firma NetApp konfrontiert sah (Sun hielt dagegen mit ihrerseits einer umfangreichen Patentklage gegen NetApp) und zum damaligen Zeitpunkt keiner wusste, wie diese Klage-Schlacht ausgeht, ob Sun verlieren oder obsiegen wird. Apple wollte von Sun damals im Angesicht dieser zunächst drohenden und dann eingetroffenen NetApp-Klage und damit unsicheren rechtlchen Situation von Sun Garantien haben, dass Apple, falls Sun die Patentklage gegen NetApp verlöre, schadlos bleiben sollte, also dass Sun auch dann dafür geradestehen sollte, falls in der weiteren Folge auch Apple wegen des Einsatzes von ZFS verklagt würde bzw. Apple an NetApp Lizenzen abzudrücken hätte. Auf diese weitgehenden Forderungen Apples konnte und wollte Sun nicht eingehen, solche weitgehenden Garantien bzw. solches weitgehendes Kopf-Hinhalten für Apple im Fall einer Klage auch gegen Apple war Sun damals nicht bereit abzugeben. Die Folge war, dass Apple von diesem Vorhaben mit ZFS abließ, das begonnene Mac-Portierungsprojekt inklusive offenem Sourcecode, welches in Apples Open-Source-Bucht Mac Os forge angesiedelt war, sofort einfror und das Projekt dann gänzlich einstampfte und die geplante und bereits fast fertige ZFS-Einbindung in MacOSX komplett strich und rückabwickelte.

Als Oracle Sun nicht lange später übernahm bzw. kaufte, war dies eine der ersten Amtshandlungen seitens Oracle: diesen Patentstreit mit NetApp irgendwie beizulegen (man ließ beiderseits alle Klagen fallen und einigte sich außergerichtlich, die gegenseitigen Bedingungen sind unter Verschluß) und Ruhe ins Schiff zu bringen:

Golem (09.09.2010): ZFS: NetApp und Oracle legen ihren Streit bei

swat.org: NetApp's filesystem patents

Ob Apple unter der nun zwischen Oracle und NetApp bereinigten Situation erneutes Interesse an ZFS anmelden wird oder schon hat oder das Ganze für immer komplett verworfen hat, darüber herrscht Unklarheit. Fakt ist, dass Apple vor 1 oder 2 Jahren eine Stellenausschreibung laufen hatte und jemanden suchte, der sich mit Dateisystemen bzw. dem Entwickeln von Dateisystemen gut auskennt. Ob Apple an einem Nachfolger von HFS+ bastelt und ob dieser Nachfolger auf HFS+ aufbaut, oder ob's etwas völlig Neues wird? Who knows? Das Entwickeln, Testen, Maturieren, eines neuen Dateisystems von dieser Größenordnung und Wichtigkeit braucht Jahre, wenn nicht sogar ein gutes Jahrzehnt.

Welcher meiner Aussagen widerspricht das jetzt?
Ich habe 06/07 für Sun Microsystems gearbeitet und eine Umgebung mit ZFS für einen bekannten Sportartikelhersteller umgesetzt. Da gab es ganze Bücher darüber zu lesen, da ist eine Seminararbeit nicht unbedingt was besonders neues für mich.

"Im Gegensatz dazu arbeitet ZFS ähnlich wie ein Datenbanksystem nach einem transaktionsbasierten Konzept mit dem Prinzip "ändere dies an folgenden Dateien oder mache nichts". Da alle kritischen Schreibvorgänge atomar sind, ist das Filesystem immer konsistent. Sollte es zu einem schwerwiegenden Fehler beim Schreiben kommen, bleibt der letzte gültige Stand aktuell. Sobald das Problem behoben wurde, wird erneut versucht die Operation durchzuführen."
Das ist genau das, was ich gesagt habe: Du schreibst terrabyte-weise Daten auf die Platte. Bei einem herkömmlichen FS wird einfach Block für Block geschrieben - bei einem Stromausfall nach der Hälfte, hast du nur eine halbe Datei.
Beim Transaktionsprinzip gilt die Datei erst als geschrieben, wenn ganz zum Schluss ein einzelner, möglichst nicht unterbrechbarer ("atomarer") Befehl folgt (Bei Datenbanken heißt des "commit");
Du glaubst doch nicht ernsthaft, dass in einem FS, das für große Volumes/Datenmengen ausgelegt ist, jedes Bit einzeln adressiert wird (Die Default-Blockgröße ist btw. mit 128k auch größer als bei den meisten FS)?

Timmeyy:

Dann habe ich mich eben in Bezug auf das Bitweise geirrt (mea culpa), und es werden trotzdem nur jene einzelnen Blöcke (variabler Größe, Default-Wert wie Du sagst: 128kB, es ginge aber auch kleiner oder größer, je nach Bedarf/Sinnhaftigkeit und Anwendungsfall) geschrieben, die zwischen Neu und Alt differieren. Ist immer noch eine viel viel kleinere Größeneinheit gerade bei großen Dateien als komplett eine ganze Datei anzufassen und von dieser komplett alle Blöcke neu zu schreiben bzw. zu überschreiben, selbst wenn nur wenige Blöcke ausreichen würden, weil nur diese sich inhaltlich geändert haben:

Wie fehlerhaft HFS+ schon bei einfachen Kopiervorgängen arbeitet, wurde mal in einem paper eindrucksvoll (bzw. besser gesagt erschreckend) unter Beweis gestellt. Link habe ich leider gerade nicht zur Hand ...

Die Prüfsummen der Dateien stimmten nicht mehr überein, Stichwort bit rot etc.

Ich habe noch nie, wirklich noch nie Probleme beim Kopieren gehabt. Nicht eine einzige beschädigte Datei. Wo soll das also her kommen? Wenn das tatsächlich so erschreckend wäre, würde sich jedes System in kürzester Zeit zerlegen. So ganz kann das also nicht stimmen.

PaulMuadDib: Schau hier

Im Übrigen ist auch der Punkt mit den Transaktionen nicht gerade unerheblich. Wie oft kommt es noch vor, daß HFS+ einen zerwürfelten Verzeichnisbaum hat? Auch das Copy On Write will man haben.

PaulMuadDib: Genau das ist ja das Problem - "an der Oberfläche" bemerkt man solche Fehler eben nicht, sondern im schlimmsten Fall erst Jahre später!

Informiere Dich einfach mal zum Thema bit rot und Prüfsummen in Dateisystemen.

@sierkb ist das normal das du immer Dinge haben willst, wovon du eh nur einen Bruchteil verstehst ?

ZFS, XFS, MPFS,JFS.. sind designed für den Serverbetrieb. Wichtige Features sind nunmal für sehr große Dateien (Oracle DBs...) ,Dateisicherheit oder administrative Features ausgelegt.

Allein für "Main Features" wie pooling werden schon MINDESTENS 3 - 9 Platten empfohlen um gegen Datenbeschädigung gesichert zu sein.

Lesen von Text auf irgendwelchen Seiten ist übrigens etwas vollkommen anderes als das ganze selber im Lab getestet zu haben ! Deine geniale FS Performance wird jedenfalls argh runtergehen wenn das erste mal scrub los legt das Array zu prüfen.

Snapshots sind ein cooles Feature. Es ist halt das gleiche wie Shadow Copy unter Microsoft's ServerOS. Es nimmt aber extrem viel Platz weg falls du das ganze auf einem Desktop PC nutzen willst. Übrigens die Geschichte mit "Snapshots sind perfekt als Backup Lösung", solltest du zwingend aus dem Kopf schlagen. Es hat damit absolut nichts zu tun. Snapshots machen nichts anderes als speichern und abgleichen von Momentaufnahmen. Da man in der Regel gleich pools snapshotted wirst du schnell dtrace scripts schreiben wollen. Backups kommen generell auf extra Storage Systeme etc.

Je nachdem was Apple an default Features an den Start bringen würde, braucht der Enduser viel viel viel RAM. Allein für das deduplication feature sind 5 GB RAM pro 1 TB empfohlen ! Dazu dann noch ACLs, Quotas, Caching tweaks... wird der Bedarf weiter ansteigen.

Ich bin mir jetzt nicht sicher aber ich glaube fehlende Dinge wie das erweitern von Arrays im laufenden Betrieb kann ZFS noch immer nicht ? Ich hatte damals jedenfalls ein wenig unter FreeBSD gespielt und wollte Space wie mit mdadm einfach hinzufügen. Mit diesem vdev hatte ich das nicht hinbekommen. Die Manpage sagte man müsse ein neues Array nur für sowas erstellen ?!


Wieso schreiben hier auch soviele das HFS+ veraltet sei ? Es wird ständig aktualisiert und mit neuen Features versehen. Also wer glaubt das es damals schon Dinge wie ACLs, journaling gab, lebt hinter dem Mond.

Ein Dateisystem ist immer nur so gut wie die Hardware auf der es installiert ist. Will ich Speed und Stabilität, dann greif ich zu Enterprise Festplatten, ECC Speicher, Mainboard, Hardware Raid und was weiss ich nicht alles.


ZFS ist gut aber es ist ein "kleiner Hype" wie auch Iphones oder andere Spielwaren von Apple.

git push:

Ruhig, Brauner... Es ist noch kein Freitag.
Wenn ich mir Deine Beiträge mal so durchlese, die Du bisher hier bei MTN gebracht hast (so einigen davon stimme ich inhaltlich sehr zu, wenngleich auch nicht unbedingt immer in der Form bzw. im Tonfall) -- bin ich Dir grad' nicht Apple-kritisch genug gewesen ( ), oder warum raunst Du mich hier so von der Seite an und feuerst mal so auf Verdacht und zur Begrüßung Breitseite (ob's nun passt und der Situation angemessen ist oder nicht, zumal ich mit keinem Wort gesagt habe, ob und dass ich ZFS unbedingt haben will, aber eine ordentliche Verbesserung gegenüber dem bisherigen HFS+ wäre es mit ganz großer Wahrscheinlichkeit -- ich hätte auch gegen ein Btrfs oder XFS nix einzuwenden, wenn Apple es einsetzen würde), um Dich in größter Selbstüberzeugung à la "Hallo, hier komm' jetzt ich!" bemerkbar zu machen? Schlechten Tag gehabt? Oder brauchst Du sowas ab und zu zur Selbstbestätigung?

zu ZFS:

Wie git push schon ausführte, und ich auch von einigen ZFS Anwender habe mir berichten lassen, benötigt ZFS sehr viel RAM. Die 5GB RAM für 1 TB ZFS Speicher sind durchaus realistisch und damit, heute noch, für den Endanwender sehr teuer. Würde bedeuten das ein normaler Mac zwischen 8-16 GB RAM haben müsste, besser 16 GB.

sierkb:
Die Annahmen, dass herkömmliche Dateisysteme ganze Dateien neu schreiben, halte ich auch für falsch. Kein RDBMS würde sonst performant laufen - außer HANA vielleicht.
Kleines Fallbeispiel: Soweit ich weiß stecken hinter ITMS und Amazon Active Dataguard Datenbanken von Oracle. Wir gehen dabei mal vom quasi-Standard aus, dass keine Big File Tablespaces verwendet werden, die Datafiles aber bis zu 32GB groß sind. Das würde bedeuten, dass jeder Einkauf bei Amazon oder iTunes einen 32GB Schreibvorgang zur Folge hätte - auf jedem einzelnen Server.
Die meisten RDMBs laufen auch bei vermeintlich schwachen FSen (UFS, ext3/4, NTFS) noch vernünftig, auch über Netzanbindungen (iSCSI, NFS).

Was du vielleicht meinst: Wenn ich Backups basierend auf Snapshots mache und diese inkrementell via zfs send auf ein anderes Volume bzw. einen anderen Server schicke, sind die Datenmengen verhältnismäßig klein. ein Restore ist für Laienhände dann aber nicht unbedingt hassle-free, vor allem, wenn man, wie bei Time Machine üblich, nur eine Datei wiederherstellen will. Regelmäßige Full-Backups sollte man auch in Betracht ziehen.

Dedup lässt sich für Privatzwecke auch deaktivieren, das spart immens Arbeitsspeicher und man kommt schon fast mit handelsüblichen Mengen aus.
Ist wohl auch eher interessant, wenn die selbe Powerpoint-Präse an 300 Leute verschickt wird, als Festzustellen, ob man das selbe Foto vielleicht an 2 Stellen auf der Platte gespeichert hat.

Wie gesagt: Nie Streß. Nie. Fakt.

Was soll bei dem Link passieren? Nur ein komisches Bild kommt da.

Klar. Wie oft kommt das tatsächlich vor?
Hier wird so getan, als sei das ein ernsthaftes Problem und es müsse unbedingt was passieren. Sagt Euch eigentlich das Problem "Silent Data Loss" etwas? Glaube, das passiert statistisch genau so oft.

Häufig, für genau Zahlen muß man erstmal ein Datenformat verwenden mit dem man in der Lage ist, Bitfehler überhaupt aufspüren zu können. Die üblichen Applikationen verwenden unter OSX kein solches Format, so daß man gar nicht in der Lage ist festzustellen, daß man ein Problem hat. Ferner muß man ein System verwenden, daß komplett auf ECC setzt, weil man sonst Gefahr läuft Bitfehler im Arbeitsspeicher auf die Platte zu kopieren.

Also wenn es häufig vor kommt, muß man eine Auswirkung spüren. Oder macht es nix, wenn einzelne Bits einer ausführbaren Datei z.B. nicht mehr gleich sind? Wohl kaum …

Naja, das stimmt ja nun als generelle Aussage mal gar nicht. Es hängt davon ab welche Features man nutzt und mit welchen Paramtern man ZSF konfiguriert. Deduplication z.B. welche viel RAM braucht, braucht der normale Home-User wohl kaum. Ansonsten braucht ZFS zusätzlich zum eigenen Code erst einmal nur ca. 64kB je gemountetem FS um zu funktionieren und z.B. mindestens 64 MB für Log-Devices. Der Rest wird halt per default bis auf 1GB komplett als Cache verwendet und kann limitiert werden wenn es nötig ist, oder wird vom System bei Bedarf freigegeben.
s.a.: und
Bei Einsatz auf einem Desktop-OS würde man wohl kaum per Default alles als Cache verwenden und den ARC von Haus aus limitieren und für diesen Fall "vernünftige" Basis-Einstellungen für ARC, L2ARC und ZIL verwenden die nicht an Storage-Servern ausgerichtet sind.

Das ist doch der Gag: das GLAUBST du. Schau dir den Link ruhig mal an. Da wird genau dieser Fall demonstriert. Sogar so, daß du das selbst ausprobieren kannst.Steht doch ganz klar oben als Text. Hint: Cursor-Tasten benutzen.

Das Missverständnis, das bei vielen hier vorherrscht ist die Ansicht, dass ZFS ein Filesystem ist, das mit dem Gedanken an Desktop Workstations "designed" wurde. Dem ist aber nicht so.

Daher ist es kein einfacher Task - bzw. eher unwarscheinlich - dieses FS einfach in ein aktuell verbreitetes Desktop OS zu integrieren. Dagegen sprechen die erhöhten Anforderungen an die Ausstattungen der Filesystem Hardware (= Anzahl der Laufwerke), der Resourcen-Bedarf im laufenden Betrieb und nicht zulestzt die Komplexität bei der Administation - die sich nicht mehr so einfach in einem schmucken "Festplattendienstprogramm" verstecken ließe. Denn wenn man wirklich die Features die ZFS auszeichnen nutzen will, muss man wissen was man will und tut - und das ist eher was für Admins als für Joe User.

Denn auch die von Apple begonnene Impementierung von ZFS in OS X war nicht für den Desktop User gedacht. Die Integration war nämlich nur für OS X Server vorgesehen und selbst dort konnte z.B. OS X selbst nicht von einem ZFS Volume booten sondern "lediglich" Volumes für Daten anlegen und ansprechen.

Mit der hier gerne naiv propagierten Prädestination von ZFS für den Desktop-Betrieb oder gar Sicherungsmechnismen ala Versions und Time Machine, hatte das alles nix zu tun und ist ZFS als OS X Filesystem auch Meilenweit entfernt.

@sierkb

Ich bin leider immer sehr "direkt". Sagen meine Kollegen auch manchmal aber so bin ich nunmal.
Man glaubt es kaum aber ich habe einen Powermac G5 (mit OSX Leopard) und einen Intel Imac 2009 (super schickes Design mit FreeBSD) Zuhause.

@arekhon
Der Vorteil von ARC und Co. ist nunmal die Performance durch das nutzen des fast kompletten RAMs für die pools. Wenn ich jetzt alles limitieren muss weil der Desktop User nur 3-4 GB im Rechner hat, sind die Features für die Katz. Für L2 und Zil brauch ich zudem noch MLCs um ja auf gutem Performance Level zu bleiben. Kostet für den "Desktoper" also wieder extra und nicht vergessen, wir brauchen noch immer einen pool für die ganze Geschichte !

Willst du jetzt wirklich mit Phrasen kommen das der Enduser das unbedingt braucht und auch voll ausnutzt ?


Für Backups kann der OSX user ja weiterhin sein gutes robustes rsync umhüllt von der Time Machine Gui nutzen.

Etwas von voll ausnutzen oder brauchen habe ich nie geschrieben. Was man als Enduser wirklich brauchen kann ist IMO gar nicht viel. Mir als Enduser würden schon die Checksummen und die Self-Repair-Möglichkeit der redundanten RAID-Level reichen. Das würde ich als wesentlichen Fortschritt ansehen.

Und der gemeine Home-User wird auch mit kleinen Varianten von ARC, L2ARC und ZIL auskommen, Caching in dem Umfang wie ZFS es könnte ist doch sowieso nur für Server-Dienste wirklich interessant und nötig.
Ähnliche Funktion zumindest im Effekt für den End-User, nur additiv bei der Kapazität hat man ja auch heute schon als Fusion-Drive. Ist halt anfälliger, weil ja das FD kein Cache ist, sondern Primärdaten im "Cache" enthält.
Snapshots und vor allem Dedup kann man getrost weglassen für nicht Server-/Storage-Server Systeme.

Das könnte man also abgespeckt mit einigem Zusatznutzen wohl machen und wer mehr nutzen will braucht dann halt auch die passenden Resourcen - aber er hätte die OPTION!
Problematischer sehe ich eher die 128bit Pointer und alles was damit an Overhead zusammenhängt. Das bekommt man auch nicht weg indem man ZFS für Clients "kleinkonfiguriert".

Soll das eine Verasche sein? Klar geht das kaputt, wenn ich das absichtlich kaputtschreibe. Welchen Fall soll das simulieren? Ich rede von 1000000000000 mal Kopieren, z.B. Und mit glauben hat das auch nix zu tun. Entweder das System, Anwendungen und Dokumente funktionieren einwandfrei, oder es gibt Fehler. Die ich bisher hoch nie entdecken konnte. Und manche meiner Daten sind mittlerweile wirklich alt.

Das kommt erschwerend hinzu. Und dem gemeinen User egal, wieviel Buzzwörter sich dahinter verstecken. Hauptsache, es geht.

PaulMuabDib: Verarsche? Da wird gezeigt, daß selbst so ein gravierender Fehler im Datenbereich von HFS+ schlicht nicht erkannt wird. Wie willst DU denn sicher sein, daß bei ein pasr deiner Dateien nicht ein paar Bits gekippt sind? In vielen Dateien sind einige wenige Bit-Fehler nicht so kritisch (Audio, Video z.B.) und dürften meist kaum auffallen. Selbst in ausführbaren Dateien dürfte es genug Stellen geben, an denen ein Bitfehler nicht (sofort) auffällt. WENN dir slso mal igendwann doch mal ein defekt auffällt, dürfte die fehlerhafte Datei längst die letzte intakte Version aus dem Backup verdrängt haben.

Zeige mir eine Statistik, die das belegt.

Und nochmal: welches Szenario soll diese schwachsinnige Demo zeigen? Wenn ich dem Computer sage, dass er Daten überschreiben soll, dann macht er das. Was soll er da auch merken? Haste mal das gleiche unter ZFS gemacht?

Ich hab jetzt keine Links auf Tasch, aber ich hatte schon vor 2-3 Jahren gelesen, daß überhaupt erst mit Dateisystemen wie ZFS (als mit welchen, die Blockchecksummen machen) wirklich belegt werden konnte, DASS Daten über die Zeit einfach kaputt gehen. Und das war wohl mehr als man ursprünglich vermutet hatte (aber weniger als daß es täglich zu Katastropfen kommen würde).

Mit Hilfe von ZFS auf Systemen mit ECC-RAM konnte man damals auch sehr gut feststellen, daß auch mal Bits beim Datentransport über Kabel kaputt gingen. Und auch Datenfehler, die von defekten Plattencontrollern (in einem Artikel ging es um Enterprise SAS-Systeme) verursacht wurden, konnten erkannt werden. Es gibt irgendwo ein Artikel, den ich nicht mehr finde, in dem gezeigt wurde, wieviel Daten beim Transport über USB kaputt gingen.

Auch wenn ZFS auf dem ersten Blick vielleicht "too much" ausschaut, so sollte man bedenken, daß es sich hier um eine der entscheidenen Komponenten eines Systems handelt. Eines, das wirklich solide sein muß. Es gibt kaum ein Bereich in der Software, in der so devensiv gearbeitet wird, wie bei den Dateisystemen. ZFS hatte gut 10 Jahre gebraucht, bis es als Produktionsreif gelabelt wurde. Bis dahen liefen ziemlich große Tests ab. Teilweise liefen bei großen Firmen eine komplette ZFS-Installation parallel zum damals aktuellen Produktiivsystem gespiegelt mit.

Ich würde vermutlich heute schon nichts von ZFS auf meinem System bemerken. Ich hab 16GB RAM einen Quad-i7. Da würde sich ein ZFS, sofern es für einen Desktop-Einsatz konfiguriert ist (also Deduplication aus, kleinere Caches usw.), kaum negativ bemerkbar machen. Auch der RAM-Verbrauch war nicht weiter auffällig. Ich meine, wer akzeptiert, daß sich ein Webbrowser >1GB genemigt, der sollte sich auch nicht über ein Dateisystem aufregen, daß sich 1GB Cache gönnt.

Ich hatte kurz mal mit Zevo gespielt und es auf meiner HDD laufen gehabt und es lief soweit ausgezeichnet. Selbst einen Scrub hatte ich kaum bemerkt, da es mit niedriger Priorität läuft. Ich hatte keine Probleme feststellen können, außer, daß iTunes sich komisch verhielt, wenn die Lib auf der ZFS-Platte lag. Es gab dann (wenn ich mich richtig erinnere) immer kleine Pausen zwischen den Titeln. Das Problem kreide ich aber iTunes an. Denn ansonsten lief das ausgezeichnet. Die Performance war auch sehr gut.

Allerdings kann ich dazu keine Benchmarks liefern, da ZFS extrem viel Gebrauch von Caches macht. Ich hatte also beim ZFS-Laufwerk ständig Resultate wie von einer RAM-Disk. Wenn ich eine große Datei von meiner HFS+SSD auf meine ZFS-HDD kopiert hatte, dann hat konnte man sehen wie die Datei mit max. SSD-Speed geladen wurde und parallel dazu mit HDD-Speed auf dem ZFS-Laufwerk geschrieben wurde – das Lesen war als sehr viel früher beendet. Das Kopieren-Fenster vom Finder war dann auch wieder zu. An einem Platten-Monitor konnte man dann sehr schön das Zuendeschreiben der Datei auf dem ZFS-Laufwerk sehen.

Am Ende hatte ich das ZFS-Experiment (zähneknirschend) wieder aufgegeben, weil iTunes leider gezickt hatte. Und die Tatsache, daß ZFS auf dem Mac noch nicht bootfähig ist und die wirklich wichtigen Daten (/Users) auf der System-SSD liegen (sollen) und man somit an der entscheidenen Stelle nicht in den Genuß von den ZFS-Features kommt.

Vielleicht probiere ich das nochmal mit einer partitionierten SSD (System + Users), wenn ich mal Zeit dafür finde (um zumindest das mit den User-Ordnern hinzubekommen). Vielleicht sollte ich mich auch endlich mal um eine iTunes-Ablösung bemühen.

Hier hat einer was in Freakshow-Kommentaren geschrieben:

Mal ein Zitat hieraus:

Dass HFS+ ein katastrophal schlechtes Filesystem ist sollte inzwischen eigentilich jedem klar sein.
Ist zwar zwei Jahre her, aber wohl immer noch relevant:

Hmm, ich habe 12 TB in einem ZFS Z-RAID Pool über 4 Platten auf einem FreeBSD System mit 16GB ECC und mounte das über Netatalk (AFP). Da liegt auch die iTunes Lib. Mit Aussetzern bei zusätzlich gleichzeitigem AirPlay Distribution habe ich keine Prob. Schätze das neuere Implementierungen besser streamen. BTW: ich mounte gleichzeitig noch per SMB von diesem Pool an ein XBMC gerät. Also genügend Last wäre da ...

Keine Ahnung was das Problem war. Es könnte sein, daß es einfach nur an der Kombi aus iTunes, OSX und ZFS-Version lag. An mangelnder CPU oder RAM lag es jedenfalls nicht.

Für meinen HTPC plane ich ja auch FreeBSD wg. ZFS einzusetzen.

Ich hatte mal ein FireWire-Kabel, welches äußerlich in Ordnung war, aber ständig fehlerhafte Daten auf der Platte produzierte. Ich hatte immer innerhalb von wenigen Stunden so inkonsistente Daten, dass das System nicht mehr damit arbeiten wollte. Ständig musste ich die Platte reparieren. (Das war so um 2004 herum.)

Erst als ich das FW-Kabel austauschte, war der Spuk vorbei.

sierkb: Mit Backups der ganzen Dateien ist man allerdings auf der sicheren Seite … geht das älteste Original verloren hat man mit den Bit-Änderungen nur mehr Datenmüll, mit neueren Dateiversion ist jede für sich allein brauchbar.
Also da hat alles seine Vor- und Nachteile und mir ist es eigentlich ganz recht, dass TM auf Dateiebene arbeitet. Für riesige Dateien mit kleinen Änderungen, wie Disk-Images von VMs ist das wohl sub-optimal, ansonsten bin ich ganz froh, dass es so ist, wie es ist.

Ist aber nicht ganz das Gleiche. Vor allem, da Du ja recht schnell bemerkt hast, was da nicht stimmt.
Und, wen juckt das? Mich nicht. Apple soll bloß nicht hingehen und ein nicht für Client optimiertes Filesystem draufklatschen, weil das auf dem Papier so toll klingt.

PaulMuadDib: Gibt es einen Grund für deine vehemente Antihalthung? Ist das so ein Not-inventet-by-Apple-Ding? Ich sehe JETZT schon mehr als genug Vorteile von ZFS für mich.

Die Rechner sind HEUTE schon (eigentlich schon seit 1-3 Jahren) überperformant für die meisten hier. Wie oft hab ich schon lesen können, daß den Leuten im Prinzip schon fast ein Tablet genugt? Oft. Da wird ja wohl das bisschen mehr an CPU und RAM, was ZFS einfordert wohl wirklich kein Problem sein, oder? Dafür bekommt man ja auch eine ordentliche Gegenleistung.

Ich will mich auch nicht an ZFS festbeissen. Meinetwegen kann es auch was anderes als ZFS sein, es muß wenigstens Blockchecksummen und Copy on Write beherrschen. Aber ZFS bietet sich halt am ehesten ab, weil es von den modernen Dateisystemen wohl das sein dürfte, was am besten erprobt und abgehangen ist. Eines, was schon längst in kritischen Installationen sein können unter Beweiß gestellt hat. Und es wäre für einen Einsatz konfigurierbar.

Bei 16GB RAM scheiß ich ehrlich gesagt auf das GB, was sich ZFS womöglich krallen wird. Hast du dich je darüber beschwert, wenn sich das OS einen großen Cache für Dateizugriffe oder andere Dinge anlegt? Aktuell dürfte 8GB der Standard sein, in winigen Jahren werden das eher 16GB werden. Selbst Smartphones und Tablets haben heute teilweise schon 2GB RAM.

Weil speziell ZFS kein System für Clients ist. Und hier immer so getan wird, als wäre HFS nicht mehr tragbar. Nur ist mir das als Anwender völlig Wurscht. Meine Rechner laufen absolut stabil.

Ich denke schon, daß Apple da was am Testen ist. Nur hoffe ich, daß so etwas erst implementieren, wenn es wirklich funktioniert. Ohne, das der Anwender sich mit asynchronen Snapshots, Snapshot-Reseves, Provisioning und all so ein Mist rumschlagen muss. Und ich denke, daß so etwas von einigen hier unterschätzt wird. All das muß absolut transparent eingebunden sein, sonst schrottet man ein System vollkommen. Egal, wie stabil es eigentlich ist.

Wo ist das Problem? Man KANN alle Features von ZFS nutzen MUSS man aber nicht. Ich würde auch kein Dedup auf dem Laptop aktiviert haben wollen. Und nochmal: wenn ich es richtig verstanden habe, dann lässt ZFS sich auf einer recht großen Bandbreite konfigurieren. Vom Desktop bis zum Datacenter. Es ist richtig, daß ZFS ursprünglich eher für Datacenter entwickelt wurde. Aber was waren denn damals (um 2000 rum) denn die gängigen Kapazitäten in großen Anlagen und Zuhause auf dem Rechner? Heutzutage ist 3TB doch schon normal. Viele haben deutlich mehr. Das kommt doch schon in die Bereiche, die für beim Design von ZFS anvisiert wurden. Nur hatte man die mögliche Größe mit 128Bit-Adressen endgültig gemacht. Muss dich doch gar nicht interessieren, daß du heute schon im Prinzip Exabytes an Platten nutzen könntest.

Beim RAM hatten wir das doch auch schon. Mal war 640kB das Maß aller Dinge, später 3GB, 8, 16, ....

Selbst unsere Smartphones haben heutzutage Kapazitäten, die vor 20-30 Jahren schon für einen ordentlichen Server gereicht hätten.

Ich will sagen: Das nächste Dateisystem sollte "endgültig" sein. Und da scheint mir ZFS nicht "too much". Das dürfte alles eine Frage der Parametrisierung sein. Lass dich nicht von Features stören, die da sind, du aber nichts von wissen willst. Ignorier sie einfach. Und wer die Features nicht kennt, der muß sie nicht mal ignorieren. Oder kümmern dich die Features von HFS+? Halten die dich nachts vom schlafen ab?

Die Probleme von HFS+ kann man nicht ignorieren. Ja, HFS+ war eine ganze Weile ein gutes Dateisystem (das ist NTFS übrigens auch, was sogar ein ehemaliger Apple-Entwickler gesagt hatte). Aber wir werden in Zukunft eher mehr Daten als weniger haben. Und Dateisysteme wie ZFS tragen diesem Umstand rechnung und Laptops sind definitiv performant genug dafür. Also warum soll man das nicht nutzen?

Das habe ich nicht „recht schnell“ bemerkt. Ich habe vorher die Platte ausgetauscht, weil ich einen Plattendefekt vermutet hatte. Das Problem hat mich einige Wochen beschäftigt, denn es war ein hochwertig aussehendes neues und unbeschädigtes FireWire-Kabel, und das hatte ich nun wirklich als letztes in Verdacht.