On 07/24/13 08:00, [email protected] wrote:
Send freebsd-fs mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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 <[email protected]>
To: [email protected]
Subject: Revisiting an old problem.. zfs snapshots and file name too
long
Message-ID:
<caodfjr3fdj18gyaw5upnzkr+pvr-5z_jtu7fwsuwu2xn4rv...@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
[email protected]:/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 <[email protected]>
To: [email protected]
Subject: Bug in FUSE unmounting
Message-ID: <[email protected]>
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 <[email protected]>
To: [email protected], [email protected]
Subject: rc.d support for zfs boot environments
Message-ID: <[email protected]>
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 <[email protected]>
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-rc
To unsubscribe, send any mail to "[email protected]"
