[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration |
Date: |
Tue, 07 Sep 2010 17:20:44 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100720 Fedora/3.0.6-1.fc12 Thunderbird/3.0.6 |
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
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, (continued)
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Avi Kivity, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Avi Kivity, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Avi Kivity, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/12
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Avi Kivity, 2010/09/12
Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/07
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Kevin Wolf, 2010/09/07
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/07
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration,
Kevin Wolf <=
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/07
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Kevin Wolf, 2010/09/07
- Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Anthony Liguori, 2010/09/07
[Qemu-devel] Re: QEMU interfaces for image streaming and post-copy block migration, Daniel P. Berrange, 2010/09/07
Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration, Avi Kivity, 2010/09/12