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>