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
