On Tue 20 Feb 2018 08:40:43 PM CET, Eric Blake wrote:
>> Compressed Clusters Descriptor (x = 62 - (cluster_bits - 8)):
>
> I'm looking at how this works for different cluster sizes. If we have
> 512-byte clusters, x is 61, and we DON'T have the 'number sectors'
> field at all!
Well, you can definitely have compressed images with 512-byte clusters.
So I think he have just found one more mistake in the documentation :)
(x = 62 - (cluster_bits - 8)):
Bit 0 - x: Host cluster offset.
x+1 - 61: Number of 512-byte sectors
That's not how it works, it's rather [0, x-1], [x, 61]. For 512-byte
clusters x is 61 and we have 1 bit for the number of sectors, allowing
one or two sectors.
If you have a compressed image with 512-byte clusters you can also see
that since the compressed data is not aligned, some compressed clusters
span two different sectors (as expected).
That means that nb_csectors in the L2 entry is two (1+1), which is the
maximum allowed in this case, so that makes sense. And since the size of
our clusters is also 512 bytes, nb_csectors is twice the cluster size,
so we need s->cluster_data to be (cluster_size * 2) bytes (minus one,
strictly speaking).
> If we ever allowed a compressed cluster to spill across two host
> clusters, it would cause mayhem in trying to track refcounts and other
> things.
I haven't checked how this works in practice but it seems to work fine.
Note that those clusters are read-only so that surely makes things
easier.
Berto
