Re: (no subject)

[Trond Myklebust <trond.myklebust@fys.uio.no>]

On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> Hi,
> 
> I'm just looking into a nfs i/o error problem. The server for /etc is unfs3 
> and the client is 2.6.16. I need some help regarding the nfs protocol.
> 
> Probably after updating mozilla /etc/mozilla/mozillarc was rewritten, I also 
> guess the inode was recycled.
> 
> A 'ls /etc/mozilla/mozillarc' worked fine and showed the correct results.
> A 'cat /etc/mozilla/mozillarc' gave i/o errors.
> 
> Ethereal shows that the getattr gives the correct results, but the read call 
> gives an NFS3ERR_STALE. 
> Should the client in this case drop its filehandle cache and entirely 
> re-request the file from the server, or is the given i/o error ok?

The ESTALE error is usually correct. The client should not be reopening
the file unless it can guarantee that the file is the same as the one
that was originally open()ed.

> From the point of the server, I guess, it already should return the 
> NFS3ERR_STALE for the getattr call, shouldn't it? I will look into the 
> sources to see why it didn't. (unfs3 was compiled with inode generation 
> number support).

Yes. Under the close-to-open caching model, the expectation is that the
filehandle will remain valid from the moment the successful GETATTR call
is sent in the first open() request until the last call to close(). If
unfs3 is caching filehandles, then it needs to use something like
inotify in order to figure out when to invalidate its cache.

Cheers,
  Trond


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs