From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjpgF-0002l9-1r for qemu-devel@nongnu.org; Mon, 12 May 2014 08:50:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjpgA-0005vt-0c for qemu-devel@nongnu.org; Mon, 12 May 2014 08:50:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:38201) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wjpg9-0005tw-JB for qemu-devel@nongnu.org; Mon, 12 May 2014 08:50:01 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4CCo0FI006892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 12 May 2014 08:50:01 -0400 Message-ID: <5370C378.2080306@redhat.com> Date: Mon, 12 May 2014 06:50:00 -0600 From: Eric Blake MIME-Version: 1.0 References: <1399628898-3241-1-git-send-email-armbru@redhat.com> <1399628898-3241-3-git-send-email-armbru@redhat.com> <20140512111156.GB4371@noname.redhat.com> In-Reply-To: <20140512111156.GB4371@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vg8fqE0w9CUP2EpAXx00FMPgeTvW4Ossv" Subject: Re: [Qemu-devel] [PATCH 2/5] block: New bdrv_nb_sectors() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf , Markus Armbruster Cc: qemu-devel@nongnu.org, stefanha@redhat.com This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --vg8fqE0w9CUP2EpAXx00FMPgeTvW4Ossv Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 05/12/2014 05:11 AM, Kevin Wolf wrote: >> The next patches will convert some users of bdrv_getlength() to >> bdrv_nb_sectors(). >> >> Signed-off-by: Markus Armbruster >=20 > Is this really the right direction to move? >=20 > Generally I think we should be trying to move away from those arbitrary= > units of 512 bytes (that are called sectors for some reason, but aren't= > really related to either guest or host sector sizes), and towards > interfaces that use byte granularity. >=20 > So I would rather see bs->total_sectors becoming bs->total_bytes than > adding a new sector-based function. I tend to agree that storing rounded information is the wrong thing to do. The qcow2 format stores the guest size in bytes, so it is technically possible to have a file where the last sector is only a partial sector. However, because the current implementation rounds to sectors (and in some cases, rounds in the wrong direction), we have situations like: $ qemu-img create -f qcow2 img 1234 Formatting 'img', fmt=3Dqcow2 size=3D1234 encryption=3Doff cluster_size=3D= 65536 lazy_refcounts=3Doff $ qemu-img info img image: img file format: qcow2 virtual size: 1.0K (1024 bytes) disk size: 196K cluster_size: 65536 Format specific information: compat: 1.1 lazy refcounts: false where I lost 210 bytes of what the guest was supposed to be able to access. Consistently tracking bdrv length in bytes, and rounding up to sectors when needed, seems like it will be better than pre-rounding to sectors and possibly truncating the user image. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --vg8fqE0w9CUP2EpAXx00FMPgeTvW4Ossv 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 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJTcMN4AAoJEKeha0olJ0NqfUUH/3BT5IhTqL1GLONOntEaiImM qm9xqL+ysPZE55k2sfuKKbmTNUxozGrpIsDQSVjOZowLt6JZOfe0oxWVZsfOqo+8 gRpyskInr8/GFAmZp1maOG3ZCUoL7B3KEkLNwP+Z4KcK2Oz6lAaxKX00zztHAkBn Q7Sf230mjwxSimmZWhDAlCfahYUdI3dihN6q4G71sKeYCbfgaXnAtt8rqzoIRnNv bKny5mcGK1LCk65lKt9369oktW20BqKtlJqvnYe6NXuSTNEJYTLOcqT+y7Zbwm7u US8JWPxOIZkHXfjBwoEUJ1wj0ejRFjeYq5JJZRqib/IKdlMBT27zFgeiBLzqw8A= =UmPx -----END PGP SIGNATURE----- --vg8fqE0w9CUP2EpAXx00FMPgeTvW4Ossv--