On Tue, Jan 9, 2018 at 10:54 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Tue, Jan 9, 2018 at 11:16 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Thu, Jan 4, 2018 at 5:40 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>> Introduce the "verify" config, module and mount options. >>> >>> If the "verify" feature is enabled then overlay filesystems will use >>> the inodes index dir to verify layers consistency. >>> >>> It is possible to enable consistency verification by default during >>> build time with the OVERLAY_FS_VERIFY config option, during runtime >>> with the "verify=on" module option or on a filesystem instance basis >>> with the "verify=on" mount option. >>> >>> The "verify" feature will prevent multiple redirects to the same lower >>> dir and will prevent broken hardlinks from using the same inode number. >>> >>> On an overlay filesystem instance with multiple lower layers, "verify" >>> feature can only use the index to prevent multiple redirects from upper >>> dirs and not from middle layer dirs. Emit a warning about this on mount >>> with multiple lower layers and "verify=on". >> >> Could the above go into Documentation/filesystems/overlayfs.txt as well? > > Will do. > BTW, are you ok with the feature name "verify" or do you prefer that > I rename it to "verify_origin" to be more descriptive as Vivek suggested? > >> >> Also, the verify feature does have some overhead, which should also be >> noted in the documentation. Do you have some measurements about how >> much impact it has on performance? >> > > I do not. It's on my TODO list. > > I'm curious though, where do you think it should performance? > I would expect that encoding a file handle and index lookup would not be > that expensive, so I don't expect much lookup overhead. No? I wasn't thinking about anything specific, but now you ask: directories always need to be connected, and that results in multiple readdirs, etc, that is probably noticeable under some conditions. > For copy up, I doubt that creating 2 dirs instead of one, or 2 hardlinks > instead of one file would make a big difference? > I suppose that a highly concurrent copy workload up will become a little > contended of the index dir lock, but still nowhere near the fully sequential > nature of dir copy up. > > "verify" feature will surely have an impact of index directory size. > I do have a concern about the impact of a very large index directory on > index lookup and creation times and I intend to test that. > > A very just concern that Vivek raised is performance of overlay mount time. > Apparently, there are some workloads that are sensitive to mount/umount > time in the containers world. > For those workloads, ovl_indexdir_cleanup() could be a problem. > For directory index entries, ovl_verify_index() is decoding the upper dir file > handle and that can be expensive. > The cleanup on mount is not strictly needed for correctness of "verify" feature, > nor for NFS export, so we may want to consider a mount option for not > running ovl_indexdir_cleanup() or for running it in a non expensive mode > that skips the file handle verification? Right. 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
