Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Jul 2013 09:05:53 -0400
From:      Nikolai Lifanov <lifanov@mail.lifanov.com>
To:        avg@FreeBSD.org
Cc:        freebsd-fs@freebsd.org, freebsd-rc@freebsd.org
Subject:   Re: freebsd-fs Digest, Vol 527, Issue 3
Message-ID:  <51EFD131.4090004@mail.lifanov.com>
In-Reply-To: <mailman.15.1374667201.32351.freebsd-fs@freebsd.org>
References:  <mailman.15.1374667201.32351.freebsd-fs@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 07/24/13 08:00, freebsd-fs-request@freebsd.org wrote:
> Send freebsd-fs mailing list submissions to
> 	freebsd-fs@freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> or, via email, send a message with subject or body 'help' to
> 	freebsd-fs-request@freebsd.org
>
> You can reach the person managing the list at
> 	freebsd-fs-owner@freebsd.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of freebsd-fs digest..."
>
>
> Today's Topics:
>
>     1. Revisiting an old problem.. zfs snapshots and file name too
>        long (Andreas Tyrosvoutis)
>     2. Bug in FUSE unmounting (Nathan Whitehorn)
>     3. rc.d support for zfs boot environments (Andriy Gapon)
>     4. Re: [SOLVED] Re: Shutdown problem with an USB memory stick as
>        ZFS cache device (Ronald Klop)
>     5. Re: r253070 and "disappearing" zpool (Andriy Gapon)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Jul 2013 19:48:01 +0300
> From: Andreas Tyrosvoutis <andreas.tyrosvoutis@gmail.com>
> To: freebsd-fs@freebsd.org
> Subject: Revisiting an old problem.. zfs snapshots and file name too
> 	long
> Message-ID:
> 	<CAOdfJR3FdJ18gYAw5uPNZKR+PVR-5z_Jtu7fwsuWu2xn4Rvf8w@mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> Hi there everyone, I wanted to see what has been discovered regarding this
> issue. This particular issue has been around since at least 2008.
>
> http://lists.freebsd.org/pipermail/freebsd-fs/2008-November/005286.html
>
> A little bit of response and progress noted here:
>
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007960.html
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007964.html
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007972.html
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html
>
>
> "Such change will break ABI compatibility with tools compiled on previous
> FreeBSD versions. As you can see in sys/sys/mount.h this is the reason
> we still keep ostatfs structure. *I'll discuss the possibilities with
> other FreeBSD committers and we will see what we can do about it.*"
>
> As far as I can tell, this problem has not been addressed in a
> satisfactory way, and still exists today.
>
> nas4free: snapshot # uname -a
>
> FreeBSD nas4free.office.pytheasgroup.com 9.1-RELEASE-p3 FreeBSD
> 9.1-RELEASE-p3 #0 r251670M: Thu Jun 13 01:59:24 CEST 2013
> root@dev.nas4free.org:/usr/obj/nas4free/usr/src/sys/NAS4FREE-amd64
> amd64
>
> nas4free: snapshot # pwd
>
> /mnt/usb-backup/Daily-Backups/mypool/home/andreas/.zfs/snapshot
>
> nas4free: snapshot # ls
>
> ls: 20130721_1829_autosnap_HOURLY: File name too long
>
> ls: 20130721_2330_autosnap_HOURLY: File name too long
>
> ls: 20130722_0936_autosnap_HOURLY: File name too long
>
> ls: 20130722_1221_autosnap_HOURLY: File name too long
>
> etc....
>
>   Not being able to use arbitrarily named snapshots or any tools in
> .zfs/snapshot folders containing such long named (72 characters? )
> snapshots seems a bit, contrary to the ZFS philosophy of (almost)
> unreachable limits.
>
> The problem is, I don't know what ABI and ostatfs or any of that is.
> Or what can actually be done about the problem. It would be handy if
> someone who is in the know, could definitively declare the issues
> ability to be, or not to be resolved. And perhaps if it can, I'd like
> to push it in the right direction. Otherwise it appears to be that BSD
> and ZFS are not really fully integrated.
>
> What do I know though. :)
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Jul 2013 22:31:30 -0500
> From: Nathan Whitehorn <nwhitehorn@freebsd.org>
> To: freebsd-fs@freebsd.org
> Subject: Bug in FUSE unmounting
> Message-ID: <51EF4A92.1090203@freebsd.org>
> Content-Type: text/plain; CHARSET=US-ASCII
>
> I ran across a bug in our FUSE port today. The unmount code in libfuse
> (mount_bsd.c) uses umount -f to unmount a file system. To do this, it
> looks up the device name corresponding to the process's communication
> file descriptor, calls getdevname() on it, and then passes that to
> umount. The problem here is that the device is always /dev/fuse (it
> seems to assume there is a number on the end) and, as a result, it will
> forcibly unmount *all* FUSE systems when trying just to unmount one.
>
> Using the mountpoint instead seems to work for me, but a better solution
> is called for.
> -Nathan
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 24 Jul 2013 13:54:12 +0300
> From: Andriy Gapon <avg@FreeBSD.org>
> To: freebsd-fs@FreeBSD.org, freebsd-rc@FreeBSD.org
> Subject: rc.d support for zfs boot environments
> Message-ID: <51EFB254.8070807@FreeBSD.org>
> Content-Type: text/plain; charset=X-VIET-VPS
>
>
> I would like to add another rc.d script or extend the current rc.d/zfs script
> for enhanced support of ZFS boot environments.
>
> 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 <avg@icyb.net.ua>
> 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"
>

You might check out the logic in the excellent sysutils/beadm port.
It's all shell and doesn't actually need rc support or even use it.

However, loader(8) support for selecting a boot environment would be 
really useful.

- Nikolai Lifanov




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?51EFD131.4090004>