NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/unix/ultrix/9115

Text File | 1992-12-29 | 3.1 KB | 66 lines

Newsgroups: comp.unix.ultrix
Path: sparky!uunet!decwrl!deccrl!news.crl.dec.com!dbased.nuo.dec.com!nntpd.lkg.dec.com!nntpd2.cxo.dec.com!nabeth!alan
From: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Subject: Re: Some buffer cache questions
Message-ID: <[e-mail]>
Lines: 53
Sender: alan@nabeth (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Reply-To: [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.)
Organization: Digital Equipment Corporation
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 30 Dec 1992 01:03:15 GMT


In article <[e-mail]>, [e-mail] (Roger Taranto) writes:
>
>In article <[e-mail]> [e-mail] (Alan Rollow - Alan's Home for Wayward Tumbleweeds.) writes:
>>[ I mention large buffer caches and delay_wbuffers ]
>
>So, what am I supposed to be watching the delay_wbuffers for?
>

This is a variable in param.c that has two values, zero and non-zero.
The default is zero.  When set to zero the buffer cache code schedules
data writes as buffer are filled by the user.  These writes are
asynchronous.  When set to non-zero data buffers are only written
when explicitly flushed (fsync(2), sync(2), etc) or a buffer is
needed to satisfy a read and a dirty one is written to free up a buffer.

An affect of having delay_wbuffers set to a non-zero value is that
the cache will fill up between update's calls to sync(2) and then
every so often there will be a flurry of writes as all the dirty
buffer are flushed.  Another affect is that the cache may have a
lot of stale data sitting around in the cache between syncs, the
classic UNIX buffer cache problem.

For small caches this may be an interesting problem.  As you
increase the size of the cache there's the potential for more
stale data to be lost or more dirty that needs to be written
out.  The "flurry" of writes can look like blizzard with a
big enough cache.

Related to this thread, Greg Pavlov at karloff.fstrf.org asked
what sort of trouble I had with large cache configurations.  The
very large cache configuration I had was a 80% of 256 MB on a
DECsystem 5800.  I believe it was a single CPU system.  Whether
it was an ULTRIX bug of the time, a 5800 specific problem or the
version of the Striping driver I was working on the time, the
system hung during one of my BIG cache flushes.  I had turned
off update and wanted to see how long it took to flush the
entire cache, after having filled it.  I wasn't able to reproduce
the hang.  I also vaguely recall having to come up with some
creative configuration lies to get a big enough system page
table to map a cache that big.

FWIW: The BIG cache flush probably took around 100 seconds.  I was
writing to a stripe set of RA90s all on an HSC70.  I was keeping the
HSC and CIBCA-BA VERY busy...  I'd love to try it on a VAX with a
CIXCD and two HSCs sometime...

>-Roger
>[e-mail]
>
--
Alan Rollow                [e-mail]