From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 31 15:48:50 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org 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 D380D16A41F for ; Mon, 31 Oct 2005 15:48:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4187343D45 for ; Mon, 31 Oct 2005 15:48:50 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 436E246B06; Mon, 31 Oct 2005 10:48:47 -0500 (EST) Date: Mon, 31 Oct 2005 15:48:47 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Scott Long In-Reply-To: <43663B6C.5020804@samsco.org> Message-ID: <20051031154701.C80645@fledge.watson.org> References: <43633948.5030801@paradise.net.nz> <43663443.2090802@centtech.com> <43663B6C.5020804@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org, Eric Anderson , Mark Kirkwood Subject: Re: Display files currently in the buffer cache X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2005 15:48:50 -0000 On Mon, 31 Oct 2005, Scott Long wrote: >>> Assuming not, is it feasible to write one to do this? (if so, any >>> pointers appreciated - massive FreeBSD internals newbie here....). >> >> This would be a cool tool! I've been thinking of that too, and also >> would like to have a lkdump tool - which dumps information about >> currently locked files. > > Does the FreeBSD VM really have a concept of filenames at all? I > thought that all it understood was buffer objects and vnodes. And since > there isn't a strong correlation between vnodes and the filesystem > namespace, it would be hard to provide such information. The usual work-arounds are either to assume this explicitly, showing device numbers and inodes, or to give it a best effort shot (use the name cache). Either way, the results are still likely to be useful. You'll get some obvious messes, such as the results of installworld deleting old libraries and running processes continuing to use the deleted ones, resulting in an inode number that doesn't have a name that can be found. The same approach is taken in lsof, whereby "good enough" is generally good enough. The problems start when assumptions are made that paths can always be found. Robert N M Watson