Re: [Xen-devel] [PATCH] vhd-util create: add -C|nocow option

[Jim Fehlig <jfehlig@xxxxxxxx>]

Chunyan Liu wrote:
>
>
>
> 2013/11/22 Jim Fehlig <jfehlig@xxxxxxxx <mailto:jfehlig@xxxxxxxx>>
>
>     Ian Jackson wrote:
>     > Ian Campbell writes ("Re: [Xen-devel] [PATCH] vhd-util create:
>     add -C|nocow option"):
>     >
>     >> On Thu, 2013-11-21 at 15:46 +0800, Chunyan Liu wrote:
>     >>
>     >>> Add '-C' (nocow) option to vhd-util create.
>     >>>
>     >>> Btrfs has terrible performance when hosting VM images, even
>     more when the guest
>     >>> in those VM are also using btrfs as file system. One way to
>     mitigate this bad
>     >>> performance is to turn off COW attributes on VM files (since
>     having copy on
>     >>> write for this kind of data is not useful). According to
>     'chattr' manpage, NOCOW
>     >>> could be set to new or empty file only on btrfs, so add a
>     option here so that
>     >>> users could have a chance to set NOCOW to a vhd image.
>     >>>
>     >> Is there not some btrfs (or generic) utility which could be
>     used to do
>     >> this after image creation rather than trying to build it in to
>     every
>     >> utility which creates an image file?
>     >>
>     >
>     > This may seem like a daft question, but why do we even have a vhd
>     > utility in our tree ?  Is there not some vhd tools package that this
>     > should be in ?
>     >
>
>     Newer qemu-img supports vhd and vhdx right?  Is there even a need for
>     this tool at all anymore?
>
>
> 'qemu-img create' doesn't support creating vhd/vhdx format images.
> Only open/probe supported.

Ah, I didn't know that.  Is it possible to merge vhd-util with
qemu-img?  You could then support nocow with something like 'qemu-img
create -f vhd -o nocow, ...'.

But I tend to agree with Ian that supporting backing store-specific
features should be higher in the stack.  E.g. a libvirt filesystem
storage pool of type btrfs could support such features when creating
volumes from the pool.

Regards,
Jim

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel