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.
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.
Doing it this way has the additional advantage that you need no image format support for this, so we could implement copy-on-read for other formats, too.
To do it efficiently, it really needs to be in the format for the same reason that copy-on-write is part of the format.
Copy-on-write is not part of the format, it's a way of how to use this format. Backing files are part of the format, and they are used for both copy-on-write and copy-on-read. Any driver implementing a format that has support for backing files should be able to implement copy-on-read.
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. Kevin