Am 15.11.2018 um 19:34 hat Eric Blake geschrieben: > Although off_t permits up to 63 bits (8EB) of file offsets, in > practice, we're going to hit other limits first. Document some > of those limits in the qcow2 spec (some are inherent, others are > implementation choices of qemu), and how choice of cluster size > can influence some of the limits. > > While we cannot map any uncompressed virtual cluster to any > address higher than 64 PB (56 bits) (due to the current L1/L2 > field encoding stopping at bit 55), qemu's cap of 8M for the > refcount table can still access larger host addresses for some > combinations of large clusters and small refcount_order. For > comparison, ext4 with 4k blocks caps files at 16PB. > > Another interesting limit: for compressed clusters, the L2 layout > requires an ever-smaller maximum host offset as cluster size gets > larger, down to a 512 TB maximum with 2M clusters. In particular, > note that with a cluster size of 8k or smaller, the L2 entry for > a compressed cluster could technically point beyond the 64PB mark, > but when you consider that with 8k clusters and refcount_order = 0, > you cannot access beyond 512T without exceeding qemu's limit of an > 8M cap on the refcount table, it is unlikely that any image in the > wild has attempted to do so. To be safe, let's document that bits > beyond 55 in a compressed cluster must be 0. > > Signed-off-by: Eric Blake <ebl...@redhat.com> > > --- > v9: Yet more wording tweaks, to call out the difference between > inherent (L2 reserved bit) and implementation (qemu's 32M L1 and > 8M refcount) limits. > > Designed to replace commit 1da4dc02 on Kevin's block branch.
Thanks, replaced the commit. Kevin
