[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


--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
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

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.