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