a take at cache coherency

[Csaba Henk]

On 2006-01-23, Simon 'corecode' Schubert <corecode at xxxxxxxxxxxx> wrote:
> i'm sorry but i don't like the patch for those reasons.  general vfs 
> code gets cluttered with namecache interal going-ons (the shadow groups) 
> and makes it super-easy to introduce a mistake.

Yeah, that's what's now. Though I didn't mean the shadow group interface used
directly as is now... the namecache interface could easily be sanitized;
yet trying to do that would have been a premature optimization at this
point.

Abstracting the namecache interface might be necessary/beneficial for
other reasons too; if that were the case, you can't say my patch is too
much off the path. I can also imagine that the current way of using the
namecache is decreed a sacred cow; in that case I admit that my approach
is not viable in this form.

> I think if we already carry the fields around in the namecache structs 
> we should also populate them.

And I don't think so :) I mean, why? Maintenance might be more expensive
than wasting some of them.

Do you have any ideas of a more economical data structure layout?

> + renames on the lower layer don't trigger namecache 
> renames/invalidations on a higher layer.  this is what the coherency 
> should be about, i think.

Oh, it's not that simple. I think of parent/child relations as
"horizontal", shadowing relations as "vertical"; I think the design
should respect this orthogonality.

Parent/child relations are not subject to shadowing; therefore
invalidations don't get propagated automatically. However, propagating
shadowing relations (vertical arrows) through ancestry (in horizontal
direction) is made easy. It's up to the user when is that done. If done
unconditionally -- like in nullfs -- then invalidations (an action
spreading horizontally) will do be propagated through overlays (vertical
direction). It is realistic that you'll want to use a more refined
overlay propagation scheme in other cases. (Unionfs maybe? You don't need
your whole unioned hierarchy getting invalidated just because one of the
fs-es in the union has gone through a namecache invalidation).

In case of renaming, yeah, you will have to take an action in both
layers. This action is not out of scope though: only the dedicated cache
API callback (cache_rename) has to be used. Again, in another situation
you might want to keep the upper namecache entries fixed and do the
actual rename only in the lower layer, so a coherency implementation
would be overzealous if it would do the rename for you everywhere.
What this API extension does do is keeping locking and resolution in sync.
That's enough for making the rest easy.

> maybe we should discuss design before actually implementing it? :)

Try to be a bit more optimistic :)

My opinion is that there is a limit how far you can go in discussion,
without brewing code that works (not necessarily optimally, but works).
(I at least found coding a better way of crystallizing ideas than
talking about them and I hope that giving an implentation will do a
better job at communicating them than talking about them could do.)

Many ideas were flying around in the thread "nullfs stabilization I", now here
is something you can match them against. That's good enough IMHO; and I
didn't say "final solution to cache coherency, please commit it ASAP", I
just said "a take at cache coherency".

It's a choice to do delve into discussions again with far-fetchedness
counter reset.

Regards,
Csaba