From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54596 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OSD6J-0004nW-Ro
	for qemu-devel@nongnu.org; Fri, 25 Jun 2010 13:54:12 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <hch@lst.de>) id 1OS4L4-00007t-8k
	for qemu-devel@nongnu.org; Fri, 25 Jun 2010 04:32:43 -0400
Received: from verein.lst.de ([213.95.11.210]:38999)
	by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from <hch@lst.de>)
	id 1OS4L3-00007C-Qe
	for qemu-devel@nongnu.org; Fri, 25 Jun 2010 04:32:42 -0400
Date: Fri, 25 Jun 2010 10:32:33 +0200
From: Christoph Hellwig <hch@lst.de>
Subject: Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing
	"writeback" cache option
Message-ID: <20100625083233.GA5744@lst.de>
References: <20100616143321.24259.15137.malonedeb@palladium.canonical.com>
	<20100623161348.15581.21305.launchpad@gandwana.canonical.com>
	<20100624001603.GI7058@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100624001603.GI7058@shareable.org>
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Jamie Lokier <jamie@shareable.org>
Cc: Bug 595117 <595117@bugs.launchpad.net>, qemu-devel@nongnu.org

On Thu, Jun 24, 2010 at 01:16:03AM +0100, Jamie Lokier wrote:
> Serge Hallyn wrote:
> > The default of qemu-img (of using O_SYNC) is not very sensible
> > because anyway, the client (the kernel) uses caches (write-back),
> > (and "qemu-nbd -d" doesn't flush those by the way). So if for
> > instance qemu-nbd is killed, regardless of whether qemu-nbd uses
> > O_SYNC, O_DIRECT or not, the data in the image will not be
> > consistent anyway, unless "syncs" are done by the client (like fsync
> > on the nbd device or sync mount option), and with qemu-nbd's O_SYNC
> > mode, those "sync"s will be extremely slow.
> 
> Do the "client syncs" cause the nbd server to fsync or fdatasync the file?

NBD does not have support for cache flushes.  Any nbd server needs to
use O_DSYNC-like semantics.

> I really wish qemu's options didn't give the false impression
> "nocache" does less caching than "writethrough".  O_DIRECT does
> caching in the disk controller/hardware, while O_SYNC hopefully does
> not, nowadays.

The current cache= options are misleading in many ways.  I'll post a
patchset soon to distangle the notion of using direct vs buffered I/O
from exposing and implementing a guest visible volatile write cache.

Exposing these improvements on the command linkes will have to wait for
the new -blockdev option.