On Wed, Apr 26, 2017 at 5:53 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, Apr 26, 2017 at 4:40 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > >> The reason I think the COPYUP vs. MERGE distinction is needed is the >> ovl_check_empty_and_clear() thing. It starts with a merged directory >> with some whiteouts in it and exchanges it with an empty and opaque >> directory. Normally the empty directory will be deleted immediately, >> but if something fails during the deletion, then it will remain there. >> The overlay is left in a consistent state, but the association with >> the original inode should still remain, so it will have COPYUP but not >> MERGE. > > One more thought: we could introduce a separate "overlay.merge" > attribute that is the exact opposite of "overlay.opaque". > "overlay.merge" would imply "overlay.fh" but "overlay.fh" would not > imply "overlay.merge". > > It would allow us to optionally get rid of "overlay.opaque" when back > compatibility is not needed. > > It would also allow a new feature: on metadata only updates of regular > files we wouldn't need to copy up the data. > So you intend to set overlay.merge for non-dir? How is it different from overlay.fh then? With it's new name, overlay.origin.fh indicates that there is a copy up origin below us. Either directly below us, or at overlay.redirect. We can also try to follow to origin by fh, but that is only an optimization - an important optimization IMO, because file rename are more common than dir renames and lookup stable inode by fh in a deep directory with many layers will be much more efficient by fh. Are we understanding each other w.r.t. overlay.merge vs overlay.fh? -- 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
