Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!usc!apple!agate!shelby!portia.stanford.edu!elaine19.stanford.edu!dhinds From: dhinds@elaine19.stanford.edu (David Hinds) Newsgroups: comp.arch Subject: Re: Sun bogosities, including MMU thrashing Message-ID: <1991Jan26.201339.22366@portia.Stanford.EDU> Date: 26 Jan 91 20:13:39 GMT References: <1991Jan25.185333.607@quick.com> Sender: news@portia.Stanford.EDU (Mr News) Organization: Stanford University - AIR Lines: 27 In article <1991Jan25.185333.607@quick.com> srg@quick.com (Spencer Garrett) writes: >In article , > pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > >You've made an incorrect assumption here, and the rest of your story >about the buffer cache bogosities therefore falls wide of the mark. >The buffer cache is a *disk* cache, not a *file* cache. Each buffer >and its associated buffer header handle a fixed-size chunk of disk >which may or may not be related to the filesystem blocksize on that disk. >When the filesystem code gets a transfer request (read or write) it >translates the file offset into an absolute sector number and >*then* goes to the disk cache to find that sector (for efficiency's >sake it actually does ranges of sectors at a time, but the idea >is the same). Remember that you can read the disk directly, without >going through the filesystem, and still use the buffer cache. This >is what the "cooked" disk device is for. Lots of files are smaller >than 8k, and one disk buffer may well hold several of them. But how often would you actually want those particular small files that just happened to be in the same disk blocks that were read in for some other purpose? OK, so the extra stuff stored in the buffer cache isn't guaranteed to be useless, but in practice, it would seem to have very little value. Or is the file system smart enough to group tiny files together based on correlations in their access patterns? -David Hinds dhinds@cb-iris.stanford.edu