On 24.03.20 18:42, Eric Blake wrote: > My proposal [1] to add an autoclear all-zero-content bit to the qcow2 > format has now stalled into 5.1 territory, but several patches in my > initial proposal are uncontroversial and obvious bug fixes worth > having in 5.0. > > [1] https://lists.gnu.org/archive/html/qemu-devel/2020-01/msg08075.html > > Eric Blake (4): > qcow2: Comment typo fixes > qcow2: List autoclear bit names in header > qcow2: Avoid feature name extension on small cluster size > sheepdog: Consistently set bdrv_has_zero_init_truncate
OK, so my only real gripe was with the question whether we could make patch 3 decide dynamically when to include or not include the feature name table. There’s little difference in practice: Right now, we could probably get away with including it in images with 4k clusters, then it would automatically switch to 8k clusters minimum (which is the limit chosen in patch 3 as-is), and at some theoretical point in the far, far future it would switch 16k clusters minimum. I don’t think anyone really cares about whether the feature name table is in images with 4k clusters or not, and I think we still have a couple of decades before we the table gets too big for images with 8k clusters (and we probably won’t be using qcow2 then anymore). So tl;dr: There’s no practical benefit of deciding dynamically, hence I’m taking this series as-is: https://git.xanclic.moe/XanClic/qemu/commits/branch/block Thanks! Max
signature.asc
Description: OpenPGP digital signature
