Am 26.01.2016 um 04:16 hat Fam Zheng geschrieben: > On Mon, 01/25 12:16, Kevin Wolf wrote: > > Am 25.01.2016 um 03:26 hat Fam Zheng geschrieben: > > > Commit d62d9dc4b8 lifted streamOptimized images's version to 3, but we > > > now refuse to open version 3 images read-write. We need to make > > > streamOptimized an exception to allow converting to it. This fixes the > > > accidentally broken iotests case 059 for the same reason. > > > > > > Signed-off-by: Fam Zheng <f...@redhat.com> > > > > How different are version 3 images for other subformats? Are we > > arbitrarily restrictring their use or is it really that they don't work > > with our driver? And if they don't work with our driver, are we sure > > that streamOptimized images can't use the features we don't support? > > > > Or is the version defined per subformat and doesn't necessarily exist > > for other types? > > Version 3 images are undocumented except in the VMware KB article mentioned in > the comment around this line (http://kb.vmware.com/kb/2064959). A few years > ago, when users complained that QEMU doesn't support version 3 images, we > presumed from the article that reading is okay, as the new feature is > "persistent changed block tracking" (although it didn't say it is the only > feature enabled by version 3), and went ahead enabling it. > > This time, it seems newer VMware products only accept version 3 if the > subformat is streamOptimized. Again, without any documentation/specification > update. Then our users complains again, so we add another exception to > mitigate. As this subformat doesn't allow overwrite, the only use case is > qemu-img converting to it. So this is pretty safe - it's always operating a > new image - and the approach is tested by multiple users (both upstream and > downstream).
I see. Then I guess we can't do much else. Thanks, applied to the block branch. Kevin