From owner-freebsd-fs@FreeBSD.ORG Wed Jan 9 18:36:44 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 03CF5838 for ; Wed, 9 Jan 2013 18:36:44 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id C96553FE for ; Wed, 9 Jan 2013 18:36:43 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1Tt0Vw-0008VX-0O; Wed, 09 Jan 2013 13:36:36 -0500 Message-ID: <50EDB8B3.4030903@cse.yorku.ca> Date: Wed, 09 Jan 2013 13:36:35 -0500 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Rick Macklem Subject: Re: Problems Re-Starting mountd References: <2094136156.1801692.1357694368838.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <2094136156.1801692.1357694368838.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: On 01/08/2013 08:19 PM, Rick Macklem wrote: > You could test the attached patch, which I think makes mountd > load new export entries from a file called /etc/exports.new > without deleting the exports already in place, when sent a > USR1 signal. > > After applying the patch to mountd.c, rebuilding and replacing > it, you would: > - put new entries for file systems not yet exported in both > /etc/exports and /etc/exports.new > # kill -USR1 > - delete /etc/exports.new > Don't send HUP to mountd for this case. > > Very lightly tested, rick > ps: Sometimes it's faster to just code this stuff instead of > discussing if/how it can be done;-) > pss: This patch isn't ready for head. If it is useful, it might > make sense to add a new mountd option that specifies the > name of the file (/etc/exports.new or ...), so that this > capability isn't enabled by default. Hi Rick, [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Cc: FreeBSD Filesystems 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, 09 Jan 2013 18:36:44 -0000 On 01/08/2013 08:19 PM, Rick Macklem wrote: > You could test the attached patch, which I think makes mountd > load new export entries from a file called /etc/exports.new > without deleting the exports already in place, when sent a > USR1 signal. > > After applying the patch to mountd.c, rebuilding and replacing > it, you would: > - put new entries for file systems not yet exported in both > /etc/exports and /etc/exports.new > # kill -USR1 > - delete /etc/exports.new > Don't send HUP to mountd for this case. > > Very lightly tested, rick > ps: Sometimes it's faster to just code this stuff instead of > discussing if/how it can be done;-) > pss: This patch isn't ready for head. If it is useful, it might > make sense to add a new mountd option that specifies the > name of the file (/etc/exports.new or ...), so that this > capability isn't enabled by default. Hi Rick, Thanks very much for looking into this. It's a pity (at least with current mountd) that there isn't maybe a more generic option for adding or removing an export on the fly. This way, a basic shell script could look at the original exports and the new exports, and then come up with the options to mountd to tell it what to do. The only "problem" I see with the patch per se is that while this would enable adding new exports without the additional delay, what happens when I delete a user and now I need to "unexport" the filesystem. Of course I have to revert to processing the whole exports file again. Right now, I don't have to think about when deletes happen becuase on my existing file server, where user home directories are stored on one of a few filesystems, if I delete a user, I only have to remove a directory. I don't have to do anything with a filesystem. However, when using one ZFS filesystem per user, if I delete a user, I have to delete a filesystem. Now, imagine the user has been logged into various systems, and their home directory is automounted everywhere. Now, I delete it on the fileserver, need to re-export, introduce the delay, and in addition, leave a bunch of machines with stale NFS mounts. yay. :) Jas.