Re: [Qemu-devel] KVM call agenda for October 25

[Daniel P. Berrange]

On Wed, Oct 26, 2011 at 01:23:05PM +0200, Kevin Wolf wrote:
> Am 26.10.2011 11:57, schrieb Daniel P. Berrange:
> > On Wed, Oct 26, 2011 at 10:48:12AM +0200, Markus Armbruster wrote:
> >> Kevin Wolf <address@hidden> writes:
> >>
> >>> Am 25.10.2011 16:06, schrieb Anthony Liguori:
> >>>> On 10/25/2011 08:56 AM, Kevin Wolf wrote:
> >>>>> Am 25.10.2011 15:05, schrieb Anthony Liguori:
> >>>>>> I'd be much more open to changing the default mode to cache=none FWIW 
> >>>>>> since the
> >>>>>> risk of data loss there is much, much lower.
> >>>>>
> >>>>> I think people said that they'd rather not have cache=none as default
> >>>>> because O_DIRECT doesn't work everywhere.
> >>>>
> >>>> Where doesn't it work these days?  I know it doesn't work on tmpfs.  I 
> >>>> know it 
> >>>> works on ext[234], btrfs, nfs.
> >>>
> >>> Besides file systems (and probably OSes) that don't support O_DIRECT,
> >>> there's another case: Our defaults don't work on 4k sector disks today.
> >>> You need to explicitly specify the logical_block_size qdev property for
> >>> cache=none to work on them.
> >>>
> >>> And changing this default isn't trivial as the right value doesn't only
> >>> depend on the host disk, but it's also guest visible. The only way out
> >>> would be bounce buffers, but I'm not sure that doing that silently is a
> >>> good idea...
> >>
> >> Sector size is a device property.
> >>
> >> If the user asks for a 4K sector disk, and the backend can't support
> >> that, we need to reject the configuration.  Just like we reject
> >> read-only backends for read/write disks.
> > 
> > I don't see why we need to reject a guest disk with 4k sectors,
> > just because the host disk only has 512 byte sectors. A guest
> > sector size that's a larger multiple of host sector size should
> > work just fine. It just means any guest sector write will update
> > 8 host sectors at a time. We only have problems if guest sector
> > size is not a multiple of host sector size, in which case bounce
> > buffers are the only option (other than rejecting the config
> > which is not too nice).
> > 
> > IIUC, current QEMU behaviour is
> > 
> >            Guest 512    Guest 4k
> >  Host 512   * OK          OK
> >  Host 4k    * I/O Err     OK
> > 
> > '*' marks defaults
> > 
> > IMHO, QEMU needs to work withot I/O errors in all of these
> > combinations, even if this means having to use bounce buffers
> > in some of them. That said, IMHO the default should be for
> > QEMU to avoid bounce buffers, which implies it should either
> > chose guest sector size to match host sector size, or it
> > should unconditionally use 4k guest. IMHO we need the former
> > 
> >            Guest 512  Guest 4k
> >  Host 512   *OK         OK
> >  Host 4k     OK        *OK
> 
> I'm not sure if a 4k host should imply a 4k guest by default. This means
> that some guests wouldn't be able to run on a 4k host. On the other
> hand, for those guests that can do 4k, it would be the much better option.
> 
> So I think this decision is the hard thing about it.

I guess it somewhat depends whether we want to strive for

 1. Give the user the fastest working config by default
 2. Give the user a working config by default
 3. Give the user the fastest (possibly broken) config by default

IMHO 3 is not a serious option, but I could see 2 as a reasonable
tradeoff to avoid complexity in chosing QEMU defaults. The user
would have a working config with 512 sectors, but sub-optimal perf
on 4k hosts due to bounce buffering. Ideally libvirt or other
higher app would be setting the best block size that a guest
can support by default, so bounce buffers would rarely be needed.
So only people using QEMU directly without setting a block size
would ordinarily suffer the bounce buffer perf hit on a 4k host
host

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|