qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation


From: Alexander Graf
Subject: Re: [Qemu-devel] [PATCH 1/3] Fix geometry sector calculation
Date: Wed, 02 May 2012 13:07:06 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.3) Gecko/20120306 Thunderbird/10.0.3

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]