linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: bernd-schubert@gmx.de
Cc: nfs@lists.sourceforge.net
Subject: Re: protocol question
Date: Wed, 26 Jul 2006 08:19:54 -0400	[thread overview]
Message-ID: <1153916394.5656.23.camel@localhost> (raw)
In-Reply-To: <200607261356.38520.bernd.schubert@pci.uni-heidelberg.de>

On Wed, 2006-07-26 at 13:56 +0200, Bernd Schubert wrote:
> [Sorry that I forgot a proper subject first]
> 
> Hi Trond,
> 
> thanks for your help,
> 
> On Wednesday 26 July 2006 13:43, Trond Myklebust wrote:
> > On Wed, 2006-07-26 at 12:47 +0200, Bernd Schubert wrote:
> [...]
> > > 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.
> 
> But the client returns an i/o error to the userspace, is this correct?

No. It will return an ESTALE to userspace in this case.

> > > 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.
> 
> Hmm, but the inode generation number should have changed, isn't it there for 
> exactly this purpose? I also restarted unfs3 first, so it didn't have any 
> filehandles cached.

Right. The inode generation number changes when the inode number is
reused. After that, any NFS rpc request containing the filehandle with
the old generation number should receive an immediate NFSERR3_STALE.

My point about inotify was merely a way to help enforce that in the case
where a userland-based server might want to cache filehandles. I've no
idea whether or not unfs3 actually does that sort of thing.

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

  reply	other threads:[~2006-07-26 14:08 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-26 10:47 (no subject) Bernd Schubert
2006-07-26 11:43 ` Trond Myklebust
2006-07-26 11:56   ` protocol question Bernd Schubert
2006-07-26 12:19     ` Trond Myklebust [this message]
2006-07-26 12:24       ` Trond Myklebust
2006-07-26 15:32       ` Bernd Schubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1153916394.5656.23.camel@localhost \
    --to=trond.myklebust@fys.uio.no \
    --cc=bernd-schubert@gmx.de \
    --cc=nfs@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).