[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] qemu disk cache mode


  • To: Stefan Berder <stefan.berder@xxxxxxxxxxxxxxxxx>
  • From: Jamon Camisso <jamonation@xxxxxxxxx>
  • Date: Tue, 23 Mar 2010 10:59:33 -0400
  • Cc: xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 23 Mar 2010 08:01:58 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=DDXlLQU2cC0OfVfZKwj0GZLzo0uAU+ReOMMDzMr8fw6MvADACSuCRr1RfAk/+lkkNq zzEKfas2s5ov60NmQ9lOt0gSwhFa8Bbz4sgEEMws5/FHkau3AKCNaLvxQiUpjNyl5H8O q1o7MiiQ8rnjv37oIfb8d1h5nAw87L2vCTA4E=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

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


 


Rackspace

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