[Removed some CC from list to reduce spam over side question] On Thu, Apr 27, 2017 at 7:08 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > So to list everything for v4 in one place: > > 5. store uuid together with lower fh inside struct ovl_fh (in overlay.origin) > There does not seem to be a reason to store root fh though for non-dir > and its not relevant for for lookup of dir for snapshot case either (single > lower layer case) > Miklos, I see you are online so I might as well ask now again to make sure (because our weekends are not aligned). With all recent conclusions, do you see a reason to keep origin root fh? For snapshots I need just one thing - Verify that origin.fh matches the lower of merge dir that was found by path. The verification is very cheap (only encode the found dentry), so we may do it in any configuration, just don't know how to act upon it. What to do in case verification fails may need configuration option. For snapshots I need a 'strict' policy meaning that "stale lower" equals "implicit opaque", but that will not do the right thing for copied layers case. The way I have it now in my snapshot patches is overload on the redirect_dir mount option and add a value redirect_dir=fh. The build time and module options are still boolean, but -o redirect_dir=fh sets config->redirect_dir=true and config->redirect_fh=true. config->redirect_fh can later be set to false if the prerequisite (samefs etc) don't apply. I may need to separate the general ofs->redirect_fh capabiltiy from the mount configuration (i.e. config->redirect_dir_fh or make config->redirect_dir an enum). I could also add more policy options for redirect_dir, i.e.: off - pre v4.10 compat on - v4.10 compat (path only) path - same as on, just to explicitly mention for when knowingly copying layers fh - snapshot case, fh must be verified auto - (the default?) best effort w.r.t lower dir renames - lookup by path, verify fh, if fails try to lookup by fh, if fails use path result anyway. I realize you prefer the "minimum configuration" policy, but I'm afraid we are at a cross road of letting the user decide. No? Amir. -- 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
