On Wed, Jul 08, 2020 at 10:23:53AM -0400, Vivek Goyal wrote: > On Wed, Jul 08, 2020 at 11:50:29AM +0300, Amir Goldstein wrote: > > On Wed, Jul 8, 2020 at 11:37 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > On Wed, Jul 8, 2020 at 10:31 AM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > > > > > > > > > > 1) is not problematic IMO and the simple patch I posted may be applied > > > > for fixing the reported issue, but it only solved the special case of null uuid. > > > > The problem still exists with re-creating lower on xfs/ext4, e.g. by > > > > rm -rf and unpacking image tar. > > > > > > How so? st_ino may be reused but the fh is guaranteed to be unique. > > > > > > > Doh! You are right. I was talking nonsense. > > The only problem would be with re-creating an xfs/ext4 lower image > > with the same uuid maybe because a basic image is cloned. > > > > In any case, it's a corner of a corner of a corner. > > I will post the patch to fix null uuid. > > It will also be good if we can bring some clarity to the documentation > for future references in section "Sharing and copying layers". > > So if IIUC, > > - sharing layers should work with all features of overlayfs. > > - copying layers works only if index and nfs_export is not enabled. Even > if index is not enabled, copying layers will change inode number > reporting behavior (as origin verification will fail). We probably > say something about this. > > - Modifying/recreating lower layer only works when > metacopy/index/nfs_export are not enabled at any point of time. This > also will change inode number reporting behavior. Well, this is not entirely true. redirect might be broken if lower layers have been modified/recreated and that will have issues with directories. /me is again wondering what's the use case of modifying lower layer with an existing upper. Is it fair to say, no don't recreate/modify lower layers and use with existing upper. Thanks Vivek
