All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bernd.schubert@pci.uni-heidelberg.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net
Subject: Re: protocol question
Date: Wed, 26 Jul 2006 13:56:38 +0200	[thread overview]
Message-ID: <200607261356.38520.bernd.schubert@pci.uni-heidelberg.de> (raw)
In-Reply-To: <1153914204.5656.13.camel@localhost>

[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?

>
> > 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 fo=
r =

exactly this purpose? I also restarted unfs3 first, so it didn't have any =

filehandles cached.


Thanks again,
	Bernd

-- =

Bernd Schubert
Physikalisch Chemisches Institut / Theoretische Chemie
Universit=E4t Heidelberg
INF 229
69120 Heidelberg
e-mail: bernd.schubert@pci.uni-heidelberg.de

-------------------------------------------------------------------------
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=3Djoin.php&p=3Dsourceforge&CID=3DDE=
VDEV
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2006-07-26 11:56 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   ` Bernd Schubert [this message]
2006-07-26 12:19     ` protocol question Trond Myklebust
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=200607261356.38520.bernd.schubert@pci.uni-heidelberg.de \
    --to=bernd.schubert@pci.uni-heidelberg.de \
    --cc=bernd-schubert@gmx.de \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.