Skip to contentSkip to conversation

overlayfs lazy unmounts?

DISCUSSION Eric Jones 3 participants 3 messages Jan 27, 2015 – Jan 28, 2015 2 messages not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

A message that is not in the archive (sent off-list or not yet received): CAJfpegtAL7dGhhRW3x8kEygXAQrW-_mdzEt3NiOo6ETaXkYOCg@mail.gmail.com

Eric Jones

author
#2 lore raw

CC'ing linux-unionfs

Quoted 7 lines · Miklos Szeredi
Quoted 5 lines · 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?

Quoted 7 lines

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?

Quoted 6 lines

Thanks,
Miklos

PS. Would you mind including the unionfs mailing list <[email protected]> in the discussion?

#3 lore raw
Quoted 26 lines · Eric Jones

CC'ing linux-unionfs

Quoted 7 lines · Miklos Szeredi
Quoted 5 lines · 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?

Quoted 7 lines

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

Quoted 8 lines

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.

Quoted 11 lines
Quoted 7 lines

Thanks,
Miklos

PS. Would you mind including the unionfs mailing list <[email protected]> in the discussion?

--
To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#4 lore raw
In reply to Eric Jones
Quoted 2 lines · Eric Jones

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.

Quoted 2 lines

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