In her video presentation on ZFS as a Root File System, Sun engineer Lori Alt, project lead of the ZFS Boot Project at Sun, begins with a look at the characteristics of a root file system, such as requiring a boot capability, having robustness, offering installation support along with swap and dump support, and providing ongoing management capabilities. She then gives an overview of ZFS that highlights how ZFS fills the bill on these requirements.

With ZFS, she notes, storage devices can be grouped into pools; pools have redundancy and robustness features of their own; datasets (file systems and volumes) are allocated from within the pool (no longer associated with disk slices); and copy-on-write allows for fast snapshots and clones of datasets (clones are writable snapshots).

Why use ZFS as a root file system, she asks and provides three answers: It is best to use a single file system type for everything; ZFS is an excellent root file system with numerous management advantages; and the forthcoming installation and management features of Solaris will depend on ZFS.

ZFS features that matter for root file systems

• pooled storage -- no need to preallocate volumes; file systems use only the space they need
• built-in redundancy capabilities at the pool level
• unparalleled data integrity features -- no fsck command required
• ZFS features snapshots and clones
• ZFS volumes can be used for in-pool sway and dump areas

Alt then displays a slide illustrating the storage layout for system software with traditional file systems and compares it with the layout for a ZFS storage pool. The first point she makes is the ease of mirroring with ZFS.

Turning to an introduction to booting Solaris and how ZFS affects the PROM phase, the booter phase, and the kernel phase, Alt then illustrates in detail exactly the effect that ZFS has on each of these phases.

It's in the booter phase, Alt contends, that ZFS really begins to make a difference, given that there is no one-to-one correspondence between boot device and root file system; instead, the boot device identifies a storage pool, not a file system, and storage pools contain multiple root file systems. The booter phase needs to be able to select among the available root file systems in the pool and to identify the default root file system to be booted and to enable the user to override the default.

ZFS identifies the root file system with its bootfs property. It also stores all the available root file systems in the pool dataset, which is at the root of the dataset hierarchy.

Alt next discusses the root file system selection in x86 systems while booting from ZFS in the booter phase, which uses the GRUB menu, in which the default entry in GRUB boots the default entry for the pool, though it can be overridden.

Alt then turns to consideration of the booter phase in SPARC booting from ZFS, in which case a control file lists the available root file systems, and a simple boot or boot disk command at the OBP prompt will boot whatever root file system is identified by the bootfs pool property. The booter itself, she notes, has an -L option that lists the bootable datasets on the disk being booted.

Once this point is reached in both the x86 and SPARC boots from ZFS, everything else is the same in both.

In the kernel phase, the ZFS mountroot function reads the pool metadata from the boot device, initializes the pool and mounts the designated dataset as root; the system is up and running and Solaris is booted.

Boot environments, which Alt discusses next, amount to root file systems with all of their subordinate file systems, with a one-to-one correspondence between boot environments and root file systems. A boot environment is a fundamental object in Solaris system software management. There can be more than one boot environment (BE) on a system, she continues, and these can be related. Multiple BEs enable safe application and testing of configuration changes.

She recommends a clone-and-modify model of system updates rather than use of in-place updates of boot environments as less risky. The Solaris LiveUpgrade toolset supports the clone and modify approach, and new install technology is being developed that will also support the approach. Furthermore, ZFS itself is ideal for clone and modify operations that are fast, easy and space-efficient.

Alt looks briefly at the clone and modify operation in traditional file systems and explains how much more efficient the operation is under ZFS. She then explains boot environment management with ZFS, notably the ability to treat the clone and modify operation as a single management object.

Alt turns to a step-by-step discussion of what she terms "the ZFS safe upgrade," providing commands for each step along the way.

The few limitations of ZFS boots that Alt mentions include that root pools can only be n-way mirrors (no striping or RAID-Z), though work is underway to ease this limitation. In addition, root pools on Solaris cannot have EFI labels because the boot firmware does not support booting from them.

Alt concludes with comments on the future expectations for improvements in installation software that relies on ZFS

More Information

ZFS bootpage

ZFS Basics at OpenSolaris.org [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter