linux-unionfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: Konstantin Khlebnikov <koct9i@gmail.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-unionfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: [RFC][PATH 0/4] Reduce excessive use of lock_rename() in overlayfs
Date: Fri, 11 Nov 2016 00:44:39 +0200	[thread overview]
Message-ID: <1478817883-27662-1-git-send-email-amir73il@gmail.com> (raw)

lock_rename() is a very big hammer used before every call to vfs_rename(),
in order to avoid some horrible corner cases that are described in the
comment above vfs_rename().

lock_rename() taked a super block global mutex before every rename operation
that involved moving to a different parent and forces all such renames in
the file system to be serialized.

That cost may be acceptable to most workloads, because moving files/dirs
between directories are not as common as other file system operations.

Overlayfs uses vfs_rename() more that most file systems do, not only for
user requested renames, but also for every copy-up and every whiteout,
so vfs_rename() can be triggered from user operations open/create/delete,
that are much more common the renames.

It turns out, though, that all the horrible corner cases that require
the big lock_rename() hammer, can be eliminated when setting up the
overlay mount and then lock_rename() can be avoided in many use cases.

I do not have any performance results to show, which is really called
for in this sort of work. But it seems obvious that when running multiple
docker containers, file system operations should not be serialized among
all of them. So I am hoping that someone, with test machines stronger
than mine, can take this code to a test drive.

This code passed regression tests with unionmount-testsuite, pjdfstest
and xfstests -g quick.
It fails xfs tests generic/373 and generic/374 and for a good reason:
those tests try to mount 2 overlayfs mounts with the same upper/work dirs.
I will send patches to fix those 2 tests.

Amir Goldstein (4):
  vfs: reinterpret sillyrename flag as delete lock
  vfs: introduce delete trylock/unlock
  ovl: delete lock upper dir and work dir
  ovl: relax lock_rename when moving files between work and upper dir

 fs/afs/dir.c             |  6 ++---
 fs/btrfs/ioctl.c         |  5 ++--
 fs/namei.c               | 25 ++++++++++++++++---
 fs/overlayfs/copy_up.c   |  7 +++---
 fs/overlayfs/dir.c       | 25 +++++++++++++------
 fs/overlayfs/overlayfs.h |  2 ++
 fs/overlayfs/super.c     | 63 +++++++++++++++++++++++++++++++++++++++---------
 include/linux/dcache.h   | 35 +++++++++++++++++++++++++++
 include/linux/namei.h    |  2 ++
 9 files changed, 137 insertions(+), 33 deletions(-)

-- 
2.7.4

             reply	other threads:[~2016-11-10 22:45 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-10 22:44 Amir Goldstein [this message]
2016-11-10 22:44 ` [RFC][PATH 1/4] vfs: reinterpret sillyrename flag as delete lock Amir Goldstein
2016-11-10 22:44 ` [RFC][PATH 2/4] vfs: introduce delete trylock/unlock Amir Goldstein
2016-11-10 22:44 ` [RFC][PATH 3/4] ovl: delete lock upper dir and work dir Amir Goldstein
2016-11-10 22:44 ` [RFC][PATH 4/4] ovl: relax lock_rename when moving files between work and upper dir Amir Goldstein
2016-11-10 23:02   ` Al Viro
2016-11-10 23:05     ` Al Viro
2016-11-10 23:11       ` Amir Goldstein
2016-11-10 23:17         ` Al Viro
2016-11-10 23:33           ` Amir Goldstein
2016-11-10 23:54             ` Al Viro
2016-11-11  0:11               ` Amir Goldstein
2016-11-11  0:27                 ` Al Viro
2016-11-11 14:43                   ` Amir Goldstein
2016-11-11 15:40                     ` Al Viro
2016-11-11 16:17                       ` Amir Goldstein
2016-11-11 17:27                         ` Al Viro
2016-11-11 17:44                           ` Miklos Szeredi
2017-01-12  5:42                             ` Amir Goldstein
2017-01-12 10:00                               ` Miklos Szeredi
2017-01-12 18:18                                 ` Amir Goldstein
2016-11-11 18:07                           ` Amir Goldstein
2016-11-12 19:45                             ` Amir Goldstein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1478817883-27662-1-git-send-email-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=koct9i@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-unionfs@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).