From: Alexander Graf <agraf@suse.de>
To: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Heinz Graalfs <graalfs@linux.vnet.ibm.com>,
Markus Armbruster <armbru@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>,
Jens Freimann <jfrei@linux.vnet.ibm.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>,
Paolo Bonzini <pbonzini@redhat.com>,
wein@linux.vnet.ibm.com, Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation
Date: Wed, 02 May 2012 13:07:06 +0200 [thread overview]
Message-ID: <4FA1155A.6080400@suse.de> (raw)
In-Reply-To: <4FA1117F.3070908@de.ibm.com>
On 05/02/2012 12:50 PM, Christian Borntraeger wrote:
> On 02/05/12 12:25, Paolo Bonzini wrote:
>> Il 02/05/2012 12:18, Christian Borntraeger ha scritto:
>>> Maybe that really points to the problem that we are trying to solve here.
>>> For a dasd device, there is usually a 4096 byte block size and on the host
>>> these 4096 arereported via getss and getpbsz.
>>> The geometry reported by the device driver is usually 15 head and 12 sectors
>>> per track, but actually means 12 sectors of 4096 bytes size (a track ~ 48k).
>>>
>>> What I want to achieve is that the guest view is identical to the host view
>>> for cyls, heads, secs, and all block sizes.
>> I think what you want is _not_ to have the same view as the host. What
>> you want is simply to have a default that is consistent with what is
>> common on actual s390 disks.
> Let me put it in another way:
>
> I want to have these values to match the _device_ that we are passing to the guest
> because several tools and the partition detection code for a compatible disk format
> (those that can be accessed by z/OS) needs those values to work properly.
>
> That of course means that the guest view is identical to the host view because both
> views describe a real property of the hardware.
>
> IOW the geometry for dasd devices is not an artifical number, it has some real meaning
> that has a influence on the data structures on the disk.
>
> Thing is, the easiest way of getting the hardware property is to query the host.
>
> Does that make the situation a bit clearer?
Another thing to consider is that there are 2 generic types of disks:
* SCSI disks
* DASD disks
Both can be accessed using virtio-blk-s390. The former have the same
semantics on geometry as what we're used to. They use normal MBRs and
essentially the geometry doesn't mean too much these days anymore ;).
However, if possible, I would like to diverge these as little as
possible from x86 virtio disks.
For DASD disks, the geometry is important, as its disk label is usually
not MBR, but something s390 specific. That one is different depending on
the geometry. So here the geometry is very important. The geometry on
the same disk can also be different, depending on how it's formatted. So
it's not quite as easy to reconstruct it from the imformation we already
have. IIUC if we have the logical block size and the information that
it's a DASD disk, we should be able to guess the geometry though.
Alex
next prev parent reply other threads:[~2012-05-02 11:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1335448165-26174-1-git-send-email-borntraeger@de.ibm.com>
[not found] ` <1335448165-26174-2-git-send-email-borntraeger@de.ibm.com>
[not found] ` <4F9AC55F.5000101@redhat.com>
2012-05-02 10:18 ` [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation Christian Borntraeger
2012-05-02 10:25 ` Paolo Bonzini
2012-05-02 10:50 ` Christian Borntraeger
2012-05-02 11:05 ` Paolo Bonzini
2012-05-02 11:07 ` Alexander Graf [this message]
2012-05-02 11:09 ` Paolo Bonzini
2012-05-02 11:10 ` Alexander Graf
2012-05-02 11:23 ` Paolo Bonzini
[not found] ` <1335448165-26174-3-git-send-email-borntraeger@de.ibm.com>
[not found] ` <4F9AC55D.3000904@redhat.com>
2012-05-02 10:27 ` [Qemu-devel] [PATCH 2/3] geometry detection: use HDIO_GETGEO Christian Borntraeger
2012-05-02 11:09 ` Alexander Graf
2012-05-02 11:26 ` Paolo Bonzini
2012-05-02 11:35 ` Alexander Graf
2012-05-02 11:38 ` Paolo Bonzini
2012-05-02 12:54 ` Alexander Graf
2012-05-02 14:27 ` Christian Borntraeger
2012-05-02 15:05 ` Alexander Graf
2012-05-02 18:49 ` Christian Borntraeger
2012-05-02 15:57 ` Stefan Weinhuber
2012-05-02 18:39 ` Alexander Graf
2012-05-02 11:56 ` Christian Borntraeger
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=4FA1155A.6080400@suse.de \
--to=agraf@suse.de \
--cc=armbru@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=graalfs@linux.vnet.ibm.com \
--cc=hch@lst.de \
--cc=jfrei@linux.vnet.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=wein@linux.vnet.ibm.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).