Re: compute swap_file_sz before packing it

From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
Date: Tue, 27 Oct 2009 21:41:45 +0100

tis 2009-10-27 klockan 13:43 -0600 skrev Alex Rousskov:

> Hi Henrik,
>
> Can you explain what you mean by "just ignore" above? It is kind of
> difficult for me to ignore the only code that seems to supply the info
> Rock store needs. Do you mean we should ultimately remove STORE_META_STD
> from Squid, replacing all its current uses with STORE_META_OBJSIZE?

The object size field in STORE_META_STD should be ignored. Got broken
many years ago (1997 or so), and should be recalculated by using
STORE_META_OBJSIZE or alternatively the on-disk object size.

> Moreover, STORE_META_OBJSIZE has the following comment attached to its
> declaration: "not implemented, squid26 compatibility" and appears to be
> unused...

Right.. should be forward ported. [attached]

> Neither approach works for Rock store because Rock store does not have a
> swap state file like COSS and does not use individual files like UFS.
> That is why it has to rely on the "file" size information supplied by
> the core. Perhaps there is a better way of getting that information, but
> I do not know it.

STORE_META_OBJSIZE is the object size (if known) not including TLV
headers, and is generally what you need to know in order to access the
object.

Long term objects should be split in TLV + HTTP Headers (probably part
of TLV) + Content, but that's another topic..

Actual file storage size is more a business of the cache_dir than the
core..

> > + // so that storeSwapMetaBuild/Pack can pack corrent swap_file_sz
> > + swap_file_sz = objectLen() + mem_obj->swap_hdr_sz;
> > +

objectLen() MAY be -1 here...

Regards
Henrik

Received on Tue Oct 27 2009 - 20:41:51 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 28 2009 - 12:00:05 MDT