From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHA6i-00034w-6I for qemu-devel@nongnu.org; Tue, 12 Aug 2014 07:19:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHA6d-0001eW-3V for qemu-devel@nongnu.org; Tue, 12 Aug 2014 07:19:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62496) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHA6c-0001eS-R7 for qemu-devel@nongnu.org; Tue, 12 Aug 2014 07:19:07 -0400 Date: Tue, 12 Aug 2014 19:19:19 +0800 From: Fam Zheng Message-ID: <20140812111919.GA2803@T430.redhat.com> References: <20140812005214.GB6226@T430.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] disk image: self-organized format or raw file List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?5ZC05YW05Y2a?= Cc: qemu-devel@nongnu.org On Tue, 08/12 06:46, =E5=90=B4=E5=85=B4=E5=8D=9A 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-spars= e-files > ] >=20 > 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 FAT3= 2 > and other FAT*. > Note that holes appear in filesystems when creating a sparse file in > inode-filesystems. While "punching holes" does remove the existent cont= ents > from the file, and it was newly added to only xfs/ext4 in newer linux > kernel. >=20 > 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 whet= her > to initialize the sectors to zero or just ignore them (filesystems neve= r > confuse with a uninitialized sector right?). Filesystems should ignore > uninitialized data just because it's meaningless. Once written, the dat= a > would be ever meaningful to the guest. >=20 > "punching holes" would add support for "DISCARD" for a image which coul= d > behave like a SSD. Otherwise the image behaves like a magnetic disk. >=20 > 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. >=20 > 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 becau= se > the "hole" is never standardized as POSIX or something else? >=20 > 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. >=20 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 t= ypes, 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