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
next prev parent 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