From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, Markus Armbruster <armbru@redhat.com>
Cc: qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/5] block: New bdrv_nb_sectors()
Date: Mon, 12 May 2014 06:50:00 -0600 [thread overview]
Message-ID: <5370C378.2080306@redhat.com> (raw)
In-Reply-To: <20140512111156.GB4371@noname.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
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 <armbru@redhat.com>
>
> Is this really the right direction to move?
>
> 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.
>
> 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=qcow2 size=1234 encryption=off cluster_size=65536
lazy_refcounts=off
$ 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.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2014-05-12 12:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-09 9:48 [Qemu-devel] [PATCH 0/5] Clean up around bdrv_getlength() Markus Armbruster
2014-05-09 9:48 ` [Qemu-devel] [PATCH 1/5] raw-posix: Fix raw_getlength() to always return -errno on error Markus Armbruster
2014-05-09 9:48 ` [Qemu-devel] [PATCH 2/5] block: New bdrv_nb_sectors() Markus Armbruster
2014-05-12 11:11 ` Kevin Wolf
2014-05-12 12:36 ` Markus Armbruster
2014-05-12 12:50 ` Eric Blake [this message]
2014-05-09 9:48 ` [Qemu-devel] [PATCH 3/5] block: Use bdrv_nb_sectors() when sectors, not bytes are wanted Markus Armbruster
2014-05-09 16:27 ` Markus Armbruster
2014-05-09 9:48 ` [Qemu-devel] [PATCH 4/5] block: Drop superfluous aligning of bdrv_getlength()'s value Markus Armbruster
2014-05-09 9:48 ` [Qemu-devel] [PATCH 5/5] block: Avoid bdrv_get_geometry() where errors should be detected Markus Armbruster
2014-05-09 12:29 ` [Qemu-devel] [PATCH 0/5] Clean up around bdrv_getlength() Stefan Hajnoczi
2014-05-09 15:30 ` Stefan Hajnoczi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5370C378.2080306@redhat.com \
--to=eblake@redhat.com \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).