Re: 1.2b14 fun

--MimeMultipartBoundary
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Michael O'Reilly wrote:
>=20
> This is during a rebuild. Note that there's a bug in
> store*Validate*. It does a stat() on the object, and compares it to
> e->object_len, and it obviously doesn't match (the metadata headers).

Didn't duane say somthing about this some time ago? That the rebuild
process is not fully updated to support metadata in objects yet.

> Is it possible to make the metadata a fixed length? or store the meta
> data header size in *e somewhere? (so that checks like this can be
> made.. )

Making the meta data fixed size is not an viable option.
* The URL is a variable-sized,, a few bytes to several KB.
* We may need to extend with additional data later on.

> Could someone possibly explain why the metadata was added to the front
> of the objects?

There is much gained in keeping the metadata and the object together in
the same file, to protect against cache corruption, and ease of
understanding.

The problem is rather that Squid has to many assumptions on disk object
sizes and so on. When I tried to add the metadata to the objects I
stumbled on the following problems:

Approach 1: Add the metadata on swapout

How to adjust the object size? Here we have two different objects. One
disk object and one memory object, and a lot of checks based on the
object vs memobject sizes.

Approach 2: Add the metadata to the mem object when created

This felt like the best approach, but I got lost in several assertion
failures, and couldn't make head or tail of the problems.

I haven't had much time to investigate the current metadata code, but I
suspect that the problems are the same.

---
Henrik Nordstr=F6m
Sparetime Squid Hacker
--MimeMultipartBoundary--