Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!sgi!calcite!vjs
From: vjs@calcite.UUCP (Vernon Schryver)
Newsgroups: comp.unix.i386
Subject: Re: Re^2: ESDI controller recommendations
Summary: bdflush is not sync(2)/update
Message-ID: <67@calcite.UUCP>
Date: 2 Sep 89 18:18:17 GMT
References: <121@mdi386.UUCP> <1474@wb3ffv.ampr.org> <4843@looking.on.ca> <1989Sep01.104447.9573@specialix.co.uk>
Organization: Rhyolite Software, Mountain View, CA
Lines: 28

In article <1989Sep01.104447.9573@specialix.co.uk>, jpp@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@uunet.uu.net     jpp@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@calcite.uucp       ...{pyramid,sgi}!calcite!vjs