From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Bligh Subject: Re: Fatal crash on xen4.2 HVM + qemu-xen dm + NFS Date: Tue, 22 Jan 2013 20:31:00 +0000 Message-ID: <4D54EE421529BA5E0A511E31@nimrod.local> References: <5B4525F296F6ABEB38B0E614@nimrod.local> <50CEFDA602000078000B0B11@nat28.tlf.novell.com> <3B1D0701EAEA6532CEA91EA0@Ximines.local> <77822E2DDAEA8F94631B6A52@Ximines.local> <1358781790.3279.224.camel@zakaz.uk.xensource.com> <1358783420.3279.235.camel@zakaz.uk.xensource.com> <1358787073.3279.257.camel@zakaz.uk.xensource.com> <19EA31DDC3BEF4D66B42CBAC@Ximines.local> Reply-To: Alex Bligh Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: Alex Bligh , Konrad Wilk , Ian Campbell , Jan Beulich , Xen Devel List-Id: xen-devel@lists.xenproject.org Stefano, --On 22 January 2013 16:09:21 +0000 Stefano Stabellini wrote: > Looking more closely at xen_disk's flush operations, > even if the semantics of the old BLKIF_OP_WRITE_BARRIER is confused, the > implementation of it in xen_disk is strickly a superset of the flushes > performed by the new BLKIF_OP_FLUSH_DISKCACHE. > > So unless blkfront issues fewer cache flushes when using > BLKIF_OP_WRITE_BARRIER, I am tempted to say that even with the old flush > operation, it might be safe to open the file write-back. Either writeback or 'user specifiable' would be my preference. Writethrough has known performance problems with various disk formats, "notably qcow2" (see qemu manpage). And "none" (aka O_DIRECT) appears to be dangerous. I suspect the best possible answer is a cache=[qemu-cache-identifier] config key, which gets put in xenstore, and which xen_disk.c then interprets using the same routine QEMU does itself for cache= on the command line, then uses exactly those BDEV flags. For completeness one could also add an emulcache= option and just pass that straight through to the qemu command line for the emulated drives. I had a quick look at this on the train and it appears that to do it properly requires fiddling with lex file and possibly xenstore, i.e. is not completely trivial. An alternative more disgusting arrangement would be to overload one of the existing options. What's the right approach here, and have I any hope of getting a patch into 4.2.2? Not a disaster if not as I already need to maintain a local tree due to the absence of HVM live migrate on qemu-upstream. -- Alex Bligh