From owner-freebsd-fs@FreeBSD.ORG Thu Jan 10 01:17:09 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 0B252D9F for ; Thu, 10 Jan 2013 01:17:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id C5BA9BFF for ; Thu, 10 Jan 2013 01:17:08 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEACcW7lCDaFvO/2dsb2JhbABEhjmzSoN2c4IeAQEEASNWBRYOCgICDRkCWQaIJgamYo83gSKLPoMngRMDiGKNKpBJgxKBSD4 X-IronPort-AV: E=Sophos;i="4.84,440,1355115600"; d="scan'208";a="11214108" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 09 Jan 2013 20:17:01 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 99A1FB4032; Wed, 9 Jan 2013 20:17:01 -0500 (EST) Date: Wed, 9 Jan 2013 20:17:01 -0500 (EST) From: Rick Macklem To: Jason Keltz Message-ID: <894889105.1842818.1357780621511.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50EDB8B3.4030903@cse.yorku.ca> Subject: Re: Problems Re-Starting mountd MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) 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: Thu, 10 Jan 2013 01:17:09 -0000 Jason Keltz wrote: > 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. > mountd.c was written in the late 1980s and has been hacked on by various people over the years. Imho, the code is now very difficult to modify for many cases (it happened this patch was easy;-). I, for one, am not volunteering to make major changes to it. It sounds like you should look seriously at using nfse instead. > 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. :) > What can I say. mountd was designed for what your current server does (export a few fixed file systems) and not what you are now trying to do (one fs/user with users being added/deleted all the time). My only suggestion would be to leave a deleted user's file system around until the end of semester or some other convenient deletion time. Good luck with it, rick > Jas.