Re: assertion failed: store_dir_diskd.c:839: "rb->flags.need_to_validate"

From: Adrian Chadd <adrian@dont-contact.us>
Date: Tue, 10 Jul 2001 16:46:25 +0800

On Tue, Jul 10, 2001, Andres Kroonmaa wrote:

> Another thing that bothers me is very slow and very cpu-eating CLEAN
> startup. It seems to me that mostly due to writing each storeentry
> individually to state.new as squid reads in swap.state. I can't see the
> need to write each sentry into .new as it goes. Instead I'd expect it to
> readin full swap.state, construct inmem storedb, and then writeout clean
> log in one shot into swap.state.clean. So I'd also propose doing so.

That is on my TODO list for the diskio branch. I did note that
if a disk file is opened for writing its opened for append also,
which may or may not be what people are after.

Unfortunately, with most things today it seems, I get around 80%
of the way through it and then get too busy to finish it.
Having the diskio branch *finished* would make these sorts of
changes much easier, since there's only one UFS branch (ufs),
and aufs/diskd are just ufs with a different type of disk IO..

(ObNote: the wall I hit is that storeRead/storeWrite buffers aren't
refcounted in any fashion, so there wasn't an easy way for the IO
layers to know whether the buffer was still valid. The only way around
this is to copy the data into local buffers and write those.
Which I will need to do to finish the diskd and (start the) posixaio
IO types.)

Adrian

-- 
Adrian Chadd			Yeah, for me its (XML) like the movie Titanic.
<adrian@creative.net.au>	  Everybody loves it.
				    I want to be different, so I hate it.
					--Duane Wessels
Received on Tue Jul 10 2001 - 02:46:31 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:06 MST