[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.