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

[Fam Zheng]

On Tue, 08/12 06:46, 吴兴博 wrote:
> Hi Fam,
>   It's glad to hear you,
> It is said in this post that "All files systems that support inodes
> (ext2/3/4, xfs, btfs, etc) support files with holes while creating the
> files..."
> [
> http://serverfault.com/questions/558761/best-linux-filesystem-for-sparse-files
> ]
> 
> I also heard this claim from other sources, and the only "popular"
> filesystems who don't support holes in real world are just the old FAT32
> and other FAT*.
> Note that holes appear in filesystems when creating a sparse file in
> inode-filesystems. While "punching holes" does remove the existent contents
> from the file, and it was  newly added to only xfs/ext4 in newer linux
> kernel.
> 
> In qemu's disk image, a hole delivers clear message---the corresponding
> sectors/blocks/clusters are never written. So it's up to the guest whether
> to initialize the sectors to zero or just ignore them (filesystems never
> confuse with a uninitialized sector right?). Filesystems should ignore
> uninitialized data just because it's meaningless. Once written, the data
> would be ever meaningful to the guest.
> 
> "punching holes" would add support for "DISCARD" for a image which could
> behave like a SSD. Otherwise the image behaves like a magnetic disk.
> 
> The message in below would not be accurate:
> * cp has --sparse option to support read and create sparse files.
> * Sadly scp doesn't support sparse files.
> * rsync also has a -S --sparse option to properly handle sparse files.
> 
> Not until recently did I realize that the hole is just widely supported in
> *almost* all filesystems. That's why I have come up this idea.
> I understand your concern about the support of hole. If this just because
> the "hole" is never standardized as POSIX or something else?
> 
> So now I get one clear reason: hole is not guaranteed by standardized
> filesystems (I guess a POSIX would be enough).
> Is their something else? If it's the only reason of not using a sparse raw
> file as image, and the only impediment is no-one-should-ever-use FAT32 or
> say the POSIX, we may be very close to  move one step forward.
> 

The problem is cp wouldn't maintain the correctness of a copied raw-with-hole
image, whereas cp does maintain the correctness of any other thin image types,
that has cluster explicit allocation info.

We can't overcome that, unless we tell users "never use `cp' to copy the image,
it will break your data, you have to use `qemu-img convert'". That's
counterintuitive and a step back.

Fam