kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	Paolo Bonzini <pbonzini@redhat.com>,
	qemu-devel@nongnu.org, kvm@vger.kernel.org
Subject: Re: [Qemu-devel] KVM call agenda for October 25
Date: Wed, 26 Oct 2011 10:48:12 +0200	[thread overview]
Message-ID: <m3bot49m0j.fsf@blackfin.pond.sub.org> (raw)
In-Reply-To: <4EA7C1B8.9000903@redhat.com> (Kevin Wolf's message of "Wed, 26 Oct 2011 10:15:52 +0200")

Kevin Wolf <kwolf@redhat.com> 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.

If the backend can only support it by using bounce buffers, I'd say
reject it unless the user explicitly permits bounce buffers.  But that's
debatable.

It's okay to default device properties to some backend-dependent value,
if that improves usability.

  reply	other threads:[~2011-10-26  8:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-24 11:04 KVM call agenda for October 25 Juan Quintela
2011-10-24 11:35 ` Paolo Bonzini
2011-10-24 12:02   ` [Qemu-devel] " Peter Maydell
2011-10-24 13:06     ` Andreas Färber
2011-10-24 15:34     ` [Qemu-devel] " Luiz Capitulino
2011-10-25 12:35   ` Kevin Wolf
2011-10-25 13:05     ` [Qemu-devel] " Anthony Liguori
2011-10-25 13:18       ` Dor Laor
2011-10-25 13:28         ` Anthony Liguori
2011-10-25 13:40         ` Andreas Färber
2011-10-25 13:56       ` Kevin Wolf
2011-10-25 14:06         ` Anthony Liguori
2011-10-25 15:32           ` Kevin Wolf
2011-10-25 22:19             ` Alexander Graf
2011-10-26 20:41             ` [Qemu-devel] " Anthony Liguori
2011-10-26  8:15           ` Kevin Wolf
2011-10-26  8:48             ` Markus Armbruster [this message]
2011-10-26  9:41               ` [Qemu-devel] " Paolo Bonzini
2011-10-26 11:12                 ` Markus Armbruster
2011-10-26  9:57               ` Daniel P. Berrange
2011-10-26 11:23                 ` Kevin Wolf
2011-10-26 11:39                   ` Daniel P. Berrange
2011-10-26 12:18                     ` 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=m3bot49m0j.fsf@blackfin.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@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).