Re^2: ESDI controller recommendations

Vernon Schryver vjs at calcite.UUCP
Sun Sep 3 04:18:17 AEST 1989


In article <1989Sep01.104447.9573 at specialix.co.uk>, jpp at specialix.co.uk (John Pettitt) writes:
> Nope, the problem is that the writeback code in a normal *ix cache
> is pretty f*'d.

If you say so.  Async writes, sync writes, and write-behinds are a messy
way to attack the problem, but one would not want to give up any of them.

>                   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.

That's not how the machines I've seen running SVR3 behave.  Nor is it the
way the bdflush() kernel process in SVR3 is coded.  Many vendors in 1989
have straight SVR3 ports, or enough of SVR3 for the suits to prattle about.

>                                                       If the
> somebody was to fix the kernel code then thengs would improve 
> greatly.
> -- 
> 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

There's always room for improvement.  Vendors of "real" UNIX computers (i.e.
not just PC's) are doing things like "page flipping".  For many applications
that makes large caches in the either the kernel or controllers suboptimal.

Vernon Schryver
vjs at calcite.uucp       ...{pyramid,sgi}!calcite!vjs



More information about the Comp.unix.i386 mailing list