Linux NFS development
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@redhat.com>
To: "Lever, Charles" <Charles.Lever@netapp.com>
Cc: Garrick Staples <garrick@usc.edu>, nfs@lists.sourceforge.net
Subject: Re: possible client stale filehandle bug?
Date: Wed, 16 Feb 2005 16:47:35 -0500	[thread overview]
Message-ID: <4213BF77.9080004@redhat.com> (raw)
In-Reply-To: <482A3FA0050D21419C269D13989C61130853976F@lavender-fe.eng.netapp.com>

Lever, Charles wrote:
>>I agree, it probably doesn't re-drive on any operation that 
>>doesn't walk 
>>a path, which is in line with what RHEL is doing currently.  I didn't 
>>mean to imply that solaris retired ESTALE in all occurances of the 
>>event.  Anywho, Can you point me to your patches?  I'd be 
>>interested to 
>>know how you managed to implement retry on ESTALE without 
>>leaking into 
>>the VFS, which I think you will recall was the big sticking 
>>point that 
>>we were debating here.
> 
> 
> the patches do touch fs/namei.c (it was al viro's suggestion) with a
> pretty simple change.  and i think they are KABI friendly enough to be
> included in RHEL 3, once we are satisfied that the solution is
> effective.
> 
> the cto-lookup-revalidate patch adds just enough of the 2.6
> lookup-intent logic to the 2.4 VFS layer to allow us to support NFS
> close-to-open in nfs_lookup_revalidate instead of in nfs_open.  this
> resolves one of the most common ESTALE failure modes, where just the
> object at the end of the pathname has been replaced.
> 
> the second patch applies on top of this.  it adds logic to redrive
> pathname resolution if an ESTALE is encountered anywhere during a
> pathname lookup.  it redrives it once from the top, asserting a flag
> that causes the VFS layer to abandon the dcache and use only real
> lookups for this resolution request.  if the redriven resolution fails,
> we give up.  this resolves the other typical ESTALE failure mode, where
> some or all of the path has been replaced, while avoiding retrying an
> unbounded number of times.
Fantastic, Thanks!
Neil

-- 
/***************************************************
  *Neil Horman
  *Software Engineer
  *Red Hat, Inc.
  *nhorman@redhat.com
  *gpg keyid: 1024D / 0x92A74FA1
  *http://pgp.mit.edu
  ***************************************************/


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-02-16 21:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-16 21:42 possible client stale filehandle bug? Lever, Charles
2005-02-16 21:47 ` Neil Horman [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-02-16 21:18 Lever, Charles
2005-02-16 21:23 ` Neil Horman
2005-02-24 19:33   ` Trond Myklebust
2005-02-24 20:43     ` nhorman
2005-01-25 17:39 Garrick Staples
2005-01-26  6:06 ` Trond Myklebust
2005-01-26  6:35   ` Garrick Staples
2005-01-26 13:11     ` Neil Horman
2005-01-26 14:31     ` raven
2005-01-26 17:49       ` Garrick Staples
2005-01-28  0:49         ` Ian Kent
2005-01-26 13:07   ` Neil Horman

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=4213BF77.9080004@redhat.com \
    --to=nhorman@redhat.com \
    --cc=Charles.Lever@netapp.com \
    --cc=garrick@usc.edu \
    --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