From: Chris Friesen <chris.friesen@windriver.com>
To: Eric Blake <eblake@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] question about block size and virtual disks
Date: Fri, 21 Apr 2017 10:26:52 -0600 [thread overview]
Message-ID: <58FA32CC.2060104@windriver.com> (raw)
In-Reply-To: <a09762ce-092f-6fb1-6cc3-08a94a3c3dd1@redhat.com>
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
next prev parent reply other threads:[~2017-04-21 16:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-20 21:03 [Qemu-devel] question about block size and virtual disks Chris Friesen
2017-04-20 21:21 ` Eric Blake
2017-04-21 16:26 ` Chris Friesen [this message]
2017-04-25 11:33 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=58FA32CC.2060104@windriver.com \
--to=chris.friesen@windriver.com \
--cc=eblake@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).