From owner-freebsd-hackers Sat Sep 14 20:44:50 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id UAA26915 for hackers-outgoing; Sat, 14 Sep 1996 20:44:50 -0700 (PDT) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id UAA26902 for ; Sat, 14 Sep 1996 20:44:45 -0700 (PDT) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.7.5/CET-v2.1) with SMTP id DAA12816; Sun, 15 Sep 1996 03:43:33 GMT Date: Sun, 15 Sep 1996 12:43:33 +0900 (JST) From: Michael Hancock To: Julian Assange cc: freebsd-hackers@freebsd.org Subject: Re: attribute/inode caching In-Reply-To: <199609141052.UAA25565@suburbia.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 14 Sep 1996, Julian Assange wrote: > > What is the present status of attribute/inode/directory caching under > freebsd? When performing a 'du' of even a relatively small hierarachy, > the second 'du' appears no faster than the first and the drive can be > heard to thrash around in exactly the same manner. There's a per-process directory cache that benefits things like 'ls' in large directories. It just stores the offset of the last successful search in the directory. If the next search is in the same directory then it starts at the cached offset. You can watch the namei cache and the per-process directory cache using systat -vmstat. The workings of the inode cache is a different story. Regards, Mike Hancock