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

[Kirill Batuzov]

On Tue, 12 Aug 2014, Fam Zheng wrote:

> On Mon, 08/11 19:38, 吴兴博 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.
> 
> Hi! I think what you described is theoretically possible, but I'm not so
> positive about this feature. What would be the advantages, compared to qcow2?
> 

I think this idea was exploited in FVD format. The research paper
reported a large performance gain compared to qcow2. The patches can be
found in the mailing list archives (feb. 2011).

http://wiki.qemu.org/Features/FVD

> My major concern is that the file system hole's transparency, meaning that the
> users normally can't tell if a "hole" is really zeroes or unallocated, would
> cause data loss more easily: the user may expect scp (1) or cp (1) to work on
> an image file, just as always, but these tools can legitimately fill the whole
> with actual zeroes, if the target is filesystem does not supporting hole.
> That's too dangerous but totally out of control of QEMU.
> 
> Fam
> 
>

-- 
Kirill