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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Feb 22, 2013 at 05:28:42PM +0000, Alex Bligh wrote:
> Konrad / Stefano,
> 
> Any update here?

Sorry, been so busy with bugs that this keeps on getting deferred.
> 
> I can't help but think a crashed dom0 and guaranteed domU corruption is
> less bad than a theoretical data loss on a crash (not that we know
> that theoretical possibility exists yet).

So from a perspective of blkif protocol, as long as the sync requests
is properly being sent - then we are fine. I recall Stefano (or mayber Roger)
finding some oddity in the xen_disk were the fsync wasn't sent.

You should be able to test this rather easy by (in your guest)
mounting an ext3 or ext4 with barrier support and then looking at
the blktrace/blkparse to make sure that the sync commands are indeed hitting
the platter.

Thought there is probably a nice framework to do all of this automatically.
Perhaps fio does that already..

> 
> I'm currently using this trivial patch
> https://github.com/abligh/qemu-upstream-4.2-testing-livemigrate/commit/a7d72
> 96aebc21af15074f3bf64c5c6795ca05f16
> 
> Alex
> 
> 
> --On 5 February 2013 15:40:33 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> 
> >Konrad / Stefano,
> >
> >Any movement / ideas on this one?
> >
> >Alex
> >
> >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@alex.org.uk> wrote:
> >
> >>Konrad,
> >>
> >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> >><stefano.stabellini@eu.citrix.com> wrote:
> >>
> >>>>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>>>index a402ac8..1c3a6f5 100644
> >>>>--- a/hw/xen_disk.c
> >>>>+++ b/hw/xen_disk.c
> >>>>@@ -603,7 +603,7 @@ static int blk_init(struct XenDevice *xendev)
> >>>>     }
> >>>>
> >>>>     /* read-only ? */
> >>>>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>>>+    qflags = /* BDRV_O_NOCACHE | */ BDRV_O_CACHE_WB |
> >>>>BDRV_O_NATIVE_AIO; if (strcmp(blkdev->mode, "w") == 0) {
> >>>>         qflags |= BDRV_O_RDWR;
> >>>>     } else {
> >>>
> >>>Before going for something like that I would like a confirmation from
> >>>Konrad about blkfront behavior regarding barriers and
> >>>BLKIF_OP_FLUSH_DISKCACHE. I certainly don't want to risk data
> >>>corruptions.
> >>
> >>Any ideas?
> >>
> >>
> >>A slightly prettier patch would look like the one pasted
> >>below (not sent with git-sendemail so beware whitespace issues).
> >>
> >>--
> >>Alex Bligh
> >>
> >>commit a7d7296aebc21af15074f3bf64c5c6795ca05f16
> >>Author: Alex Bligh <alex@alex.org.uk>
> >>Date:   Thu Jan 24 09:41:34 2013 +0000
> >>
> >>    Disable use of O_DIRECT by default as it results in crashes.
> >>
> >>    See:
> >>      http://lists.xen.org/archives/html/xen-devel/2012-12/msg01154.html
> >>    for more details.
> >>
> >>diff --git a/hw/xen_disk.c b/hw/xen_disk.c
> >>index a402ac8..a618d8d 100644
> >>--- a/hw/xen_disk.c
> >>+++ b/hw/xen_disk.c
> >>@@ -45,6 +45,8 @@ static int batch_maps   = 0;
> >>
> >> static int max_requests = 32;
> >>
> >>+static int use_o_direct = 0;
> >>+
> >> /* ------------------------------------------------------------- */
> >>
> >> # define BLOCK_SIZE  512
> >>@@ -603,7 +605,7 @@ static int blk_init(struct XenDevice *xendev)
> >>     }
> >>
> >>     /* read-only ? */
> >>-    qflags = BDRV_O_NOCACHE | BDRV_O_CACHE_WB | BDRV_O_NATIVE_AIO;
> >>+    qflags = (use_o_direct?BDRV_O_NOCACHE:0) | BDRV_O_CACHE_WB |
> >>BDRV_O_NATIVE_AIO;
> >>     if (strcmp(blkdev->mode, "w") == 0) {
> >>         qflags |= BDRV_O_RDWR;
> >>     } else {
> >>
> >>
> >>
> >
> >
> >
> >--
> >Alex Bligh
> >
> >
> 
> 
> 
> -- 
> Alex Bligh