Date: Fri, 2 Feb 2007 19:25:19 -0500 From: Craig Rodrigues <rodrigc@crodrigues.org> To: Pawel Jakub Dawidek <pjd@FreeBSD.org> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sbin/mount Makefile mount.c Message-ID: <20070203002519.GA1517@crodrigues.org> In-Reply-To: <20070202235942.GC25236@garage.freebsd.pl> References: <200702022358.l12NwAlV049192@repoman.freebsd.org> <20070202235942.GC25236@garage.freebsd.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Feb 03, 2007 at 12:59:43AM +0100, Pawel Jakub Dawidek wrote: > Should we also restart mountd(8) on successful umount(8)? Your fix to mount(8) is a good one, since the existing behavior of mount(8) is to SIGHUP mountd, based on the pid in /var/run/mountd.pid. I don't like how these sneaky behaviors with non-obvious side-effects sneak into existing utilities like mount(8).....but that's what we have today. A sneaky side effect of the existing behavior, is that when you SIGHUP mountd, it deletes all existing NFS exports, re-reads /etc/exports, and then re-creates all the NFS exports. Some people find this very annoying, especially when you are already using an NFS export ( http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/9619 ). I am looking at some patches from Andrey Simonenko which fix this problem, but they are quite intrusive changes to userland and kernel, so it is slow going on my part. So for now, I would recommend leaving umount alone, to avoid adding new side effects, even though based on existing behavior, it seems logical to add it. However, if this behavior is necessary for ZFS, then I won't oppose modifying umount to SIGHUP mountd. :) It seems a lot of cruft has accumulated in a simple utility like mount(8) over the years! -- Craig Rodrigues rodrigc@crodrigues.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070203002519.GA1517>