Sun and OracleChannel SunHow to BuyLog InEnglish

Solaris ZFS - Administrationshandbuch
  Search only this book
Search Help
View this book in:
Contained Within
Find More Documentation
Featured Support Resources
 Download this book in PDF (1803 KB)

Kapitel 1 Das ZFS-Dateisystem (Einleitung)

Dieses Kapitel bietet einen Überblick über das ZFS-Dateisystem, seine Funktionen und Vorteile. Darüber hinaus werden die in diesem Handbuch verwendeten Grundbegriffe erläutert.

Dieses Kapitel enthält die folgenden Abschnitte:

Neuerungen in ZFS

In diesem Abschnitt sind die neuen Leistungsmerkmale des ZFS-Dateisystems zusammengefasst.

Unterstützung für ZFS- und Flash-Installation

Solaris 10 10/09-Release: In diesem Solaris-Release haben Sie die Möglichkeit, ein JumpStart-Profil zur Identifizierung eines Flash-Archivs eines ZFS-Root-Pools einzurichten. Weitere Informationen finden Sie unter Installieren eines ZFS-Root-Dateisystems (Flash-Archiv-Installation).

ZFS-Benutzer- und Gruppenkontingente

Solaris 10 10/09-Release: In früheren Solaris-Versionen konnten Kontingente und Reservierungen zur Verwaltung und Reservierung von Speicherplatz auf ZFS-Dateisysteme angewendet werden.

In diesem Solaris-Release können Sie ein Kontingent für den Speicherplatz, der von zu einem bestimmten Benutzer oder einer bestimmten Gruppe gehörigen Dateien beansprucht wird, einrichten. Das Einrichten von Benutzer- oder Gruppenkontingenten ist in einer Umgebung mit vielen Benutzern oder Gruppen sinnvoll.

Sie können Benutzer- oder Gruppenkontingente unter Verwendung der Eigenschaften zfs userquota und zfs groupquota wie folgt einrichten:


# zfs set userquota@user1=5G tank/data
# zfs set groupquota@staff=10G tank/staff/admins

Sie können die aktuelle Einstellung eines Benutzer- oder Gruppenkontingents wie folgt anzeigen:


# zfs get userquota@user1 tank/data
NAME       PROPERTY         VALUE            SOURCE
tank/data  userquota@user1  5G               local
# zfs get groupquota@staff tank/staff/admins
NAME               PROPERTY          VALUE             SOURCE
tank/staff/admins  groupquota@staff  10G               local

Stellen Sie allgemeine Informationen über ein Kontingent wie folgt ein:


# zfs userspace tank/data
TYPE        NAME   USED  QUOTA  
POSIX User  root     3K   none  
POSIX User  user1     0    5G  

# zfs groupspace tank/staff/admins
TYPE         NAME   USED  QUOTA  
POSIX Group  root     3K   none  
POSIX Group  staff     0    10G

Sie können individuelle Speicherplatzbelegung von Benutzern oder Gruppen über die Eigenschaften userused@user und groupused@ group wie folgt anzeigen:


# zfs get userused@user1 tank/staff
NAME        PROPERTY        VALUE           SOURCE
tank/staff  userused@user1  213M            local
# zfs get groupused@staff tank/staff
NAME        PROPERTY         VALUE            SOURCE
tank/staff  groupused@staff  213M             local

Weitere Informationen zum Einrichten von Benutzerkontingenten finden Sie unter Einstellen von ZFS-Kontingenten und -Reservierungen.

ZFS-Zugriffssteuerungslistenvererbungsmodus "Pass Through" zur Ausführungsberechtigung

Solaris 10 10/09-Release: In früheren Solaris-Versionen konnte die Zugriffssteuerungslistenvererbung angewendet werden, sodass alle Dateien mit den Zugriffsrechten 0664 oder 0666 erstellt wurden. Wenn Sie die Ausführungsberechtigung aus dem Dateierstellungsmodus optional in die vererbbare Zugriffssteuerungsliste einschließen möchten, können Sie in diesem Release den Vererbungsmodus "Pass Through" zur Ausführungsberechtigung verwenden.

Ist aclinherit=passthrough-x auf einem ZFS-Dataset aktiviert, so können Sie die Ausführungsberechtigung für eine aus dem Tool cc oder gcc erstellte Ausgabedatei einschließen. Beinhaltet die vererbbare Zugriffssteuerungsliste die Ausführungsberechtigung nicht, so ist die Ausgabe des Compilers erst dann ausführbar, wenn Sie mit dem Befehl chmod die Berechtigungen der Datei ändern.

Weitere Informationen finden Sie unter Beispiel 8–12.

Verbesserungen der ZFS-Eigenschaften

Solaris 10/09-Release: Die folgenden Verbesserungen der ZFS-Dateisysteme sind in diesem Release inbegriffen.

  • Einstellung der Eigenschaften von ZFS-Dateisystemen zum Zeitpunkt der Erstellung eines Pools – Sie können die Eigenschaften des ZFS-Dateisystems bei Erstellung eines Pools einstellen. Im folgenden Beispiel ist die Komprimierung auf dem ZFS-Dateisystem, das bei Erstellung des Pools eingerichtet wird, aktiviert.


    # zpool create -O compression=on pool mirror c0t1d0 c0t2d0

  • Einstellung von Cache-Eigenschaften auf einem ZFS-Dateisystem – In Solaris 10/09 werden zwei neue Eigenschaften von ZFS-Dateisystemen zur Verfügung gestellt, mit denen Sie kontrollieren können, was im primären Cache (ARC) und was im sekundären Cache (L2ARC) gespeichert wird. Die Cache-Eigenschaften sind folgendermaßen eingestellt:

    • primarycache – Kontrolliert, was im ARC gespeichert wird.

    • secondarycache – Kontrolliert, was im L2ARC gespeichert wird.

    • Mögliche Werte für beide Eigenschaften – all, none und metadata. Ist diese Eigenschaft auf all gesetzt, werden sowohl Benutzerdaten als auch Metadaten im Cache gespeichert. Ist diese Eigenschaft auf none gesetzt, werden weder Benutzerdaten noch Metadaten im Cache gespeichert. Ist diese Eigenschaft auf metadata gesetzt, werden nur Metadaten im Cache gespeichert. Die Standardeinstellung ist all.

    Sie können diese Eigenschaften für ein bereits vorhandenes Dateisystem oder bei der Erstellung des Dateisystems einstellen. Beispiel:


    # zfs set primarycache=metadata tank/datab
# zfs create -o primarycache=metadata tank/newdatab

    Handelt es sich um ein bereits vorhandenes Dateisystem, werden nur neue E/A-Operationen auf der Basis des Werts dieser Eigenschaften im Cache gespeichert.

    Bei einigen Datenbank-Umgebungen kann es von Vorteil sein, Benutzerdaten nicht im Cache zu speichern. Sie können selbst bestimmen, ob das Einstellen von Cache-Eigenschaften für Ihre Umgebung sinnvoll ist.

  • Eigenschaften der Speicherplatzverwaltung – Mit neuen schreibgeschützten Dateisystem-Eigenschaften können Sie die Speicherplatzbelegung für Klone, Dateisysteme und Volumes identifizieren, allerdings nicht für Snapshots. Folgende Eigenschaften stehen zur Verfügung:

    • usedbychildren – Gibt den Speicherplatz an, der von untergeordneten Elementen dieses Datasets beansprucht wird, und der beim Löschen dieser untergeordneten Elemente frei werden würde. Die Abkürzung für die Eigenschaft lautet usedchild

    • usedbydataset – Gibt den Speicherplatz an, der vom Dataset selbst beansprucht wird und der beim Löschen des Datasets und vorherigem Löschen aller Snapshots und Entfernen von refreservation frei werden würde. Die Abkürzung für die Eigenschaft lautet usededds

    • usedbyrefreservation – Gibt den von einem refreservation-Set auf diesem Dataset beanspruchten Speicherplatz an, der beim Entfernen von refreservation frei werden würde. Die Abkürzung für die Eigenschaft lautet usedrefreserv

    • usedbysnapshots – Gibt den von Snapshots dieses Datasets beanspruchten Speicherplatz an. Insbesondere geht es dabei um den Speicherplatz, der beim Löschen aller Snapshots des Datasets frei werden würde. Beachten Sie, dass es sich dabei nicht einfach um die Summe der used Eigenschaften der Snapshots handelt, da Speicherplatz von mehreren Snapshots geteilt werden kann. Die Abkürzung für die Eigenschaft lautet usedsnap

    Diese neuen Eigenschaften teilen den Wert der used Eigenschaft in die verschiedenen Elemente auf, die Speicherplatz beanspruchen. Genauer betrachtet wird der Wert der used Eigenschaft folgendermaßen aufgeteilt:


    used property = usedbychildren + usedbydataset + usedbyrefreservation + usedbysnapshots

    Sie können diese Eigenschaften mit dem Befehl zfs list - o space genauer betrachten. Beispiel:


    $ zfs list -o space
NAME               AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool              25.4G  7.79G         0     64K              0      7.79G
rpool/ROOT         25.4G  6.29G         0     18K              0      6.29G
rpool/ROOT/snv_98  25.4G  6.29G         0   6.29G              0          0
rpool/dump         25.4G  1.00G         0   1.00G              0          0
rpool/export       25.4G    38K         0     20K              0        18K
rpool/export/home  25.4G    18K         0     18K              0          0
rpool/swap         25.8G   512M         0    111M           401M          0

    Der obige Befehl entspricht dem Befehl zfs list - o name,avail,used,usedsnap,usedds,usedrefreserv,usedchild -t filesystem,volume.

  • Snapshots auflisten– Die Pool-Eigenschaft listsnapshots steuert, ob Snapshot-Informationen mit dem Befehl zfs list angezeigt werden. Der Standardwert ist on, Snapshot-Informationen werden also standardmäßig angezeigt.

    Wenn Sie die Eigenschaft listsnapshots deaktivieren, können Sie den Befehl zfs list -t snapshots verwenden, Snapshot-Informationen werden angezeigt.

Wiederherstellung von ZFS-Protokolliergeräten

Solaris 10 10/09-Release: In diesem Release identifiziert ZFS Intent-Protokoll-Fehler durch den Befehl zpool status. Diese Fehler werden auch von.FMA gemeldet. Ein Intent-Protokoll-Fehler kann sowohl mit ZFS als auch mit FMA behoben werden.

Wenn das System beispielsweise plötzlich herunterfährt, bevor synchrone Schreibvorgänge auf einem Pool mit separatem Protokolliergerät abgeschlossen werden können, werden Meldungen dieser Art angezeigt:


# zpool status -x
  pool: pool
 state: FAULTED
status: One or more of the intent logs could not be read.
        Waiting for adminstrator intervention to fix the faulted pool.
action: Either restore the affected device(s) and run 'zpool online',
        or ignore the intent log records by running 'zpool clear'.
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        pool        FAULTED      0     0     0 bad intent log
          mirror    ONLINE       0     0     0
            c0t1d0  ONLINE       0     0     0
            c0t4d0  ONLINE       0     0     0
        logs        FAULTED      0     0     0 bad intent log
          c0t5d0    UNAVAIL      0     0     0 cannot open

Nach dem Fehlschlag des Protokolliergeräts können Sie den Normalbetrieb folgendermaßen wiederherstellen:

  • Ersetzen Sie das Protokolliergerät oder stellen Sie es wieder her. In diesem Beispiel handelt es sich um das Gerät c0t5d0.

  • Nehmen Sie das Protokolliergerät wieder in Betrieb.


    # zpool online pool c0t5d0

  • Setzen Sie den Fehlerzustand "Protokolliergerät fehlgeschlagen" zurück.


    # zpool clear pool

Wenn Sie den Normalbetrieb wiederherstellen möchten, ohne das Protokolliergerät zu ersetzen, können Sie ihn mit dem Befehl zpool clear löschen. In diesem Szenario läuft der Pool in eingeschränktem Modus, und die Protokolleinträge werden in den Haupt-Pool geschrieben, bis das separate Protokolliergerät ersetzt wurde.

Um die Auswirkungen des Fehlschlags eines Protokolliergeräts abzuschwächen, können Sie gespiegelte Protokolliergeräte verwenden.

Verwenden von Cache-Geräten im ZFS-Speicher-Pool

Solaris 10 10/09-Release: In diesem Solaris-Release können Sie Pools erstellen und Cache-Geräte angeben, die zur Speicherung von Speicher-Pool-Daten im Cache dienen.

Cache-Speicher·bietet zwischen Hauptspeicher und Festplatte eine zusätzliche Schicht zur Datenspeicherung. Die Verwendung von Cache-Speicher bietet für die Speicherung meist statischer Daten mithilfe von wahlfreiem Zugriff die größte Leistungsverbesserung.

Beim Erstellen eines Speicher-Pools können eines oder meherer Cache-Speichergeräte angegeben werden. Beispiel:


# zpool create pool mirror c0t2d0 c0t4d0 cache c0t0d0
# zpool status pool
  pool: pool
 state: ONLINE
 scrub: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        pool        ONLINE       0     0     0
          mirror    ONLINE       0     0     0
            c0t2d0  ONLINE       0     0     0
            c0t4d0  ONLINE       0     0     0
        cache
          c0t0d0    ONLINE       0     0     0

errors: No known data errors

Nach dem Erstellen von Cache-Speichergeräten werden diese nach und nach mit Daten aus dem Hauptspeicher gefüllt. Je nach Größe eines definierten Cache-Speichergeräts kann es bis zu über eine Stunde lang dauern, bis es voll ist. Die Kapazität und Lesevorgänge können mithilfe des Befehls zpool iostat wie folgt überwacht werden:


# zpool iostat -v pool 5

Nach der Erstellung eines Pools können zu ihm Cache-Speichergeräte hinzugefügt und wieder entfernt werden.

Weitere Informationen finden Sie unter Erstellen eines ZFS-Speicher-Pools mit Cache-Geräten und Beispiel 4–4.

Zonenmigration in einer ZFS-Umgebung

Solaris 10 5/09: Dieses Release bietet eine erweiterte Unterstützung für das Migrieren von Zonen in einer ZFS-Umgebung mit Live Upgrade. Weitere Informationen finden Sie unter Verwenden von Solaris Live Upgrade zum Migrieren oder Aktualisieren eines Systems mit Zonen (Solaris 10 5/09 und Solaris 10 10/09).

Die Solaris 10 5/09-Versionshinweise enthalten eine Liste der bekannten Probleme mit diesem Release.

Unterstützung für Installation und Booten von ZFS-Root-Dateisystemen

Solaris 10 10/08: In diesem Solaris-Release können ZFS-Root-Dateisysteme installiert und gebootet werden. Das Installieren eines ZFS-Root-Dateisystems ist sowohl mit der Erstinstallationsoption als auch mit der JumpStart-Funktion möglich. Alternativ kann ein UFS-Root-Dateisystem mithilfe der Live Upgrade-Funktion in ein ZFS-Root-Dateisystem migriert werden. Außerdem steht ZFS-Unterstützung für Swap- und Dump-Geräte zur Verfügung. Weitere Informationen finden Sie in Kapitel 5Installieren und Booten eines ZFS-Root-Dateisystems.

Die Solaris 10 10/08-Versionshinweise enthalten eine Liste der bekannten Probleme mit diesem Release.

Wiederherstellen eines Datasets ohne Aushängen

Release Solaris 10 10/08: Dieses Release bietet die Möglichkeit, Datasets wiederherzustellen, ohne sie zuerst auszuhängen. Dieses Leistungsmerkmal bedeutet, dass es nicht mehr notwendig ist, mit der Option zfs rollback -f das Aushängen zu erzwingen. Die Option -f wird nicht mehr Unterstützt und wird bei Angabe ignoriert.

Verbesserungen des Befehls zfs send

Release Solaris 10 10/08: Dieses Release umfasst die folgenden Verbesserungen des Befehls zfs send.

  • Senden aller inkrementellen Streams von einem Snapshot zu einem kumulativen Snapshot. Beispiel:


    # zfs list
NAME                      USED  AVAIL  REFER  MOUNTPOINT
pool                      428K  16.5G    20K  /pool
pool/fs                    71K  16.5G    21K  /pool/fs
pool/fs@snapA              16K      -  18.5K  -
pool/fs@snapB              17K      -    20K  -
pool/fs@snapC              17K      -  20.5K  -
pool/fs@snapD                0      -    21K  -
# zfs send -I pool/fs@snapA pool/fs@snapD > /snaps/fs@combo

    Alle inkrementellen Snapshots zwischen fs@snapA und fs@snapD werden nach fs@combo gesendet.

  • Senden eines inkrementellen Streams vom ursprünglichen Snapshot, um einen Klon zu erstellen. Der ursprüngliche Snapshot muss auf der Empfangsseite bereits vorhanden sein, damit der inkrementelle Stream angenomme werden kann. Beispiel:


    # zfs send -I pool/fs@snap1 pool/clone@snapA > /snaps/fsclonesnap-I
.
.
# zfs receive -F pool/clone < /snaps/fsclonesnap-I

  • Senden eines Replikationsstreams aller abhängigen Dateisysteme zu den benannten Snapshots. Nach dem Empfang werden alle Eigenschaften, Snapshots, abhängigen Dateisysteme und Klone beibehalten. Beispiel:


    zfs send -R pool/fs@snap > snaps/fs-R

    Ein ausführlicheres Beispiel finden Sie in Beispiel 7–1.

  • Senden eines inkrementellen Replikationsstreams. 


    zfs send -R -[iI] @snapA pool/fs@snapD

    Ein ausführlicheres Beispiel finden Sie in Beispiel 7–1.

Weitere Informationen finden Sie unter Senden und Empfangen komplexer ZFS-Snapshot-Datenstreams.

ZFS-Kontingente und -Reservierungen ausschließlich für Dateisystemdaten

Release Solaris 10 10/08: Zusätzlich zu den vorhandenen ZFS-Funktionen für Kontingente und Reservierungen enthält diese Version in der Speicherplatzanzeige auch Dataset-Kontingente und -Reservierungen ohne abhängige Entitäten wie z. B. Snapshots oder Klone.

  • Die Eigenschaft refquota beschränkt den Speicherplatz, den ein Dataset belegen kann. Sie erzwingt einen absoluten Grenzwert des belegbaren Speicherplatzes. Dieser absolute Grenzwert berücksichtigt jedoch nicht den von abhängigen Entitäten wie z. Snapshots oder Klonen belegten Speicherplatz.

  • Die Eigenschaft refreservation legt den für ein Dataset minimal garantierten Speicherplatz (ohne Speicherplatz für abhängige Entitäten) fest.

So können Sie beispielsweise in refquota für studentA einen Wert von 10 GB festlegen, der für den von diesem Benutzer belegten Speicherplatz einen absoluten Grenzwert von 10 GB festlegt. Zum Erreichen einer zusätzlichen Flexibilität können Sie ein 20 GB-Quotum einstellen, mit dessen Hilfe Sie die Snapshots von studentA verwalten können.


# zfs set refquota=10g tank/studentA
# zfs set quota=20g tank/studentA

Weitere Informationen finden Sie unter Einstellen von ZFS-Kontingenten und -Reservierungen.

Eigenschaften von ZFS-Speicher-Pools

Release Solaris 10 10/08: Die Eigenschaften von ZFS-Speicher-Pools wurden mit einem vorigen Release eingeführt. In diesem Release stehen zusätzliche Informationen zu den Eigenschaften zur Verfügung. Beispiel:


# zpool get all mpool
NAME   PROPERTY     VALUE             SOURCE
mpool  size         33.8G             -
mpool  used         5.76G             -
mpool  available    28.0G             -
mpool  capacity     17%               -
mpool  altroot      -                 default
mpool  health       ONLINE            -
mpool  guid         2689713858991441653  -
mpool  version      10                default
mpool  bootfs       mpool/ROOT/zfsBE  local
mpool  delegation   on                default
mpool  autoreplace  off               default
mpool  cachefile    -                 default
mpool  failmode     continue          local

Eine Beschreibung dieser Eigenschaften können Sie Tabelle 4–1 entnehmen.

  • Eigenschaft cachefile - Solaris 10 10/08: Diese Version enthält die neue Eigenschaft cachefile die festlegt, wo Informationen zur Poolkonfiguration im Cache-Speicher abgelegt werden. Alle Pools im Cache werden beim Booten des Systems automatisch importiert. Es kann jedoch sein, dass Installations- und Cluster-Umgebungen diese Informationen an verschiedenen Stellen im Cache-Speicher ablegen müssen, sodass Pools nicht automatisch importiert werden.

    Sie können diese Eigenschaft so einstellen, dass Poolkonfigurationen an einer anderen Stelle im Cache-Speicher abgelegt werden und später mithilfe des Befehls zpool import c importiert werden können. Für die meisten ZFS-Konfigurationen wird diese Eigenschaft nicht verwendet.

    Die Eigenschaft cachefile ist nicht beständig und wird nicht auf Festplatte gespeichert. Diese Eigenschaft löst die Eigenschaft temporary ab, die in früheren Solaris-Versionen anzeigte, dass Poolinformationen nicht im Cache gespeichert werden sollten.

  • Eigenschaft failmode - Release Solaris 10 10/08: Diese Version enthält die Eigenschaft failmode, mit der festgelegt wird, wie sich das System im Falle eines äußerst schwerwiegenden·Poolausfalls aufgrund von Unterbrechungen in der Gerätekonnektivität bzw. dem gleichzeitigen Ausfall aller Speichergeräte im Pool verhalten soll. Die Eigenschaft failmode kann auf die Werte wait, continue oder panic gesetzt werden. Der Standardwert ist wait. Dies bedeutet, dass Sie das ausgefallene Gerät neu in den Pool integrieren oder auswechseln und den Fehler danach mit dem Befehl zpool clear löschen müssen.

    Die Eigenschaft failmode wird wie andere einstellbare ZFS-Eigenschaften auch gesetzt. Dies kann vor oder nach dem Erstellen eines Pools geschehen. Beispiel:


    # zpool set failmode=continue tank
# zpool get failmode tank
NAME  PROPERTY  VALUE     SOURCE
tank  failmode  continue  local
    		 

    # zpool create -o failmode=continue users mirror c0t1d0 c1t1d0

    Eine Beschreibung aller Eigenschaften für ZFS-Pools finden Sie in Tabelle 4–1.

Verbesserungen des ZFS-Befehlsprotokolls (zpool history)

Release Solaris 10 10/08: Der Befehl zpool history wurde um die folgenden neuen Leistungsmerkmale erweitert:

  • Informationen zu ZFS-Dateisystemereignissen werden angezeigt. Beispiel:


    # zpool history
History for 'rpool':
2009-08-26.16:49:07 zpool create -f -o failmode=continue -R /a -m legacy -o cachefile=
/tmp/root/etc/zfs/zpool.cache rpool c1t1d0s0
2009-08-26.16:49:08 zfs set canmount=noauto rpool
2009-08-26.16:49:08 zfs set mountpoint=/rpool rpool
2009-08-26.16:49:09 zfs create -o mountpoint=legacy rpool/ROOT
2009-08-26.16:49:10 zfs create -b 8192 -V 2048m rpool/swap
2009-08-26.16:49:11 zfs create -b 131072 -V 1024m rpool/dump
2009-08-26.16:49:14 zfs create -o canmount=noauto rpool/ROOT/zfs1009BE
2009-08-26.16:49:15 zpool set bootfs=rpool/ROOT/zfs1009BE rpool
2009-08-26.16:49:15 zfs set mountpoint=/ rpool/ROOT/zfs1009BE
2009-08-26.16:49:16 zfs set canmount=on rpool
2009-08-26.16:49:17 zfs create -o mountpoint=/export rpool/export
2009-08-26.16:49:18 zfs create rpool/export/home
2009-08-28.08:17:59 zpool attach rpool c1t1d0s0 c1t0d0s0

  • Die Option -l zum Anzeigen eines langen Formats mit Benutzernamen, Hostnamen und Angabe der Zone, in der die Operation ausgeführt wurde. Beispiel:


    # zpool history -l rpool
History for 'rpool':
2009-08-26.16:49:07 zpool create -f -o failmode=continue -R /a -m legacy -o cachefile=
/tmp/root/etc/zfs/zpool.cache rpool c1t1d0s0 [user root on neo:global]
2009-08-26.16:49:08 zfs set canmount=noauto rpool [user root on neo:global]
2009-08-26.16:49:08 zfs set mountpoint=/rpool rpool [user root on neo:global]
2009-08-26.16:49:09 zfs create -o mountpoint=legacy rpool/ROOT [user root on neo:global]
2009-08-26.16:49:10 zfs create -b 8192 -V 2048m rpool/swap [user root on neo:global]
2009-08-26.16:49:11 zfs create -b 131072 -V 1024m rpool/dump [user root on neo:global]
2009-08-26.16:49:14 zfs create -o canmount=noauto rpool/ROOT/zfs1009BE [user root on neo:global]
2009-08-26.16:49:15 zpool set bootfs=rpool/ROOT/zfs1009BE rpool [user root on neo:global]
2009-08-26.16:49:15 zfs set mountpoint=/ rpool/ROOT/zfs1009BE [user root on neo:global]
2009-08-26.16:49:16 zfs set canmount=on rpool [user root on neo:global]
2009-08-26.16:49:17 zfs create -o mountpoint=/export rpool/export [user root on neo:global]
2009-08-26.16:49:18 zfs create rpool/export/home [user root on neo:global]
2009-08-28.08:17:59 zpool attach rpool c1t1d0s0 c1t0d0s0 [user root on neo:global]

  • Die Option -i zum Anzeigen von Informationen zu internen Ereignissen. Diese sind für diagnostische Zwecke nutzbar. Beispiel:


    # zpool history -i rpool
History for 'rpool':
2009-08-26.16:49:07 zpool create -f -o failmode=continue -R /a -m legacy -o cachefile=
/tmp/root/etc/zfs/zpool.cache rpool c1t1d0s0
2009-08-26.16:49:07 [internal property set txg:6] mountpoint=/ dataset = 16
2009-08-26.16:49:07 [internal property set txg:7] mountpoint=legacy dataset = 16
2009-08-26.16:49:08 [internal property set txg:8] canmount=2 dataset = 16
2009-08-26.16:49:08 zfs set canmount=noauto rpool
2009-08-26.16:49:08 [internal property set txg:10] mountpoint=/rpool dataset = 16
2009-08-26.16:49:08 zfs set mountpoint=/rpool rpool
2009-08-26.16:49:09 [internal create txg:12] dataset = 31
2009-08-26.16:49:09 [internal property set txg:13] mountpoint=legacy dataset = 31
2009-08-26.16:49:09 zfs create -o mountpoint=legacy rpool/ROOT
2009-08-26.16:49:09 [internal create txg:15] dataset = 37
2009-08-26.16:49:10 [internal property set txg:16] refreservation=2147483648 dataset = 37
2009-08-26.16:49:10 [internal refreservation set txg:16] 2147483648 dataset = 37
2009-08-26.16:49:10 zfs create -b 8192 -V 2048m rpool/swap
2009-08-26.16:49:10 [internal create txg:18] dataset = 43
2009-08-26.16:49:10 [internal property set txg:19] refreservation=1073741824 dataset = 43
2009-08-26.16:49:10 [internal refreservation set txg:19] 1073741824 dataset = 43
.
.
.

Weitere Informationen zur Verwendung des Befehls zpool history entnehmen Sie bitte dem Abschnitt Erkennen von Problemen in ZFS.

Upgrade von ZFS-Dateisystemen (zfs upgrade)

Release Solaris 10 10/08: Dieses Release bietet den Befehl zfs upgrade, mit dem Dateisysteme künftig auf neue ZFS-Dateisystemverbesserungen aufgerüstet werden können. ZFS-Speicherpools besitzen eine ähnliche Upgrade-Funktion, um vorhandene Speicherpools um neue Funktionalität zu erweitern.

Beispiel:


# zfs upgrade
This system is currently running ZFS filesystem version 3.

All filesystems are formatted with the current version.
Hinweis –

Auf aufgerüstete Dateisysteme sowie aus diesen mit dem Befehl zfs send erstellte Datenstreams kann auf Systemen nicht zugegriffen werden, die unter einer älteren Softwareversion laufen.

Delegierte ZFS-Administration

Release Solaris 10 10/08: In diesem Release können fein abgestimmte Zugriffsrechte für die Durchführung von ZFS-Administrationsaufgaben an Benutzer ohne ausreichende Zugriffsrechte delegiert werden.

Zum Gewähren und Verweigern von Zugriffsrechten dienen die Befehle zfs allow und zfs unallow.

Mit der Speicherpool-Eigenschaft delegation kann die delegierte Administration aktiviert und deaktiviert werden. Beispiel:


# zpool get delegation users
NAME  PROPERTY    VALUE       SOURCE
users  delegation  on          default
# zpool set delegation=off users
# zpool get delegation users
NAME  PROPERTY    VALUE       SOURCE
users  delegation  off         local

Standardmäßig ist die Eigenschaft delegation aktiviert.

Weitere Informationen entnehmen Sie bitte Kapitel 9Delegierte ZFS-Administration und zfs(1M).

Einrichten separater ZFS-Protokolliergeräte

Release Solaris 10 10/08: Das Protokoll ZIL (ZFS Intent Log) erfüllt die POSIX-Anforderungen für synchrone Transaktionen. So setzen Datenbanken bei der Rückkehr von Systemaufrufen beispielsweise oft voraus, dass Transaktionen auf stabilen Speichergeräten stattfinden. NFS und andere Anwendungen können zur Gewährleistung der Datenstabilität ebenfalls fsync() verwenden. Standardmäßig wird das ZIL aus Blöcken innerhalb des Hauptspeicherpools zugewiesen. Durch Verwendung getrennter Intent-Protokolliergeräte im ZFS-Speicher-Pool wie z. B. NVRAM oder eine speziell dafür vorgesehene Festplatte kann jedoch eine höhere Leistung erreicht werden.

Protokolliergeräte für das Intent-Protokoll von ZFS sind etwas Anderes als Datenbankprotokolldateien.

Die Einrichtung eines ZFS-Protokolliergeräts kann bei oder nach der Erstellung des Speicher-Pools erfolgen. Beispiele zum Einrichten von Protokolliergeräten finden Sie unter Erstellen eines ZFS-Speicher-Pools mit Protokolliergerätenund Hinzufügen von Datenspeichergeräten zu einem Speicher-Pool.

Sie können zur Datenspiegelung an ein vorhandenes Protokolliergerät ein weiteres Protokolliergerät anschließen. Dies entspricht dem Verbinden eines Speichergeräts in einem Speicher-Pool ohne Datenspiegelung.

Berücksichtigen Sie folgende Aspekte bei der Überlegung, ob die Einrichtung eines ZFS-Protokolliergeräts für Ihre Umgebung ratsam ist:

  • Jegliche Leistungssteigerung durch die Implementierung eines separaten Protokolliergeräts ist von der Art des Geräts, der Hardwarekonfiguration des Speicher-Pools sowie von der Arbeitslast der Anwendung abhängig. Vorläufige Informationen zur Leistung finden Sie in diesem Blog:

    http://blogs.sun.com/perrin/entry/slog_blog_or_blogging_on

  • Es ist möglich, Protokolliergeräte zu spiegeln oder deren Replikation aufzuheben. RAID-Z wird für Protokolliergeräte jedoch nicht unterstützt.

  • Wenn ein separates Protokolliergerät nicht gespiegelt wurde und das Gerät mit den Protokollen ausfällt, wird durch Speicherung von Protokollblöcken auf den Speicher-Pool zurückgeschaltet.

  • Protokolliergeräte können als Teil des Speicher-Pools hinzugefügt, ersetzt, angehängt, abgehängt und importiert und exportiert werden. Derzeit können Protokolliergeräte nicht entfernt werden.

  • Die Mindestgröße für ein Protokolliergerät entspricht der Mindestgröße für jedes Gerät in einem Pool. Dies sind 64 MB. Auf einem Protokolliergerät können verhältnismäßig wenige Ausführungsdaten gespeichert werden. Bei Bestätigung der Protokolltransaktion (Systemaufruf) werden die Protokollblöcke geleert.

  • Ein Protokolliergerät sollte nicht größer als rund die Hälfte des physischen Speichers sein, da dies die Höchstmenge an potenziellen Ausführungsdaten ist, die gespeichert werden kann. So sollten Sie beispielsweise für ein System mit 16 GB physischem Speicher ein Protokolliergerät von höchstens 8 GB Größe in Erwägung ziehen.

Erstellen intermediärer ZFS-Datasets

Release Solaris 10 10/08: Durch Verwendung der Option -p mit den Befehlen zfs create, zfs clone und zfs rename können Sie schnell ein intermediäres Dataset erstellen, falls es noch nicht vorhanden ist.

So können Sie beispielsweise ZFS-Datasets (users/area51) im Speicher-Pool datab erstellen.


# zfs list
NAME                        USED  AVAIL  REFER  MOUNTPOINT
datab                       106K  16.5G    18K  /datab
# zfs create -p -o compression=on datab/users/area51

Wenn während des Erstellungsvorgangs bereits ein intermediäres Dataset vorhanden ist, wird er ohne Fehlermeldung abgeschlossen.

Angegebene Eigenschaften gelten für das Ziel-Dataset und nicht für die intermediären Datasets. Beispiel:


# zfs get mountpoint,compression datab/users/area51
NAME                PROPERTY     VALUE                SOURCE
datab/users/area51  mountpoint   /datab/users/area51  default
datab/users/area51  compression  on                   local

Es wird ein intermediäres Dataset mit Standard-Einhängepunkt erstellt. Alle zusätzlichen Eigenschaften werden für dieses intermediäre Dataset deaktiviert. Beispiel:


# zfs get mountpoint,compression datab/users
NAME         PROPERTY     VALUE         SOURCE
datab/users  mountpoint   /datab/users  default
datab/users  compression  off           default

Weitere Informationen finden Sie in der Manpage zfs(1M).

Verbesserungen der ZFS-Hotplug-Funktion

Release Solaris 10 10/08: In diesem Release reagiert ZFS effektiver auf Speichergeräte, die entfernt werden. Darüber hinaus steht ein Mechanismus zur automatischen Erkennung von neu eingesetzten Speichergeräten zur Verfügung, der folgende Verbesserungen bietet:

  • Sie können ein Speichergerät durch ein anderes auswechseln, ohne dafür den Befehl zpool replace eingeben zu müssen.

    Die Eigenschaft autoreplace legt die Charakteristika des automatischen Erkennens ausgewechselter Geräte fest. Wenn diese Eigenschaft auf „off“ gesetzt ist, muss das Auswechseln von Speichergeräten vom Administrator mithilfe des Befehls zpool replace initiiert werden. Wenn diese Eigenschaft auf „on“ gesetzt ist, wird das neue Speichergerät an der physischen Adresse des vorherigen Speichergeräts im Pool automatisch formatiert und in den Pool eingebunden. Standardeinstellung ist „off“.

  • Für die physische Entfernung eines Speichergeräts bzw. Hot-Spares bei laufendem System gibt es jetzt den Speicher-Pool-Status REMOVED. Falls verfügbar, wird ein Hot-Spare für das entfernte Speichergerät in den Pool eingebunden.

  • Wenn ein Speichergerät entfernt und danach wieder eingesetzt wird, wird es online geschaltet. Wenn für das entfernte Speichergerät ein Hot-Spare eingebunden wurde, wird dieses bei Abschluss der Online-Schaltung wieder entfernt.

  • Das automatische Erkennen entfernter und hinzugefügter Speichergeräte ist hardwareabhängig und wird nicht von allen Plattformen unterstützt. So werden USB-Speichergeräte beispielsweise beim Einfügen automatisch konfiguriert. SATA-Laufwerke müssen unter Umständen jedoch mit dem Befehl cfgadm -c configure konfiguriert werden.

  • Hot-Spares werden regelmäßig überprüft, um sicherzustellen, dass sie online und verfügbar sind.

Weitere Informationen finden Sie in der Manpage zpool(1M).

Rekursives Umbenennen von ZFS-Snapshots (zfs rename -r)-

Release Solaris 10 10/08: Der Befehl zfs rename -r ermöglicht es, alle untergeordneten ZFS-Snapshots rekursiv umzubenennen.

Erstellen Sie z. B. einen Snapshot von einer Reihe von ZFS-Dateisystemen.


# zfs snapshot -r users/home@today
# zfs list
NAME                     USED  AVAIL  REFER  MOUNTPOINT
users                    216K  16.5G    20K  /users
users/home                76K  16.5G    22K  /users/home
users/home@today            0      -    22K  -
users/home/markm          18K  16.5G    18K  /users/home/markm
users/home/markm@today      0      -    18K  -
users/home/marks          18K  16.5G    18K  /users/home/marks
users/home/marks@today      0      -    18K  -
users/home/neil           18K  16.5G    18K  /users/home/neil
users/home/neil@today       0      -    18K  -

Führen Sie am nächsten Tag eine Umbenennung der Snapshots durch.


# zfs rename -r users/home@today @yesterday
# zfs list
NAME                         USED  AVAIL  REFER  MOUNTPOINT
users                        216K  16.5G    20K  /users
users/home                    76K  16.5G    22K  /users/home
users/home@yesterday            0      -    22K  -
users/home/markm              18K  16.5G    18K  /users/home/markm
users/home/markm@yesterday      0      -    18K  -
users/home/marks              18K  16.5G    18K  /users/home/marks
users/home/marks@yesterday      0      -    18K  -
users/home/neil               18K  16.5G    18K  /users/home/neil
users/home/neil@yesterday       0      -    18K  -

Snapshots sind die einzigsten Daten, die rekursiv umbenannt werden können.

Weitere Informationen zu Snapshots finden Sie unter Überblick über ZFS-Snapshots und in folgendem Blog-Eintrag, in dem die Erstellung rotierender Snapshots beschrieben ist:

http://blogs.sun.com/mmusante/entry/rolling_snapshots_made_easy

GZIP-Komprimierung für ZFS

Release Solaris 10 10/08: In diesem Solaris-Release können ZFS-Dateisysteme zusätzlich zu lzjb auch mit gzip komprimiert werden. Sie können festlegen, dass die Komprimierung vom Typ gzip (Standardeinstellung) sein soll oder vom Typ gzip-N, wobei N den Wert 1 bis 9 haben kann. Beispiel:


# zfs create -o compression=gzip users/home/snapshots
# zfs get compression users/home/snapshots
NAME                  PROPERTY     VALUE            SOURCE
users/home/snapshots  compression  gzip             local
# zfs create -o compression=gzip-9 users/home/oldfiles
# zfs get compression users/home/oldfiles
NAME                  PROPERTY     VALUE           SOURCE
users/home/oldfiles   compression  gzip-9          local

Weitere Informationen zum Setzen von ZFS-Eigenschaften finden Sie unter Setzen von ZFS-Eigenschaften.

Speichern mehrerer Kopien von ZFS-Benutzerdaten

Release Solaris 10 10/08: Sofern möglich, werden ZFS-Dateisystem-Metadaten im Rahmen der Zuverlässigkeitsfunktionen automatisch auf mehreren Festplatten gespeichert. Dies wird als ditto blocks bezeichnet.

In dieser Version können Sie über den Befehl zfs set copies festlegen, dass mehrere Kopien der Benutzerdaten auch pro Dateisystem gespeichert werden. Beispiel:


# zfs set copies=2 users/home
# zfs get copies users/home
NAME        PROPERTY  VALUE       SOURCE
users/home  copies    2           local

Verfügbare Werte sind 1, 2 oder 3. Der Standardwert ist 1. Diese Kopien werden zusätzlich zu den von Redundanzfunktionen (Datenspiegelung bzw. RAID-Z) auf Pool-Ebene angelegten Sicherungskopien erstellt.

Die Speicherung mehrerer Kopien von ZFS-Benutzerdaten bringt die folgenden Vorteile mit sich:

  • Verbesserte Datenaufbewahrung, da für alle ZFS-Konfigurationen die Wiederherstellung von nicht wiederherstellbaren Blocklesefehlern zugelassen wird, z. B. Datenträgerfehler (bit rot)

  • Bietet Schutz der Daten auch wenn nur ein Laufwerk verfügbar ist

  • Ermöglicht die Auswahl von Datenschutzrichtlinien auf Dateisystembasis jenseits der Grenzen des Speicher-Pools

Je nach Zuweisung der ditto blocks im Speicher-Pool ist es möglich, dass mehrere Kopien auf einer einzigen Festplatte abgelegt werden. Ein Ausfall einer ganzen Festplatte kann folglich bedeuten, dass sämtliche ditto blocks unverfügbar sind.

Die Verwendung von ditto blocks kann hilfreich sein, wenn Sie versehentlich einen nicht-redundanten Pool erstellen und Richtlinien für die Datenaufbewahrung festlegen müssen.

In folgendem Blog wird ausführlich darauf eingegangen, wie sich die Erstellung von Kopien auf einem System mit Einzelplatten-Pool oder Mehrplatten-Pool auf den Datenschutz im Allgemeinen auswirken kann:

http://blogs.sun.com/relling/entry/zfs_copies_and_data_protection

Weitere Informationen zum Setzen von ZFS-Eigenschaften finden Sie unter Setzen von ZFS-Eigenschaften.

Verbesserte Ausgabe von zpool status

Release Solaris 10 8/07: Mit dem Befehl zpool status -v können Sie sich eine Liste der Dateien mit dauerhaften Fehlern ausgeben lassen. In früheren Versionen mussten die Dateinamen mithilfe des Befehls find -inum anhand der Liste der angezeigten Knoten ermittelt werden.

Weitere Informationen zum Anzeigen einer Liste von Dateien mit dauerhaften Fehlern finden Sie unter Reparatur beschädigter Dateien bzw. Verzeichnisse.

Verbesserungen für ZFS mit Solaris iSCSI

Release Solaris 10 8/07: In diesem Solaris-Release können Sie durch Setzen der Eigenschaft shareiscsi im ZFS-Volume ein ZFS-Volume als ein Solaris iSCSI-Zielgerät erstellen. Mithilfe dieses Verfahrens können Solaris iSCSI-Zielgeräte schnell eingerichtet werden. Beispiel:


# zfs create -V 2g tank/volumes/v2
# zfs set shareiscsi=on tank/volumes/v2
# iscsitadm list target
Target: tank/volumes/v2
    iSCSI Name: iqn.1986-03.com.sun:02:984fe301-c412-ccc1-cc80-cf9a72aa062a
    Connections: 0

Nach dem Erstellen des iSCSI-Zielgeräts muss der iSCSI-Initiator definiert werden. Informationen zur Einrichtung eines Solaris iSCSI-Initiators finden Sie in Kapitel 14, Configuring Solaris iSCSI Targets and Initiators (Tasks) in System Administration Guide: Devices and File Systems.

Weitere Informationen zur Verwaltung eines ZFS-Volumes als iSCSI-Zielgerät entnehmen Sie bitte dem Abschnitt Verwendung von ZFS-Volumes als Solaris-iSCSI-Zielgerät.

ZFS-Befehlsprotokoll (zpool history)

Release Solaris 10 8/07: In diesem Solaris-Release protokolliert ZFS automatisch erfolgreich ausgeführte Aufrufe der Befehle zfs und zpool, die Daten zu Pool-Zuständen ändern. Beispiel: 


# zpool history
History for 'newpool':
2007-04-25.11:37:31 zpool create newpool mirror c0t8d0 c0t10d0
2007-04-25.11:37:46 zpool replace newpool c0t10d0 c0t9d0
2007-04-25.11:38:04 zpool attach newpool c0t9d0 c0t11d0
2007-04-25.11:38:09 zfs create newpool/user1
2007-04-25.11:38:15 zfs destroy newpool/user1

History for 'tank':
2007-04-25.11:46:28 zpool create tank mirror c1t0d0 c2t0d0 mirror c3t0d0 c4t0d0

Dank dieses Leistungsmerkmals können Sie oder Sun-Supportmitarbeiter genau feststellen, welche ZFS-Befehle bei der Behebung eines Fehlers ausgeführt wurden.

Spezifische Speicher-Pools können mit dem Befehl zpool history identifiziert werden. Beispiel:


# zpool history newpool
History for 'newpool':
2007-04-25.11:37:31 zpool create newpool mirror c0t8d0 c0t10d0
2007-04-25.11:37:46 zpool replace newpool c0t10d0 c0t9d0
2007-04-25.11:38:04 zpool attach newpool c0t9d0 c0t11d0
2007-04-25.11:38:09 zfs create newpool/user1
2007-04-25.11:38:15 zfs destroy newpool/user1

In diesem Solaris-Release werdenuser-ID, hostname und zone-name über den Befehl zpool history nicht aufgezeichnet. Weitere Informationen finden Sie unter Verbesserungen des ZFS-Befehlsprotokolls (zpool history).

Weitere Informationen zur Behebung von ZFS-Problemen siehe Erkennen von Problemen in ZFS.

Verbesserungen der ZFS-Eigenschaften

ZFS-Eigenschaft xattr

Release Solaris 10 8/07: Mit der Eigenschaft xattr können Sie für ein bestimmtes ZFS-Dateisystem erweiterte Attribute deaktivieren oder aktivieren. Standardmäßig sind sie aktiviert. Eine Beschreibung von ZFS-Eigenschaften finden Sie unter ZFS-Eigenschaften.

ZFS-Eigenschaft canmount

Release Solaris 10 8/07: Mit der neuen Eigenschaft canmount können Sie festlegen, ob ein Dataset mithilfe des Befehls zfs mount eingehängt werden kann. Weitere Informationen dazu finden Sie unter Die Eigenschaft canmount.

Benutzerdefinierte ZFS-Eigenschaften

Release Solaris 10 8/07: Zusätzlich zu den nativen Standardeigenschaften, die zum Exportieren interner Statistiken oder Steuern des ZFS-Dateisystemverhaltens dienen, unterstützt ZFS benutzerdefinierte Eigenschaften. Benutzerdefinierte Eigenschaften wirken sich nicht auf das ZFS-Verhalten aus, können jedoch zum Versehen von Datasets mit Informationen, die für Ihre lokalen Gegebenheiten wichtig sind, verwendet werden.

Weitere Informationen finden Sie unter Benutzerdefinierte ZFS-Eigenschaften.

Setzen von Eigenschaften beim Erstellen von ZFS-Dateisystemen

Release Solaris 10 8/07: In diesem Solaris-Release können Sie Eigenschaften nicht nur nach, sondern auch bereits bei der Erstellung von Dateisystemen festlegen.

Die folgenden Beispiele zeigen die entsprechende Syntax:


# zfs create tank/home
# zfs set mountpoint=/export/zfs tank/home
# zfs set sharenfs=on tank/home
# zfs set compression=on tank/home


# zfs create -o mountpoint=/export/zfs -o sharenfs=on -o compression=on tank/home

Anzeigen aller ZFS-Dateisysteminformationen

Release Solaris 10 8/07: In diesem Solaris-Release können Sie sich mithilfe verschiedener Versionen des Befehls zfs get Informationen zu allen Datasets anzeigen lassen, wenn weder ein Dataset noch all angegeben wurde. Bisher war es nicht möglich, mit dem Befehl zfs get Informationen aller Datensätze anzuzeigen.

Beispiel:


# zfs get -s local all
tank/home               atime          off                    local
tank/home/bonwick       atime          off                    local
tank/home/marks         quota          50G                    local

Neue Option F für -zfs receive

Release Solaris 10 8/07: Sie können nun die neue Option -F für den Befehl zfs receive verwenden, um das Dateisystem auf den letzten Snapshot vor dem Empfang zurückzusetzen. Die Verwendung dieser Option kann erforderlich werden, wenn das Dateisystem zwischen dem Zeitpunkt des Rollbacks und des Beginns der receive-Operation geändert wurde.

Weitere Informationen finden Sie unter Empfangen von ZFS-Snapshots.

Rekursive ZFS-Snapshots

Release Solaris 10 11/06: Wenn Sie zum Erstellen eines Dateisystem-Snapshots den Befehl zfs snapshot verwenden, können Sie durch die Verwendung der Option -r erreichen, dass für alle untergeordneten Dateisysteme rekursiv Snapshots erstellt werden. Darüber hinaus werden bei der Löschung eines Snapshots mit der Option - r alle nachfolgenden Snapshots rekursiv gelöscht.

Rekursive ZFS-Snapshots werden schnell als eine einzige Kernoperation erstellt. Snapshots werden entweder zusammen (d. h. alle auf einmal) oder gar nicht erstellt. Der Vorteil solcher simultaner Snapshots besteht darin, dass die Snapshot-Daten auch bei Dateisystemhierarchien zu einem einzigen konsistenten Zeitpunkt erstellt werden.

Weitere Informationen finden Sie unter Erstellen und Löschen von ZFS-Snapshots.

RAID-Z-Konfiguration mit doppelter Parität (raidz2)

Release Solaris 10 11/06: Redundante RAID-Z-Konfigurationen können jetzt einfache oder doppelte Parität besitzen. Das bedeutet, dass in einem System bis zu zwei Geräteausfälle ohne Datenverlust möglich sind. Eine RAID-Z-Konfiguration doppelter Parität kann mithilfe des Schlüsselworts raidz2 angegeben werden. Entsprechend können Sie für eine RAID-Z-Konfiguration mit einfacher Parität eines der Schlüsselwörter raidz oder raidz1 angeben.

Weitere Informationen finden Sie unter Erstellen von RAID-Z-Speicher-Pools oder zpool(1M).

Hot-Spares für ZFS-Speicher-Pools

Release Solaris 10 11/06: Mithilfe der ZFS-Hot-Spare-Funktion können Sie Datenträger ermitteln, die zum Ersetzen eines ausgefallenen bzw. fehlerhaften Geräts in einem bzw. mehreren Speicher-Pools verwendet werden können. Das Vorsehen eines Datenträgers als Hot-Spare-Gerät bedeutet, dass bei Ausfall eines aktiven Datenträgers im Pool das Hot-Spare-Gerät diesen automatisch ersetzt. Alternativ dazu können Sie Datenträger in einem Speicher-Pool auch manuell durch ein Hot-Spare-Gerät ersetzen.

Weitere Informationen finden Sie unter Zuweisen von Hot-Spares im Speicher-Pool und zpool(1M).

Ersetzen eines ZFS-Dateisystems durch einen ZFS-Klon (zfs promote)

Release Solaris 10 11/06: Der Befehl zfs promote ermöglicht es, ein vorhandenes ZFS-Dateisystem durch einen Klon desselben zu ersetzen. Diese Funktion ist hilfreich, wenn Sie an verschiedenen Versionen eines Dateisystems Tests ausführen und danach eine alternative Version des Dateisystems zum aktiven Dateisystem machen möchten.

Weitere Informationen finden Sie in Ersetzen eines ZFS-Dateisystems durch einen ZFS-Klon und zfs(1M).

Aufrüsten von ZFS-Speicher-Pools (zpool upgrade)

Release Solaris 10 6/06: Mit dem Befehl zpool upgrade können Sie ein Upgrade eines Speicher-Pools vornehmen, um die neuesten Funktionen zu nutzen. Darüber hinaus wurde der Befehl zpool status so geändert, dass Sie jetzt darauf hingewiesen werden, wenn Pools mit älteren Versionen laufen.

Weitere Informationen finden Sie unter Aufrüsten von ZFS-Speicher-Pools und zpool(1M).

Wenn Sie die ZFS-Administrationskonsole auf einem System mit einem Pool aus früheren Solaris-Versionen nutzen möchten, müssen Sie die Pools vor Verwendung der ZFS-Administrationskonsole aufrüsten. Mit dem Befehl zpool status lässt sich ermitteln, ob Pools aufgerüstet werden müssen. Informationen zur ZFS-Administrationskonsole finden Sie unter Webbasierte ZFS-Verwaltung.

ZFS-Befehle „backup“ und „restore“ wurden umbenannt

Release Solaris 10 6/06: In diesem Solaris-Release heißen die Befehle zfs backup und zfs restore nun zfs send und zfs receive. Diese Namen geben die Funktion der Befehle genauer wieder. Diese Befehle dienen zum Speichern und Abrufen von ZFS-Datenstreaminstanzen.

Weitere Informationen zu diesen Befehlen finden Sie unter Senden und Empfangen von ZFS-Daten.

Wiederherstellen gelöschter Speicher-Pools

Release Solaris 10 6/06: Dieses Solaris-Release enthält den Befehl zpool import -D. Damit können Sie Pools wiederherstellen, die zuvor mit dem Befehl zpool destroy gelöscht wurden.

Weitere Informationen dazu finden Sie unter Wiederherstellen gelöschter ZFS-Speicher-Pools.

Integration von ZFS mit Fault Manager

Release Solaris 10 6/06: Dieses Release enthält ein integriertes ZFS-Diagnoseprogramm, das Pool- und Datenträgerausfälle diagnostiziert und meldet. Darüber hinaus werden auch mit solchen Pool- bzw. Datenträgerausfällen im Zusammhang stehende Prüfsummen-, E/A-, Geräte- und Poolfehler gemeldet.

Das Diagnoseprogramm enthält keine Funktion zur Früherkennung von Prüfsummen- bzw. E/A-Fehlern und umfasst auch keine auf Fehleranalysen beruhenden proaktiven Operationen.

Bei einem ZFS-Ausfall wird von fmd in etwa die folgende Meldung angezeigt:


SUNW-MSG-ID: ZFS-8000-D3, TYPE: Fault, VER: 1, SEVERITY: Major
EVENT-TIME: Fri Aug 28 09:10:27 PDT 2009
PLATFORM: SUNW,Sun-Fire-T200, CSN: -, HOSTNAME: neo
SOURCE: zfs-diagnosis, REV: 1.0
EVENT-ID: d6725ad6-4546-6c48-fa16-eace4d371981
DESC: A ZFS device failed.  Refer to http://sun.com/msg/ZFS-8000-D3 for more information.
AUTO-RESPONSE: No automated response will occur.
IMPACT: Fault tolerance of the pool may be compromised.
REC-ACTION: Run 'zpool status -x' and replace the bad device.

Durch Überprüfen der empfohlenen Aktion, die nach den spezifischeren Anweisungen im Befehl zpool status angezeigt wird, können Sie die Fehlerursache schnell erkennen und beheben.

Ein Beispiel für die Wiederherstellung des Normalbetriebs nach einem aufgetretenen ZFS-Problem finden Sie unter Reparieren eines ausgefallenen Geräts.

Neuer Befehl zpool clear

Release Solaris 10 6/06: Dieses Release enthält den Befehl zpool clear, mit dem Fehlerzähler für Geräte- bzw. Poolausfälle zurückgesetzt werden können. In früheren Versionen wurden Fehlerzähler bei der Wiederinbetriebnahme eines Datenträgers im Pool mithilfe des Befehls zpool online zurückgesetzt. Weitere Informationen finden Sie unter zpool(1M) und Löschen von Gerätefehlern im Speicher-Pool.

Kompaktes Format von NFSv4-Zugriffssteuerungslisten

Release Solaris 10 6/06: In diesem Release sind für NFSv4-Zugriffssteuerungslisten drei Formate verfügbar: ausführlich, positional und kompakt. Mit den neuen kompakten und positionalen Zugriffssteuerungslistenformaten können Zugriffssteuerungslisten gesetzt und angezeigt werden. Mit dem Befehl chmod können Sie alle drei Zugriffssteuerungslistenformate setzen. Mit dem Befehl ls -V können Sie Zugriffssteuerungslisten im kompakten und positionalen Format, mit ls -v im ausführlichen Format anzeigen.

Weitere Informationen finden Sie unter Setzen und Anzeigen von Zugriffssteuerungslisten an ZFS-Dateien im Kompaktformat, chmod(1) und ls(1).

Dienstprogramm fsstat zum Überwachen von Dateisystemen

Release Solaris 10 6/06: Zum Melden von Operationen an Dateisystemen steht das neue Dienstprogramm fsstat zur Dateisystemüberwachung zur Verfügung. Aktivitäten können nach Einhängepunkt oder Dateisystemtypen protokolliert werden. Das folgende Beispiel zeigt eine allgemeine Aktivität eines ZFS-Dateisystems.


$ fsstat zfs
 new  name   name  attr  attr lookup rddir  read read  write write
 file remov  chng   get   set    ops   ops   ops bytes   ops bytes
7.82M 5.92M 2.76M 1.02G 3.32M  5.60G 87.0M  363M 1.86T 20.9M  251G zfs

Weitere Informationen finden Sie in der Manpage fsstat(1M).

Webbasierte ZFS-Verwaltung

Release Solaris 10 6/06: Zum Ausführen vieler Administrationsaufgaben steht ein webbasiertes ZFS-Verwaltungsprogramm zur Verfügung. Mit diesem Programm können Sie folgende Aufgaben ausführen:

  • Erstellen eines neuen Datenspeicher-Pools

  • Erweitern der Kapazität eines vorhandenen Datenspeicher-Pools

  • Verlagern (Exportieren) eines Datenspeicher-Pools auf ein anderes System

  • Importieren eines zuvor exportierten Datenspeicher-Pools, um diesen auf einem anderen System verfügbar zu machen

  • Anzeigen von Informationen zu Datenspeicher-Pools

  • Erstellen von Dateisystemen

  • Erstellen von Volumes

  • Erstellen eines Snapshots von Dateisystemen bzw. Volumes

  • Wiederherstellen eines früheren Snapshots eines Dateisystems

Sie können mithilfe eines sicheren Webbrowsers unter der folgenden URL auf die ZFS-Administrationskonsole zugreifen:


https://system-name:6789/zfs

Wenn Sie die entsprechende URL eingeben und die ZFS-Administrationskonsole nicht erreichen, kann es sein, dass deren Server nicht läuft. Geben Sie den folgenden Befehl ein, um den Server zu starten:


# /usr/sbin/smcwebserver start

Geben Sie den folgenden Befehl ein, wenn der Server beim Hochfahren des Systems automatisch gestartet werden soll:


# /usr/sbin/smcwebserver enable
Hinweis –

Die Solaris Management Console (smc) kann nicht zur Verwaltung von ZFS-Speicher-Pools bzw. -Dateisystemen verwendet werden.

Was ist ZFS?

Das ZFS-Dateisystem ist ein revolutionäres neues Dateisystem, das die Verwaltung von Dateisystemen grundlegend ändert. Es besitzt Leistungsmerkmale und Vorteile, die in keinem anderen heutzutage verfügbaren Dateisystem zu finden sind. ZFS ist robust, skalierbar und einfach zu verwalten.

Speicher-Pools in ZFS

Die physische Datenspeicherung beruht bei ZFS auf dem Konzept der Speicher-Pools. Früher wurden Dateisysteme auf ein einziges physisches Datenspeichergerät aufsetzend konzipiert. Damit mehrere Datenspeichergeräte addressiert werden können und Datenredundanz möglich wird, entwickelte man sogenannte Volume Manager, durch die Dateisysteme nur einen Datenträger „sehen“, wo tatsächlich mehrere Datenträger vorhanden sind. So mussten Dateisysteme nicht modifiziert werden, damit sie mit einem System mehrerer Datenspeichergeräte arbeiten können. Dieses Design fügte ein neues Komplexitätsniveau hinzu und behinderte bestimmte Weiterentwicklungen an Dateisystemen, da das Dateisystem keine Kontrolle über die physische Speicherung von Daten auf den zu einem virtuellen System zusammengefassten einzelnen Datespeichergeräten (Volumes) hatte.

In ZFS ist diese Verwaltung einzelner Volumes nicht mehr erforderlich. Anstatt einer erzwungenen Erstellung virtueller Volume-Systeme fasst ZFS Datenspeichergeräte in so genannten Speicher-Pools zusammen. Ein solcher Speicher-Pool beschreibt die physischen Eigenschaften der Speicherung (Gerätestruktur, Datenredundanz usw.) und fungiert als flexibler Datenspeicher, aus dem Dateisysteme erstellt werden können. Dateisysteme sind nicht mehr auf individuelle Datenträger beschränkt und können den Speicherplatz im Pool gemeinsam nutzen. Sie müssen die Kapazität eines Dateisystems nicht mehr vorher angeben, da diese automatisch innerhalb des im Speicher-Pool zugewiesenen Speicherplatzes erweitert werden. Wenn ein Pool um neuen Speicherplatz erweitert wird, können alle Dateisysteme dieses Pools diesen neuen Speicherplatz sofort nutzen, ohne dass dafür Konfigurationen geändert werden müssen. Ein Speicher-Pool verhält sich in vielerlei Hinsicht wie ein virtuelles Speichersystem. Wenn ein System um neue DIMM-Speicherchips erweitert wird, brauchen Sie auf Betriebssystemebene keine Befehle einzugeben, mit denen dieser neue Speicher konfiguriert und zu einzelnen Prozessen zugewiesen werden muss. Alle Prozesse des Systems verwenden automatisch diesen zusätzlichen Speicherplatz.

Transaktionale Semantik

ZFS ist ein transaktionales Dateisystem. Das bedeutet, dass der Dateisystemstatus auf dem Datenträger stets konsistent ist. Bei herkömmlichen Dateisystemen werden vorhandene Daten überschrieben. Dies kann dazu führen, dass sich ein Dateisystem in einem undefinierten Status befindet, wenn beispielsweise zwischen dem Zeitpunkt der Zuweisung eines Datenblocks und dem der Verknüpfung mit einem Verzeichnis ein Stromausfall aufgetreten war. Früher wurde dieses Problem durch den Befehl fsck behoben. Dieser Befehl überprüfte den Dateisystemstatus auf Konsistenz und versuchte, Dateisystembereiche in einem undefinierten Status zu reparieren. Diese Methode verursachte Systemadministratoren viele Unannehmlichkeiten und bot nicht die Garantie, alle Probleme zu beheben. Zuletzt wurden Dateisysteme entwickelt, die auf dem Konzept des so genannten Journaling beruhen. Beim Journaling werden Aktionen in einem eigenen „Journal“ festgehalten, das im Falle von Systemcrashs sicher eingespielt werden kann. Diese Methode verursachte jedoch unnötigen Datenverarbeitungsaufwand, da Daten zweimal geschrieben werden müssen. Darüber hinaus entstanden oft weitere Probleme, wenn beispielsweise das Journal nicht fehlerfrei gelesen werden konnte.

Transaktionale Dateisysteme verwalten Daten mithilfe der so genannten Copy on Write-Semantik. Bei diesem Verfahren werden niemals Daten überschrieben, und jegliche Folge von Vorgängen wird entweder vollständig ausgeführt oder ganz ignoriert. Das bedeutet, dass ein Dateisystem bei diesem Verfahren durch Stromausfälle oder Systemabstürze grundsätzlich nicht beschädigt werden kann. Deswegen ist ein Befehl der Art fsck nicht mehr erforderlich. Obwohl ganz zuletzt gespeicherte Daten unter Umständen verloren gehen können, bleibt das Dateisystem an sich stets konsistent. Darüber hinaus werden (mithilfe des O_DSYNC-Flags geschriebene) synchrone Daten stets vor der Rückkehr geschrieben, sodass sie niemals verloren gehen.

Prüfsummen und Daten mit Selbstheilungsfunktion

In ZFS werden alle Daten und Metadaten mit Prüfsummen versehen, die durch einen benutzerspezifisch auswählbaren Algorithmus berechnet werden. Wegen der zusätzlichen Schicht der Datenträgerverwaltung und des grundsätzlichen Aufbaus herkömmlicher Dateisysteme führen solche Systeme mit Prüfsummenfunktionalität die Prüfsummenberechnung datenblockweise aus. Aufgrund des herkömmlichen Designs dieser Dateisysteme kann es vorkommen, dass bestimmte Fehlersituationen wie z. B. das Speichern eines Datenblocks an einem falschen Speicherort zu Daten mit korrekten Prüfsummen führen, obwohl die Daten tatsächlich fehlerhaft sind. ZFS-Prüfsummen werden so gespeichert, dass solche Fehlersituationen erkannt und der ordnungsgemäße Zustand des Dateisystems wiederhergestellt werden kann. Alle Prüfsummenberechnungen und Datenwiederherstellungen finden auf Dateisystemebene statt und sind so für Anwendungsprogramme sichtbar.

Darüber hinaus bietet ZFS Selbstheilungsfunktionen für Daten. ZFS unterstützt Speicher-Pools mit unterschiedlichen Stufen der Datenredundanz einschließlich Datenspiegelung und eine RAID-5-Variante. Bei Erkennung beschädigter Datenblöcke ruft ZFS die unbeschädigten Daten von einer redundanten Kopie ab und repariert die beschädigten Daten, indem es diese mit der unbeschädigten Kopie ersetzt.

Konkurrenzlose Skalierbarkeit

ZFS wurde von Grund auf mit dem Ziel entwickelt, eine für Dateisysteme bislang unerreichte Skalierbarkeit bereitzustellen. Das Dateisystem beruht auf der 128-Bit-Architektur, was die Speicherung von 256 Billiarden Zettabyte Daten ermöglicht. Alle Metadata werden dynamisch zugewiesen. Damit entfällt die Notwendigkeit, Inodes vorher zuweisen bzw. die Skalierbarkeit eines Dateisystems bei der ersten Erstellung anderweitig einschränken zu müssen. Alle Algorithmen wurden im Hinblick auf eine bestmögliche Skalierbarkeit entwickelt. Verzeichnisse können bis zu 248 (256 Billionen) Einträge enthalten, und für die Anzahl der Dateisysteme bzw. die Anzahl der in einem Dateisystem enthaltenen Dateien bestehen keine Beschränkungen.

ZFS-Snapshots

Ein Snapshot ist eine schreibgeschützte Kopie eines Dateisystems bzw. Volumes. Snapshots können schnell und einfach erstellt werden. Anfänglich belegen Snapshots keinen zusätzlichen Speicherplatz im Pool.

Mit der Änderung von Daten innerhalb des aktiven Datasets belegt der Snapshot mehr Speicherplatz, da weiterhin Verweise auf die älteren Daten gespeichert sind. So verhindern Snapshots, dass der von den Daten belegte Speicherplatz für den Pool freigegeben wird.

Vereinfachte Administration

Eine der wichtigsten Eigenschaften von ZFS ist das erheblich vereinfachte Administrationsmodell. Durch hierarchische Dateisystemstrukturen, Eigenschaftsvererbung sowie automatische Verwaltung von Einhängepunkten und NFS-Netzwerksemantik können in ZFS Dateisysteme auf einfache Weise erstellt und verwaltet werden, ohne dass dafür mehrere Befehle erforderlich sind oder Konfigurationsdateien bearbeitet werden müssen. Sie können auf einfache Weise Kontingente bzw. Reservierungen vornehmen, Datenkomprimierung aktivieren/deaktivieren oder Einhängepunkte für mehrere Dateisysteme mit einem einzigen Befehl verwalten. Datenspeichergeräte können überprüft bzw. repariert werden, ohne dass dafür Kenntnisse über einen separaten Volume Manager-Befehlssatz erforderlich sind. Sie können eine unbegrenzte Anzahl sofortiger Dateisystem-Snapshots erstellen sowie von einzelnen Dateisystemen Sicherungskopien erstellen und diese Dateisysteme aus Sicherungskopien wiederherstellen.

ZFS verwaltet Dateisysteme über eine Hierarchie, die eine vereinfachte Verwaltung von Eigenschaften wie z. B. Kontingenten, Reservierungen, Komprimierung und Einhängepunkten ermöglicht In diesem Modell werden Dateisysteme zur zentralen Verwaltungsstelle. Dateisysteme sind (vergleichbar mit einem neuen Verzeichnis) an sich sehr kostengünstig. Deswegen sollten Sie für jeden Benutzer und Arbeitsbereich sowie für jedes Projekt ein neues Dateisystem erstellen. Dieses Design ermöglicht sehr fein abgestimmte Verwaltungsknoten.

In ZFS verwendete Begriffe

In diesem Abschnitt werden die im vorliegenden Dokument verwendeten Begriffe erläutert:

Alternative Boot-Umgebung

Eine mit dem Befehl lucreate erstellte und möglicherweise mit dem Befehl luupgrade aktualisierte Boot-Umgebung, die derzeit weder die aktive noch die primäre Boot-Umgebung darstellt. Die alternative Boot-Umgebung (ABU) kann mithilfe des Befehls luactivate zur primären Boot-Umgebung (PBU) ernannt werden.

checksum

Mithilfe eines 256-Bit-Hash-Algorithmus verschlüsselte Daten eines Dateisystemblocks. Prüfsummenalgorithmen reichen vom einfachen und schnellen Fletcher2-Algorithmus (die Standardeinstellung) bis hin zu Hash-Algorithmen mit starker Verschlüsselung wie z. B. SHA256.

Klon

Ein Dateisystem, dessen anfänglicher Inhalt identisch mit dem Inhalt eines Snapshots ist.

Informationen zu Klonen finden Sie in Überblick über ZFS-Klone.

Dataset

Ein allgemeiner Name für die folgenden ZFS-Entitäten: Klone, Dateisysteme, Snapshots oder Volumes (Datenträger).

Jedes Dataset wird im ZFS-Namensraum durch einen eindeutigen Namen identifiziert. Datasets werden mithilfe des folgenden Formats benannt:

Pool/Pfad[ @Snapshot]

pool

Der Name des Speicher-Pools, der das Dataset enthält

Pfad

Ein durch Schrägstriche begrenzter Pfadname für das Dataset-Objekt

Snapshot

Eine optionale Komponente, die den Snapshot eines Datasets identifiziert

Weitere Informationen zu Datasets finden Sie in Kapitel 6Verwalten von ZFS-Dateisystemen.

Dateisystem

Ein ZFS-Dataset der Art filesystem, der im Standardnamensraum des Systems eingehängt ist und sich wie jedes andere Dateisystem verhält.

Weitere Informationen zu Dateisystemen finden Sie in Kapitel 6Verwalten von ZFS-Dateisystemen.

Mirror

Eine Konfiguration mit virtuellen Geräten, in der identische Kopien von Daten auf zwei oder mehr Festplatten gespeichert werden. Wenn eine Festplatte im Datenspiegelungssystem ausfällt, stellt eine andere Festplatte dieses Systems die gleichen Daten bereit.

Pool

Eine logische Gruppe von Geräten, die das Layout und die physischen Merkmale des verfügbaren Speichers beschreibt. Datensätzen wird Speicher aus einem Pool zugewiesen.

Weitere Informationen zu Speicher-Pools finden Sie in Kapitel 4Verwalten von ZFS-Speicher-Pools.

Primäre Boot-Umgebung

Eine Boot-Umgebung, aus der mit dem Befehl lucreate die alternative Boot-Umgebung erstellt wird. Standardmäßig ist die primäre Boot-Umgebung (PBU) die aktuelle Boot-Umgebung. Dieses Standardverhalten kann mit lucreate und der Option - s außer Kraft gesetzt werden.

RAID-Z

Ein virtuelles Gerät, das Daten und Paritäten auf mehreren Festplatten speichert (vergleichbar mit RAID-5). Weitere Informationen zu RAID-Z finden Sie unter Speicher-Pools mit RAID-Z-Konfiguration.

Resilvering

Den Vorgang des Übertragens von Daten von einem Datenspeichergerät auf ein anderes Gerät nennt man Resilvering. Beispiel: Wenn eine Speicherkomponente ersetzt oder offline genommen wird, werden die Daten von der aktuellen Spiegelkomponente in die neu wiederhergestellte Spiegelkomponente kopiert. Dieser Vorgang heißt in herkömmlichen Datenträgermanagement-Produkten Neusynchronisierung der Datenspiegelung.

Weitere Informationen zum ZFS-Resilvering finden Sie in Anzeigen des Resilvering-Status.

snapshot

Ein schreibgeschütztes Abbild eines Dateisystems oder Volumes zu einem bestimmten Zeitpunkt.

Weitere Informationen zu Snapshots finden Sie in Überblick über ZFS-Snapshots.

Virtuelles Gerät

Ein logisches Gerät in einem Pool. Dies kann ein physisches Datenspeichergerät, eine Datei oder ein Geräteverbund sein.

Weitere Informationen zu virtuellen Geräten finden Sie unter Anzeigen von Informationen zu virtuellen Geräten in Storage-Pools.

volume

Ein Dataset, mit dem ein physisches Datenspeichergerät emuliert wird. Beispielsweise lässt sich ein ZFS-Volume als Swap-Gerät erstellen.

Weitere Informationen zu ZFS-Volumes finden Sie unter ZFS-Volumes.

Konventionen für das Benennen von ZFS-Komponenten

Jede ZFS-Komponente muss nach den folgenden Regeln benannt werden:

  • Leere Komponenten sind unzulässig

  • Eine Komponente darf nur alphanumerische Zeichen sowie die folgenden vier Sonderzeichen enthalten:

    • Unterstrich (_)

    • Bindestrich (-)

    • Doppelpunkt (:)

    • Punkt (.)

  • Pool-Namen müssen mit einem Buchstaben beginnen. Dabei gelten folgende Ausnahmen:

    • Die Zeichenfolge c[0-9] ist am Namensbeginn nicht erlaubt.

    • Der Name log ist reserviert.

    • Namen, die mit mirror, raidz oder spare beginnen, sind nicht erlaubt, da diese Namen reserviert sind.

    Darüber hinaus dürfen Pool-Namen kein Prozentzeichen (%) enthalten.

  • Dataset-Namen müssen mit einem alphanumerischen Zeichen beginnen. Dataset-Namen dürfen kein Prozentzeichen (%) enthalten.