Date: Mon, 16 Sep 1996 13:18:38 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bde@zeta.org.au (Bruce Evans) Cc: bde@zeta.org.au, terry@lambert.org, freebsd-hackers@FreeBSD.org, proff@suburbia.net Subject: Re: attribute/inode caching Message-ID: <199609162018.NAA02780@phaeton.artisoft.com> In-Reply-To: <199609150215.MAA32073@godzilla.zeta.org.au> from "Bruce Evans" at Sep 15, 96 12:15:52 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609162018.NAA02780>