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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 22 Feb 2013, Konrad Rzeszutek Wilk wrote:
> 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 also have been too busy to look at this yet


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

Yes, if you can prove that the sync requests are all sent at the right
time and handled properly, then I am OK with the change.


> > 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@xxxxxxxxxxx> wrote:
> > 
> > >Konrad / Stefano,
> > >
> > >Any movement / ideas on this one?
> > >
> > >Alex
> > >
> > >--On 25 January 2013 11:28:31 +0000 Alex Bligh <alex@xxxxxxxxxxx> wrote:
> > >
> > >>Konrad,
> > >>
> > >>--On 23 January 2013 16:29:20 +0000 Stefano Stabellini
> > >><stefano.stabellini@xxxxxxxxxxxxx> 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@xxxxxxxxxxx>
> > >>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
> 

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