Unterschiede zwischen Oracle Solaris ZFS und herkömmlichen Dateisystemen

• Granularität von ZFS-Dateisystemen

• Berechnung von ZFS-Festplattenkapazität

• Einhängen von ZFS-Dateisystemen

• Herkömmliche Datenträgeradministration

• Solaris ACL-Modell basierend auf NFSv4

Granularität von ZFS-Dateisystemen

Früher waren Dateisysteme auf ein Datenspeichergerät und damit auf die Kapazität dieses Geräts beschränkt. Das Erstellen und Neuerstellen herkömmlicher Dateisysteme aufgrund von Kapazitätsbeschränkungen ist zeitaufwändig und in einigen Fällen kompliziert. Herkömmliche Administrationslösungen unterstützen diesen Prozess.

Da ZFS-Dateisysteme nicht auf spezielle Geräte beschränkt sind, können sie ähnlich wie Verzeichnisse schnell und einfach erstellt werden. ZFS-Dateisysteme werden innerhalb der verfügbaren Festplattenkapazität des Speicher-Pools, in dem sie enthalten sind, automatisch vergrößert.

Anstatt ein Dateisystem (z. B. /export/home) zum Verwalten von Benutzerverzeichnissen zu erstellen, können Sie pro Benutzer ein Dateisystem anlegen. Sie können Dateisysteme auf einfache Weise einrichten und verwalten, indem Sie Eigenschaften festlegen, die von untergeordneten Dateisystemen innerhalb einer Hierarchie geerbt werden.

Ein Beispiel, das zeigt, wie eine Dateisystemhierarchie erstellt wird, finden Sie unter Erstellen einer ZFS-Dateisystemhierarchie.

Berechnung von ZFS-Festplattenkapazität

ZFS beruht auf dem Konzept der Datenspeicherung in Pools. Im Gegensatz zu herkömmlichen, physischen Datenträgern direkt zugewiesenen Dateisystemen teilen sich ZFS-Dateisysteme in einem Pool den in diesem Pool verfügbaren Speicherplatz. Somit kann sich die verfügbare Festplattenkapazität, die von Serviceprogrammen wie z. B. df gemeldet wird, auch dann ändern, wenn das betreffende Dateisystem inaktiv ist, da andere Dateisysteme im Pool Festplattenkapazität belegen bzw. freigeben.

Bitte beachten Sie, dass die maximal mögliche Dateisystemkapazität durch die Zuteilung von Kontingenten beschränkt werden kann. Weitere Informationen zu Kontingenten finden Sie unter Setzen von Kontingenten für ZFS-Dateisysteme. Durch Reservierungen kann einem Dateisystem eine bestimmte Festplattenkapazität garantiert werden. Weitere Informationen zu Reservierungen finden Sie unter Setzen von Reservierungen für ZFS-Dateisysteme. Dieses Modell gleicht dem NFS-Modell sehr; dort werden mehrere Verzeichnisse vom gleichen Dateisystem (z. B. /home) eingehängt.

Alle Metadaten werden in ZFS dynamisch zugewiesen. In herkömmlichen Dateisystemen erfolgt die Zuweisung von Metadaten meist vorher. Deswegen muss für diese Metadaten schon beim Erstellen des Dateisystems zusätzlicher Speicherplatz reserviert werden. Dieses Verhalten bedeutet weiterhin, dass die mögliche Gesamtdateianzahl eines Dateisystems schon vorher festgelegt ist. Da ZFS Metadaten nach Bedarf zuweist, muss vorher kein zusätzlicher Speicherplatz reserviert werden, und die Anzahl von Dateien wird lediglich durch die verfügbare Festplattenkapazität begrenzt. Die Ausgabe des Befehls df -g ist bei ZFS anders als bei herkömmlichen Dateisystemen zu interpretieren. Die unter total files ausgegebene Dateinanzahl ist lediglich ein Schätzwert, der auf dem Betrag des im Pool verfügbaren Speicherplatzes beruht.

ZFS ist ein transaktionales Dateisystem. Das bedeutet, dass die meisten Dateisystemmodifikationen in Transaktionsgruppen zusammengefasst und asynchron auf dem Datenträger ausgeführt werden. Diese Modifikationen gelten so lange als anstehende Änderungen, bis sie auf dem Datenträger festgeschrieben sind. Die von einer Datei oder einem Dateisystem belegte, verfügbare und referenzierte Festplattenkapazität berücksichtigt keine anstehenden Änderungen. Anstehende Änderungen werden im Allgemeinen innerhalb weniger Sekunden abgeschlossen. Auch nach dem Festschreiben einer Änderung auf der Festplatte durch fsync(3c) oder O_SYNC werden die Informationen zur belegten Festplattenkapazität nicht unbedingt sofort aktualisiert.

Bei einem UFS-Dateisystem protokolliert der du-Befehl die Größe des Datenblocks innerhalb der Datei. Bei einem ZFS-Dateisystem protokolliert du die tatsächliche Größe der Datei wie auf der Festplatte gespeichert. Die Größe umfasst Metadaten sowie Komprimierung. Mit diesen Berichten kann die Frage "Wie viel Speicherplatz erhalte ich zusätzlich, wenn ich diese Datei entferne?" einfacher beantwortet werden. Auf diese Weise sehen Sie selbst wenn die Komprimierung deaktiviert ist, unterschiedliche Ergebnisse zwischen ZFS und UFS.

Wenn Sie die Speicherplatzbelegung, die von dem Befehl df angegeben wird, mit dem Befehl zfs list vergleichen, beachten Sie, dass df die Poolgröße und nicht nur die Größe der Dateisysteme angibt. Außerdem berücksichtigt df untergeordnete Dateisysteme oder das Vorhandensein von Schnappschüssen nicht. Wenn ZFS-Eigenschaften, wie Komprimierung und Quota für Dateisysteme festgelegt sind, ist der Abgleich der Speicherplatzbelegung, die von df protokolliert wird, möglicherweise schwierig.

Beachten Sie die folgenden Szenarios, die sich auch auf die protokollierte Speicherplatzbelegung auswirken können:

• Bei Dateien, die größer sind als recordsize ist der letzte Block der Datei im Allgemeinen halb voll. Wenn der Standardwert für recordsize auf 128 KB festgelegt ist, werden pro Datei ca. 64 KB nicht genutzt, was schwerwiegende Auswirkungen haben kann. Die Integration von RFE 6812608 würde dieses Problem lösen. Sie können dieses Problem durch Aktivierung der Komprimierung umgehen. Selbst wenn die Daten bereits komprimiert sind, wird der nicht belegte Teil des letzten Blockes mit Null gefüllt und kann ebenfalls gut komprimiert werden.

• Bei einem RAIDZ-2-Pool belegt jeder Block mindestens 2 Sektoren (512-Byte-Blöcke) mit Paritätsinformationen. Der von den Paritätsinformationen belegte Speicherplatz wird nicht protokolliert. Da er jedoch variieren und bei kleineren Blöcken einen wesentlich größeren Prozentsatz darstellen kann, kann sich dies auf die Protokollierung des Speicherplatzes auswirken. Die Auswirkung ist wesentlich größer, wenn recordsize auf 512 Byte festgelegt ist, wobei jeder logische 512-Byte-Block 1,5 KB belegt (3-mal mehr als der ursprüngliche Speicherplatz). Wenn die Speicherplatzeffizienz ungeachtet der Daten, die gespeichert werden, für Sie wichtig ist, sollten Sie den Standardwert von recordsize (128 KB) beibehalten und die Komprimierung (mit dem Standardwert lzjb) aktivieren.

• Der Befehl df berücksichtigt deduplizierte Dateidaten nicht.

Verhalten bei ungenügendem Speicherplatz

Schnappschüsse von Dateisystemen sind in ZFS äußerst einfach und ohne hohen Aufwand zu erstellen. Schnappschüsse sind in den meisten ZFS-Umgebungen vorhanden. Weitere Informationen zu ZFS-Schnappschüssen finden Sie in Kapitel 6, Arbeiten mit Oracle Solaris ZFS-Schnappschüssen und -Klonen.

Das Vorhandensein von Schnappschüssen kann beim Freigeben von Festplattenkapazität ein unvorgesehenes Verhalten hervorrufen. Normalerweise können Sie mit den entsprechenden Zugriffsrechten eine Datei aus einem vollständigen Dateisystem löschen, wodurch im Dateisystem mehr Festplattenkapazität verfügbar wird. Wenn die zu löschende Datei jedoch in einem Schnappschuss eines Dateisystems vorhanden ist, wird durch das Löschen dieser Datei keine Festplattenkapazität freigegeben. Die von dieser Datei belegten Datenblöcke werden weiterhin vom Schnappschuss referenziert.

Deswegen kann infolge des Löschens einer Datei mehr Festplattenkapazität belegt werden, da eine neue Verzeichnisversion erstellt werden muss, die den neuen Namespace-Status widerspiegelt. Dadurch können beim Löschen von Dateien unvorhergesehene ENOSPC- oder EDQUOT-Fehler auftreten.

Einhängen von ZFS-Dateisystemen

ZFS soll die Komplexität verringern und die Administration vereinfachen. Bei herkömmlichen Dateisystemen müssen Sie beispielsweise bei jedem Hinzufügen eines neuen Dateisystems die Datei /etc/vfstab entsprechend ändern. In ZFS ist das nicht mehr erforderlich, da Dateisysteme je nach den Dateisystemeigenschaften automatisch ein- und ausgehängt werden. ZFS-Einträge müssen also nicht in der Datei /etc/vfstab verwaltet werden.

Weitere Informationen zum Einhängen und Freigeben von ZFS-Dateisystemen finden Sie unter Einhängen von ZFS-Dateisystemen.

Herkömmliche Datenträgeradministration

Wie bereits unter Speicherpools in ZFS erwähnt, ist für ZFS kein spezielles Serviceprogramm zur DatenträgerAdministration erforderlich. ZFS arbeitet mit im raw-Modus betriebenen Geräten. Deswegen können Speicher-Pools erstellt werden, die aus (software- oder hardwarebasierten) Logical Volumes bestehen. Diese Konfiguration wird jedoch nicht empfohlen, da ZFS am besten mit im raw-Modus betriebenen Geräten arbeitet. Die Verwendung von Logical Volumes kann sich negativ auf die Leistung und die Zuverlässigkeit auswirken und sollte deswegen vermieden werden.

Solaris ACL-Modell basierend auf NFSv4

Frühere Versionen des Betriebssystems Solaris unterstützten eine auf der POSIX-Spezifikation beruhende Implementierung von Zugriffskontrolllisten. POSIX-basierte Zugriffskontrolllisten dienen zum Schutz von UFS-Dateien. Zum Schutz von ZFS-Dateien wird ein neues, auf der NFSv4-Spezifikation beruhendes Solaris-Modell für Zugriffskontrolllisten verwendet.

Die Hauptunterschiede des neuen Solaris-Zugriffskontrolllistenmodells bestehen in Folgendem:

• Das Modell basiert auf der NFSv4-Spezifikation und ist den NT-Zugriffskontrolllistenmodellen ähnlich.

• Das Modell bietet feiner abgestimmte Zugriffsrechte.

• Zugriffskontrolllisten werden mit den Befehlen chmod und ls anstatt setfacl und getfacl eingestellt und angezeigt.

• Das Modell bietet eine reichhaltigere Vererbungssemantik zum Festlegen der Weitergabe von Zugriffsrechten von über- an untergeordnete Verzeichnisse usw.

Weitere Informationen zu Zugriffskontrolllisten mit ZFS-Dateien finden Sie in Kapitel 7, Schützen von Oracle Solaris ZFS-Dateien mit Zugriffskontrolllisten und Attributen.