All of lore.kernel.org
 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 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.