Am 13.12.2011 13:37, schrieb Paolo Bonzini:
> Running with mismatched host and guest logical block sizes is going
> to become more important as 4k-sector disks become more widespread.
> This is because we need a 512 byte disk to boot from.
>
> Mismatched block sizes have two problems:
>
> 1) with cache=none or with non-raw protocols, you just cannot do 512-byte
> granularity output. You need to do read-modify-write cycles like "hybrid"
> 512b-logical/4k-physical disks do. (Note that actually only the iSCSI
> protocol supports 4k logical blocks).
>
> 2) when host block size < guest block size, guests issue 4k-aligned
> I/O and expect it to be atomic. This problem cannot really be solved
> completely, because power or I/O failures could leave a partially-written
> block ("torn page"). However, at least you can serialize reads against
> overlapping writes, which guarantees correctness as long as shutdown is
> clean and there are no I/O errors.
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. If you want to migrate between two hosts with different
sector sizes, you need to specify the block size of the virtual device
explicitly. I think this is reasonable so far.
It also means that depending on which disk your image resides, the guest
sees different hardware by default. It may well happen that an image
that ran just fine on a host with 512 byte sectors refuses to work on a
host with 4k sectors. This is something that I don't really like to see.
(I wonder if it would make sense to optionally save a block size in the
qcow2 image header that would be used by default?)
Other defaults would imply doing (potentially unsafe) emulation, so I
think what you chose might be the least bad option. Still worth having a
discussion about it on the list.
Kevin
