From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=48377 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1ORa72-0001gr-MQ
	for qemu-devel@nongnu.org; Wed, 23 Jun 2010 20:16:14 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1ORa71-0006G2-Kj
	for qemu-devel@nongnu.org; Wed, 23 Jun 2010 20:16:12 -0400
Received: from mail2.shareable.org ([80.68.89.115]:41090)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <jamie@shareable.org>) id 1ORa71-0006FV-GZ
	for qemu-devel@nongnu.org; Wed, 23 Jun 2010 20:16:11 -0400
Date: Thu, 24 Jun 2010 01:16:03 +0100
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] [Bug 595117] Re: qemu-nbd slow and missing
	"writeback" cache option
Message-ID: <20100624001603.GI7058@shareable.org>
References: <20100616143321.24259.15137.malonedeb@palladium.canonical.com>
	<20100623161348.15581.21305.launchpad@gandwana.canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100623161348.15581.21305.launchpad@gandwana.canonical.com>
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: Bug 595117 <595117@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org

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?

> It appears it is because by default the disk image it serves is open
> with O_SYNC. The --nocache option, unintuitively, makes matters a
> bit better because it causes the image to be open with O_DIRECT
> instead of O_SYNC.
[...]
> --cache=off is the same as --nocache (that is use O_DIRECT),
> writethrough is using O_SYNC and is still the default so this patch
> doesn't change the functionality. writeback is none of those flags,
> so is the addition of this patch. The patch also does an fsync upon
> "qemu-nbd -d" to make sure data is flushed to the image before
> removing the nbd.

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.

-- Jamie