From: Neil Horman <nhorman@redhat.com>
Subject: Re: possible client stale filehandle bug?
Date: Wed, 16 Feb 2005 16:47:35 -0500
Message-ID: <4213BF77.9080004@redhat.com>
References: <482A3FA0050D21419C269D13989C61130853976F@lavender-fe.eng.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Cc: Garrick Staples <garrick@usc.edu>, nfs@lists.sourceforge.net
To: "Lever, Charles" <Charles.Lever@netapp.com>
In-Reply-To: <482A3FA0050D21419C269D13989C61130853976F@lavender-fe.eng.netapp.com>
Sender: nfs-admin@lists.sourceforge.net
Errors-To: nfs-admin@lists.sourceforge.net

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