From: "J. Bruce Fields" <bfields@fieldses.org>
To: Miklos Szeredi <mszeredi@redhat.com>
Cc: Jeff Layton <jlayton@poochiereds.net>,
Al Viro <viro@zeniv.linux.org.uk>,
linux-unionfs@vger.kernel.org,
lkml <linux-kernel@vger.kernel.org>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [RFC PATCH] locks: fix file locking on overlayfs
Date: Tue, 19 Jul 2016 11:36:02 -0400 [thread overview]
Message-ID: <20160719153602.GB3335@fieldses.org> (raw)
In-Reply-To: <CAOssrKdrSbS8=BO2rLPEOip8Cg3NgNbCGX6s_J933hRKYBEEfg@mail.gmail.com>
On Tue, Jul 19, 2016 at 04:46:14PM +0200, Miklos Szeredi wrote:
> On Tue, Jul 19, 2016 at 4:01 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Tue, Jul 19, 2016 at 02:27:44PM +0200, Miklos Szeredi wrote:
> >> This patch allows flock, posix locks, ofd locks and leases to work
> >> correctly on overlayfs.
> >>
> >> Instead of using the underlying inode for storing lock context use the
> >> overlay inode. This allows locks to be persistent across copy-up.
> >
> > Remind me when the overlay inode is created--is it immediately on any
> > (even read-only) open?
>
> So basically overlay has three types of inodes: lower, upper (these
> are called underlying or real inodes) and overlay inode.
>
> Overlay inode is created on lookup, just like any other filesystem.
> Overlayfs's own lookup then it proceeds to look up underlying dentry
> and stores ref in the overlay dentry.
>
> Copy-up happens on read-write open (or other modifying operation),
> which creates inode on upper and copies data/metadata from lower inode
> to upper inode.
Thanks for the explanation. So, if I understand correctly:
Locking should look completely normal as long as all locking is done
through the overlay.
Locks may fail to conflict when expected if one of the overlayed layers
is accessed elsewhere somehow--but that's a reasonably easy rule to
document, and consistent with other overlayfs behavior.
--b.
next prev parent reply other threads:[~2016-07-19 15:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 12:27 [RFC PATCH] locks: fix file locking on overlayfs Miklos Szeredi
2016-07-19 14:01 ` J. Bruce Fields
2016-07-19 14:46 ` Miklos Szeredi
2016-07-19 15:36 ` J. Bruce Fields [this message]
2016-07-19 18:01 ` Jeff Layton
2016-07-20 4:08 ` Miklos Szeredi
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=20160719153602.GB3335@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@poochiereds.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-unionfs@vger.kernel.org \
--cc=mszeredi@redhat.com \
--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).