freebsd-fs Digest, Vol 527, Issue 3
Nikolai Lifanov
lifanov at mail.lifanov.com
Wed Jul 24 13:06:00 UTC 2013
On 07/24/13 08:00, freebsd-fs-request at freebsd.org wrote:
> Send freebsd-fs mailing list submissions to
> freebsd-fs at 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 at freebsd.org
>
> You can reach the person managing the list at
> freebsd-fs-owner at 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 at gmail.com>
> To: freebsd-fs at freebsd.org
> Subject: Revisiting an old problem.. zfs snapshots and file name too
> long
> Message-ID:
> <CAOdfJR3FdJ18gYAw5uPNZKR+PVR-5z_Jtu7fwsuWu2xn4Rvf8w at 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 at 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 at freebsd.org>
> To: freebsd-fs at freebsd.org
> Subject: Bug in FUSE unmounting
> Message-ID: <51EF4A92.1090203 at 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 at FreeBSD.org>
> To: freebsd-fs at FreeBSD.org, freebsd-rc at FreeBSD.org
> Subject: rc.d support for zfs boot environments
> Message-ID: <51EFB254.8070807 at 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 at 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
More information about the freebsd-fs
mailing list