On Tue, Jan 9, 2018 at 6:35 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Tue, Jan 9, 2018 at 5:31 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Tue, Jan 9, 2018 at 6:08 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >>> On Thu, Jan 4, 2018 at 5:40 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>>> With the 'verify' feature enabled, all dirs are indexed on copy up. >>>> Non-dir files are copied up directly to indexdir and then hardlinked >>>> to upper dir. >>>> >>>> Directories are copied up to indexdir, then an index entry is created >>> >>> Makes me wonder: do we need a workdir at all? Temp files are already >>> differentiated by leading "#", so that takes care of cleanup. >>> Advantage: one less directory to worry about in implementation. >>> >> >> One advantage of keeping legacy work dir is that existence of index dir >> is the one and only "feature bit" in overlayfs on-disk format and I wouldn't >> like that bit to get lost. We can also look for non # entries in index as >> indication to past index=on mount, but a simple exists indication is nicer. >> >> I guess we could always use indexdir for copy up with index=on, >> but I don't know that is going to simplify code, given that this (dir index) >> patch didn't even need to change struct ovl_copy_up_ctx. > > We could always use index dir for everything. Since workdir lifetime > is for the duration of the mount, no back compatibility issues with > just not using it at all. > I got that. I referred to loosing the information of whether or not overlay was ever mounted with index=on (a.k.a. index feature bit is set). Today, workdir/index exists => overlay was mounted with index=on. If we always use workdir/index instead of workdir/work, we will loose this simple and quick test. Not the end of the world, but nice to have. OTOH, my POC for implementing overlay features depends on existence of indexdir and on mount calling ovl_indexdir_cleanup(): https://github.com/amir73il/linux/commits/ovl-features So if something like that is adopted, my "feature bit" concern is addressed. 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
