From owner-freebsd-fs@FreeBSD.ORG Sat Sep 22 16:49:38 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C056106564A; Sat, 22 Sep 2012 16:49:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 587368FC08; Sat, 22 Sep 2012 16:49:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA07478; Sat, 22 Sep 2012 19:49:35 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TFStb-000NTq-6o; Sat, 22 Sep 2012 19:49:35 +0300 Message-ID: <505DEC1C.4000305@FreeBSD.org> Date: Sat, 22 Sep 2012 19:49:32 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:15.0) Gecko/20120913 Thunderbird/15.0.1 MIME-Version: 1.0 To: freebsd-fs@FreeBSD.org X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit Cc: Subject: znextboot: nextboot-like tool for zfs at zfsboot level X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Sep 2012 16:49:38 -0000 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