From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHH5k-0000Qu-T4 for qemu-devel@nongnu.org; Tue, 12 Aug 2014 14:46:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHH5h-0004Sy-2A for qemu-devel@nongnu.org; Tue, 12 Aug 2014 14:46:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHH5g-0004Sh-RM for qemu-devel@nongnu.org; Tue, 12 Aug 2014 14:46:36 -0400 Date: Tue, 12 Aug 2014 19:46:30 +0100 From: "Daniel P. Berrange" Message-ID: <20140812184630.GP8471@redhat.com> References: 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 Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?5ZC05YW05Y2a?= Cc: qemu-devel@nongnu.org On Mon, Aug 11, 2014 at 07:38:50PM -0400, =E5=90=B4=E5=85=B4=E5=8D=9A wro= te: > Hello, >=20 > 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 :). >=20 > (1) Currently the raw format doesn't support COW. In other words, a ra= w > image cannot have a backing file. COW depends on the mapping table on w= hich > we it knows whether each block/cluster is present (has been modified) i= n > 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 (may= be > block/raw-posix.c) may obtain correct 'present information about blocks. > However this information may be limited to be aligned with file allocat= ion > 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. >=20 > (2) As most popular filesystems support delay-allocation/on-demand > allocation/holes, whatever, a raw image is also thin provisioned as oth= er > 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 ext= ents > would become a burden of the host filesystem. >=20 > (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 bo= th > guest/host's filesystem can also provide similar functionality. >=20 > (4) I don't have too much understanding on how snapshot works but I th= ink > theoretically it would be using the techniques no more than that used i= n > COW and backing file. >=20 > 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 fo= r > more features from outside world). > I would be very sorry if my ignorance wasted your time. FWIW, much of what you say about features supported in filesystems is correct, however, that is only considering the needs of deployment on your specific platform. One value of QCow2 is that it is a portable format you can use on any platform where QEMU builds, whether it be Linux, Windows, *BSD or Solaris. If you were to rely on the host filesystem then obviously you'd have to figure out the different solution for the particular OS you deploy on. Taking the compression feature - arguably the biggest benefit of that is when you distribute disk images. eg if someone provides a root disk image on a web server, using compression in qcow2 can dramatically lower the download size, while still allowing QEMU to directly run from that qcow2 file. Sure you could wrap your disk images in gzip and then convert to your local filesystem at time of use but this introduces multiple extra steps. There's similar arguments for other features in qcow2. That's not to say you are wrong in your analysis of your own needs. It is simply a case that different scenarios imply different solutions, so for some qcow2 may be optimal, while for others using native filesystem features might be better Regards, Daniel --=20 |: http://berrange.com -o- http://www.flickr.com/photos/dberrange= / :| |: http://libvirt.org -o- http://virt-manager.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vn= c :|