All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jamie Lokier <jamie@shareable.org>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Alexander Graf <agraf@suse.de>,
	armbru@redhat.com, qemu-devel@nongnu.org,
	Paul Brook <paul@codesourcery.com>,
	Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] Re: [PATCH 2/2] Add flush=off parameter to -drive
Date: Tue, 11 May 2010 17:32:42 +0100	[thread overview]
Message-ID: <20100511163242.GA27028@shareable.org> (raw)
In-Reply-To: <4BE959B2.3090904@codemonkey.ws>

Anthony Liguori wrote:
> On 05/11/2010 08:12 AM, Paul Brook wrote:
> >>>cache=always (or a more scary name like cache=lie to defend against
> >>>idiots)
> >>>
> >>>    Reads and writes are cached. Guest flushes are ignored.  Useful for
> >>>    dumb guests in non-critical environments.
> >>>       
> >>I really don't believe that we should support a cache=lie.  There are
> >>many other obtain the same results.  For instance, mount your guest
> >>filesystem with barrier=0.
> >>     
> >Ideally yes. However in practice I suspect this is still a useful option. 
> >Is
> >it even possible to disable barriers in all cases (e.g. NTFS under 
> >windows)?
> >
> >In a production environment it's probably not so useful - you're generally
> >dealing with long lived, custom configured guests.
> >
> >In a development environment the rules can be a bit different. For example 
> >if
> >you're testing an OS installer then you really don't want to be passing 
> >magic
> >mount options. If the host machine dies then you don't care about the 
> >state of
> >the guest because you're going to start from scratch anyway.
> >   
> 
> Then create a mount point on your host and mount the host file system 
> under that mount with barrier=0.

Two reasons that advice doesn't work:

1. It doesn't work in many environments.  You can't mount a filesystem
with barrier=0 in one place and barrier=1 on a different point, and
there's ofen only one host partition.

2. barrier=0 does _not_ provide the cache=off behaviour.  It only
disables barriers; it does not prevent writing to the disk hardware.

If you are doing a transient OS install, ideally you want an amount
equal to your free RAM not written to disk until the end.  barrier=0
does not achieve that.

> The problem with options added for developers is that those options are 
> very often accidentally used for production.

We already have risky cache= options.  Also, do we call fdatasync
(with barrier) on _every_ write for guests which disable the
emulated disk cache?

-- Jamie

  parent reply	other threads:[~2010-05-11 16:33 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-10 21:51 [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush Alexander Graf
2010-05-10 21:51 ` [Qemu-devel] [PATCH 1/2] Add no-op aio emulation stub Alexander Graf
2010-05-10 21:51   ` [Qemu-devel] [PATCH 2/2] Add flush=off parameter to -drive Alexander Graf
2010-05-11  8:36     ` [Qemu-devel] " Kevin Wolf
2010-05-11 10:55       ` Christoph Hellwig
2010-05-11 12:15         ` Paul Brook
2010-05-11 12:43           ` Anthony Liguori
2010-05-11 13:12             ` Paul Brook
2010-05-11 13:20               ` Anthony Liguori
2010-05-11 13:50                 ` Paul Brook
2010-05-11 15:40                   ` Anthony Liguori
2010-05-11 15:53                     ` Paul Brook
2010-05-11 17:09                       ` Anthony Liguori
2010-05-11 22:33                         ` Paul Brook
2010-05-11 19:11                     ` Avi Kivity
2010-05-11 16:32                 ` Jamie Lokier [this message]
2010-05-11 17:15                   ` Anthony Liguori
2010-05-11 18:13                     ` Jamie Lokier
2010-05-11 15:18           ` Alexander Graf
2010-05-11 18:20           ` Jamie Lokier
2010-05-11 21:58             ` Paul Brook
2010-05-11 22:11               ` Paul Brook
2010-05-12 10:09                 ` Jamie Lokier
2010-05-17 12:40                 ` Christoph Hellwig
2010-05-14  9:16         ` Markus Armbruster
2010-05-17 12:41           ` Christoph Hellwig
2010-05-17 12:42             ` Alexander Graf
2010-05-11 19:04       ` Avi Kivity
2010-05-12 15:05       ` Alexander Graf
2010-05-12 15:36         ` Kevin Wolf
2010-05-12 15:51           ` Alexander Graf
2010-05-11  6:18   ` [Qemu-devel] [PATCH 1/2] Add no-op aio emulation stub Stefan Hajnoczi
2010-05-11  8:29   ` [Qemu-devel] " Kevin Wolf
2010-05-10 21:59 ` [Qemu-devel] [PATCH 0/2] Enable qemu block layer to not flush Anthony Liguori
2010-05-10 22:03   ` Alexander Graf
2010-05-10 22:12     ` Anthony Liguori
2010-05-11 21:48       ` Jamie Lokier
2010-05-12  8:51         ` Stefan Hajnoczi
2010-05-12  9:42           ` Jamie Lokier
2010-05-12 10:43             ` Stefan Hajnoczi
2010-05-12 12:50               ` Jamie Lokier

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=20100511163242.GA27028@shareable.org \
    --to=jamie@shareable.org \
    --cc=agraf@suse.de \
    --cc=anthony@codemonkey.ws \
    --cc=armbru@redhat.com \
    --cc=hch@lst.de \
    --cc=kwolf@redhat.com \
    --cc=paul@codesourcery.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.