Re: [Xen-devel] Fatal crash on xen4.2 HVM + qemu-xen dm + NFS

[Alex Bligh <alex@xxxxxxxxxxx>]

Stefano,

--On 22 January 2013 16:09:21 +0000 Stefano Stabellini 
<stefano.stabellini@xxxxxxxxxxxxx> 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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel