Re: [Qemu-devel] disk image: self-organized format or raw file

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, Aug 11, 2014 at 07:38:50PM -0400, 吴兴博 wrote:
> Hello,
> 
>   The introduction in the wiki page present several advantages of qcow2
> [1]. But I'm a little confused. I really appreciate if any one can give me
> some help on this :).
> 
>  (1) Currently the raw format doesn't support COW. In other words, a raw
> image cannot have a backing file. COW depends on the mapping table on which
> we it knows whether each block/cluster is present (has been modified) in
> the current image file. Modern file-systems like xfs/ext4/etc. provide
> extent/block allocation information to user-level. Like what 'filefrag'
> does with ioctl 'FIBMAP' and 'FIEMAP'. I guess the raw file driver (maybe
> block/raw-posix.c) may obtain correct 'present information about blocks.
> However this information may be limited to be aligned with file allocation
> unit size. Maybe it's just because a raw file has no space to store the
> "backing file name"? I don't think this could hinder the useful feature.
> 
>  (2) As most popular filesystems support delay-allocation/on-demand
> allocation/holes, whatever, a raw image is also thin provisioned as other
> formats. It doesn't consume much disk space by storing useless zeros.
> However, I don't know if there is any concern on whether fragmented extents
> would become a burden of the host filesystem.
> 
>  (3) For compression and encryption, I'm not an export on these topics at
> all but I think these features may not be vital to a image format as both
> guest/host's filesystem can also provide similar functionality.
> 
>  (4) I don't have too much understanding on how snapshot works but I think
> theoretically it would be using the techniques no more than that used in
> COW and backing file.
> 
> After all these thoughts, I still found no reason to not using a 'raw' file
> image (engineering efforts in Qemu should not count as we don't ask  for
> more features from outside world).
> I would be very sorry if my ignorance wasted your time.

FWIW, much of what you say about features supported in filesystems is
correct, however, that is only considering the needs of deployment on
your specific platform. One value of QCow2 is that it is a portable
format you can use on any platform where QEMU builds, whether it be
Linux, Windows, *BSD or Solaris. If you were to rely on the host
filesystem then obviously you'd have to figure out the different
solution for the particular OS you deploy on.

Taking the compression feature - arguably the biggest benefit of that
is when you distribute disk images. eg if someone provides a root disk
image on a web server, using compression in qcow2 can dramatically
lower the download size, while still allowing QEMU to directly run
from that qcow2 file. Sure you could wrap your disk images in gzip
and then convert to your local filesystem at time of use but this
introduces multiple extra steps.

There's similar arguments for other features in qcow2. That's not to
say you are wrong in your analysis of your own needs. It is simply a
case that different scenarios imply different solutions, so for some
qcow2 may be optimal, while for others using native filesystem features
might be better

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|