lkml.org 
[lkml]   [2016]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH] locks: fix file locking on overlayfs
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.

\
 
 \ /
  Last update: 2016-07-19 18:21    [W:0.052 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site