Zunächst gibt es allerlei verschiedene Bezeichnungen die man im Zusammenhang mit ZFS immer wieder liest.

ZFS beinhaltet, zusätzlich zum eigentlichen Dateisystem, einen VolumeManager. Dieser VolumeManager ermöglicht es mehrere Festplatten (oder andere Devices - VDEV) zu einem großen Volume zusammen zu fassen. Ein solches Volume ist dann ein ZPOOL.

Das Dateisystem selbst heisst ZFS. Ein ZFS wird immer auf einem ZPOOL angelegt.

In unixoiden Betriebssystemen werden Partitionen normalerweise in das Dateisystem gemountet. Auf diese Weise werden klassisch oft verschiedene Partitionen angelegt um das Dateisystem aufzuteilen. Dies sist jedoch mit einigen Nachteilen verbunden. Innerhalb eines ZPOOL können beliebig viele DATASETs angelegt werden. Ein Dataset ist ähnlich einer Partition die innerhalb des ZROOT angelegt wird und in das Dateisystem eingebunden werden kann. Wird nichts anderes eingestellt teilen sich alle Datasets eines ZPOOL den gemeinsamen Speicherplatz.

Ein VDEV ist ein „Virtual Device“. Dahinter kann sich alles verstecken worauf ZFS als Datenspeicher arbeiten kann. So z.B. Festplatten, Partitionen (ja ZFS kann auch in Festplatten ohne Partitionen arbeiten, das ist aber nicht zu empfehlenswert), USB-Sticks, Dateien,… Aus ein oder mehreren VDEV kann ein ZPOOL gebaut werden.

Bei der Auslegung von ZFS standen Serversysteme mit viel Speicherplatz und Arbeitsspeicher im Fokus. Entsprechend ist ZFS, im Vergleich zu anderen Dateisystemen, auch sehr Ressourcenhungrig. Der ARC ist der Lesecache des ZFS welcher im Arbeitsspeicher des Rechners angelegt wird. Auf stark ausgelasteten Systemen kann der ARC einige GB an RAM belegen.

Zusätzlich zum ARC kann man einen 2nd-Level-ARC einrichten. Dies ist ein zusätzlicher Lesecache für ZFS welcher auf einer sehr schnellen Festplatte (meist einer oder mehrerer SSDs) angelegt werden kann. ZFS nutzt diesen Bereich wenn der ARC zu klein wird. Da es sich bei dem L2ARC um einen reinen Lese-Cache handelt ist es nicht notwendig ihn redundant auszuführen.

Zu den hohen Ansprüchen von ZFS gehört es, dass das Dateisystem zu keinem Zeitpunkt inkonsistent wird. Wenn ZFS Daten auf das Dateisystem schreiben soll werden diese zunächst in den Schreibcache geschrieben. Von diesem werden sie anschließend ins Dateisystem geschrieben. Dieser Schreibcache ist das ZIL. Wird kein ZIL explizit erzeugt nutzt ZFS einen Bereich in seinem ZPOOL als ZIL. Um Schreibzugriffe zu beschleunigen ist es sinnvoll ein ZIL auf einem schnellen Datenspeicher anzulegen (z.B. einer oder mehrerer SSDs). Da es sich hierbei um den Schreibchache handelt sollte die ZIL immer Redundant (idealerweise in einem MIRROR) angelegt werden. Fällt eine Festplatte in einem nicht Redundanten ZIL aus kann dies zu Datenverlust führen.

Mit ZFS werden meist größere Storagelösungen gebaut. Für diese Zwecke ist eine Redundanz in den Datenspeichern meist sehr wichtig. Aber auch um einige der Vorteile von ZFS auszunutzen ist es wichtig Redundanzen zu haben. Ein RAID-Z entspricht dabei in etwa der Anordnung wie man sie meist „RAID-5“ nennt (verteilte Redundanz). Es gibt RAID-Z mit unterschiedlicher Redundanztiefe. Man spricht dann von RAID-Z1 (mit einfacher Redundanz), RAIDZ-2 (mit doppelter Redundanz) und RAID-Z3 (mit dreifacher Redundanz). Der „Redundanzlevel“ gibt dabei immer an wieviele Festplatten zusätzlich verbaut werden müssen um Redundanzdaten zu ermöglichen.

Für RAID-Z1 benötigt man mindestens 3 Festplatten (mit 2 wäre es ein MIRROR). Dabei ist der Speicherplatz einer Festplatte (über alle drei Platten verteilt) nur zur Speicherung der Redundanz. Verbaut man also z.B. drei Festplatten zu je 1TB erhält man ca. 2TB nutzbaren Speicherplatz im ZPOOL. Eine Festplatte könnte ausfallen ohne, dass man einen Datenverlust erleidet (diese sollte dann aber schnellstmöglich ausgetauscht werden. Beim Verlust der zweiten Festplatte ist das Dateisystem hinüber).

Ein RAID-Z2 müsste entsprechend aus mindestens 4 Festplatten bestehen. Mit 4 Festplatten zu je 1TB erhält man dann auch ca. 2TB nutzbaren Speicher. Im Unterschied zu RAID-Z2 können jedoch 2 Festplatten ausfallen ohne, dass das Dateisystem Schaden nimmt.

Analoges gilt für RAID-Z3.

Eine Weitere Möglichkeit Redundanzen zu schaffen ist die Verwendung eines MIRROR (Spiegel). Dies entspricht einem klassischen „RAID-1“. Hierbei werden mindestens 2 Festplatten verwendet, wobei alle Daten auf allen Festplatten parallel abgelegt werden. Jede der Festplatten ist eine komplette Spiegelung der anderen Platten. Der Nachteil hierbei ist zwar, dass man relativ viel Festplattenspeicher für Redundanz verliert, dafür ist es das einfachste System. Ein weiterer Vorteil ist, dass ZFS bei lesenden Zugriffen von allen Festplatten gleichzeitig lesen kann, was die Lesegeschwindigkeit ebenfalls etwas steigert.

Heutige Festplatten haben meist eine Sektorgröße von 4096 und arbeiten auch nur mit dieser Größer mit voller Performance. ZFS nutzt automatisch die Größe die ihm sein Datenträger nennt (genauer gesagt nutzt es 4K-Sektoren soblad ein Provider ihm eine entsprechende Sektorgröße nennt). Aus Kompatibilitätsgründen melden jedoch viele Festplatten dennoch eine Sektorgröße von 512 was dazu führt, dass ZFS nicht optimal auf den Festplatten performt. Um eine Sektorgröße von 4K zu erzwingen wird die folgende sysctl-Variable gesetzt (es ist sinnvoll die Variable immer in /etc/sysctl.conf zu setzen um später angelegte Pools ebenfalls an den 4K-Sektoren auszurichten):

vfs.zfs.min_auto_ashift=12

Ältere Festplatten mit 512er Sektorgröße funktionieren auch mit 4K-Sektoren (die einzige Einschränkung ist ein geringer Kapazitätsverlust bei viele kleinen Dateien). Damit das Alignment immer stimmt, also nicht in der Mitte eines Sektors landet sollten Partitionen mittels gpart immer mit dem Schalter -a 1m angelegt werden. Damit werden Partitionen immer am vollen MB ausgelegt. Somit werden Festplatten aller Sektorgrößen korrekt gehandelt.