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
