nfs/svn/apache strange interaction

[J. Bruce Fields]

On Mon, May 05, 2008 at 03:16:09PM +0200, Guillaume Rousse wrote:
> J. Bruce Fields a écrit :
>> On Tue, Apr 29, 2008 at 11:36:35AM +0200, Guillaume Rousse wrote:
>>> OK, I just discovered there was an .htaccess file in my public_html
>>> directory, which I was not aware. I tested with and without this file,
>>> the problem still persist. Here are the related traces (this time with
>>> no limit for tcpdump capture).
>>
>> OK, thanks.  The tcpdump.nohtaccess file shows a pretty simple
>> situation--the client opens index.txt (after first creating the
>> clientid), reads it, closes it, then 9 seconds letter tries to do a
>> getattr on it and gets ESTALE.
>>
>> The getattr in the compound with the close shows nlink as 1, so the file
>> was still linked at that point.  There's nothing else in the trace
>> between that close and the final getattr.
>>
>> Presumably svn removed index.html and replaced it sometime during those
>> 9 seconds (an strace of svn could confirm this), and the final getattr
>> is just apache doing a stat() call.
> Here it is. svn seems to create a temporary file, and rename it thereafter:
> rename(".svn/tmp/index.txt.tmp", "index.txt") = 0

OK, then I think we completely understand the situation, thanks.

>> In any case, there's no clear bug on the client or the server side.  And
>> I'm not sure what apache could be doing to avoid this either.
> Indeed. Trying 'stat index.txt' instead of 'cat index.txt' from a shell  
> also triggers the error. So basically we have a nfs/svn interaction  
> issue here, apache is innocent.

So probably the best we can do is find some way to let the client retry
the lookup once.  That won't solve every possible problem--for example,
if the file is replaced again while we're retrying the lookup--but in
practice it seems unlikely you'd hit that case in your situation.

It sounds like there's been some thought about how to do that, but I
don't know if anyone's written up a clear plan.

--b.