znextboot: nextboot-like tool for zfs at zfsboot level

Andriy Gapon avg at FreeBSD.org
Sat Sep 22 16:49:38 UTC 2012



Please find here a patchset that implement znextboot, a nextboot-like tool for
zfs at zfsboot level:
http://people.freebsd.org/~avg/znextboot.diff

Theory of operation.
zfsboot, through loader, exports to kernel environment the GUIDs of the very
first pool it found ("primary pool") and the very first leaf vdev of that pool
("primary vdev").  Note that the primary pool is not necessarily a boot pool or
a root pool, since a user can switch between pools and filesystems at various
stages: zfsboot, zfsloader, rootfs specification.
znextboot is a new tool that simply passes zfsboot/boot2 options to kernel ZFS
via ioctl.  Kernel ZFS writes the options as a NUL terminated ASCII string to
the Pad2 area of the primary vdev of the primary pool.  The Pad2 area has been
known as "Boot Block Header" before.  Its use was never formalized.  Peviously
it used to contain a special header (with zero useful information), now ZFS just
zeroes it out.
So, upon reboot zfsboot reads options from that area and zeros the area.

The tool is intended for remote management of systems that use approaches
similar to "Boot Environments".
It is implemented at zfsboot level as opposed to loader level, because it was
easier.  My skills weren't sufficient to integrate the ZFS logic with loader's
nextboot logic implemented in Forth.

Some problematic areas in the current patchset:
- I used just the next number for the nextboot ioctl.  This will result in
conflict when a new ioctl is added upstream.  We need to think about reserving a
range for OS-specific ioctls.
- znextboot userland utility currently lacks any documentation.
- znextboot lacks any sanity checking / validation for arguments that are passed
to it.
- probably more...

-- 
Andriy Gapon


More information about the freebsd-fs mailing list