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? 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? Thanks, 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
