[ On Wednesday, June 27, 2001 at 15:52:05 (+0200), Manuel Bouyer wrote: ]
> Subject: Re: very weird NFS/VND error during "make depend" of kernel....
>
> It's not the vnd device, it's mount. when you mount/umount a filesystem,
> mount will wake up mountd to rebuild the export list. mountd will flush the
> current export list before installing the new one, so there is a short window
> in which nothing is exported. Bad luck, you client tried talking to the
> server at this time.

Ah, of course!

> The bug is in the NFS system: NFS requests should either be dropped or
> queued while mountd is working.

Hmmm... that almost sounds like a design flaw.

It seems as though the server's forcing the clients to unmount when
their filesystems are (temporarily) unexported.

I guess that might be a requirement of the statelessness of NFS, but it
would seem more logical to me to allow existing mount points to stay
regardless of their new export status.

Don't some NFS implementations have the equivalent of the RFS 'fumount'
command?  (it unadvertises the specified resource and then "forces" any
remote clients to unmount it; it is separate from 'unadv' which just
unadvertises the resource and thus only prevents future remote mounts
from taking place, leaving existing ones alone)

SunOS-5 seems to leave existing mounts alone and only check for access
rights on the first access by a client to a filesystem resource, so
maybe this doesn't have to be the way it is simply due to the
statelessness of NFS (assuming nfsd and/or the kernel can keep some
state about remote mounts).

> > Should I send-pr this?
> 
> I already have a PR open on this issue: 5844.

Ah yes -- now that I read it again I remember it from before....

> I just shaw it's closed, I open it again.

Thanks!

> The fix which was commited has been backed out.

From the commit log messages the "fix" in mountd sounded not so bad.

I'm not sure exactly what kernel information the 1.62 message was
referring to.  Ah!  I guess if mountd dies and is restarted then it
won't know what mounts might already be in the kernel.

Too bad MNT_DELEXPORT isn't documented in mount(2).

But I do find MNT_EXPORTED et al it in getfsstat(2) though, so maybe the
claim in the 1.62 commit message is not really true?  Mountd should be
able to use getmntinfo(3) to find out what the kernel currently has
recorded about exports, no?  If so then it can simply do the add/delete
algorithm to update the kernel to match the "new" /etc/exports.

Hmmmm....  but what about those pesky non-mount-point exports?  :-(

Maybe they should be treated a pseudo-mount-points in the kernel (and
normally ignored by the likes of 'df' and 'mount')....

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>