From: Kevin Wolf <kwolf@redhat.com>
To: Robert Wang <wdongxu@linux.vnet.ibm.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>,
Ming M Shu <shuming@cn.ibm.com>,
qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] External COW format for raw images
Date: Tue, 19 Jul 2011 12:28:57 +0200 [thread overview]
Message-ID: <4E255C69.6040508@redhat.com> (raw)
In-Reply-To: <4E254D8E.6000601@linux.vnet.ibm.com>
Am 19.07.2011 11:25, schrieb Robert Wang:
> As you known, raw image is very popular,but the raw image format does
> NOT support Copy-On-Write,a raw image file can NOT be used as a copy
> destination, then image streaming/Live Block Copy will NOT work.
>
> To fix this, we need to add a new block driver raw-cow to QEMU. If
> finished, we can use qemu-img like this:
> qemu-img create -f raw-cow -o backing_file=ubuntu.img,raw_file=my_vm.img
> my_vm.raw-cow
Just one comment for the start: This is not only useful for raw (while
certainly being the most important case), but also for every other image
format for which qemu doesn't support backing files.
This means that we should look for a better name than raw-cow. I know,
it was me who introduced this, but only for lack of a better name.
> 1) ubuntu.img is the backing file, my_vm.img is a raw file,
> my_vm.raw-cow stores a COW bitmap related to my_vm.img.
>
> 2) If the entire COW bitmap is set to dirty flag then we can get all
> information from my_vm.img and can ignore ubuntu.img and my_vm.raw-cow
> from now.
>
> To implement this, I think I can follow these steps:
> 1) Add a new member to BlockDriverState struct:
> char raw_file[1024];
> This member will track raw_file parameter related to raw-cow file from
> command line.
Can't this be private to the COW driver? It certainly will have a
BDRVRawCowState or something like that.
> 2) * Create a new file block/raw-cow.c. It will be much more like the
> mixture of block/cow.c and block/raw.c.
>
> So I will change some functions in cow.c and raw.c to none-static, then
> raw-cow.c can re-use them.
I think it's better to keep drivers cleanly separated. If we really need
to share code, we should provide some sort of a library that is used by
both, but I doubt that it's required in this case.
What the driver should probably do, is to open the raw file internally
and keep a BlockDriverState of the raw file in its private structure.
For all accesses to the raw file, use the "official" interfaces of the
raw driver, like bdrv_aio_readv/writev.
> When read operation occurs, determine whether
> dirty flag in raw-cow image is set. If true, read directly from the raw
> file. After write operation, set related dirty flag in raw-cow image.
> And other functions might also be modified.
>
> * Of course, format_name member of BlockDriver struct will be "raw-cow".
> And in order to keep relationship with raw file( like my_vm.img) ,
> raw_cow_header struct should be
> struct raw_cow_header {
> uint32_t magic;
> uint32_t version;
> char backing_file[1024];
> char raw_file[1024];/* added*/
> int32_t mtime;
> uint64_t size;
> uint32_t sectorsize;
I don't think any of mtime, size and sectorsize are necessary. They will
just be taken from the raw file (if needed at all).
> };
> * Struct raw_cow_create_options should be one member plus based on
> cow_create_options:
> {
> .name = BLOCK_OPT_RAW_FILE,
> .type = OPT_STRING,
> .help = "Raw file name"
> },
>
> 3) Add bdrv_get_raw_filename in img_info function of qemu-img.c. In
> bdrv_get_raw_filename, if the format of the image file is "raw-cow",
> print the related raw file.
Hm... Won't be implemented by any other driver, but I guess it makes
some sense to provide this information.
Kevin
next prev parent reply other threads:[~2011-07-19 10:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-19 9:25 [Qemu-devel] External COW format for raw images Robert Wang
2011-07-19 9:55 ` Stefan Hajnoczi
2011-07-19 10:28 ` Kevin Wolf [this message]
2011-07-19 13:20 ` Anthony Liguori
2011-07-20 8:35 ` Stefan Hajnoczi
2011-07-20 15:57 ` Marcelo Tosatti
2011-07-26 10:16 ` Stefan Hajnoczi
2011-07-19 14:39 ` Frediano Ziglio
2011-07-20 7:27 ` Robert Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E255C69.6040508@redhat.com \
--to=kwolf@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=shuming@cn.ibm.com \
--cc=stefanha@linux.vnet.ibm.com \
--cc=wdongxu@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).