Date: Wed, 9 Jan 2013 20:17:01 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Jason Keltz <jas@cse.yorku.ca> Cc: FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Problems Re-Starting mountd Message-ID: <894889105.1842818.1357780621511.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50EDB8B3.4030903@cse.yorku.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mountd's pid> > > - 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?894889105.1842818.1357780621511.JavaMail.root>