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

[Xingbo Wu <wuxb45@gmail.com>]

On Wed, Aug 13, 2014 at 11:54 AM, Kevin Wolf <kwolf@redhat.com> wrote:
> Am 12.08.2014 um 01:38 hat 吴兴博 geschrieben:
>> 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.
>
> Even if it did work (that it's problematic is already discussed in other
> subthreads) what advantage would you get from using an extended raw
> driver compared to simply using qcow2, which supports all of this today?
>
> Kevin


I read several messages from this thread: "[RFC] qed: Add QEMU
Enhanced Disk format". To my understanding, if the new format can be
acceptable to the community:
  It needs to retain all the key features provided by qcow2,
especially for compression, encryption, and internal snapshot, as
mentioned in that thread.
  And, needless to say, it must run faster.

Yes I agree it's at least a subset of the homework one need to do
before selling the new format to the community.

Thanks and another question:
What's the magic that makes QED runs faster than QCOW2? In some simple
parallel IO tests QED can run a magnitude faster than QCOW2.  I saw
differences on simple/complex metadata organization, and coroutine/aio
(however "bdrv_co_"s finally call "bdrv_aio_"s via "_em". If you can
provide some insight on this I would be really appreciate.


-- 

Cheers!
       吴兴博  Wu, Xingbo <wuxb45@gmail.com>