*BSD News Article 1854


Return to BSD News archive

Newsgroups: comp.unix.bsd
Path: sserve!manuel!munnari.oz.au!uunet!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: Take out fs cache!
Message-ID: <1992Jul9.141010.2324@ntuix.ntu.ac.sg>
Organization: Nanyang Technological University - Singapore
Date: Thu, 9 Jul 1992 14:10:10 GMT
Lines: 76

Why was buffer cache introduced?
Quoted from Bach,M.J.:The design of the Unix Operating System.

i) uniform disk access for kernel, it does not have to know where.
Rebuff: The complexity which may be less in the kernel code would have to
be handled by other code. It is just inconceivable that we do not know where
the data is to be fetched from or sent to.
	If you just examine the getblk(), it still has to calculate where in
the cache the data has to come from.
	If there is no cache, everything would be even simpler. Less code.
Just allow the user to access form device directly via the kernel. The
user process sends the destination address, the kernel do block transfer from
 the device driver to the user-space directly without copying to
the cache first. Would not the code be simpler because there is less work
to do.

ii)no data alignment restrictions:
Rebuff: You can do the same without fs buffer cache. Just introduce 
device/driver cache. All hard-disks now have built in cache.

iii)can reduce disk traffic:
Only for randowm access. It becomes worse for sequential access.
Large IO tasks are more frequently sequential and this is the most obvious
performance limitation. Random accesses almost always transfer small 
amount of data.
	For large random access we may need index files which are best
stored in RAM. Once the index is in RAM, the cache would reduce performance by
half, unless the data is already there. Usually users need data only once,
why should we penalise the whole system for infrequently used operation.
	For IO with cache there is 50% penalty for sequential access of large
data, unless there is a mechanism to disable the cache.The reason is that
data needs to be loaded to the cache first before being sent to the user.
The penaly is minimal if the hard-disk is very slow but for RAMDISKS or
disks with cache, this penalty rises to 50%.
 That means the fs cache let us down when we really need it.
	Also the penalty increases if the hard-disk is cached.
iii) The buffer help ensure file system integrity by serialising access:
If every transfer is controlled by the kernel, the integrity can still be
maintained even without the cache.

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.
	I bet that given the same amount of cache, the specialised IO
cache would outperform an fs cache under similar conditions. Any
data on this?

	I think the most valid reason for fs cache is the one described by
A.S. Tanembaum in his book Design and Implementation of OS.
	 In a microkernel,
it would be better to modularise the design by letting the fs control the
data transfer even at the expense of speed. The kernel is supposed to be
a separate process.
	The above reasoning is similar to Bach (i).
	The solution would be to allow the kernel master control over all
other processes although it has a separate state. It can manipulate the
other process' memory space. After all, the kernel is the master. A bug
in the kernel is a bug for all.
	This view is also good for hardware design. The kernel mode is 
equivalent to the real mode in X86 architecture. It is used for bootstrap 
before going into protected mode.
	The device drivers can be at separate processes.
	HOwever I do not know much about threads.

For another angle of explanation please refer to my article at comp.unix.linux:
Issues in Fs.


--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet