On Fri, May 19, 2000 at 11:57:22AM +0100, Paul Jakma mentioned:
> 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.
No it's not. The problem is that the application thinks that a filehandle
it has is a valid one. It's not. The best way that can be fixed is by
shutting the application down.
> > 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. :)
Brain fart. I'd actually meant bouncing the client is overkill.
> however, will bouncing the application do any good?
> AIUI, the nfs client should try and obtain another filehandle right?
You'd like to think that, wouldn't you ? But, what if the file isn't
there. Example:
On an NFS drive, run:
mkdir blah
cd blah
touch blah2
On the server, run:
rm -rf blah
On the client, run:
ls -l
- and you should get problems. Why ? Bash has the cwd open, and it gets
confused when it's suddenly gone - after all, unix states that a file
should be left on disk, until all apps using it have died/closed the file.
This isn't happening. Running "cd ~" or something, will clear the problem.
Some apps, that start up in a directory, and don't have anyway of changing
their cwd into one that exists will have that problem until they are
killed.
> 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 the
> client.
> ie NFS filehandle != file descriptor. and client must not assume
> otherwise.
I'm arguing that the kernel is OK. It's not the one with the issue with
state NFS handles.
The client knows nothing about NFS filehandles. All it knows is that it's
trying to read a file that it was given a *valid* filedescriptor to. The
kernel goes "Ah. That filedescriptor is no longer valid, as it points to
an NFS filehandle referring to a file that's been deleted, or renamed or
something".
>> > 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.
Yeah, but not if the file is deleted or moved.
> also, do you really want to add "EVOLGONE" to the kernel? What does
> it add? Nothing imo.
No. But that's an example. Unix also has no way of telling an application
"That file is gone too", as on every other filesystem, an inode isn't
released till all apps close the file. NFS does it differently.
Kate
--
"The fool must be beaten with a stick, for an intelligent person
the merest hint is sufficient" -- Zen Master Greg
Maintained by the ILUG website team. The aim of Linux.ie is to
support and help commercial and private users of Linux in Ireland. You can
display ILUG news in your own webpages, read backend
information to find out how. Networking services kindly provided by HEAnet, server kindly donated by
Dell. Linux is a trademark of Linus Torvalds,
used with permission. No penguins were harmed in the production or maintenance
of this highly praised website. Looking for the
Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
