On Wed, Jul 26, 2017 at 11:54 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Wed, Jul 26, 2017 at 10:51 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> On Wed, Jul 26, 2017 at 10:47 AM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: >> >>> Aren't we allowed to update the stale index? >> >> The answer is no, of course (otherwise client would get success for >> something it should get error for). Eeturning ESTALE is the right >> thing to do. > > Can encode an overlay-generation in the handle. That would allow us > to have a stale index as well as a new one for the same underlying > origin. > Yes, we can do that. We will never have two different index generations on-disk at the same time. A new generation index always obsoletes an old index generation (index name does not include the generation). Verifying index/origin consistency should happen no later than at encode time, but it really doesn't cost much to verify that at merge dir lookup time. If index/origin is not consistent with merge dir upper/lower, need to replace it with a newer generation consistent index and need to update origin xattr. I would think that it also makes sense to verify index->upper->origin->index consistency on mount, as we anyway should check that index->upper reference is not stale. But I must wonder: does carrying this extra complexity for index generation really worth the effort of not changing behavior of modified lower dir (when user opts-in for the change with index=on)? Do you think there are users out there depending on the current behavior in a setup that does NOT involve copying layers?? Anyway, another not-really-a-reason I am wondering if we can avoid index generation is that I was going to use struct ovl_fh for both on-disk (origin xattr and index name) and for on-wire (NFS), so I'm still resisting the idea to diverge the structs... 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
