From owner-freebsd-rc@FreeBSD.ORG Wed Jul 24 13:55:42 2013 Return-Path: Delivered-To: freebsd-rc@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C203ECB; Wed, 24 Jul 2013 13:55:42 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF31320C4; Wed, 24 Jul 2013 13:55:40 +0000 (UTC) Received: from jre-mbp.elischer.org (etroy.elischer.org [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.7/8.14.6) with ESMTP id r6ODtUVq025161 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Jul 2013 06:55:32 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51EFDCCC.4040205@freebsd.org> Date: Wed, 24 Jul 2013 21:55:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: rc.d support for zfs boot environments References: <51EFB254.8070807@FreeBSD.org> In-Reply-To: <51EFB254.8070807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:55:42 -0000 On 7/24/13 6:54 PM, Andriy Gapon wrote: > I would like to add another rc.d script or extend the current rc.d/zfs script > for enhanced support of ZFS boot environments. isn't this what PC-BSD are working on? > > To be short, a ZFS boot environment is a filesystem that typically has loader, > kernel and can be mounted as a root filesystem. By having multiple filesystems > of this kind a user can easily select which one to boot to. This allows for > things like having known good configurations, easily recovering from failed > upgrades, experimenting with new code, etc. > > One of the features of boot environments is support for subordinate filesystems. > For example: > NAME MOUNTPOINT CANMOUNT > pond/ROOT/20130331 /pond/ROOT/20130331 noauto > pond/ROOT/20130331/usr /usr off > pond/ROOT/20130331/usr/local /usr/local noauto > pond/ROOT/20130331/usr/local/etc /usr/local/etc noauto > pond/ROOT/kms /pond/ROOT/kms noauto > pond/ROOT/kms/usr /usr off > pond/ROOT/kms/usr/local /usr/local noauto > pond/ROOT/kms/usr/local/etc /usr/local/etc noauto > > 20130331 and kms are two boot environments here. > .../usr, .../usr/local, .../usr/local/etc are their subordinate datasets / > filesystems. > The idea is that one can have filesystems that are tied to a boot environment. > These filesystems hold files that must be in the boot environment but they are > better to be stored in a different filesystem than the main one. There can be > different reasons for this like a need for different ZFS properties or > convenience of separate management (snapshots, cloning, etc). > > Because these filesystems should not be automatically mounted during boot they > are configured with canmount=noauto. The root filesystem is mounted > automatically by the kernel. But the subordinate filesystems are not mounted by > rc.d/zfs -> zfs mount -a because of the canmount property. So they need to be > mounted explicitly. > > Below is a patch that I have for this case. > I would like to ask both fs@ and rc@ communities to review the patch for > correctness, soundness and style. I will appreciate any suggestions and comments. > If you are already using boot environments and think that you may need to use > subordinate datasets, then testing is most welcome too. > > commit df1df94f75a13f611a8234b01bfb9d6b43172c45 > Author: Andriy Gapon > Date: Sun Jul 7 21:01:27 2013 +0300 > > rc.d/zfsbe: a new script designed for boot environment support > > currently it ensures that subordinate datasets are mounted at the > right points. > > diff --git a/etc/rc.d/zfs b/etc/rc.d/zfs > index 598723a..3c40043 100755 > --- a/etc/rc.d/zfs > +++ b/etc/rc.d/zfs > @@ -4,7 +4,7 @@ > # > > # PROVIDE: zfs > -# REQUIRE: mountcritlocal > +# REQUIRE: zfsbe > > . /etc/rc.subr > > diff --git a/etc/rc.d/zfsbe b/etc/rc.d/zfsbe > new file mode 100755 > index 0000000..9e4c50e > --- /dev/null > +++ b/etc/rc.d/zfsbe > @@ -0,0 +1,70 @@ > +#!/bin/sh > +# > +# $FreeBSD$ > +# > + > +# PROVIDE: zfsbe > +# REQUIRE: mountcritlocal > + > +# Handle boot environment subordinate filesystems > +# that may have canmount property set to noauto. > +# For these filesystems mountpoint relative to / > +# must be the same as their dataset name relative > +# to BE root dataset. > + > +. /etc/rc.subr > + > +name="zfsbe" > +rcvar="zfs_enable" > +start_cmd="be_start" > +stop_cmd="be_stop" > +required_modules="zfs" > + > +mount_subordinate() > +{ > + local _be > + > + _be=$1 > + zfs list -rH -o mountpoint,name,canmount -s mountpoint -t filesystem $_be | \ > + while read _mp _name _canmount ; do > + [ "$_canmount" = "off" ] && continue > + case "$_mp" in > + "") > + ;; > + "legacy") > + ;; > + "/") > + ;; > + "/$_be") > + ;; > + "/$_be/"*) > + mount -t zfs $_name ${_mp#/$_be} > + ;; > + *) > + zfs mount $_name > + ;; > + esac > + done > +} > + > +be_start() > +{ > + if [ `$SYSCTL_N security.jail.jailed` -eq 1 ]; then > + : > + else > + mount -p | while read _dev _mp _type _rest; do > + [ $_mp = "/" ] || continue > + if [ $_type = "zfs" ] ; then > + mount_subordinate $_dev > + fi > + break > + done > + fi > +} > + > +be_stop() > +{ > +} > + > +load_rc_config $name > +run_rc_command "$1" > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"