Am 12.10.2011 14:51, schrieb Stefan Hajnoczi: >> Also a bit in l2 offset to say "there is no l2 table" cause all >> clusters in l2 are contiguous so we avoid entirely l2. Obviously this >> require an optimization step to detect or create such condition. > > There are several reserved L1 entry bits which could be used to mark > this mode. This mode severely restricts qcow2 features though: how > would snapshots and COW work? Perhaps by breaking the huge cluster > back into an L2 table with individual clusters? Backing files also > cannot be used - unless we extend the sub-clusters approach and also > keep a large bitmap with allocated/unallocated/zero information. > > A mode like this could be used for best performance on local storage, > where efficiently image transport (e.g. scp or http) is not required. > Actually I think this is reasonable, we could use qemu-img convert to > produce a compact qcow2 for export and use the L2-less qcow2 for > running the actual VM. > > Kevin: what do you think about fleshing out this mode instead of sub-clusters?
I'm hesitant to something like this as it adds quite some complexity and I'm not sure if there are practical use cases for it at all. If you take the current cluster sizes, an L2 table contains 512 MB of data, so you would lose any sparseness. You would probably already get full allocation just by creating a file system on the image. But even if you do have a use case where sparseness doesn't matter, the effect is very much the same as allowing a 512 MB cluster size and not changing any of the qcow2 internals. (What would the use case be? Backing files or snapshots with a COW granularity of 512 MB isn't going to fly. That leaves only something like encryption.) Kevin
