|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration |
Date: | Tue, 07 Sep 2010 10:30:04 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 |
On 09/07/2010 10:20 AM, Kevin Wolf wrote:
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.
But as a web site owner, it's extremely useful for me to associate copy-on-read with an image because it significantly reduces my bandwidth.
I have a hard time believing this isn't a valuable use-case and not one that's actually pretty common.
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.
N.B. the whole concept of compat features in QED is that if the features are ignored, the image is still perfectly readable. It's extra information that let's an implementation to smarter things with a given image.
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.
If we determine that having copy-on-read be a part of the image is universally a bad idea, then I'd agree with you. Keep in mind, I don't expect to merge the cor or streaming stuff with the first merge of QED.
I'm still not convinced that having cor as a compat feature is a bad idea though.
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)
Okay, the only place I'm disagreeing slightly is that I think an image format should be able to request copy_on_read such that the default behavior if an explicit flag isn't specified is to do what the image suggests we do.
Regards, Anthony Liguori
Kevin
[Prev in Thread] | Current Thread | [Next in Thread] |