From: Anthony Liguori <anthony@codemonkey.ws>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [RFC][PATCH] make sure disk writes actually hit disk
Date: Fri, 28 Jul 2006 15:12:04 -0500 [thread overview]
Message-ID: <pan.2006.07.28.20.12.03.531169@codemonkey.ws> (raw)
In-Reply-To: 44CA6B76.7000004@redhat.com
On Fri, 28 Jul 2006 15:54:30 -0400, Rik van Riel wrote:
> This is the simple approach to making sure that disk writes actually hit
> disk before we tell the guest OS that IO has completed. Thanks to
> DMA_MULTI_THREAD the performance still seems to be adequate.
Hi Rik,
Right now Fabrice is working on rewriting the block API to be
asynchronous. There's been quite a lot of discussion about why using
threads isn't a good idea for this (I wish Xen wouldn't use this patch but
that's another conversation :-)).
The async block API will allow the use of different kinds of async
"backends". The default (on Linux) will be posix-aio. I'm currently
working on an HTTP backend and will also write a linux-aio (which, of
course, will be using O_DIRECT).
> A fancier solution would be to make the sync/non-sync behaviour of the
> qemu disk backing store tunable from the guest OS, by tuning the IDE disk
> write cache on/off with hdparm, and having hw/ide.c call ->fsync functions
> in the block backends.
With a proper async API, is there any reason why we would want this to be
tunable? I don't think there's much of a benefit of prematurely claiming
a write is complete especially once the SCSI emulation can support
multiple simultaneous requests.
I was hoping to just make linux-aio the default if it was available...
Regards,
Anthony Liguori
> I'm willing to code up the fancy solution if people prefer that.
next prev parent reply other threads:[~2006-07-28 20:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-28 19:54 [Qemu-devel] [RFC][PATCH] make sure disk writes actually hit disk Rik van Riel
2006-07-28 19:58 ` [Qemu-devel] " Rik van Riel
2006-07-28 20:12 ` Anthony Liguori [this message]
2006-07-28 20:18 ` Rik van Riel
2006-07-28 20:30 ` Paul Brook
2006-07-28 20:43 ` Rik van Riel
2006-07-28 21:01 ` Paul Brook
2006-07-31 7:08 ` Jens Axboe
2006-07-29 9:57 ` [Qemu-devel] " Fabrice Bellard
2006-07-29 14:59 ` Rik van Riel
2006-07-29 16:04 ` Paul Brook
2006-07-29 16:22 ` Rik van Riel
2006-07-29 16:31 ` Paul Brook
2006-07-31 7:08 ` Jens Axboe
2006-07-29 17:33 ` Bill C. Riemers
2006-07-30 21:47 ` Jamie Lokier
2006-07-30 21:41 ` Jamie Lokier
2006-07-31 9:52 ` andrzej zaborowski
2006-07-31 10:17 ` Jens Axboe
2006-07-31 17:50 ` andrzej zaborowski
2006-07-31 7:08 ` Jens Axboe
2006-07-31 7:56 ` Jonas Maebe
2006-07-31 8:18 ` Jens Axboe
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=pan.2006.07.28.20.12.03.531169@codemonkey.ws \
--to=anthony@codemonkey.ws \
--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).