Re: Fixing bug #7

From: Henrik Nordstrom <henrik_at_henriknordstrom.net>
Date: Tue, 25 Aug 2009 14:33:41 +0200

ons 2009-08-26 klockan 00:01 +1200 skrev Amos Jeffries:

> Hmm, I'm thinking there should not be too much functional change to make
> this fix Bug-7 in a slightly better way than squid-2 did.

Oh, but there is...

all this change does is to allow older objects to get back into memory.
It does not change how in-memory objects gets updated with new info.
This change does not make fixing bug #7 any easier or harder.

> What if:
> promoted objects had their disk copy dropped when the memory copy
> changes? that gets halfway there. if nothing else it will make Squid
> fetch a clean new copy next time after the memory copy dies.

And what about the objects which never get promoted back into memory?

> if changed memory-promoted objects could get 'demoted' to a new disk
> filenumber that would solve bug-7 fully for the promotable objects.

Yes, but you would still need to solve it for the other objects.

> side case would be the ones that don't get promoted. they are still
> screwed over for now.

Exactly.

> Of have I got the disk/memory interaction overview completely screwed in
> my head?

Only partially.

For disk objects the cache_mem is seen as a shadow copy, not as a
replacement. Depending on timing, object size and access pattern a
single client may access both.

The big change here is to actually write these objects out to disk
again, and is what the Squid-2 approach does by looping the data into a
new StoreEntry. Changing the cache to do the same while keeping the same
StoreEntry requires fairly substantial surgery to the disk cache
interface, which is actually unrelated to the in-memory update, and
requires a different swapout mechanism than used today, swapping out the
parsed headers and not the raw received data as done today..

Currently the in-memory updated objects is inconsistent, with parsed
headers being updated but the raw object data is still the original data
we once upon a time received from the network. The swapout knows nothing
about headers and just swaps out the raw object data as-is, with a
little meta header added infront (the TLV area).

Regards
Henrik
Received on Tue Aug 25 2009 - 12:33:47 MDT

This archive was generated by hypermail 2.2.0 : Tue Aug 25 2009 - 12:00:06 MDT