[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#7389: rename() over NFS

From: Eric Blake
Subject: bug#7389: rename() over NFS
Date: Sat, 13 Nov 2010 14:24:11 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20101103 Fedora/1.0-0.33.b2pre.fc14 Lightning/1.0b3pre Mnenhy/0.8.3 Thunderbird/3.1.6

On 11/13/2010 07:30 AM, Jim Meyering wrote:
> Bruno Haible wrote:
>> Jim Meyering wrote:
>>> if you see ways to improve things without impacting performance
>>> or maintainability, I'm all for it.
>> Maintainability wouldn't be impacted, because the fix would be to use
>> lib/rename.c, with
>>   #define RENAME_HARD_LINK_BUG 1
>> But performance would be impacted, since 2 lstat() calls would happen
>> before every rename().
> That sounds like it would be excessive.
> Currently, moving 100 regular files into a subdir
> incurs 100% of its time in 100 rename and 200 stat calls:
> % time     seconds  usecs/call     calls    errors syscall
> ------ ----------- ----------- --------- --------- ----------------
>  79.69    0.000051           1       100           rename
>  20.31    0.000013           0       200       100 lstat
>   0.00    0.000000           0         8           read
> Adding a rename wrapper and doubling the number of lstat calls
> per file would represent a significant slow-down.

The two lstat() calls occur before coreutils calls rename().  And it
appears that the NFS rename() bug that we are concerned about is only in
the case of renaming one directory onto another empty one; which is
generally only possible via 'mv -T a b' (where b is the empty directory
to be overwritten by directory a).

So maybe it's still possible to do a relatively-maintainable patch to
coreutils that detects when we are about to call rename() onto an
existing directory (basically, when 'mv -T' is in effect), and manually
call rmdir("b") before renaming "a", which should work around the NFS
bug, all without needing a rename() wrapper.  At any rate, the gnulib
documentation would need a patch describing the bug, and stating that
gnulib does not work around it.

But I'm not sure if changing mv to avoid this corner-case POSIX
violation on NFS not renaming directories properly is made any better by
inserting the rmdir() call, since that also feels like it is a POSIX
violation for not making an atomic rename attempt.  Maybe all the more
we can do is document this, and ping the kernel folks to see if they can
fix their NFS implementation bug.

Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]