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

[Fam Zheng <famz@redhat.com>]

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?

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