Return to BSD News archive
Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!mips!mips!zaphod.mps.ohio-state.edu!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!math.fu-berlin.de!hrz.tu-chemnitz.de!wutcd
From: wutcd@hrz.tu-chemnitz.de (Joerg Wunsch)
Subject: Re: Take out fs cache!
Message-ID: <wutcd.710795614@hrz.tu-chemnitz.de>
Sender: bin@hrz.tu-chemnitz.de (Owner of all binaries)
Organization: tu-chemnitz
References: <1992Jul9.141010.2324@ntuix.ntu.ac.sg>
Date: Fri, 10 Jul 1992 19:13:34 GMT
Lines: 52
in article <1992Jul9.141010.2324@ntuix.ntu.ac.sg>, Othman Ahmad
<eoahmad@ntuix.ntu.ac.sg> asks:
> Why was buffer cache introduced?
> ...
> The cache is only feasible if hard-disks are not cached themselves or the
> hard-disk cache is much slower than system RAM. However even in these
> circumstances, the no fs cache is still faster, by having cache at the
> IO driver. Having specialised cache for a particular device is better than
> having a general purpose one.
This opinion is only one side. It may become true when shuffling large
amounts of data, eg. if copying a large file into another partition of
the same disk.
On the other hand, consider a well-designed o/s, which is able of using
the _whole_ memory either as user's space, or as fs cache, on demand.
Together with a more intelligent update daemon (not a stupid one only
flushing all buffers twice a minute), which only flushes last recent used
buffers, file system performance may significantly increase, indeed.
Let's assume an average shell script on a not-overloaded system (ie.,
there's always a reasonable amount of memory available). This shell script
issues some commands, and if the resulting data exceeds some kilobytes
(so it could not be held in a shell variable), they will be written into
some temp file. Maybe, there's more than one such file, each some 100
kilobytes, and the last command takes them and processes them so the user
can view the result. This is surely a five-second task at all. Under the
mentioned circumstances, i'm sure, _no_ disk traffic will occur _at all_.
Though there will be inodes allocated, and `disk' blocks written, all
the data is kept in cache. At the end (since it's a well-designed shell
script), the temp files are being deleted, all buffers outdate and get
re-used on next disk i/o.
Maybe, something is simplified too much, but i guess it isn't totally
wrong...
btw:
It's incorrect to say that sequential disk access will be decreased by
the cache. Caching strategy should involve some kind of prefetch. This
is done quickly, since the data from contiguos blocks is in the hard-
disk's (or controller's) cache, but - in a multiprocessing environment -
next disk access may be from another process at another place on disk.
If then the former process gets its next piece of cpu time, it may con-
tinue reading sequential data, but will first get the prefetched data.
J"org Wunsch
--
J"org Wunsch joerg_wunsch%bonnie@hadrian.hrz.tu-chemnitz.de
Textil Computer Design GmbH
R"ahnitzgasse 18, D-O-8060 Dresden
If anything can go wrong, it will. (Murphy's Law)