From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 27 13:05:23 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 17CF716A4CF; Sun, 27 Mar 2005 13:05:23 +0000 (GMT) Received: from f12.mail.ru (f12.mail.ru [194.67.57.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3B9543D31; Sun, 27 Mar 2005 13:05:22 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f12.mail.ru with local id 1DFXSH-000HDU-00; Sun, 27 Mar 2005 17:05:25 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Sun, 27 Mar 2005 17:05:25 +0400 From: Igor Shmukler To: Matthew Dillon Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Sun, 27 Mar 2005 17:05:25 +0400 In-Reply-To: <200502212147.j1LLlP7n010674@apollo.backplane.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org cc: rwatson@freebsd.org Subject: name cache (was Re[4]: vn_fullpath()) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Igor Shmukler 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:05:23 -0000 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.