name cache (was Re[4]: vn_fullpath())

[Robert Watson]

On Sun, 27 Mar 2005, Igor Shmukler wrote:

> Sorry for reopening an old thread. I am doing this because last time
> around I was unaware of some issues. 
> 
> There are more corner cases/issues with vn_fullpath() and possibly the
> name cache.  Please correct me if I am wrong. Perhaps, I would even
> personally look into fixing these, but I would like to know everyone
> agrees that this is needed. 
> 
> 1. vn_fullpath() does not return names for VCHR vnodes. I think it would
> be handy if this was possible. 

On FreeBSD, this occurs because devfs doesn't use the name cache.  Two
easy solutions are:

- Use the name cache in devfs.  This would have to be done carefully in
  the context of cloning, etc, but should work out.

- Add a VOP/VFS operation to help figure out a pathname with the help of
  the file system, and implement it for devfs.  This would avoid having to
  deal with cache invalidation issues in devfs.

> 2. It appears that vn_fullpath() has problems with FD 0..2. [It even
> seems to happen regardless whether file descriptors were inherited or
> open via $foo >my.file]

I'm not familiar with this issue specifically.  Normally these descriptors
point to tty's (unnamed due to devfs issues above) and pipes (no name),
which would generally explain the issues.  However, the >my.file case is a
bit concerning.  Could you confirm that the file descriptor in that case
is definitely pointed at a vnode?

> I am under the impression that Linux d_path() does these things. Is
> there an agreement that this a problem and it would be benefitial to
> have vn_fullpath() [and name cache] behave in a "proper" way? 

Linux does something a little different in how they maintain references to
files -- their "struct inode" is logically equivilent to our "struct
vnode", in that it's a virtualized inode.  However, they have an
additional structure named "struct dentry", which is a reference counted
inode reference, but includes pointers into the name cache and a cached
local name.  The "struct file" in Linux references a dentry rather than a
pure inode.  This means that name information for inodes is usually
immediately available to consumers, and the name cache is aware of the use
of inodes and paths more explicitly.  A dentry is not always present,
though, but often will be when there's a process around acting explicitly
on a file.

Robert N M Watson

> 
> Where does dragonfly stand on this?
> 
> Thank you,
> 
> Igor
> 
> > :I seem to recall that DragonFly keeps the intermediate nodes.
> > 
> >     There's no way to backport that, it would be hundreds of man hours of
> >     work.  DragonFly uses a totally different namecache topology now, one
> >     that is mandatory and which guarentees the existance of intermediate
> >     nodes.
> > 
> >     You'd have to implement something similar to libc's getcwd code.  e.g.
> >     ".." through and scan each directory to find the matching inode if
> >     the namecache entry is not present.  It actually wouldn't be too hard
> >     to do.  It wouldn't be efficient, but vn_fullpath() is rarely used
> >     so it shouldn't be a problem.
> 
>