Der Kult um ZFS

Es ist recht verbreitet, dass IT-Kreise eine gewisse kult- oder “fanboy”-artige Mentalität entwickeln. Was diese Reaktion auf Technologien und Produkte hervorruft, weiß ich nicht genau, doch dass sie geschieht, ist unbestreitbar. Ein Bereich, in dem ich nie gedacht hätte, dies zu erleben, ist der Bereich der Dateisysteme – eine der am meisten “unter der Haube” liegenden Systemkomponenten und eine, die bis vor Kurzem buchstäblich keinerlei Aufmerksamkeit erhielt, selbst in einigermaßen technischen Kreisen. Seien wir ehrlich: Das Missverständnis, wann etwas aus Active Directory gegenüber NTFS stammt, ist nahezu allgegenwärtig. Dateisysteme werden, schlicht gesagt, ignoriert. Seit der Veröffentlichung von Windows NT 4, als NTFS die einzige praktikable Option war, ist die Vorstellung, dass ein Dateisystem keine inhärente Komponente eines Betriebssystems ist und dass es andere Optionen für die Dateispeicherung geben könnte, so gut wie verschwunden. Das heißt, bis vor Kurzem.

Die eine Gemeinschaft, in der dies, zu einem geringen Grad, nicht geschah, war die Linux-Gemeinschaft, doch selbst dort gewannen Ext2 und seine Nachfahren so vollständig die Vorherrschaft im Bewusstsein, dass alternative Dateisysteme, obwohl sie weithin verfügbar waren, ins Abseits gedrängt wurden und historisch nur XFS überhaupt Aufmerksamkeit erhielt, und selbst dieses erhielt nur sehr wenig.

Wo in jüngerer Zeit ein wahrhaft seltsames Verhalten aufgetreten ist, ist rund um Oracles Dateisystem ZFS, das ursprünglich für das Betriebssystem Solaris und die offene Speicherplattform X4500 “Thumper” entwickelt wurde (ursprünglich unter der Ägide von Sun vor der Übernahme durch Oracle). Zu der Zeit (vor neun Jahren), als ZFS veröffentlicht wurde, waren konkurrierende Dateisysteme größtenteils schlecht darauf vorbereitet, die großen Festplatten-Arrays zu bewältigen, die in den kommenden Jahren entstehen sollten. ZFS war darauf ausgelegt, sie zu bewältigen, und läutete das Zeitalter der großmaßstäblichen Dateisysteme ein. Wie die meisten Dateisysteme zu jener Zeit war ZFS auf ein einziges Betriebssystem beschränkt, und so erzeugte es, obwohl es weithin als großer Fortschritt im Dateisystemdesign galt, nur wenige Wellen in der Speicherwelt und noch weniger in der “Systeme”-Welt, in der selbst Solaris-Administratoren es geraume Zeit im Allgemeinen lediglich als Kuriosum betrachteten und überwiegend dem altbewährten UFS treu blieben, das sie viele Jahre lang verwendet hatten.

ZFS war wahrhaftig ein bahnbrechendes Dateisystem, und ich war und bleibe ein großer Befürworter davon. Doch es ist sehr wichtig zu verstehen, warum ZFS tat, was es tat, was seine Ziele sind, warum diese Ziele wichtig waren und wie es heute auf uns zutrifft. Die Komplexität von ZFS hat zu viel Verwirrung und Missverständnissen darüber geführt, wie das Dateisystem funktioniert und wann seine Verwendung angebracht ist.

Die grundlegenden Ziele von ZFS waren, ein Dateisystem zu schaffen, das gut auf sehr große Festplatten-Arrays skaliert. Zum Zeitpunkt seiner Einführung war das Ausmaß, zu dem ZFS fähig war, in anderen Dateisystemen unerhört, doch es bestand kein realer Bedarf dafür, dass ein Dateisystem so groß werden konnte. Als der Bedarf entstand, hatten viele andere Dateisysteme wie NTFS, XFS, Ext3 und andere bereits skaliert, um den Bedarf zu decken. ZFS führte gewiss den Vorstoß zur Handhabung größerer Dateisysteme an, wurde aber bald darauf von vielen anderen begleitet.

Da ZFS aus der Solaris-Welt stammte, in der es, wie bei allen Big-Iron-UNIX-Systemen, kein Hardware-RAID gibt, musste Software-RAID verwendet werden. Solaris hatte stets Software-RAID als eigenes Subsystem verfügbar gehabt. Es wurde die Entscheidung getroffen, eine neue Software-RAID-Implementierung direkt in ZFS einzubauen. Dies würde eine vereinfachte Verwaltung über ein einziges Werkzeugset sowohl für die RAID-Schicht als auch für das Dateisystem ermöglichen. Es führte keine bedeutende Veränderung oder Verbesserung an ZFS ein, wie oft angenommen wird, es verlagerte lediglich die Schnittstelle für die Software-RAID-Schicht von einem eigenen Befehlssatz hin zu einem Teil des ZFS-Befehlssatzes.

ZFS’ Implementierung von RAID führte Stripes variabler Breite in Paritäts-RAID-Levels ein. Diese Innovation schloss ein kleineres Risiko des Paritäts-RAID, bekannt als das “Write Hole”. Diese Innovation war sehr schön, kam aber sehr spät, da die Ära des zuverlässigen Paritäts-RAID zu enden begann und das Write-Hole-Problem bereits als ein unerwähntes “Hintergrundrauschen”-Risiko von Paritäts-Arrays galt, da es im Allgemeinen aufgrund seiner Beseitigung durch den Einsatz batteriegepufferter Array-Caches und, etwa zur selben Zeit, nichtflüchtiger Array-Caches nicht als Bedrohung betrachtet wurde – vermeide den Stromausfall, und du vermeidest das Write Hole. ZFS musste dieses Problem angehen, weil es als Software-RAID einem größeren Risiko durch das Write Hole ausgesetzt war als Hardware-RAID, da es keine Möglichkeit für einen gegen Stromausfall geschützten Cache gibt – Hardware-RAID bietet das Potenzial für eine zusätzliche Schicht des Stromausfallschutzes für Arrays.

Die wahre “Innovation”, die ZFS unbeabsichtigt hervorbrachte, war, dass es statt der einfachen Implementierung der üblichen RAID-Levels 1, 5, 6 und 10 diese Levels stattdessen mit seinen eigenen Namenskonventionen “brandmarkte”. RAID 5 ist als RAIDZ bekannt. RAID 6 ist als RAIDZ2 bekannt. RAID 1 ist einfach als Mirroring bekannt. Und so weiter. Dies wurde zu jener Zeit weithin als albern und sinnlos verwirrend betrachtet, doch wie sich herausstellte, wurde diese Verwirrung zum Eckpfeiler von ZFS’ Wiederbelebung viele Jahre später.

Es muss angemerkt werden, dass ZFS später die branchenweit erste Produktivimplementierung eines RAID 7 (auch RAID 7.3) mit dreifacher Parität hinzufügte und es als RAIDZ3 brandmarkte. Diese spätere Ergänzung ist eine wichtige Innovation für großmaßstäbliche Arrays, die das Höchstmaß an Kapazität benötigen und dabei äußerst sicher bleiben, aber bereit sind, hierfür Leistung zu opfern. Dies bleibt ein einzigartiges Merkmal von ZFS, jedoch eines, das selten genutzt wird.

Im Geiste der Komprimierung des Storage-Stacks und der Verwendung eines einzigen Befehlssatzes zur Verwaltung aller Aspekte des Storage wurden auch die Funktionen der logischen Volume-Verwaltung in ZFS eingegliedert. Es wird in bestimmten Kreisen oft fälschlicherweise angenommen, dass ZFS die logische Volume-Verwaltung eingeführt habe, doch nahezu alle Enterprise-Plattformen, einschließlich AIX, Linux, Windows und sogar Solaris selbst, hatten bereits seit vielen Jahren eine logische Volume-Verwaltung. ZFS tat dies nicht, um ein neues Paradigma einzuführen, sondern lediglich, um die Verwaltung zu konsolidieren und alle drei wesentlichen Storage-Schichten (RAID, logische Volume-Verwaltung und Dateisystem) zu einer einzigen Einheit zusammenzufassen, die einfacher zu verwalten wäre und eine inhärente Kommunikation auf- und abwärts durch den Stack bereitstellen könnte. Es gibt Vor- und Nachteile dieser Methode, und eine Branchenmeinung bleibt fast ein Jahrzehnt später unausgeformt.

Einer der wichtigsten Aspekte dieser Konsolidierung dreier Systeme zu einem ist, dass wir nun ein sehr verwirrendes Produkt zu erörtern haben. ZFS ist ein Dateisystem, ja, aber es ist nicht nur ein Dateisystem. Es ist ein Logical Volume Manager, aber nicht nur ein Logical Volume Manager. Menschen bezeichnen ZFS als ein Dateisystem, was seine primäre Funktion ist, doch dass es so viel mehr als ein Dateisystem ist, kann sehr verwirrend sein und erschwert Vergleiche mit anderen Speichersystemen. Ich glaube, dass diese Verwirrung zu jener Zeit nicht vorhergesehen wurde.

Was aus dieser verwirrenden Verschmelzung resultiert ist, dass ZFS oft mit anderen Dateisystemen wie XFS oder Ext4 verglichen wird. Doch das ist verwirrend, da ZFS ein vollständiger Stack ist und XFS nur ein Aspekt eines Stacks. ZFS ließe sich besser mit MD (Linux Software RAID) / LVM / XFS oder mit SmartArray (HP Hardware RAID) / LVM / XFS vergleichen als mit XFS allein. Andernfalls erscheint es, als sei ZFS voller Funktionen, die XFS fehlen, doch in Wirklichkeit ist es nur ein semantischer Sieg. Die meisten der von ZFS-Befürwortern oft angepriesenen Funktionen entstanden nicht mit ZFS und waren bei den alternativen Dateisystemen lange vor der Existenz von ZFS allgemein verfügbar. Doch es ist schwer zu vergleichen “kann Ihr Dateisystem das”, weil die Antwort lautet “nein …. mein RAID oder mein Logical Volume Manager tun das.” Und wahrhaftig ist es nicht ZFS das Dateisystem, das RAIDZ bereitstellt, es ist ZFS das Software-RAID-Subsystem, das dies tut.

Um sehr große Dateisysteme elegant zu bewältigen, wurden Funktionen zur Datenintegrität in ZFS eingebaut, zu denen eine Prüfsumme oder ein Hash-Check über das gesamte Dateisystem hinweg gehörte, die das inklusive Software-RAID nutzen konnten, um beschädigte Dateien zu reparieren. Dies wurde aufgrund der erwarteten Größe von ZFS-Dateisystemen in der Zukunft als notwendig erachtet. Dateisystembeschädigung ist ein selten beobachtetes Phänomen, doch mit zunehmender Größe der Dateisysteme steigt das Risiko. Dieses weniger bekannte Merkmal von ZFS ist möglicherweise sein größtes.

ZFS veränderte auch, wie Dateisystemprüfungen gehandhabt werden. Aufgrund der Annahme, dass ZFS auf sehr großen Dateisystemen eingesetzt würde, bestand die echte Befürchtung, dass eine Dateisystemprüfung beim Bootvorgang unmöglich lange dauern könnte, und so wurde eine alternative Strategie gefunden. Anstatt mit einer Prüfung bis zum Neustart zu warten, würde das System einen Scrubbing-Prozess erfordern, der läuft und eine ähnliche Prüfung durchführt, während das System in Betrieb ist. Dies erfordert mehr Systemoverhead, während das System läuft, doch das System ist in der Lage, sich von einem unerwarteten Neustart rascher zu erholen. Ein Kompromiss, aber einer, der weithin als sehr positiv betrachtet wird.

ZFS verfügt über leistungsstarke Snapshot-Fähigkeiten in seiner logischen Volume-Schicht und hat in seiner RAID-Schicht sehr robuste Caching-Mechanismen implementiert, was ZFS zu einer exzellenten Wahl für viele Anwendungsfälle macht. Diese Funktionen sind in ZFS nicht einzigartig, sondern in Systemen, die älter als ZFS sind, weithin verfügbar. Sie sind jedoch sehr gute Implementierungen jeder einzelnen und aufgrund der Natur von ZFS sehr gut integriert.

Einst war ZFS Open Source, und in jener Ära wurde sein Code Teil der Betriebssysteme Mac OSX von Apple und FreeBSD, weil diese mit der ZFS-Lizenz kompatibel waren. Linux erhielt ZFS zu jener Zeit aufgrund von Herausforderungen rund um die Lizenzierung nicht. Hätte die ZFS-Lizenzierung Linux dessen unbelastete Nutzung erlaubt, wäre die Linux-Landschaft heute wahrscheinlich sehr anders. Mac OSX ließ ZFS letztlich fallen, da es nicht als ausreichend vorteilhaft angesehen wurde, um es in jener Umgebung zu rechtfertigen. FreeBSD hielt an ZFS fest, und im Laufe der Zeit wurde es zum beliebtesten Dateisystem auf der Plattform, obwohl auch UFS nach wie vor stark genutzt wird. Oracle schloss den Quellcode von ZFS nach der Sun-Übernahme und ließ FreeBSD ohne fortlaufende Updates für seine Version von ZFS zurück, während Oracle ZFS intern für Solaris weiterentwickelte.

Heute verwendet Solaris weiterhin die ursprüngliche ZFS-Implementierung, nun mit mehreren Updates seit seiner Trennung von der Open-Source-Gemeinschaft. FreeBSD und andere verwendeten ZFS weiterhin in dem Zustand, in dem es war, als der Code Closed Source wurde, ohne fortan Zugang zu Oracles neuesten Updates zu haben. Schließlich wurde die Arbeit zur Aktualisierung der aufgegebenen Open-Source-ZFS-Codebasis aufgenommen und ist heute als OpenZFS bekannt. OpenZFS steckt noch in den Anfängen und hat seine Spuren noch nicht wirklich hinterlassen, hat aber ein gewisses Potenzial, die ZFS-Plattform im Open-Source-Bereich wiederzubeleben, doch zum gegenwärtigen Zeitpunkt hinkt OpenZFS ZFS noch hinterher.

Die Open-Source-Entwicklung in diesem Bereich hat sich in den letzten Jahren stärker auf ZFS’ neuen Rivalen BtrFS konzentriert, der nativ unter Linux entwickelt wird und von vielen großen Betriebssystemanbietern gut unterstützt wird. BtrFS ist noch sehr jung, macht aber große Fortschritte, um bei den implementierten Funktionen Funktionsparität mit ZFS zu erreichen, hat aber große Ambitionen und genießt aufgrund von ZFS’ Closed-Source-Natur den Vorteil des Marktmomentums. BtrFS wurde, wie ZFS, von Oracle ins Leben gerufen und wird weithin als Oracles Sicht auf die Zukunft betrachtet, als Ersatz für ZFS selbst bei Oracle. Zum gegenwärtigen Zeitpunkt hat BtrFS, wie ZFS, bereits die Schichten Dateisystem, logische Volume-Verwaltung und Software-RAID zusammengeführt, Checksumming für die Dateisystemintegrität implementiert, skaliert sogar noch größer als ZFS (dasselbe absolute Limit, handhabt aber mehr Dateien), Copy-on-Write-Snapshots usw.

ZFS war ohne Zweifel ein erstaunliches Dateisystem in seiner Blütezeit und bleibt auch heute ein Vorreiter. Ich war 2005 ein Befürworter davon und glaube nach wie vor fest daran. Doch es hat mich betrübt, mitanzusehen, wie die Gemeinschaft rund um ZFS eine Inbrunst und einen Eifer annimmt, der ihm keinen Dienst erweist und die Erwähnung von ZFS fast wie etwas Negatives erscheinen lässt – ZFS wird so universell aus den falschen Gründen gewählt: in erster Linie aus dem Glauben, dass seine Funktionen nirgendwo sonst existieren, dass sein RAID nicht den Risiken und Einschränkungen unterliegt, denen diese RAID-Levels stets unterliegen, oder dass es für einen anderen Zweck (in erster Linie Leistung) entworfen wurde als den, für den es entworfen wurde. Und selbst wenn ZFS eine gute Wahl ist, wird es oft schlecht implementiert, basierend auf unwahren Annahmen.

ZFS trägt selbstverständlich keine Schuld. Ebenso wenig, soweit ich erkennen kann, seine Unternehmensunterstützer oder seine Open-Source-Entwickler. Wo ZFS in die Irre gegangen zu sein scheint, ist in einer losen, inoffiziellen Gemeinschaft, die ZFS erst vor Kurzem kennengelernt hat und oft glaubt, es sei neu oder “next generation”, weil sie es erst kürzlich entdeckt hat. Nach allem, was ich gesehen habe, geschieht dies fast nie über Solaris- oder FreeBSD-Kanäle, sondern fast ausschließlich über kleinere Unternehmen, die ein vorgefertigtes “NAS-OS” wie FreeNAS oder NAS4Free einsetzen möchten und die mit UNIX-Betriebssystemen nicht vertraut sind. Die Verwendung vorgefertigter NAS-Betriebssysteme, in erster Linie durch IT-Abteilungen, die weder tiefe UNIX- noch Storage-Kenntnisse besitzen und folglich wenig Berührung mit der breiteren Welt der Dateisysteme außerhalb von Windows haben und oft wenig bis gar keine Berührung mit logischer Volume-Verwaltung und RAID, insbesondere Software-RAID überhaupt, scheint zu einer “Mythos”-Kultur rund um ZFS zu führen, wobei es einen nahezu unhinterfragbaren, unfehlbaren Status annimmt.

Diese kultartige Anhängerschaft und das allgemeine Missverständnis von ZFS führen häufig zu Fehlanwendungen von ZFS oder zu einer Kette von Entscheidungen, die auf falschen Annahmen beruhen und einen sehr in die Irre führen können.

Eine der erstaunlichsten Veränderungen in diesem Bereich ist der Wandel der Anhängerschaft von Hardware-RAID hin zu Software-RAID. Traditionell war Software-RAID in Windows-Administrationskreisen ohne triftigen Grund ein Außenseiter – Windows-Administratoren und Kleinunternehmen, oft nicht vertraut mit größeren UNIX-Servern, glaubten, Hardware-RAID sei allgegenwärtig, während in Wirklichkeit größere Systeme stets Software-RAID verwendeten. Hardware-RAID galt nahezu branchenweit als Notwendigkeit, und Software-RAID wurde völlig gemieden. Dasselbe Publikum, nun mit der Bewegung des “Kults um ZFS” konfrontiert, reagiert jetzt genau auf die entgegengesetzte Weise und glaubt, Hardware-RAID sei schlecht und ZFS’ Software-RAID sei die einzige praktikable Option. Der Wandel ist dramatisch, und keiner der beiden Ansätze ist stichhaltig – sowohl Hardware- als auch Software-RAID und beide in vielen Implementierungen sind sehr stichhaltige Optionen, und selbst bei der Verwendung von ZFS könnte der Einsatz von Hardware-RAID durchaus angebracht sein.

ZFS wird oft gewählt, weil man glaubt, es sei die Option mit der höchsten Leistung unter den Dateisystemen, doch dies war nie ein zentrales Designziel von ZFS. Die Funktionen, die es ihm ermöglichen, so groß zu skalieren und so viele verschiedene Aspekte des Storage zu bewältigen, machen es tatsächlich sehr schwierig, hochperformant zu sein. Von ZFS wurde zum Zeitpunkt seiner Entstehung nicht einmal erwartet, dass es so schnell sei wie das ehrwürdige UFS, das auf denselben Systemen lief wie es. Dies ist jedoch oft zweitrangig gegenüber der Tatsache, dass die Dateisystemleistung weithin belanglos ist, da alle modernen Dateisysteme äußerst schnell sind und die Dateisystemgeschwindigkeit selten ein wichtiger Faktor ist – insbesondere außerhalb massiver, hochwertiger Speichersysteme in sehr großem Maßstab.

Eine interessante Studie von zehn Dateisystemen unter Linux, die 2013 von Phoronix erstellt wurde, zeigte massive Unterschiede zwischen Dateisystemen je nach Arbeitslast, aber keine klaren Sieger, was die Gesamtleistung betrifft. Was die Studie schlüssig zeigte, ist, dass die Abstimmung der Arbeitslast auf das Dateisystem die wichtigste Entscheidung ist, dass ZFS selbst in seinen moderneren Implementierungen auf die langsamere Seite aller gängigen Dateisysteme fällt und dass die Wahl eines Dateisystems aus Leistungsgründen ohne ein sehr tiefes Verständnis der Arbeitslast zu unvorhersehbarer Leistung führen wird – kein Dateisystem sollte blind gewählt werden, wenn Leistung ein wichtiger Faktor ist. Bedauerlicherweise fehlte der Studie, da der Test unter Linux durchgeführt wurde, UFS, das oft ZFS’ zentraler Konkurrent ist, insbesondere unter Solaris und FreeBSD, und es fehlte HFS+ von Mac OSX.

Der Wechsel von Hardware-RAID zu Software-RAID birgt für Abteilungen, die in UNIX nicht erfahren sind, zudem zusätzliche, oft unvorhergesehene Risiken. Obwohl ZFS Hot-Swapping ermöglicht, wird oft vergessen, dass Hot-Swap in erster Linie ein Merkmal der Hardware ist, nicht der Software, und es ist auch weithin unbekannt, dass Blind-Swapping (das Entfernen von Festplatten, ohne sie zuvor im Betriebssystem offline zu nehmen) nicht gleichbedeutend mit Hot-Swapping ist, und dies kann zu Katastrophen führen für Abteilungen, die von einer Tradition des Hardware-RAID, das Kompatibilität, Hot-Swap und Blind-Swapping transparent für sie handhabte, zu einem Software-RAID-System wechseln, das viel mehr Planung, Koordination und Verständnis des Systems erfordert, um sicher genutzt zu werden.

Ein geringeres, aber dennoch verbreitetes Missverständnis von ZFS ist, dass es ein Cluster-Dateisystem sei, das für den Einsatz in Szenarien mit gemeinsam genutztem DAS oder SAN geeignet sei, etwa wie OCFS, VxFS und GFS2. ZFS ist kein Cluster-Dateisystem und teilt in diesem Bereich dieselben Einschränkungen wie alle seine gängigen Konkurrenten.

ZFS kann eine exzellente Wahl sein, ist aber bei Weitem nicht die einzige. ZFS bringt erhebliche Vorbehalte mit sich, nicht zuletzt die mit ihm verbundenen Betriebssystembeschränkungen, und obwohl es viele Vorteile hat, sind wenige, wenn überhaupt welche, einzigartig für ZFS, und es ist sehr selten, dass eine Abteilung von jedem einzelnen von ihnen profitieren wird. Wie bei jeder Technologie sind Kompromisse einzugehen. Eine Größe passt nicht für alle. Der Schlüssel zu wissen, wann ZFS das Richtige für Sie ist, besteht darin zu verstehen, was ZFS ist, was an ihm einzigartig ist und was nicht, was seine Designziele sind, wie der Vergleich eines Speicher-Stacks mit einem reinen Dateisystem irreführende Ergebnisse hervorbringt und welche inhärenten Einschränkungen mit ihm verbunden sind.

ZFS ist eine zentrale Überlegung und die übliche Wahl, wenn Solaris oder FreeBSD das gewählte Betriebssystem ist. Mit seltener Ausnahme sollte das Betriebssystem niemals wegen ZFS gewählt werden, sondern stattdessen sollte ZFS oft, aber nicht immer, gewählt werden, sobald das Betriebssystem gewählt ist. Das Betriebssystem sollte in allen außer den seltensten Fällen die Dateisystementscheidungen bestimmen. Die Wahl des Betriebssystems ist so dramatisch viel wichtiger als die Wahl des Dateisystems.

ZFS kann unter Linux verwendet werden, gilt dort aber nicht als Enterprise-Option, sondern eher als Hobby-System zum Experimentieren, da kein Enterprise-Anbieter (wie Red Hat, Suse oder Canonical) ZFS unter Linux unterstützt und Linux bereits über großartige Alternativen verfügt. Eines Tages könnte ZFS unter Linux zu einem erstklassigen Dateisystem aufsteigen, doch dies wird nicht erwartet, da BtrFS bereits in den Mainline-Kernel Einzug gehalten hat und von mehreren großen Anbietern in Produktivversionen aufgenommen wurde.

Obwohl ZFS in der überwiegenden Mehrheit der Solaris- und FreeBSD-Bereitstellungen anzutreffen sein wird, liegt dies in erster Linie daran, dass es in die Position des Standard-Dateisystems gerückt ist, und nicht daran, dass es in jenen Fällen eindeutig die überlegene Wahl ist oder auch nur kritisch bewertet wurde. ZFS ist vollkommen gut geeignet, ein Allzweck-Dateisystem zu sein, dort, wo es nativ und unterstützt ist.

Was ist ZFS’ primärer Anwendungsfall?

ZFS’ Designziel und hauptsächlicher Anwendungsfall ist für Solaris- und FreeBSD-Open-Storage-Systeme, die entweder gemeinsam genutzten Speicher für andere Server oder als massive Datenrepositorien für lokal installierte Anwendungen bereitstellen. In diesen Fällen kommen ZFS’ Fokus auf Skalierbarkeit und Datenintegrität wirklich zur Geltung. ZFS neigt stark zu großen und Enterprise-Umgebungen und im Allgemeinen weg von der Anwendbarkeit im Bereich kleiner und mittlerer Unternehmen, wo Solaris- und FreeBSD-Kenntnisse sowie großmaßstäbliche Speicheranforderungen selten sind.

Referenz: http://www.phoronix.com/scan.php?page=article&item=linux_310_10fs&num=1