From: Paul Jakma (paul at domain clubi.ie)
Date: Fri 19 May 2000 - 11:55:48 IST
On Fri, 19 May 2000, John P. Looney wrote:
> > ok that's between the client and the kernels VFS layer.
> Where else is a problem with a client application going to crop up ;)
but it's an NFS problem.. not an application problem. And therefore
between kernel nfs client and remote kernel nfs server.
> > uhmm.. no. AFAIK the server can invalidate the filehandle next time the
> > client tries to use it. continious stale file handle messages is [afaik]
> > where a client persists in presenting an old file handle.
> Indeed. And the solution - bounce the client application. Bouncing a
> server is overkill.
i wasn't arguing for bouncing the server, i was arguing for bouncing
the client machine. :)
however, will bouncing the application do any good?
AIUI, the nfs client should try and obtain another filehandle right?
AUIU because of NFS's stateless way of working, the client kernel can
not presume that the filehandle it has obtained from the nfs server
will be valid across the lifetime of an open file descriptor local to
ie NFS filehandle != file descriptor. and client must not assume
> I did a lot of playing around with usermode NFS, during my postgrad
> (before I got bored of it, and found FIST, the programmable filesystem) -
> for what it does, it does well. But it's a shame that Unix filesystems
> aren't network-aware - there is no way of telling an application "Sorry,
> that volume is gone off the network". It'll just keep retrying, or quit.
does there need to be? With NFS the server can go down for /days/ (if
not longer) and as soon as it comes back up the clients that were
using it can continue on with what they were doing.
also, do you really want to add "EVOLGONE" to the kernel? What does
it add? Nothing imo.
-- Paul Jakma paul at domain clubi.ie PGP5 key: http://www.clubi.ie/jakma/publickey.txt ------------------------------------------- Fortune: It is easier to fight for one's principles than to live up to them. -- Alfred Adler
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:06:13 GMT