Re: [fsck.overlay RFC PATCH] overlay: add fsck utility

[Jeff Layton <jlayton@kernel.org>]

On Tue, 2018-03-20 at 17:44 +0100, Miklos Szeredi wrote:
> On Thu, Mar 8, 2018 at 8:51 AM, Amir Goldstein <amir73il@gmail.com> wrote:
> > On Thu, Mar 8, 2018 at 4:38 AM, yangerkun <yangerkun@huawei.com> wrote:
> > > 
> > 
> > [...]
> > > > > > 
> > > > > > In fsck.overlay, lower layer file/dir may be modified with there is not
> > > > > > I_OVL_INUSE in lower layer, but we cannot check does lower layer mounted
> > > > > > with I_OVL_INUSE.
> > > > > > 
> > 
> > [...]
> > > > Also, if we follow my suggestion above for upperdir/workdir
> > > > fsck.overlay may still
> > > > try to aquire I_OVL_INUSE on lowerdir with O_EXCL|O_DIRECTORY and kernel
> > > > can test I_OVL_INUSE flag on lowerdir without trying to set it on mount.
> > > 
> > > 
> > > It's good when we want to mount overlayfs with fsck.overlay is running; But
> > > when there is a mounted overlayfs before fsck.overlay, we cannot use this
> > > way to check if the lower layer has already been used.
> > 
> > Perhaps we should acquire a shared POSIX lock from kernel on lower/upper/work
> > dirs and fsck.overlay should acquire an exclusive POSIX lock.
> > 
> > I'm not sure how acquiring a POSIX lock from kernel should work and which
> > task should be the owner of the lock, but generally overlayfs could either have
> > a single owner task in the kernel for all super blocks or one owner
> > per sb, in which
> > case, we could acquire an exclusive lock on work/upper dirs instead of using
> > the custom  I_OVL_INUSE lock.
> > 
> > Just a thought - not sure if this makes sense. CC'ing Jeff for reality check.
> 
> Much better to use flock(2) locks which, unlike POSIX locks, have sane
> semantics.   The owner is not a task but a file, so just need to keep
> an file open referring to each layer's root in overlayfs.
> 

Oops, missed this thread before.

Yes, a flock lock should be fine as long as you're locking the whole
file (and I assume you would be here). If you need byte ranges, consider
OFD locks.
-- 
Jeff Layton <jlayton@kernel.org>