[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALYGNiMXhvGOq0P-NG_1jMyN7qp+1+UJ8qihp6wVr0xAKjNHsQ@mail.gmail.com>
Date: Mon, 7 Nov 2016 13:08:27 +0300
From: Konstantin Khlebnikov <koct9i@...il.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Raphael Hertzog <hertzog@...ian.org>,
Miklos Szeredi <mszeredi@...hat.com>,
"linux-unionfs@...r.kernel.org" <linux-unionfs@...r.kernel.org>,
Guillem Jover <guillem@...ian.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] ovl: redirect on rename-dir
On Mon, Nov 7, 2016 at 1:04 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> On Mon, Nov 7, 2016 at 10:58 AM, Konstantin Khlebnikov <koct9i@...il.com> wrote:
>
>> I've stumbled on somehow related problem - concurrent copy-ups are
>> strictly serialized by rename locks.
>> Obviously, file copying could be done in parallel: locks are required
>> only for final rename.
>> Because of that overlay slower that aufs for some workloads.
>
> Easy to fix: for each copy up create a separate subdir of "work".
> Then the contention is only for the time of creating the subdir, which
> is very short.
Yeah, but lock_rename() also takes per-sb s_vfs_rename_mutex (kludge by Al Viro)
I think proper synchronization for concurrent copy-up (for example
round flag on ovl_entry) and locking rename only for rename could be
better.
Powered by blists - more mailing lists