Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Sep 2012 19:49:32 +0300
From:      Andriy Gapon <avg@FreeBSD.org>
To:        freebsd-fs@FreeBSD.org
Subject:   znextboot: nextboot-like tool for zfs at zfsboot level
Message-ID:  <505DEC1C.4000305@FreeBSD.org>

next in thread | raw e-mail | index | archive | help


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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?505DEC1C.4000305>