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