* Re: overlayfs lazy unmounts?
2015-01-27 20:41 ` overlayfs lazy unmounts? Eric Jones
@ 2015-01-28 1:23 ` Ian Kent
2015-01-28 3:59 ` hujianyang
1 sibling, 0 replies; 3+ messages in thread
From: Ian Kent @ 2015-01-28 1:23 UTC (permalink / raw)
To: Eric Jones; +Cc: Miklos Szeredi, linux-unionfs
On Tue, 2015-01-27 at 12:41 -0800, Eric Jones wrote:
> CC'ing linux-unionfs
>
> On Mon, Jan 26, 2015 at 06:00:35PM +0100, Miklos Szeredi wrote:
> > On Fri, Jan 23, 2015 at 7:03 PM, Eric Jones <ejones <at> cray.com> wrote:
> > > Hi. Thanks for overlayfs.
> > >
> > > We're using overlayfs, and we're trying to deal with the "undefined" behavior when modifying the lower layer. The approach we are taking is to lazy unmount all overlays, modify the lower layer, and remount with the same upper/lower.
> > >
> > > Would you expect processes with references to the lazily unmounted overlayfs to behave? Even if the overlay is immediately recreated?
> >
> > While referencing the old overlay they will behave in an undefined
> > way, regardless of the recreated overlay.
> >
> > Now "undefined" does not necessarily mean it will do something bad.
> > Depends on what you expect it to do...
> >
> > What's the use case? Why and how are you modifying the lower layer?
>
> Consider managing /opt on a very large diskless cluster. Lower layer is NFS. Upper layer is tmpfs. Upper has portions of /opt we want in memory for performance considerations.
>
> Lower could be one of:
> server:/var/images/opt_A
> server:/var/images/opt_B
> server:/var/images/opt_C
> server:/var/images/opt_XXXX
>
> Upper is tmpfs /.opt and they are overlayfs mounted on /opt.
>
> So this would be a typical mount command:
> mount -t overlayfs -olowerdir=/var/images/opt_A,upperdir=/.opt none /opt
>
> 1. Will creating new verions of /var/images/opt_XXXX on the NFS server affect existing overlayfs mounts? The docs say modifying the lower filesystem is not allowed, but will anything "bad" happen if we are just adding a sibling directory tree that is not yet overlay mounted?
>
> 2. We switch to a new /var/images/opt_XXXX by doing a lazy unmount of the old and mounting the new. Will processes with outstanding references see broken pwd/cwd? Corruption?
I don't know about corruption but pwd will be broken because the lazy
umount has unlinked the mount from the tree so the kernel can't walk
back up to the root.
>
> >
> > Thanks,
> > Miklos
> >
> > PS. Would you mind including the unionfs mailing list
> > <linux-unionfs@vger.kernel.org> in the discussion?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: overlayfs lazy unmounts?
2015-01-27 20:41 ` overlayfs lazy unmounts? Eric Jones
2015-01-28 1:23 ` Ian Kent
@ 2015-01-28 3:59 ` hujianyang
1 sibling, 0 replies; 3+ messages in thread
From: hujianyang @ 2015-01-28 3:59 UTC (permalink / raw)
To: Eric Jones; +Cc: Miklos Szeredi, linux-unionfs, raven
On 2015/1/28 4:41, Eric Jones wrote:
>
> 1. Will creating new verions of /var/images/opt_XXXX on the NFS server affect existing overlayfs mounts? The docs say modifying the lower filesystem is not allowed, but will anything "bad" happen if we are just adding a sibling directory tree that is not yet overlay mounted?
Overlayfs doesn't affect lowerfs but may cache some filesystem
data of lowerfs in memory. I think if the sibling directory is
entirely independent with the lowerdir of overlayfs, modifying
is OK.
But there are many using case in filesystem, e.g. link, may affect
the lowerdir even if the operations is performed on sibling dir.
Keep lowerfs stable is safe.
>
> 2. We switch to a new /var/images/opt_XXXX by doing a lazy unmount of the old and mounting the new. Will processes with outstanding references see broken pwd/cwd? Corruption?
New mount will create new metadata in my considering. They are
different mount for OS. You are worry about that new mount and
old mount may modify upperdir in the same time, Am I right? So
I think it is similar with the case that mounting two different
overlayfs with same upperdir, I think you could handle it in
userspace.
What's your use case? You can try something first and see what
will happen, then send out the result.
BR,
Hu
^ permalink raw reply [flat|nested] 3+ messages in thread