[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration



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.

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.

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.

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.

Regards,

Anthony Liguori

Kevin


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]