Re: Fatal crash on xen4.2 HVM + qemu-xen dm + NFS

[Stefano Stabellini <stefano.stabellini@eu.citrix.com>]

On Tue, 22 Jan 2013, Alex Bligh wrote:
> Ian,
> 
> --On 22 January 2013 10:13:58 +0000 Ian Campbell <Ian.Campbell@citrix.com> 
> wrote:
> 
> > 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.
> 
> Except it isn't the safe option because O_DIRECT (apparently) is not safe
> with NFS or (we think) iSCSI, and in a far nastier way. And fixing that
> is more intrusive (see your patch series).
> 
> I can't test it at the moment (travelling), but if not using O_DIRECT
> fixed things, would you accept something that somehow allowed one to
> specify an option of not using O_DIRECT? I need to look at how to get
> the disk config line from xen_disk.c if so.

I think that it would be acceptable.


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

Actually it is other way around: IDE has a way to specify that data
needs to hit the disk. The block protocol has it too, but the old
operation to do that (BLKIF_OP_WRITE_BARRIER) wasn't considered safe.
Konrad might be able to elaborate on the reasons why.


> You mean the equivalent of flush/fua? I can't comment, but I believe
> the write barrier stuff isn't in 4.2 in xen_disk either.

It is not, but given that it can be considered an important bug fix (the
old BLKIF_OP_WRITE_BARRIER op is known to have issues), I would be OK with
backporting it.