From owner-freebsd-hackers Sat Sep 14 15:03:26 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA10533 for hackers-outgoing; Sat, 14 Sep 1996 15:03:26 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA10523 for ; Sat, 14 Sep 1996 15:03:21 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA12694; Sat, 14 Sep 1996 15:00:33 -0700 From: Terry Lambert Message-Id: <199609142200.PAA12694@phaeton.artisoft.com> Subject: Re: attribute/inode caching To: proff@suburbia.net (Julian Assange) Date: Sat, 14 Sep 1996 15:00:33 -0700 (MST) Cc: freebsd-hackers@freebsd.org In-Reply-To: <199609141052.UAA25565@suburbia.net> from "Julian Assange" at Sep 14, 96 08:52:24 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. POSIX mandates that the access time will be marked for update when you read the directory; thus it's written out, and the thrashing is expected. One issue which is a big one in my book is that only data hung off a vnode is cached in the buffer cache. The caching is by inode/extent rather than by device/extent. The net result of this will be that the inode data itself will not be cached. There is a "second chance" ihash cache in FFS; other FS's are not so lucky; thus your performance will depend on number of elements before the hash overflows and whether or not you are testing FFS or some other FS. For instance, expect EXT2FS to have significantly worse performance under BSD. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.