Re: [RFC][PATH 4/4] ovl: relax lock_rename when moving files between work and upper dir

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

 



On Fri, Nov 11, 2016 at 5:40 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> On Fri, Nov 11, 2016 at 04:43:57PM +0200, Amir Goldstein wrote:
>
>> > Surely, the copying of data itself is outside of that lock, isn't it?
>>
>> Mmmmmm, no it isn't, but I am going to make it right.
>
> Well, if you really have the copyup itself done under lock_rename(), you
> are looking at potentially copying gigabytes of data from r/o layer to
> workdir under fs-wide lock.  _That_ is really asking for contention from
> hell, and for no good reason.  Renames/whiteout creations/removals are
> trivial noise compared to that.  I'm somewhat surprised, TBH - I thought
> the copyup itself is done outside of that thing.  Are you sure it really
> isn't?

I'm afraid so.
It seems to me that most of the time, lock_rename() is being used in
overlayfs for no better alternative to lock 2 directories (work+upper).

My suggestion is a small modification to the overlayfs locking scheme.
---Instead of this:
assert(lock_rename(workdir, upperdir) != NULL));
   copy_up(src, tmp);
   vfs_rename(tmp, dst);
unlock_rename(workdir, upperdir);

+++Use this:
assert(lock_rename(workdir, upperdir) != NULL));
mutex_unlock(s_vfs_rename_mutex);
   copy_up(src, tmp);
inode_unlock(upperdir);
inode_unlock(workdir);
assert(lock_rename(workdir, upperdir) != NULL));
  vfs_rename(tmp, dst);
unlock_rename(workdir, upperdir);

Miklos,

Do you see any problem with the proposed scheme?
Anything that can go wrong while releasing the workdir lock before vfs_rename()?

Do you think we should do the same for the remove/create functions
or leave the lock_rename() over whiteout+rename+cleanup as it is?

Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Filesystems Devel]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux