we've had some customer complaints about ESTALEs becoming permanent
errors, until a file system is unmounted and remounted again. ESTALE
can be temporary if an NFS share is unexported and reexported while a
client is actively using files on that export. we've seen this problem
on 2.4 and 2.6 clients, but the Solaris client seems to deal with it
correctly.
the logic in nfs_lookup_revalidate doesn't handle stale inodes
correctly. right now, if nfs_cached_lookup doesn't find the matching
entry and the inode is already marked stale, there is no way to
revalidate the file handle again.
if a real lookup is used to revalidate the file handle, that should be
enough to allow the client to clear NFS_INO_STALE on a stale inode,
right?
i've attached a tested patch (against 2.6.9-rc2) that allows
nfs_lookup_revalidate to recover from a stale file handle properly.
comments?
- Chuck Lever
--
corporate: <cel at netapp dot com>
personal: <chucklever at bigfoot dot com>
P=E5 on , 22/09/2004 klokka 13:44, skreiv Lever, Charles:
> we've had some customer complaints about ESTALEs becoming permanent
> errors, until a file system is unmounted and remounted again. ESTALE
> can be temporary if an NFS share is unexported and reexported while a
> client is actively using files on that export. we've seen this problem
> on 2.4 and 2.6 clients, but the Solaris client seems to deal with it
> correctly.
Tough shit for the customers...
Honestly, if the server returns ESTALE, then we do *NOT TRUST* that the
inode resulting from the "temporary" situation is the same as the inode
that existed before.
The Solaris client does not often have to deal with the userspace NFS
daemon (which does not have inode generation numbers etc).
Cheers,
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
P=E5 to , 23/09/2004 klokka 00:27, skreiv Trond Myklebust:
> Honestly, if the server returns ESTALE, then we do *NOT TRUST* that the
> inode resulting from the "temporary" situation is the same as the inode
> that existed before.
To clarify (once again!) what I mean here:
If the client receives an ESTALE error, then it will drop all pending
reads/writes like a stone, so it is not as if this is an error that the
kernel can recover from automatically. Better that the customer be told
right up front that something stupid has happened on the server, and it
is up to them to fix the problem manually.
Trond
-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM.
Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs