From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49414 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYbFY-00006f-7m for qemu-devel@nongnu.org; Tue, 13 Jul 2010 04:54:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYbFU-0004sd-3a for qemu-devel@nongnu.org; Tue, 13 Jul 2010 04:54:00 -0400 Received: from mx1.redhat.com ([209.132.183.28]:60663) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYbFT-0004sN-TT for qemu-devel@nongnu.org; Tue, 13 Jul 2010 04:53:56 -0400 Message-ID: <4C3C299C.20306@redhat.com> Date: Tue, 13 Jul 2010 10:53:48 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: BTRFS: Unbelievably slow with kvm/qemu References: <4C3ABF96.9070405@msgid.tls.msk.ru> <20100712134347.GB15754@dhcp231-156.rdu.redhat.com> In-Reply-To: <20100712134347.GB15754@dhcp231-156.rdu.redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Josef Bacik Cc: linux-fsdevel , Giangiacomo Mariotti , Michael Tokarev , linux-kernel@vger.kernel.org, qemu-devel Am 12.07.2010 15:43, schrieb Josef Bacik: > On Mon, Jul 12, 2010 at 03:34:44PM +0200, Giangiacomo Mariotti wrote: >> On Mon, Jul 12, 2010 at 9:09 AM, Michael Tokarev wrote: >>> >>> This looks quite similar to a problem with ext4 and O_SYNC which I >>> reported earlier but no one cared to answer (or read?) - there: >>> http://permalink.gmane.org/gmane.linux.file-systems/42758 >>> (sent to qemu-devel and linux-fsdevel lists - Cc'd too). You can >>> try a few other options, esp. cache=none and re-writing some guest >>> files to verify. >>> >>> /mjt >>> >> Either way, changing to cache=none I suspect wouldn't tell me much, >> because if it's as slow as before, it's still unusable and if instead >> it's even slower, well it'd be even more unusable, so I wouldn't be >> able to tell the difference. What I can say for certain is that with >> the exact same virtual hd file, same options, same system, but on an >> ext3 fs there's no problem at all, on a Btrfs is not just slower, it >> takes ages. >> > > O_DIRECT support was just introduced recently, please try on the latest kernel > with the normal settings (which IIRC uses O_DIRECT), that should make things > suck alot less. IIUC, he uses the default cache option of qemu, which is cache=writethrough and maps to O_DSYNC without O_DIRECT. O_DIRECT would only be used for cache=none. Kevin