On Mon, Jul 24, 2017 at 2:14 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Mon, Jul 24, 2017 at 11:48 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Fri, Jul 14, 2017 at 12:58 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> >>> If you don't want to bundle index=on with NFS export, then no rush to merge >>> these patches now. The added benefit on patch 9 (retroactive marking merge >>> dir with origin for not exposing whiteouts) is relevant to a patch that is not >>> going to land in v4.13 anyway. right? >> >> Right. >> >> Can we maybe postpone the verification until fh decode time? > > Not sure I follow. > Failure to verify lower dir can result in merge dir not being merged or being > merged with a different lower dir (followed by fh). > > The question is which inode we choose to encode in case lower dir cannot be > verified: the unverified lower inode, the stored origin inode or the > upper inode. > > Are you suggesting that "normal" lookup will merge the unverified lower dir > and then a pair of encode/decode will result in another dentry? > or are you suggesting to return ESTALE in that case? > If latter, then that error we be permanent? encode/decode will alway end up > with ESTALE?? Putting a bit more thought into this... I think we have several different cases a) offline move of lower dir, no active NFS export b) online move of lower dir, no active NFS export c) offline move of lower dir, active NFS export d) online move of lower dir, active NFS export e) offline move of lower dir, snapshotfs f) online move of lower dir, snapshotfs The behavior of (a) is well defined: we do not follow origin of directories for merging. It might make sense to introduce a variant that does follow origin, but I'm not sure I see the usefulness. The behavior of (b) is undefined, it might make sense to add an ovl_d_revalidate() and make that case behave like (a) For first version we can say that (c) and (d) are both undefined. I think the logical behavior would be to return ESTALE when we detect such an inconsistency (not sure how expensive that would be) and then the lookup would end up with the updated lower. For (f) we obviously need to follow the origin dir and I guess we don't care about (e). To summarize, only snapshotfs and maybe some other special application of overlay would need the directory following behavior. For NFS export we can just do whatever is simplest in the unverified case for now. Thanks, Miklos -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
