Break metadata into smaller chunks (number of chunks=10) for faster delta generation.

Break metadata into smaller chunks (number of chunks=10) for faster delta generation.

Here are some data for comparison.

Without any metadata processing:
  Run Time:
    real 2m22.331s
    user 1m56.040s
    sys  0m6.170s
  Payload Size:
    756162 bytes

With metadata processing (number of chunks=4):
  Run Time:
    real 13m48.292s
    user 13m10.120s
    sys  0m6.920s
  Payload Size:
    749713 bytes

With metadata processing (number of chunks=10):
  Run Time:
    real 3m46.242s
    user 3m17.880s
    sys  0m6.640s
  Payload Size:
    748464 bytes

BUG=chromium-os:10669
TEST=Generated delta payloads between two images that do not have their
metadata preserved.  Ran the delta generator with and without metadata
processing and also used different number of chunks for comparison
purposes.

Change-Id: If7244e8414155043480ea9b0aea0a61b4abf8fe0

Committed: http://chrome-svn/viewvc/chromeos?view=rev&revision=4e8a306

[thieule, 2011-01-05 19:07:44]

I've changed the number of chunks to 10 to help make the delta generator run
faster between any two images, regardless if their metadata have been preserved.

PTAL

[petkov, 2011-01-05 19:47:43]

LGTM -- but is there any benefit in having this number be a power of two (e.g.,
8 or 16)?

[thieule, 2011-01-05 20:06:29]

On 2011/01/05 19:47:43, petkov wrote:
> LGTM -- but is there any benefit in having this number be a power of two
(e.g.,
> 8 or 16)?

Not really.  The metadata in this case are the block groups.  Within a block
group, the metadata (bg descriptor, bitmaps, inode table, etc) are packed on a
block boundary.  The number of blocks for each metadata is based on the size of
the partition and is not necessarily a power of two.  The num_chunks is used to
compute the number of blocks per chunk.

[sosa, 2011-01-05 20:32:16]

Thanks for making this change.  It'll make some of our builders much
happier campers I'm sure.

On Wed, Jan 5, 2011 at 12:06 PM,  <thieule@chromium.org> wrote:
> On 2011/01/05 19:47:43, petkov wrote:
>>
>> LGTM -- but is there any benefit in having this number be a power of two
>
> (e.g.,
>>
>> 8 or 16)?
>
> Not really.  The metadata in this case are the block groups.  Within a block
> group, the metadata (bg descriptor, bitmaps, inode table, etc) are packed on
> a
> block boundary.  The number of blocks for each metadata is based on the size
> of
> the partition and is not necessarily a power of two.  The num_chunks is used
> to
> compute the number of blocks per chunk.
>
> http://codereview.chromium.org/6011014/
>

[adlr, 2011-01-05 20:34:05]

LGTM

On Wed, Jan 5, 2011 at 12:32 PM, Chris Sosa <sosa@chromium.org> wrote:

> Thanks for making this change.  It'll make some of our builders much
> happier campers I'm sure.
>
> On Wed, Jan 5, 2011 at 12:06 PM,  <thieule@chromium.org> wrote:
> > On 2011/01/05 19:47:43, petkov wrote:
> >>
> >> LGTM -- but is there any benefit in having this number be a power of two
> >
> > (e.g.,
> >>
> >> 8 or 16)?
> >
> > Not really.  The metadata in this case are the block groups.  Within a
> block
> > group, the metadata (bg descriptor, bitmaps, inode table, etc) are packed
> on
> > a
> > block boundary.  The number of blocks for each metadata is based on the
> size
> > of
> > the partition and is not necessarily a power of two.  The num_chunks is
> used
> > to
> > compute the number of blocks per chunk.
> >
> > http://codereview.chromium.org/6011014/
> >
>