From owner-freebsd-hackers Mon Sep 16 13:19:25 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA04686 for hackers-outgoing; Mon, 16 Sep 1996 13:19:25 -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 NAA04679 for ; Mon, 16 Sep 1996 13:19:23 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id NAA02780; Mon, 16 Sep 1996 13:18:39 -0700 From: Terry Lambert Message-Id: <199609162018.NAA02780@phaeton.artisoft.com> Subject: Re: attribute/inode caching To: bde@zeta.org.au (Bruce Evans) Date: Mon, 16 Sep 1996 13:18:38 -0700 (MST) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@FreeBSD.org, proff@suburbia.net In-Reply-To: <199609150215.MAA32073@godzilla.zeta.org.au> from "Bruce Evans" at Sep 15, 96 12:15:52 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 > If the buffer cache didn't thrash, then it would be written on the next > sync, much later. If in addition writes were ordered in block order, > then it would be written efficiently together with nearby dirty inodes. > Normally, ffs_sync() writes things in the semi-random vnode list order. > disksort() sorts the into block order, but this only helps if the disk > can't keep up with the i/o requests. > > Another way to look at it: consider traversing my /usr/src, which has > 21097 inodes and 2810 directories. if the cache thrashes (certain) > and the inodes are contiguous on disk (unlikely :-), then there will > be a 2637KB of reads and a whole 351KB of writes to update the atimes. > The write time should be relatively negligible if the cache is working > (more so, because you can schedule delayed writes but reads have to be > synchronous). Well, then, we are back to talking about implementing strategies, like write gathering, to clean up the mess. The problem, of course, is that since the cache is not device/offset (despite the discussion that claims blocks are hung of the device vnode to the contrary), then it is impossible to gather things which are physically contiguous, even though doing so would be a win. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.