On Wed, Nov 30, 2016 at 1:58 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > On Wed, Nov 30, 2016 at 1:09 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Mon, Nov 21, 2016 at 5:57 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >>> The benefit of making directories opaque on creation >>> is that lookups can stop short when they reach the >>> original created directory, instead of continue lookup >>> the entire depth of parent directory stack. >>> >>> The best case is overlay with N layers, performing >>> lookup for first level directory, which exists only in upper. >>> In that case, there will be only one lookup instead of N. >> >> I split this up, changed it around a bit and pushed the result to >> overlayfs-next. >> > > Nice cleanup. FYI, you left me as sole S-O-B on the change. Okay, fixed. > Anyway, it passed my tests. > > In case you are still interested, I rebase concurrent copy up > on top of overlay-rorw and pushed to branch #concurrent_copyup > on my github, with slightly improved commit message. > But I guess this merge window is crowded enough already and > I personally much rather see rorw merged than concurrent copy up. My problem with the concurrent copy up is the complexity of locking rules. Why not do some sort of overlay private lock here? If a mutex is deemed too expensive, then just a bool "copying" in ovl_entry and a waitq in ovl_fs in would do. 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
