From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 13:53:48 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADD0F16A4CE for ; Sun, 27 Mar 2005 13:53:48 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B16243D39 for ; Sun, 27 Mar 2005 13:53:48 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 6678C46B55; Sun, 27 Mar 2005 08:53:47 -0500 (EST) Date: Sun, 27 Mar 2005 13:50:41 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Igor Shmukler In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: hackers@freebsd.org Subject: Re: name cache (was Re[4]: vn_fullpath()) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2005 13:53:48 -0000 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. > >