Date: Sun, 15 Sep 1996 12:15:52 +1000 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, terry@lambert.org Cc: freebsd-hackers@freebsd.org, proff@suburbia.net Subject: Re: attribute/inode caching Message-ID: <199609150215.MAA32073@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> >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. >> >> Wrong. Neither marking for update nor updating the access times requires >> writing anything. In FreeBSD, writing is a side affect of thrashing the >> caches and updating is often a side effect of writing. First, when the >> vnode cache thrashes, the vnodes have to be updated and written to the >> buffer cache. Second, when the buffer cache thrashes, the dirty buffers >> containing the vnodes have to be written out. They are usually written >> with delayed writes, so the writes need not more than double the overhead >> for the thrashing (probably much worse in practice because of seeks). > >If it weren't marked, it wouldn't be written. I stand behind my statement. 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). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609150215.MAA32073>