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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list