Re: [QUESTION] Why overlayfs cannot mounted as nfs_export and metacopy?

[Vivek Goyal <vgoyal@redhat.com>]

On Tue, Aug 10, 2021 at 03:48:55PM -0400, Vivek Goyal wrote:

[..]
> > But beyond the complexity, what is the benefit?
> > I was under the impression that container manager do not know how
> > to build images with metacopy, so what are the chances of actually
> > seeing metacopy in middle layers in the wild?
> 
> Sure, we don't put metacopy inodes into portable images. But I thougt
> this could be part of a lower directory on same system. For example,
> docker devicemapper driver used to take an image and explode that
> on a thin volume. Then it will take a snaphost, modify some files
> and prefix that intermediate state with "-init". And then containers
> will use this "-init" as base for container rootfs and take snapshot
> of this.
> 
> I am not sure if container managers are doing this for overlayfs
> or not on same system. But I will not be surprised if somebody
> decides to do that. That's is change some metadata in image
> (which triggers metacopy) and then use upper layer as lower layer
> for container rootfs.
> 

In the past we were experimenting with chowning all files in image
according to user namespace of container using metacopy and use chowned
dir as lower layer for container rootfs. Ofcourse now, idmapped mounts
are available (not sure if it works with overlayfs yet or not) so chowning
images should not be required.

But point I am trying to make it is that I will not be surprised
that somebody comes up with use case of metacopy inode in lower
layer. So will be nice we take care of that configuration as well
while enabling metacopy with nfs_export (and deal with extra
complexity).

Vivek