[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] block-raw: Allow pread beyond the end of growab
From: |
Christoph Hellwig |
Subject: |
Re: [Qemu-devel] [PATCH] block-raw: Allow pread beyond the end of growable images |
Date: |
Wed, 1 Jul 2009 13:37:26 +0200 |
User-agent: |
Mutt/1.3.28i |
On Wed, Jul 01, 2009 at 11:08:07AM +0200, Kevin Wolf wrote:
> raw-win32 is actually a good question, I haven't tested that one. I
> think nbd is used as a protocol rather than the format. qcow1/2 should
> work, don't know for other formats like VMDK.
>
> What is biting us here is that nobody has ever specified what the block
> driver functions are supposed to do. They exist because they are in the
> struct, their parameters have names that give a rough idea about their
> meaning and that's it. Who cares about special cases?
>
> That said, while implementing the the fix in bdrv_pwrite is going to be
> ugly, we could do it in bdrv_read. Maybe this is the best approach.
I have looked a bit at this area and it's even uglier than I expected.
First problem is our use of the growable flag - it's overloaded for two
different purposes: First we use it to allow growing files if they are
protocols and opened through bdrv_file_open. Which already seems broken
for host devices, but I'll need to test it.
Second inside qcow2 it allows reading/writing past any image internally
if bdrv_pwrite/bdrv_pread are called via
qcow_put_buffer/qcow_get_buffer. I think we'd be much more future-proof
if we make these flags to aio_read/aio_write to allow writing past the
image size.
Also none of this currently is easily testable as we don't expose
the growable flag through qemu-io.
And last not least I really hate how we tie up writing the VM metadata
into the block/image code. I think we should also allow writing it
into an external file with no ties to the image to allow offline
migration or savevm even on a plain file or more important LVM volume.