Name cache question

[Eric Jacobs]

Hi all,

I am interested in exploring the option of operating DragonFly with non-
traditional filesystem layouts that make use of features like
hard-linked directories, nullfs/unionfs-type mounts, per-process
namespace, etc, but I'm having trouble figuring out how it would work
with the new namecache system.

I did try nullfs and got very bizarre results. nullfs was using the
old VFS interface, but when I looked at updating it, I had several
concerns.

It appears that we are representing a (dvp,cn) -> vp association with
up to n distinct namecache structures, where n is the number of unique
nc_parent chains that lead to vp. As a consequence:

1. In the general case that the filesystem layout is a DAG, because the
namecache is a tree, we end up with a potentially high ratio of ncp's
to the vnode-associations that they are supposed to represent;

2. There's no way in the API to express the notion that a namecache
entry is an alias of another one. v_namecache particularly does not
help, because that indexes * -> vp associations, which may be totally
independent (like normal hard-links to files). In addition in stacking
FS scenarios, the vp's may be totally different and not show in the
v_namecache at all. So we can't even conservatively fallback to say
doing cache_inval_vp exclusively to preserve coherency.

3. Because the system has no knowledge of which ncp's are aliases of
which, we don't get the benefit of caching for those aliases. The
more we DAG-ify the filesystem, the less benefit of namecache we get.

I understand that some of these design decisions were motivated by the
desire to have ../fullpath handled by the namecache, but I wonder if that
will prove to be a high price to pay in terms of efficiency and API
complexity when we move ahead to per-process VFS environments and other
non-traditional uses of the filesystem.

How should we proceed? How should the namecache of an upper-level FS be
invalidated as a result of activity on the lower-level FS?

-Eric