Re: Rename window

[Peter Staubach <staubach@redhat.com>]

Trond Myklebust wrote:

>On Fri, 2005-11-11 at 09:58 -0500, Peter Staubach wrote:
>  
>
>>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?
>>    
>>
>
>That causes weird behaviour to pop up in other places. One classic is
>the rename of an open file onto a hard link of itself, where unless
>someone (either NFS or the VFS) tests those inodes for equality, NFS
>will end up sillyrenaming the hard link, then renaming the open file in
>complete violation of POSIX.
>

I suppose that a check could be added for the hard link count, but yuck,
that is a nasty situation.  Oh well, good point...

       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