Problems Re-Starting mountd

Rick Macklem rmacklem at uoguelph.ca
Wed Jan 9 00:18:48 UTC 2013


Jason Keltz wrote:
> On 01/08/2013 10:05 AM, Andrey Simonenko wrote:
> > I created 2000 file systems on ZFS file system backed by vnode md(4)
> > device. The /etc/exports file contains 4000 entries like your
> > example.
> >
> > On 9.1-STABLE mountd spends ~70 seconds in flushing current NFS
> > exports
> > in the NFS server, parsing data from /etc/exports and loading parsed
> > data into the NFS server. ~70 seconds is not several minutes. Most
> > of
> > time mountd spends in nmount() system call in "zio->io_cv" lock.
> >
> > Can you show the output of "truss -fc -o /tmp/output.txt mountd"
> > (wait wchan "select" state of mountd and terminate it by a signal).
> > If everything is correct you should see N statfs() calls, N+M
> > nmount()
> > calls and something*N lstat() calls, where N is the number of
> > /etc/exports
> > lines, M is the number of mounted file systems. Number of lstat()
> > calls
> > depends on number of components in pathnames.
> 
> Andrey,
> 
> Would that still be an ~70 second period in which new mounts would not
> be allowed? In the system I'm preparing, I'll have at least 4000
> entries
> in /etc/exports, probably even more, so I know I'll be dealing with
> the
> same issue that Tim is dealing with when I get there. However, I don't
> see how to avoid the issue ... If I want new users to be able to login
> shortly after their account is created, and each user has a ZFS
> filesystem as a home directory, then at least at some interval, after
> adding a user to the system, I need to update the exports file on the
> file server, and re-export everything. Yet, even a >1 minute delay
> where users who are logging in won't get their home directory mounted
> on
> the system they are logging into - well, that's not so good...
> accounts
> can be added all the time and this would create random chaos. Isn't
> there some way to make it so that when you re-export everything, the
> existing exports are still served until the new exports are ready?
I can't think of how you'd do everything without deleting the old stuff,
but it would be possible to "add new entries". It has to be done by
modifying mountd, since it keeps a tree in its address space that it uses
for mount requests and the tree must be grown.

I don't know about nfse, but you'd have to add this capability to mountd
and, trust me, it's an ugly old piece of C code, so coming up with a patch
might not be that easy. However, it might not be that bad, since the only difference
from doing the full reload as it stands now would be to "not delete
the tree that already exists in the utility and don't do the DELEXPORTS
syscall" I think, so the old ones don't go away. There could be a file called
something like /etc/exports.new for the new entries and a different
signal (SIGUSR1??) to load these. (Then you'd add the new entries to
/etc/exports as well for the next time mountd restarts, but wouldn't
send it a SIGHUP.)

I haven't tried to code this, so I don't know how hard it would be.
If you did this, it would only be useful to add exports for file
systems not already exported.

> Would this be the same for NFSv3 versus NFSv4? I suspect yes.
> 
Yep, the file system exports are done the same way.

rick

> Jason.
> 
> _______________________________________________
> freebsd-fs at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"


More information about the freebsd-fs mailing list