From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHC2r-0002NN-SZ for qemu-devel@nongnu.org; Tue, 12 Aug 2014 09:23:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XHC2n-0002TG-JW for qemu-devel@nongnu.org; Tue, 12 Aug 2014 09:23:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XHC2n-0002T2-CX for qemu-devel@nongnu.org; Tue, 12 Aug 2014 09:23:17 -0400 Message-ID: <53EA1541.50500@redhat.com> Date: Tue, 12 Aug 2014 07:23:13 -0600 From: Eric Blake MIME-Version: 1.0 References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0LttKh2wBDwdI9jOWVaHcPT5rsjqxBmIh" 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?= , qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0LttKh2wBDwdI9jOWVaHcPT5rsjqxBmIh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 08/11/2014 05:38 PM, =E5=90=B4=E5=85=B4=E5=8D=9A wrote: > 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= =2E > 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= =2E Search the list archives; at one point in the past, an 'addcow' format was proposed, which is an additional file alongside a raw which provides enough information to (temporarily) add cow to raw (or any other file without a native backing file). I don't know why that format was not pursued further. You could use xattr to store a user attribute of a backing file or addcow file to associate with a raw file. But file system holes are NOT a good metadata tool for distinguishing between data not present (refer to the backing file) vs. data explicitly all zero. Your proposal of using holes in raw files as metadata is NOT going to reliably work. Also, using SEEK_HOLE/SEEK_DATA is a much nicer interface for iterating raw file holes than FIEMAP. It conveys less information, but that information is more portable (POSIX will be adding requirements for SEEK_HOLE/SEEK_DATA, and even NFSv4.2 is considering[1] adding this support because of POSIX). GNU cp is capable of using both FIEMAP and SEEK_HOLE to optimize copies where the destination tries to preserve the same hole layout as the source (not always possible, given that not all systems have the same granularities of holes, and also given that not all consecutive blocks of all-zero bytes have to be reported as holes). The SEEK_HOLE implementation has ALWAYS worked, but the FIEMAP implementation uncovered various bugs in file systems, and at one point would corrupt the copy unless cp did a sync() first, which slowed down the operation and defeated the point of attempting to use it for optimizations. While holes are a cool thing, they are best only for optimizations, and not for reliable metadata information. [1] http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-15.1= 2 --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --0LttKh2wBDwdI9jOWVaHcPT5rsjqxBmIh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg iQEcBAEBCAAGBQJT6hVBAAoJEKeha0olJ0NqQNkIAK+YWeZ+uvwiKVdiZ7wOtm8g 4bjV4v8WCResygqUe1xzqV39LLQuG2GXfWwqb8Uuq4KxSs11znaARX8aX/i8s0iT bX/iUKgAdzGQyfUL4YB8gNoPdfFA1eH8MaAxwJDZ5TyoX3yIZSPg6xgdoJVPumrx 9NJsC/FMN/88eR8Wpqw/3BA621F0CjApF22pbgyW8VIjVwbnCTAepFfTCt+k4Pbh EJMf/ivbDN3Wy/EZnVyv4CJkiyzJ92Tq7zZushvwHPjJ1rURnDekQcx7wPRtMT0h OPDfMOT3QEpHrfGCUkXDrGw6JBeVNzwqbsx4Le9MbrHIockEWBKrBhVDZsvzeXw= =dFce -----END PGP SIGNATURE----- --0LttKh2wBDwdI9jOWVaHcPT5rsjqxBmIh--