[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 00/17] Support mismatched host and guest logical
Re: [Qemu-devel] [PATCH 00/17] Support mismatched host and guest logical block sizes
Wed, 14 Dec 2011 13:40:22 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1
On 12/14/2011 01:05 PM, Kevin Wolf wrote:
Am 14.12.2011 12:47, schrieb Paolo Bonzini:
On 12/14/2011 12:13 PM, Kevin Wolf wrote:
As we discussed before, the really interesting point here is defaults,
and whatever you choose to do is wrong in some respect.
So it looks like you chose to make the virtual device default to the
host block size.
... wait wait, I default to 512. :)
Here is the rationale. 512-over-4k may be slow, but is safe (but it is
not slow if you align partitions properly). 4k-over-512 is unsafe. So,
defaulting to 512 seemed the right thing after all.
Which means bounce buffers by default on 4k hosts.
In practice it doesn't (quite surprisingly). The patches do the following:
- if the initial and ending sector is aligned, submit directly to paio.
Otherwise, only bounce the extra host sectors (up to 2) required to
align the operation: the bulk of the request will reuse the guest's data
- if the buffer is not 4k-aligned, paio will linearize the request with
a bounce buffer. This will almost always happen if the initial sector
is misaligned, but not if only the ending sector is misaligned.
If the partitions are aligned, the OS will always issue aligned
requests, because file system blocks are already 4k. And kernel buffers
will usually be page-aligned rather than block-aligned, so paio will
also let the request through. You'll see perhaps half a dozen
misaligned requests in the whole guest lifetime, for example to read the
partition table. So for aligned partitions, the performance difference
on iozone was well within statistical noise.
Is this going to
become our next cache=writethrough? At some point 4k disks will be in
wide use, but we'll still be stuck with a slow default of 512.
Unless you switch to EFI, the boot disk has to remain anyway on 512-byte
No matter what we decide here, I think it might really be a good idea to
save the block size in the image and use that as the default if nothing
else is specified on the command line.
Yeah, that's sensible to do (though it can be a follow-up).
- [Qemu-devel] [PATCH 12/17] block: allow waiting only for overlapping writes, (continued)
- [Qemu-devel] [PATCH 12/17] block: allow waiting only for overlapping writes, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 10/17] raw: probe host_block_size, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 16/17] block: default physical block size to host block size, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 14/17] block: protect against "torn reads" for guest_block_size > host_block_size, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 15/17] block: align and serialize I/O when guest_block_size < host_block_size, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 13/17] block: allow waiting at arbitrary granularity, Paolo Bonzini, 2011/12/13
- [Qemu-devel] [PATCH 17/17] qemu-io: add blocksize argument to open, Paolo Bonzini, 2011/12/13
- Re: [Qemu-devel] [PATCH 00/17] Support mismatched host and guest logical block sizes, Kevin Wolf, 2011/12/14