From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KpQ1L-00050j-6n
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:11:47 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KpQ1I-0004z1-8e
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:11:46 -0400
Received: from [199.232.76.173] (port=52127 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KpQ1I-0004yw-4H
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:11:44 -0400
Received: from ecfrec.frec.bull.fr ([129.183.4.8]:59358)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Laurent.Vivier@bull.net>) id 1KpQ1H-0005yX-PY
	for qemu-devel@nongnu.org; Mon, 13 Oct 2008 12:11:44 -0400
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
From: Laurent Vivier <Laurent.Vivier@bull.net>
In-Reply-To: <48EE38B9.2050106@codemonkey.ws>
References: <48EE38B9.2050106@codemonkey.ws>
Content-Type: text/plain; charset=utf-8
Date: Mon, 13 Oct 2008 18:11:39 +0200
Message-Id: <1223914299.4153.22.camel@frecb07144>
Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Reply-To: qemu-devel@nongnu.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.gnu.org/pipermail/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: qemu-devel@nongnu.org
Cc: Chris Wright <chrisw@redhat.com>, Mark McLoughlin <markmc@redhat.com>, Ryan Harper <ryanh@us.ibm.com>, kvm-devel <kvm-devel@lists.sourceforge.net>

Le jeudi 09 octobre 2008 =C3=A0 12:00 -0500, Anthony Liguori a =C3=A9crit=
 :
[...]
> So to summarize, I think we should enable O_DSYNC by default to
> ensure=20
> that guest data integrity is not dependent on the host OS, and that=20
> practically speaking, cache=3Doff is only useful for very specialized=20
> circumstances.  Part of the patch I'll follow up with includes
> changes=20
> to the man page to document all of this for users.

perhaps I'm wrong but I think O_DSYNC (in fact O_SYNC for linux) will
impact host filesystem performance, at least with ext3, because the
synchronicity is done through the commit of the journal of the whole
filesystem:

see fs/ext3/file.c:ext3_file_write() (I've removed the comments here) :

...
        if (file->f_flags & O_SYNC) {
=20
                if (!ext3_should_journal_data(inode))
                        return ret;

                goto force_commit;
        }


        if (!IS_SYNC(inode))
                return ret;

force_commit:
        err =3D ext3_force_commit(inode->i_sb);
        if (err)
                return err;
        return ret;
}

Moreover, the real behavior depends on the type of the journaling system
you use...

Regards,
Laurent
--=20
----------------- Laurent.Vivier@bull.net  ------------------
  "La perfection est atteinte non quand il ne reste rien =C3=A0
ajouter mais quand il ne reste rien =C3=A0 enlever." Saint Exup=C3=A9ry