Disk cache: Add support for having a sparse entry block that...

Disk cache: Add support for having a sparse entry block that
is not totally filled. This is required to allow two
consecutive writes to fill a given range without caring
about the actual start offset of the second one (as long as
it is right where the first one ended).

This CL also takes care of all pending TODOs of the sparse
disk cache. Sparse disk cache support is now feature
complete.

BUG=12258
TEST=unittests


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=20988

[Alpha Left Google, 2009-07-15 23:32:41]

LGTM.

My only concern is that in SparseControl, a lot of operations are strongly tied
to block size and entry size that you do >> 10 and << 10, but yet there's
kBlockSize and kMaxEntrySize defined. It's fine if we never will change these
numbers.. or we can define some inline methods to do this? It's up to you if you
prefer this way.

I see in EntryTest we have CleanupSparseEntry, do you want me to write one for
memory only cache?

[rvargas (doing something else), 2009-07-16 00:49:24]

On 2009/07/15 23:32:41, Alpha wrote:
> LGTM.
> 
> My only concern is that in SparseControl, a lot of operations are strongly
tied
> to block size and entry size that you do >> 10 and << 10, but yet there's
> kBlockSize and kMaxEntrySize defined. It's fine if we never will change these
> numbers.. or we can define some inline methods to do this? It's up to you if
you
> prefer this way.

yeah, I thought about it. The truth is that the constants are there not to allow
parametrization but to reduce the chance of bugs due to typos. 

> I see in EntryTest we have CleanupSparseEntry, do you want me to write one for
> memory only cache?

not particularly. It is important for the disk cache because we have to deal
with stuff that comes from disk. You don't expose the sparse entries to the
caller so changes of corruption are minimal (if at all possible).

Thanks.

[Nicolas Sylvain, 2009-07-17 19:15:23]

LGTM