All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Cody <jcody@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/4] block/vpc: give option to force the current_size field in .bdrv_create
Date: Wed, 24 Feb 2016 16:17:24 -0500	[thread overview]
Message-ID: <20160224211724.GA26318@localhost.localdomain> (raw)
In-Reply-To: <56CE0454.5050202@kamp.de>

On Wed, Feb 24, 2016 at 08:28:20PM +0100, Peter Lieven wrote:
> Am 24.02.2016 um 14:40 schrieb Jeff Cody:
> > On Wed, Feb 24, 2016 at 02:07:18PM +0100, Kevin Wolf wrote:
> >> Am 24.02.2016 um 13:44 hat Peter Lieven geschrieben:
> >>> if the size is forced I would set the chs values to max. this way no
> >>> new creator String is needed and it is even backwards compatible. this
> >>> is what disk2vhd does.
> >> Does disk2vhd do it this way even if the size is smaller than the
> >> maximum that can be represented with CHS?
> >>
> > I don't know about disk2vhd, but I just created a 5G dynamic VHD
> > image on Hyper-V, and it produced:
> >
> > cyl: 10402, heads: 16, secs: 63
> > virtual size: 5.0G (5368709120 bytes)
> >
> > (the virtual size as calculated by CHS in that case would have been
> > 5368430592 bytes)
> >
> > I then tested the reverse - I modified qemu to create a VHD image with
> > 5G as the current_size, but maxed out CHS parameters.  I imported it
> > into Hyper-V, and it worked fine - just recognized as a 5G disk with
> > 5368709120 bytes.
> 
> So the idea to set CHS to MAX is not that bad.
> 

I agree.  I just did a test with disk2vhd, against an empty (but
formatted) 7.5G usb drive.  Here is what it created:

# ./qemu-img info /mnt/nfs-2/tmp/WINtsts2.VHD
cyls: 65535, heads: 16, sectors: 255
image: /mnt/nfs-2/tmp/WINtsts2.VHD
file format: vpc
virtual size: 7.5G (8095006720 bytes)

I really like how one company has 3 different tools that all handle
this differently.

> >
> > But with all that, it seems like it may be better to mimic the Hyper-V
> > behavior, and use a new creator app string, with the normal CHS
> > values.
> 
> But this means that it is not backwards compatible. Maxing out CHS
> when forcing the size would mean all old qemu version would look
> at current size and not CHS.
>

That is a valid concern.  So, how about this:

With 'force_size' during image create, set the CHS parameters to MAX
(as d2v does), but also set the creator app to 'qem2'.  This at least
gives other software a chance to learn that new creator app and handle
it differently, if needed (and it shouldn't hurt anything, and will
still be backwards compatible).


> Might it be that Hyper-V and others use CHS when an ATA disk is emulated
> and the cur_size otherwise? I think this is what virtualbox does.

I tested the Hyper-V created image under a Linux VM in Hyper-V.  The
VM is using IDE controllers, and the image size was the current_size,
not the CHS calculation.

Jeff

  reply	other threads:[~2016-02-24 21:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-24  0:47 [Qemu-devel] [PATCH 0/4] VHD/VPC format compatibility Jeff Cody
2016-02-24  0:47 ` [Qemu-devel] [PATCH 1/4] block/vpc: choose size calculation method based on creator_app field Jeff Cody
2016-02-24  0:47 ` [Qemu-devel] [PATCH 2/4] block/vpc: tests for auto-detecting VPC and Hyper-V VHD images Jeff Cody
2016-02-24 10:23   ` Kevin Wolf
2016-02-24 12:19     ` Jeff Cody
2016-02-24 15:40     ` Jeff Cody
2016-02-24 15:44       ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-02-24 15:47         ` Jeff Cody
2016-02-24 15:49       ` Max Reitz
2016-02-24  0:47 ` [Qemu-devel] [PATCH 3/4] block/vpc: give option to force the current_size field in .bdrv_create Jeff Cody
2016-02-24 10:19   ` Kevin Wolf
2016-02-24 12:24     ` Jeff Cody
2016-02-24 12:44       ` Peter Lieven
2016-02-24 13:07         ` Kevin Wolf
2016-02-24 13:40           ` Jeff Cody
2016-02-24 19:28             ` Peter Lieven
2016-02-24 21:17               ` Jeff Cody [this message]
2016-02-24 19:29           ` Peter Lieven
2016-02-24  0:47 ` [Qemu-devel] [PATCH 4/4] block/vpc: add tests for image creation force_size parameter Jeff Cody

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=20160224211724.GA26318@localhost.localdomain \
    --to=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pl@kamp.de \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.