From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) Subject: Re: File system issues! Date: Thu, 9 Jul 1992 11:48:35 GMT
In article <1992Jul9.082537.19043@daffy.cs.wisc.edu> quale@saavik.cs.wisc.edu (Douglas E. Quale) writes:
: In article <710630507.F00090@remote.halcyon.com> Rob.Levin@f217.n3802.z1.fidonet.org (Rob Levin) writes:
: >
: >2) Caching. It should be possible to turn on and off the write-back
: >portion of caching, both as a default at system startup time, and
: >dynamically.
:
: I'm afraid that this is unacceptable. There is already such an OS that
: runs on more even hardware than Linux does. You guessed it -- its name is
: Mud. Err, I mean DOS. The first software that anyone gets when complaining
: of DOS's poor I/O performance is a disk cache "utility". I have never known
I have tried disk cache. Benchmarks programs are impressive but there is not
real improvement for real programs that need fast IO so I have never used it
any more. Better use RAMDISKs. They are more deterministic. Because MSDOS
cannot disable its cache, performace drops by 50%.
I have rarely seen people who uses cache for disks any more even
smartdrive for windows.
In fact the reason why MSDOS and CPM is undeniably more successful
than any operating system in the world is because it does not have write
cache, despite all its so called major disadvantage. Remember, just one
disadvantage can kill an OS.
: anyone with DOS disk cache software to disable the write cache (if available)
: just because it would be safer -- everyone wants faster, safety be damned.
Don't you realise that the cache is the cause of slow IO speed? Why do you think
BSD and SysV introduces raw & NONBLOCK , precisely for the reasons that cache
is slowing down sequential access. Don't you think that sequential access is
by far the most common high IO jobs, tar,fsck,dd, cat,more, compiling etc.
You may think that database processing benefits with fs caching, but
it does not. What really happens is that before accessing the required data,
a database program would load all index into RAM AND do the search there.
Once the index is found, it would go the the location of the data. In fact
the fs cache is slowing it down by half because it has to load the data into
the cache first. It may save time if there is not IO cache on the driver itself
and the same data is needed again. It is rare that the same data is needed.
We only need the data once in most cases.
:
: Seriously, losing caching on writes would hurt *a lot*. The real solution
: is clear documentation and a good fsck, run automatically by /etc/rc.
Do you think people could understand the documentation 100%. Don't you
think that people make mistakes even those that know what they are doing?
CAn fsck repair all demages? If this would improve performance,fine, but it
does not.
The real solution is to take out cache from fs completely. REplace it
with cache at the IO device itself or driver. There is already 64kbyte
cache at the hard-disk which can transfer data at maximum bus speed to
RAM. This bus speed can be increased to match RAM bandwidth because it is
not IO, rather real static RAM.
Common fs cache cannot cater for various devices. For example floppy
and hard-disk have different sectors per tracks. Even in systems with multiple
hard-disks may use different transfer mechanism for efficient use.
The fs cache is slowing it by 50% if you have RAMDISKS, or hard-disks
or floppy disks controllers that have cache, which is almost always the case
nowadays.
fs cache was developed when IO was very slow(no cache built) so
random trasfer can be improved consiserably. It is not true now becaus RAM
has become so cheap. In fact the IO cache can be larger than system RAM.
What about 16Mbyte for hard-disk cache.
: --
: Doug Quale
: quale@saavik.cs.wisc.edu
I would prepare another more technical discussion in article to be tittled:
take out file cache/buffer!