On 01.05.2012 12:27, Stefan Hajnoczi wrote:
> On Mon, Apr 30, 2012 at 4:52 PM, Michael Tokarev <m...@tls.msk.ru> wrote:
>> This value is used currently for virtio-blk only.  It was defined
>> as uint16_t before, which is the same as in kernel<=>user interface
>> (in virtio_blk.h, struct virtio_blk_config).  But the problem is
>> that in kernel<=>user interface the units are sectors (which is
>> usually 512 bytes or more), while in qemu it is in bytes.  However,
>> for, say, md raid5 arrays, it is typical to have actual min_io_size
>> of a host device to be large.  For example, for raid5 device of
>> 3 drives with 64Kb chunk size, that value will be 128Kb, which does
>> not fit in a uint16_t anymore.
>> Increase the value size from 16bits to 32bits for now.
>> But apparently, the kernel<=>user interface needs to be fixed too
>> (while it is much more difficult due to compatibility issues),
>> because even with 512byte units, the 16bit value there will overflow
>> too with quite normal MD RAID configuration.
>> Signed-off-by: Michael Tokarev <m...@tls.msk.ru>
>> ---
>>  block.h |    4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> Which kernel<=>user interface?

struct virtio_blk_config in virtio_blk.h, which is used to
pass information about block device from (qemu) userspace
to guest kernel.

Besides, it appears that at least minimum_io_size is not used
anywhere in the kernel, -- so, for example, filesystems does
not directly benefit from seeing this information.  But mkfs.xfs
do use it.

> Reviewed-by: Stefan Hajnoczi <stefa...@linux.vnet.ibm.com>



Reply via email to