[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel][PATCH]ioemu:
>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@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |