From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 29 01:05:25 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 7D90516A4CE; Tue, 29 Mar 2005 01:05:25 +0000 (GMT) Received: from f16.mail.ru (f16.mail.ru [194.67.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id D476643D46; Tue, 29 Mar 2005 01:05:24 +0000 (GMT) (envelope-from shmukler@mail.ru) Received: from mail by f16.mail.ru with local id 1DG5AU-0008eB-00; Tue, 29 Mar 2005 05:05:18 +0400 Received: from [24.185.245.215] by win.mail.ru with HTTP; Tue, 29 Mar 2005 05:05:18 +0400 From: Igor Shmukler To: Bruce M Simpson Mime-Version: 1.0 X-Mailer: mPOP Web-Mail 2.19 X-Originating-IP: [24.185.245.215] Date: Tue, 29 Mar 2005 05:05:18 +0400 In-Reply-To: <20050329000306.GD752@empiric.icir.org> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Message-Id: cc: hackers@freebsd.org cc: Robert Watson Subject: Re[2]: name cache cont. 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: Tue, 29 Mar 2005 01:05:25 -0000 Bruce, Thank you for your reply. If you could email me a tarball, I would appreciate it. I don't have that much practical experience with FreeBSD name cache. However, I had some expeirence with other systems. I think the big question here do other developers agree that name cache could use some work. Obviously everything here is IMHO. Solaris has a very straightforward scalable cache. The FreeBSD cache is not bad, but as far as I understand issues I mentioned are a side-effect of design desicions aiming to lower pressure on the cache. I would very much be interested to know what Jeff and everyone else thinks about this. Is there a desire within the people who have hands-on expereience maintaining this part of FreeBSD to change the cache. I need d_path() like functionality for a specific kernel module. Right now, to get away, a secondary cache is implemented by intercepting open(2)/close(2). To minimize the amount of memory this cache needs (and keep to code simple) a dedicated kernel thread gc'es duplicate names from this cache, i.e. if vn_fullpath() works delete name from secondary cache). It's ugly, but it works for now. I would rather FreeBSD takes care of this for us. I am willing to contribute if folks who know VFS well, think it's a worthy cause. Igor. > > On Mon, Mar 28, 2005 at 05:42:52PM +0400, Igor Shmukler wrote: > > For my purposes the Linux/DragonFly functionality is needed. > > > > Is there a way to know that once a patch that correctly resolves corner cases for > > vn_fullpath() (including name cache changes) exists it will be committed to the 5.x > > branch? > > Hey, I did some of this work quite some time ago. It is still floating > around in the archives. I'm more than happy for people with more vfs > knowledge than I to pick it up, review it, and commit it, but I don't > have free time to do this right now. > > BMS