The default cache mode has been changed from write-back to
write-through after merging in Oct 23. And this make the guest
boot slowly with qcow. This patch changes it to write-back again.
Best Regards
--yang
diff --git a/xenstore.c b/xenstore.c
index 6bfcdbb..7463cef 100644
--- a/xenstore.c
+++ b/xenstore.c
@@ -472,7 +472,7 @@ void xenstore_parse_domain_config(int hvm_domid)
#ifdef CONFIG_STUBDOM
if (pasprintf(&danger_buf, "%s/device/vbd/%s",
danger_path, e_danger[i]) == -1)
continue;
- if (bdrv_open2(bs, danger_buf, 0 /* snapshot */, &bdrv_vbd) == 0) {
+ if (bdrv_open2(bs, danger_buf, BDRV_O_CACHE_WB | BDRV_O_RDONLY/* snapshot and
write-back */, &bdrv_vbd) == 0) {
pstrcpy(bs->filename, sizeof(bs->filename), params);
} else
#endif
@@ -498,7 +498,7 @@ void xenstore_parse_domain_config(int hvm_domid)
}
}
pstrcpy(bs->filename, sizeof(bs->filename), params);
- if (bdrv_open2(bs, params, 0 /* snapshot */, format) < 0)
+ if (bdrv_open2(bs, params, BDRV_O_CACHE_WB | BDRV_O_RDONLY/*
snapshot and write-back */, format) < 0)
fprintf(stderr, "qemu: could not open vbd
''%s'' or hard disk image ''%s'' (drv
''%s'' format ''%s'')\n", buf, params, drv
? drv : "?", format ? format->format_name : "0");
}
--
1.6.0.rc1
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Zhang, Yang writes
("[Xen-devel][PATCH]ioemu:"):> The default cache mode has been changed from write-back to
> write-through after merging in Oct 23. And this make the guest
> boot slowly with qcow. This patch changes it to write-back again.
I''m slightly puzzled by this because the effect is to add O_DSYNC to
the flags passed to open(). But this should effectively be the
default for us anyway because we implement IDE cache control, which
defaults to cacheing off. Does your guest enable the IDE cache ?
However I agree that passing BDRV_O_CACHE_WB, to disable O_DSYNC,
would be correct at least for the non-stubdom case. Does O_DSYNC even
have any effect in stubdom ? I would have expected not.
Why did you set BDRV_O_RDONLY as well ? That seems wrong to me. In
fact, it worries me that your guest could boot at all with
BDRV_O_RDONLY forced on. Also your comment seems somewhat confused;
the code path your patching is used for all disk opens and not just
snapshots.
I''ll hold off doing anything for now until the situation becomes
slightly clearer. Thanks for your contribution. (And next time
please include a Signed-Off-By.)
Regards,
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
>I''m slightly puzzled by this because the effect is to add O_DSYNC to >the flags passed to open(). But this should effectively be the >default for us anyway because we implement IDE cache control, which >defaults to cacheing off. Does your guest enable the IDE cache ?I use the default configure to boot my guest. I don''t know whether the IDE cache is enable default or how to disable it.And i can see that guest boots more slowly than before with qcow image when I using the write-through. And I see the upstream qemu also has the problem and it has changed to write-back. But the code about the cache-mode seems doesn''t been executed in qemu-unstable.>However I agree that passing BDRV_O_CACHE_WB, to disable O_DSYNC, >would be correct at least for the non-stubdom case. Does O_DSYNC even >have any effect in stubdom ? I would have expected not.I doesn''t test if it is effect in stubdom. May be you are right. I should not change it in stubdom>Why did you set BDRV_O_RDONLY as well ? That seems wrong to me. In >fact, it worries me that your guest could boot at all with >BDRV_O_RDONLY forced on. Also your comment seems somewhat confused; >the code path your patching is used for all disk opens and not just >snapshots.The arg default is zero. And I see the BDRV_O_RDONLY is defined as zero too in "block.h". So I think I can change the zero to BDRV_O_RDONLY. There are nothing different in essentially. But I think you are right. I should only add the BDRV_O_CACHE_WB. Best Regards --yang _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Zhang, Yang writes ("RE:
[Xen-devel][PATCH]ioemu:"):> [Ian:]
> >However I agree that passing BDRV_O_CACHE_WB, to disable O_DSYNC,
> >would be correct at least for the non-stubdom case. Does O_DSYNC even
> >have any effect in stubdom ? I would have expected not.
>
> I doesn''t test if it is effect in stubdom. May be you are right. I
> should not change it in stubdom
I think it is better to be consistent in the two cases. Not passing
O_DSYNC should be harmless in stubdom I think.
> >Why did you set BDRV_O_RDONLY as well ? [...]
>
> The arg default is zero. And I see the BDRV_O_RDONLY is defined as
> zero too in "block.h". So I think I can change the zero to
> BDRV_O_RDONLY.
Oh, I see. No, that''s not what zero means. In fact BDRV_O_RDONLY is
broken; I had remembered there was a problem here but I didn''t look at
the definition to check to see how your code could possibly work,
before emailing you. Sorry.
> There are nothing different in essentially. But I think you are
> right. I should only add the BDRV_O_CACHE_WB.
I have commited a change to do this.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel