Path: utzoo!attcan!uunet!nwnexus!amc-gw!quick!srg From: srg@quick.com (Spencer Garrett) Newsgroups: comp.arch Subject: Re: Sun bogosities, including MMU thrashing Message-ID: <1991Jan25.185333.607@quick.com> Date: 25 Jan 91 18:53:33 GMT References: <1991Jan10.214122.9506@news.arc.nasa.gov> Organization: Quicksilver Engineering, Seattle USA Lines: 23 In article , pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > This greatly complicates life, especially as the kernel, up to SunOS 3, > has a cache of blocks. Having variable block sizes means having variable > buffer sizes (which complicates life quite a bit, as you must then put > the buffer cache in virtual memory). Each buffer is described by a > buffer header, and now this not only contains its address but also the > block size. 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.