On Thu, Jan 4, 2018 at 5:40 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > When the "verify" feature is enabled, a directory inode found in lower > layer by name or by redirect_dir is verified against the file handle of > the copy up origin that is stored in the upper layer. > > This introduces a change of behavior for the case of lower layer > modification while overlay is offline. A lower directory created or > moved offline under an exisitng upper directory, will not be merged with > that upper directory. > > The "verify" feature should not be used after copying layers, > because the new lower directory inodes would fail verification. > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> > --- > Documentation/filesystems/overlayfs.txt | 16 ++++++++++++++++ > fs/overlayfs/namei.c | 13 +++++++++++++ > 2 files changed, 29 insertions(+) > > diff --git a/Documentation/filesystems/overlayfs.txt b/Documentation/filesystems/overlayfs.txt > index e6a5f4912b6d..00e0595f3d7e 100644 > --- a/Documentation/filesystems/overlayfs.txt > +++ b/Documentation/filesystems/overlayfs.txt > @@ -299,6 +299,22 @@ filesystem are not allowed. If the underlying filesystem is changed, > the behavior of the overlay is undefined, though it will not result in > a crash or deadlock. > > +When the underlying filesystems supports NFS export, overlay mount can be > +made more resilient to offline and online changes of the underlying lower > +layer by enabling the "verify" feature. > + > +On every copy_up, an NFS file handle of the lower inode, along with the > +UUID of the lower filesystem, are encoded and stored in an extended > +attribute "trusted.overlay.origin" on the upper inode. > + > +When the "verify" feature is enabled, a lookup of a merged directory, that > +found a lower directory at the lookup path or at the path pointed to by > +the "trusted.overlay.redirect" extended attribute, will verify that the > +found lower directory file handle and lower filesystem UUID match the > +origin file handle that was stored at copy_up time. If a found lower > +directory does not match the stored origin, that directory will not be > +merged with the upper directory. Ah, here's the doc. Thinking a bit about this... I think this is a slightly different category than "redirect_dir=on". There we were expanding the functionality, to allow directory renaming. With "verify=on" we are restricting the functionality to not allow some offline changes. Which is really what we want for NFS. But the doc should come with more info about when it makes sense to enable it for non-NFS case and when it does not. I think enabling directory origin verification by default (e.g. with config option or module option) is probably something most users or distros do not want to do, and the documentation should reflect that. As for the name, whatever describes the function best but is as short as possible (e.g. "verify_dir=on/off" should be okay, I think). The issue here is that NFS export will need lots of options, and that may be confusing. How about an "nfs_export=on" option that acts as a shorthand for all options needed for NFS export? 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
