From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:46531)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VPTvt-00042E-TU
	for qemu-devel@nongnu.org; Fri, 27 Sep 2013 05:01:59 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VPTvn-0001Ar-VK
	for qemu-devel@nongnu.org; Fri, 27 Sep 2013 05:01:53 -0400
Received: from mx1.redhat.com ([209.132.183.28]:2601)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1VPTvn-0001Al-OE
	for qemu-devel@nongnu.org; Fri, 27 Sep 2013 05:01:47 -0400
Message-ID: <5245498B.4060308@redhat.com>
Date: Fri, 27 Sep 2013 11:02:03 +0200
From: Paolo Bonzini <pbonzini@redhat.com>
MIME-Version: 1.0
References: <CAERYnoZJ0cV9CVH3J2zGwa2h5vyDG=ATpBD45Jhqs9Q6qq24WA@mail.gmail.com>
	<20130926075843.GC24531@stefanha-thinkpad.redhat.com>
	<5243F661.8000401@redhat.com>
	<CAERYnoYJVeGV+eMyEio-e1zn46j5r+JKsLAD9MsQdwtxO0bxxA@mail.gmail.com>
	<5244673F.4000203@redhat.com>
	<5245B92F020000660001DF93@soto.provo.novell.com>
In-Reply-To: <5245B92F020000660001DF93@soto.provo.novell.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] qemu-img create: set "nocow" flag to solve
 performance issue on btrfs
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Chun Yan Liu <cyliu@suse.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel@nongnu.org

Il 27/09/2013 10:58, Chun Yan Liu ha scritto:
>> If so, you could run QEMU with "cache=unsafe" and have
>> basically the same data safety guarantees as "cache=writeback" on
>> every other file system.
> "cache=unsafe" means it never calls fsync() ?

Yes.  However, metadata writes are still done and ordered correctly with
respect to data writes.

> If so, it seems to be
> not proper to use this option to disk image of a running VM. In case
> someone has run the VM for a very long time and made many changes
> already on the disk image, but all those are in cache (?) Then due to
> a power off, all these changes are lost. Although the disk image is
> still in a consistent data status, but the data is maybe too old.

Perhaps for btrfs-cow a different strategy is better, with fsyncs
coalesced and issued by QEMU every N seconds.

Paolo