WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] qemu disk cache mode

To: Stefan Berder <stefan.berder@xxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-users] qemu disk cache mode
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
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=pg3BYxL/PkHAtnW60U8GvY5uoDHNWvQU+2tNt6xswl0=; b=uy2f6ALDXxwfzLEfeLKtph1pvXjPQa4LCdpHk7pP2G87M2i4J5+q/jwAZwXGLF23yV AgcOYtQvXwWIu1Kv39aAcZg7yfg8rKM9V61Fxda+m8rJsfbY19u8+054Qu9R/bv8z6m/ Xg1YUw2G9RhXAeETWRKk2MXgzGtRfqHeUolkE=
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=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <a6502b231003230302o1bbac392ld446cac23e394dd1@xxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <a6502b231003230302o1bbac392ld446cac23e394dd1@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.20 (2009-06-14)
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

<Prev in Thread] Current Thread [Next in Thread>