From: John P. Looney (jplooney-ilug at domain online.ie)
Date: Fri 19 May 2000 - 09:58:11 IST
On Thu, May 18, 2000 at 06:47:09PM +0100, Paul Jakma mentioned:
> On Thu, 18 May 2000, John P. Looney wrote:
> > Er, but the application open()s a file on an NFS filesystem.
> ok that's between the client and the kernels VFS layer.
Where else is a problem with a client application going to crop up ;)
> > If the NFS
> > filesystem is trashed, and the kernel knows it
> which kernel? the server or client?
client kernel.
> > (as in, if the file on the
> > NFS file in question is deleted or moved), then it'll return a "state NFS
> > filehandle" error.
> 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.
> but these are nfs internals, i'm way out of my depth. dave airlie might be
> able to speak authoratively about this.. :) all i wanted to do was suggest
> that the guy reboot the client machine, as ime that's where the problem is
> most likely to be.
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.
Kate
-- "The fool must be beaten with a stick, for an intelligent person the merest hint is sufficient" -- Zen Master Greg
This archive was generated by hypermail 2.1.6 : Thu 06 Feb 2003 - 13:06:13 GMT