name cache (was Re[4]: vn_fullpath())
Hi, 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. 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 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? 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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: name cache (was Re[4]: vn_fullpath())
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. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re[2]: name cache (was Re[4]: vn_fullpath())
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. I would prefer whatever would be a lowest impact uniform (for different FSs) solution. I will start looking into this issue. 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 will do this. I would like to point out ( guess I was not clear the first time). That even if std[in/out/err] is VREG, not VCHR after child process inhereted this descriptor vn_fullpath() does not work. I understand that this sounds fishy, because fd simply points to vnode, but that the impression for now. If one closes a standard descriptor then opens a file, it does work, but seems not to survive through inheritance. I will follow-up with more information on this. Maybe, files issue for 0..2 is a just a product of imagination :) Linux does something a little different in how they maintain references to I am aware that Linux dentry/inode/cache are different, but I was asking this for a simple (selfish) reason. If there is a concesus that d_path() like functionality [in a black-box way i.e. let's forget how it is implemented] would be very helpful, then I think if a patch was made it might be committed before 5.5 is out. In that case, I would try to work on this and/or even ask my colleagues to help with coding/testing. If this is viewed as an obscure feature that will not be included anytime soon, I would remove from my agenda for now. I thank you Robert and everyone else who spent time reading this thread and thinking about this whole issue. Thank you, Igor ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
