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
