[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-users] qemu disk cache mode
On Tue, Mar 23, 2010 at 06:02:27PM +0800, Stefan Berder wrote: > Hi all, > I can't find any good talk about this subject and would like some insights > and advices on the cache side in xen. > I discovered that a domO power outage can lead to a severe filesystem > corruption of the domUs. The domO is a dual disk dell server with a PERC > controler in writethrough cache mode, the disk cache is disabled, the > scheduler in the domO/domU is NOOP, the domO is holding an LVM in which > LVs are created to be used as physical disks (phy:) in the domU. Using xm > destroy to shut the domU is ok and the filesystem doesn't crash. Pulling > the power plug from the domO leads to severe damage on the domU ext3 > filesystem. It is easily reproductible and always leads to fs corruption > (therefore database inconsistencies). Did some test with the same domU > converted in PV, the corruption does not appear but the write performance > is really low. I find that last point very interesting, paravirtualized domUs should have better I/O performance than fully-virtualized (that goes for most performance measures). I would look at the domU schedulers in use in your PV guests and try using noop. That way your dom0 does all I/O scheduling. I think the one caveat is if your domU is using SAN/NAS backed volumes, in which case deadline should give better performance in your use case than CFQ (lower latency with deadline). Even in that case, the PERC controller might be a reason to still use noop and leave it all to the hardware/dom0. Bottom line, try passing elevator={noop,deadline,cfq} (depends on what is built into your kernel) and test each to see which scheduler is best for your PV domUs. > Going through various search results on google, I discovered that qemu is > doing some writeback caching by default. It seems that xen is not > supporting this option in the configuration files therefore I can't find > any good way to disable this behavior when running a domU. I can't find a > good explanation of the internal of a domU creation (maybe I'm bad at > searching for this one) and is struggling with the python code to make a > cache=[none|writeback|writethrough] option but I'm not even sure it is > necessary/useful. Is there a reason for not running your domUs paravirtualized apart from the I/O throughput you mention above? Regards, Jamon _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |