Re: [Qemu-devel] question about block size and virtual disks

[Eric Blake]

On 04/20/2017 04:03 PM, Chris Friesen wrote:
> Hi,
> 
> Suppose the host has a physical disk that only supports 4KB access, with
> no 512B fallback.
> 
> If we boot a guest with "cache=none", does the guest need to be able to
> handle disks with 4KB blocks or is qemu able to handle guests trying to
> access the disk with 512B granularity?

qemu should be able to handle the fallback automatically (that is, the
block layer is smart enough to honor bs->bl.request_alignment=4096 such
that it will never submit a request smaller than 4096 to the underlying
host storage, regardless of what size request the guest uses).

In fact, the blkdebug driver can be used to test this setup on top of
any real driver constraints, so we have some pretty good assurance that
our minimum-size code works even when tested on a platform that still
has 512B granularity.

> 
> Also, does the 4KB block size get "passed-through" to the guest somehow
> so that the guest knows it needs to use 4KB blocks, or does that need to
> be explicitly specified via virtio-blk-pci.logical_block_size and/or
> virtio-blk-pci.physical_block_size parameters?  (Assuming I'm using
> virtio-blk-pci.)

Again, qemu should be passing the advertisement of host properties down
to the guest insofar as possible (so a good guest will see that the
hardware is 4k only and will not try to make 512-byte requests), but at
the same time, qemu should handle guests that are so old that they are
blissfully unaware of the hardware advertisements and send 512-byte
requests anyway.  Of course, such guests are penalized with
read-modify-write delays when submitting 512-byte IO.  But explicitly
stating available parameters is always the wisest course of action, if
you don't want to rely on defaults changing underneath you.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature