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

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

[Chris Friesen]

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?

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.)

Thanks,
Chris

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

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

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

[Chris Friesen]

On 04/20/2017 03:21 PM, Eric Blake wrote:
> On 04/20/2017 04:03 PM, Chris Friesen wrote:

>> 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.

I did an experiment with qemu-kvm-ev-2.6.0-28.el7_3.6.1, using -drive 
cache=none,aio=native and an LVM volume as the storage.

The guest saw the logical/physical block size as 512B, even though on the host 
both were 4KB.

Unless something is being lost in the LVM layer (which is possible) it appears 
that qemu defaults to 512B block size unless explicitly told otherwise.

Chris

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

[Kevin Wolf]

Am 21.04.2017 um 18:26 hat Chris Friesen geschrieben:
> On 04/20/2017 03:21 PM, Eric Blake wrote:
> >On 04/20/2017 04:03 PM, Chris Friesen wrote:
> 
> >>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.
> 
> I did an experiment with qemu-kvm-ev-2.6.0-28.el7_3.6.1, using
> -drive cache=none,aio=native and an LVM volume as the storage.
> 
> The guest saw the logical/physical block size as 512B, even though
> on the host both were 4KB.
> 
> Unless something is being lost in the LVM layer (which is possible)
> it appears that qemu defaults to 512B block size unless explicitly
> told otherwise.

Yes, this is the default as it is the most compatible setting (qemu
didn't support 4k sectors initially).

If you know that your guest can handle 4k sectors just fine, it is
recommended to explicitly set both options to 4k to avoid expensive
512 byte sector emulation. If you need to boot from the disk with BIOS,
you won't be able to change the logical block size, but you can still
try setting the physical block size to 4k.

In practice, it shouldn't make too much of a difference because the
OS will work only in complete file system blocks and/or pages, which are
already 4k, so even on a disk with 512 byte sectors, you should mostly
see 4k aligned requests that don't need emulation in qemu.

Kevin