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