Re^2: ESDI controller recommendations

John Pettitt jpp at specialix.co.uk
Fri Sep 1 20:44:47 AEST 1989


brad at looking.on.ca (Brad Templeton) writes:

>While cylinder or track caching is an eminently sensible idea that I
>have been waiting to see for a long time, what is the point in the
>controller or drive sotring more than that?

It's faster !

>Surely it makes more sense for the OS to do all other cache duties.
>Why put the 512K in your drive when you can put it in your system and
>bump your cache there?   Other than the CPU overhead of maintaining the
>cache within the OS, I mean.  I would assume the benefit from having
>the cache maintained by software that knows a bit about what's going
>on would outweigh this.

Nope, the problem is that the writeback code in a normal *ix cache
is pretty f*'d.   What happens when you increase the cache to say
3 MB is that is waits until a good chunk of it is dirty that writes
all the dirty pages out a sync time.   This causes the disk do be
effectivly dead for 10 seconds or mosre at a time, not an acceptable
situation.   If you use a controller like the DPT with a smaller
unix cache the sync is written to the controller cache and then
flushed to disk.  If any reads are requested while the controller
cache is being flushed these take priority so the system is not
hung up for the duration.

So to answere your question, adding cache to a *ix system (well
Xenix and UNIX 5.3.x 386) via more buffers don't help.  If the
somebody was to fix the kernel code then thengs would improve 
greatly.

>-- 
>Brad Templeton, Looking Glass Software Ltd.  --  Waterloo, Ontario 519/884-7473
-- 
John Pettitt, Specialix, Giggs Hill Rd, Thames Ditton, Surrey, U.K., KT7 0TR
{backbone}!ukc!slxsys!jpp    jpp%slxinc at uunet.uu.net     jpp at specialix.co.uk
Tel: +44-1-941-2564       Fax: +44-1-941-4098         Telex: 918110 SPECIX G
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<



More information about the Comp.unix.i386 mailing list