From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: Fatal crash on xen4.2 HVM + qemu-xen dm + NFS
Date: Tue, 22 Jan 2013 10:13:58 +0000
Message-ID: <1358849638.3279.314.camel@zakaz.uk.xensource.com>
References: <5B4525F296F6ABEB38B0E614@nimrod.local>
	<50CEFDA602000078000B0B11@nat28.tlf.novell.com>
	<3B1D0701EAEA6532CEA91EA0@Ximines.local>
	<alpine.DEB.2.02.1301161302020.4978@kaball.uk.xensource.com>
	<F1DF150F7B2469CFD587A2A4@Ximines.local>
	<alpine.DEB.2.02.1301161620390.4978@kaball.uk.xensource.com>
	<E57EC0AFE2B6901CB9A11068@Ximines.local>
	<alpine.DEB.2.02.1301161718120.4978@kaball.uk.xensource.com>
	<77822E2DDAEA8F94631B6A52@Ximines.local>
	<1358781790.3279.224.camel@zakaz.uk.xensource.com>
	<F7F59FF70A5F8648886565B5@Ximines.local>
	<1358783420.3279.235.camel@zakaz.uk.xensource.com>
	<F7775BEAD1475FBBDEB2B9C4@Ximines.local>
	<1358787073.3279.257.camel@zakaz.uk.xensource.com>
	<19EA31DDC3BEF4D66B42CBAC@Ximines.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <19EA31DDC3BEF4D66B42CBAC@Ximines.local>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Alex Bligh <alex@alex.org.uk>
Cc: Konrad Wilk <konrad.wilk@oracle.com>, Xen Devel <xen-devel@lists.xen.org>, Jan Beulich <JBeulich@suse.com>, Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
List-Id: xen-devel@lists.xenproject.org

On Mon, 2013-01-21 at 20:37 +0000, Alex Bligh wrote:
> Is the BDRV_O_NOCACHE | BDRV_O_CACHE_WB combination intentional or
> should BDRV_O_NOCACHE be removed? Why would the default be different
> for emulated and PV disks? 

AIUI it is intentional. The safe option (i,e, the one which doesn't risk
trashing the filesystem) is not to cache (so that writes have really hit
the disk when the device says so). We want to always use this mode with
PV devices.

However the performance impact of not caching the emulated (esp IDE)
devices is enormous and so the trade off was made to cache them on the
theory that they would only be used during install and early boot and
that OSes would switch to PV drivers ASAP. Also AIUI the emulated IDE
interface doesn't have any way to request that something really hits the
disk anyway, but I might be misremembering that.

Check the archives from around the time this change was made, I'm pretty
sure there was some discussion of why things are this way.

Ian.