Am 16.08.2019 um 15:30 hat Alberto Garcia geschrieben: > On Fri 16 Aug 2019 02:59:21 PM CEST, Kevin Wolf wrote: > > The requirement so that this bug doesn't affect the user seems to be > > that the image size is a multiple of 64k * 8k = 512 MB. Which means > > that users are probably often lucky enough in practice. > > Or rather: cluster_size^2 / 8, which, if my numbers are right: > > |--------------+-------------| > | Cluster size | Multiple of | > |--------------+-------------| > | 4 KB | 2 MB | > | 8 KB | 8 MB | > | 16 KB | 32 MB | > | 32 KB | 128 MB | > | 64 KB | 512 MB | > | 128 KB | 2 GB | > | 256 KB | 8 GB | > | 512 KB | 32 GB | > | 1024 KB | 128 GB | > | 2048 KB | 512 GB | > |--------------+-------------| > > It get trickier with larger clusters, but if you have a larger cluster > size you probably have a very large image anyway, so yes I also think > that users are probably lucky enough in practice.
Yes, I assumed 64k clusters. The other somewhat popular cluster size is probably 2 MB, where I think images sizes that are not a multiple of 512 GB are rather likely... > (also, the number of cache tables is always >= 2, so if the image size > is less than twice those numbers then it's also safe) Right. I already corrected my statement to include > 1024 MB in the Red Hat Bugzilla (but still didn't consider other cluster sizes). > And yes, the odd value on the 512KB row on that we discussed last month > is due to this same bug: > > https://lists.gnu.org/archive/html/qemu-block/2019-07/msg00496.html Hm... And suddently it makes sense. :-) So I assume all of 512k/1024k/2048k actually perform better? Or is the effect neglegible for 1024k/2048k? Kevin