Re: Rename window

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>On Fri, 2005-11-11 at 11:42 +0000, Edward Hibbert wrote:
>  
>
>>I have noticed a atomicity problem with the handling of rename by the
>>Linux NFS client, and just wanted to check if this is something that
>>we just have to work-around, or is there some other solution.
>> 
>>The problem arises when two different machines issue a file rename
>>which is identical.
>> 
>>E.g. rename oldname newname
>> 
>>You would expect that one machine would be successful, and the other
>>would fail.    However, the NFS client seems to be issuing 3 NFS
>>operations to perform the rename
>>      * LOOKUP oldname 
>>      * LOOKUP newname 
>>      * RENAME oldname newname
>>There is a timing window where both LOOKUPs can succeed (if the other
>>machine does the rename at the right time).   In this case, the Linux
>>NFS client does not issue the final NFS RENAME operation - BUT still
>>returns success to the caller.
>> 
>>Thus both machines have succeeded in renaming the file.
>> 
>>You might argue that since they are performing the same operation that
>>it is OK for both to succeed, but I have an application that depends
>>on the atomicity of the operation, as it uses the filename to hold a
>>counter, and rename to assign a unique counter to a process.
>>    
>>
>
>This is another of those cases where the VFS has optimised for local
>filesystem behaviour, and where fixing this problem would require
>significant VFS changes.
>You'd basically have to add a new lookup intent for the RENAME function
>in order to tell the NFS layer that it can ignore the lookup requests.
>We probably will get round to doing that sometime, but it is not one of
>the most pressing bugs on my list.
>
>In the meantime, I'd suggest just not relying on this level of atomicity
>(there are in any case situations where this is always impossible - for
>instance in sillyrename() situations).
>

It is true that rename(2) is supposed to be atomic.

It is also true that this is a problem in an optimization in the file system
independent layer in the current Linux.  There is a check which compares the
"from" inode and the "to" inode and, if they are the same, just returns no
error, ie. success.  NFS does need at least the lookup on the "to" name so
that it can handle the rename to an open file case.

Couldn't this be (fairly) easily handled by making the short circuit check
in vfs_rename() conditional and not use it for NFS mounted file systems
and perhaps others?

    Thanx...

       ps


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs