Timos Blog

Beim Anlegen von ZFS-Speicherpools stellt sich die Frage, ob man ZPOOL die gesamte(n) Disk(s) verwalten lässt (durch Angabe von z.B. c0t0d1 unter Solaris oder /dev/sdb unter Linux) oder den Pool aus einzelnen Partitionen aufbaut (ggf. mit ZFS als einziger Partition auf der Platte).
In letzterem Fall stellt sich außerdem die Frage, welchen Typ von Partitionstabelle man verwenden soll (MBR/DOS-Partitionstabelle, GUID Partition Table (GPT)/EFI Disklabel oder Solaris VTOC).

Insbesondere die zweite Frage ist dann von Bedeutung, wenn man den ZFS-Pool unter verschiedenen Betriebssystemen (z.B. Solaris, Linux und Mac OS X) verwenden möchte.

Diesen beiden Fragen möchte ich im Folgenden versuchen, auf den Grund zu gehen.

• Generell wird empfohlen, die Disks jeweils komplett für ZFS zu verwenden (d.h. man übergibt ZFS entweder das „RAW-Device” oder weist dem ZFS eine Partition zu, die sich über die gesamte Festplatte erstreckt).
• Lässt man zpool das gesamte Gerät verwalten, legt ZFS dort ein GPT-Disklabel an (siehe auch meinen Kommentar)
  (Allerdings entspricht dieses wohl nicht ganz dem, was z.B. Linux erwartet; siehe hier bzw. hier)

• Bei großen Festplatten scheiden DOS-Partitionstabellen und Solaris VTOCs aus:
  • DOS-Partitionstabellen erlauben Partitionen von max. 2 TB Größe
  • Solaris VTOCs unterstützen Festplatten von max. 1 TB Größe

Zu dem Thema habe ich im Folgenden noch etwas „Belegmaterial” zusammengestellt:

Den ZFS Best Practices Guide auf SolarisInternals.com ist zu entnehmen:

• Set up one storage pool using whole disks per system, if possible.
• For production systems, use whole disks rather than slices for storage pools for the following reasons:
  • Allows ZFS to enable the disk’s write cache for those disks that have write caches. If you are using a RAID array with a non-volatile write cache, then this is less of an issue and slices as vdevs should still gain the benefit of the array’s write cache.
  • The recovery process of replacing a failed disk is more complex when disks contain both ZFS and UFS file systems on slices.
  • ZFS pools (and underlying disks) that also contain UFS file systems on slices cannot be easily migrated to other systems by using zpool import and export features.
  • In general, maintaining slices increases administration time and cost. Lower your administration costs by simplifying your storage pool configuration model.
• If you must use slices for ZFS storage pools, review the following:
  • Consider migrating the pools to whole disks after a transition period.
  • Use slices on small systems, such as laptops, where experts need access to both UFS and ZFS file systems.
  • However, take great care when reinstalling OSes in different slices so you don’t accidentally clobber your ZFS pools.
  • Managing data on slices is more complex than managing data on whole disks.

In Getting started with ZFS auf MacForge steht:

[...] the disks need to use the GUID Partition Table (GPT) and ZFS typically works best when it owns the entire disk due in part to how conservative it is with the write cache.

Alex Blewitt schreibt auf der MacForge-Mailingliste zfs-discuss:

You read = use the whole disk
You thought = no partitions

That’s not the case.
If you give the whole disk (with one zfs partition) it kicks in the optimisations. If you have more partitions on there, it doesn’t

It’s perfectly possible for a disk to contain a single ZFS partition taking up the whole disk. However, that’s not the same as writing to a raw (unpartitioned) disk.

“use the whole disk” and “create a single zfs partition” are not mutually exclusive options.

In any case, as long as you import the pool, you can do either.
Automated importing only works when there is a ZFS partition present,
however.

Timo Holle Linux, Mac OS X, Solaris disk, EFI, GPT, Linux, Mac OS X, OpenSolaris, Solaris, ZFS