>> I don't know.  :)  Like I said, my knowledge of NFS is pretty weak.
>> I was under the impression that there's some procedure that the
>> client and server go through to re-establish a mount after a server
>> crash/reboot.

No, at least not with Sun's NFS; one of the explicit design goals was
that it be stateless, to the extent that a crashed server is no
different from a very slow server.

> When the server reboots, all of the file handles the client has been
> using become "stale".  When the client attempts to use a stale
> handle, the server returns an error, prompting the client to
> re-negotiate with the server's mountd to get a new handle.

> At least, I'm pretty sure that is what happens... someone might want
> to correct me if I got any of that wrong :-)

This is not the way Sun's NFS works, and while I haven't checked, I
feel certain it's not the way ours works either.  Normally, the file
handle contains, encoded somehow, the device, inumber, and generation
count, which allows the server to locate the relevant inode for the
request.  (The generation count is what really causes stale
filehandles; if the generation count doesn't match, the client is using
a file handle after the underlying inode got freed.)

As for the problem that started this thread off, there isn't much to be
done there, unless you want to have the kernel constantly checking with
mountd to verify that each client does in fact have a mount entry.
Perhaps the kernel could kick mountd for every thousandth request or
something, which would get clients back into the mount table without
loading things down too much.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B