[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Geometry and blocksize support for backing devices
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Geometry and blocksize support for backing devices |
Date: |
Fri, 07 Nov 2014 16:58:26 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Christian Borntraeger <address@hidden> writes:
> Am 07.11.2014 10:17, schrieb Markus Armbruster:
>> Christian Borntraeger <address@hidden> writes:
[...]
>>> Now here comes my proposal:
>>> Markus statement brought up an idea of special casing DASDs support. We can
>>> call an ioctl BIODASDINFO on the block device that will only
>>> succeed if the host
>>> disk is really a dasd. We could enable the auto detection for that case.
>>
>> If BIODASDINFO succeeds, QEMU uses that instead of making up device
>> geometry as described above. Correct?
>>
>> Let's spell out when exactly BIODASDINFO succeeds, to avoid
>> misunderstandings. It does when the backend is a DASD (/dev/dasd*).
>> What about a partition on a DASD? A file in a filesystem on a DASD?
>
> BIODASDINFO (we will propbably use BIODASDINFO2) will succeed only if
> the backend is backed by a dasd or its partitions. It will fail on
> other block devices and files on a dasd.
>
> Now: when passing in only a dasd partition we cannot do any sane thing
> with the dasd oddities inside the guest (e.g. creating dasd
> partitions, reading volume label or TOC etc.)
> So there is no need passing in geometry and block size. We could make
> the special case even stricter and check for start == 0 when doing the
> HDIO_GETGEO.
> So pass-through of geometry and block size is only performed if
> BIODASDINFO2 succeeds, and the GETGEO call indicates that this is not
> a partions by having start == 0.
>
> Makes sense?
Yes. Thank you!
[...]