Am 07.09.2010 17:11, schrieb Anthony Liguori: > On 09/07/2010 10:02 AM, Kevin Wolf wrote: >> Am 07.09.2010 16:49, schrieb Anthony Liguori: >> >>>> Shouldn't it be a runtime option? You can use the very same image with >>>> copy-on-read or copy-on-write and it will behave the same (execpt for >>>> performance), so it's not an inherent feature of the image file. >>>> >>>> >>> The way it's implemented in QED is that it's a compatible feature. This >>> means that implementations are allowed to ignore it if they want to. >>> It's really a suggestion. >>> >> Well, the point is that I see no reason why an image should contain this >> suggestion. There's really nothing about an image that could reasonably >> indicate "use this better with copy-on-read than with copy-on-write". >> >> It's a decision you make when using the image. >> > > Copy-on-read is, in many cases, a property of the backing file because > it suggests that the backing file is either very slow or potentially > volatile. The simple copy-on-read without actively streaming the rest of the image is not enough anyway for volatile backing files. > IOW, let's say I'm an image distributor and I want to provide my images > in a QED format that actually streams the image from an http server. I > could provide a QED file without a copy-on-read bit set but I'd really > like to convey this information as part of the image. > > You can argue that I should provide a config file too that contained the > copy-on-read flag set but you could make the same argument about backing > files too. No. The image is perfectly readable when using COW instead of COR. On the other hand, it's completely meaningless without its backing file. >>> So yes, you could have a run time switch that overrides the feature bit >>> on disk and either forces copy-on-read on or off. >>> >>> Do we have a way to pass block drivers run time options? >>> >> We'll get them with -blockdev. Today we're using colons for format >> specific and separate -drive options for generic things. >> > > That's right. I think I'd rather wait for -blockdev. Well, then I consider -blockdev a dependency of QED (the copy-on-read part at least) and we can't merge it before we have -blockdev. >>> You need to understand the cluster boundaries in order to optimize the >>> metadata updates. Sure, you can expose interfaces to the block layer to >>> give all of this info but that's solving the same problem for doing >>> block level copy-on-write. >>> >>> The other challenge is that for copy-on-read to be efficiently, you >>> really need a format that can distinguish between unallocated sectors >>> and zero sectors and do zero detection during the copy-on-read >>> operation. Otherwise, if you have a 10G virtual disk with a backing >>> file that's 1GB is size, copy-on-read will result in the leaf being 10G >>> instead of ~1GB. >>> >> That's a good point. But it's not a reason to make the interface >> specific to QED just because other formats would probably not implement >> it as efficiently. > > You really can't do as good of a job in the block layer because you have > very little info about the characteristics of the disk image. I'm not saying that the generic block layer should implement copy-on-read. I just think that it should pass a run-time option to the driver - maybe just a BDRV_O_COPY_ON_READ flag - instead of having the information in the image file. From a user perspective it should look the same for qed, qcow2 and whatever else (like copy-on-write today) Kevin -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list