From owner-freebsd-fs@FreeBSD.ORG Wed Jul 24 13:06:00 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7BD94EC9; Wed, 24 Jul 2013 13:06:00 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 55D6C2EB5; Wed, 24 Jul 2013 13:06:00 +0000 (UTC) Received: from [10.1.3.5] (cnet520-windstream.mcclatchyinteractive.com [166.108.16.2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 75C721A0638; Wed, 24 Jul 2013 13:05:54 +0000 (UTC) Message-ID: <51EFD131.4090004@mail.lifanov.com> Date: Wed, 24 Jul 2013 09:05:53 -0400 From: Nikolai Lifanov User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130628 Thunderbird/17.0.7 MIME-Version: 1.0 To: avg@FreeBSD.org Subject: Re: freebsd-fs Digest, Vol 527, Issue 3 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-rc@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:06:00 -0000 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 > To: freebsd-fs@freebsd.org > Subject: Revisiting an old problem.. zfs snapshots and file name too > long > Message-ID: > > 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 > 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 > 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 > 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