Il 20/08/2014 11:35, Christian Borntraeger ha scritto: > On 20/08/14 10:19, Paolo Bonzini wrote: >> Il 29/07/2014 14:27, Ekaterina Tumanova ha scritto: >>> The new HDIO_GETGEO logic is required for two use cases: >>> a) Support for geometries of Direct Attached Storage Disks (DASD) >>> on s390x configured as backing of virtio block devices. >> >> Is this still relevant now that QEMU can emulate 512-byte sectors on top >> of host devices with 4k sectors? > > Yes, the geometry and the block size define the layout of the DASD disk > format. This defines how the ibm disk layout partition table looks like. So > partition detection of the IBM layout only works if values are correct. (see > linux block/partitions/ibm.c. it needs these values to correctly locate the > data structures). > > Furthermore, if you do an mkfs in the host and the guest sees a different > block size all kind of strange things will happen when mounting, no? > >> >>> b) Support for FCP attached SCSI disks that do not yet have a >>> partition table. Without this patch, fdisk -l on the host would >>> return different results then fdisk -l in the guest. >> >> Can you provide an example? > > scsi disk in the host: > [root@host ~]# sfdisk -g > /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593 > /dev/disk/by-id/wwn-0x6005076305ffc1ae0000000000002593: 1011 cylinders, 34 > heads, 61 sectors/track > > same scsi disk in the guest as virtio-blk: > scsi disk in the guest: > [root@guest ~]# sfdisk -g /dev/disk/by-id/virtio-d20 > /dev/disk/by-id/virtio-d20: 2080 cylinders, 16 heads, 63 sectors/track > > 16/63 is currently hardcoded by QEMU, no matter what the host thinks. This > gets overridden as soon as there is a partition table. > > command line was: > -drive > file=/dev/disk/by-id/scsi-36005076305ffc1ae0000000000002593,if=none,id=drive-virtio-disk20,format=raw,serial=d20,cache=none,aio=native
But this risks changing whenever you move data from a disk to another disk, or if you move a virtual DASD disk from physical DASD to physical SCSI. If s390 is so sensitive to the head count and number of sectors/track (on x86 everything is done with LBAs nowadays, even in the firmware), I think whatever management layer you use should always specify them explicitly. I'm not saying this patch shouldn't be included---but it should be treated as a handy thing for developers rather than as a definitive fix. Paolo
