From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbvD5-00022J-LF for Qemu-devel@nongnu.org; Wed, 29 Jun 2011 09:53:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbvD3-0005xi-Pe for Qemu-devel@nongnu.org; Wed, 29 Jun 2011 09:53:43 -0400 Received: from mail-gy0-f173.google.com ([209.85.160.173]:46827) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbvD3-0005xa-ED for Qemu-devel@nongnu.org; Wed, 29 Jun 2011 09:53:41 -0400 Received: by gyg10 with SMTP id 10so562749gyg.4 for ; Wed, 29 Jun 2011 06:53:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4E0B1943.4090400@codemonkey.ws> References: <4E0B1399.4050807@redhat.com> <4E0B152B.1000201@codemonkey.ws> <4E0B1787.30709@redhat.com> <4E0B1943.4090400@codemonkey.ws> Date: Wed, 29 Jun 2011 15:53:40 +0200 Message-ID: From: Frediano Ziglio Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Default cache mode List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi , Christoph Hellwig 2011/6/29 Anthony Liguori : > On 06/29/2011 07:16 AM, Kevin Wolf wrote: >> >> Am 29.06.2011 14:06, schrieb Anthony Liguori: >>> >>> On 06/29/2011 06:59 AM, Kevin Wolf wrote: >>>> >>>> Hi, >>>> >>>> I think we have touched this topic before during some IRC discussions = or >>>> somewhere deep in a mailing list thread, but I think it hasn't been >>>> discussed on the list. >>>> >>>> Our default cache mode of cache=3Dwritethrough is extremely conservati= ve >>>> and provides absolute safety at the cost of performance, >>> >>> But for the most part, we track bare metal fairly well in terms of bloc= k >>> performance, no? >>> >>> Or are you really referring to qcow2 as a specific example? =C2=A0In th= e >>> past, we used a different default caching mode for qcow2. =C2=A0I think= that >>> could be done again if there was a compelling reason. >> >> No, people are also complaining about bad performance with raw. Which >> isn't really surprising when you do a flush after each single write >> request. O_SYNC is really much more than is needed in the average case. > > Which file system on the host? > > At any rate, I'm a big fan of making wce tunable in the guest and then I > think setting wce=3D1 is quite reasonable to do by default. > > Regards, > > Anthony Liguori > >> >> Kevin > > > Personally I think default lead to poor performance but currently people know that even critical application are handled correctly. Assuming a client connect to a database server on a qemu guest when server reply "transaction ok" you know that even a host crash lead to a successful transaction. At least the fact that this assumption won't be true has to be stated. Lately I'm doing some extensive testing on image performance and I noted that are not only image dependent but also filesystem (where image is stored) dependent but when data are allocated speed is good. raw disks are not so fast as expected? Try to use fallocate command to allocate the file than do a dd to fill the entire file with zeros and writethrough will perform very well. Allocating raw with qemu-img lead to a normal sparse file which written with O_DSYNC flag is quite slow due to extents allocation and fragmentation. Regards Frediano Ziglio