On Wed 22 Apr 2020 08:09:53 PM CEST, Vladimir Sementsov-Ogievskiy wrote: >> There's currently an inconsistency now that I think of it: if an image >> has subclusters and QCOW_OFLAG_ZERO set then qcow2_get_cluster_type() >> returns QCOW2_CLUSTER_ZERO_* but qcow2_get_subcluster_type() returns >> QCOW2_SUBCLUSTER_INVALID. >> >> Two alternatives: >> >> - We add QCOW2_CLUSTER_INVALID so we get an error in both >> cases. Problem: any function that calls qcow2_get_cluster_type() >> should be modified to handle that. >> >> - We ignore QCOW_OFLAG_ZERO. Simpler, and it would allow us to use >> that bit in the future if we wanted. >> > > Hmm. Actually we don't check other reserved bits. But ZERO bit is > risky, we may miss data corruptions during transmission to the > qcow2-subclusters world.
That's the best argument for checking that bit. > So I'm for the first variant if it's not too huge. The other problem is that if we ever want to use that bit for something else then we would need to add an incompatible feature. If we just ignore it now then we may be able to make it a compatible feature. But the chances for that are low I think, and we still have 8 available bits in the L2 entry. Berto
