From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=42784 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Oxj2D-0002fo-0j for qemu-devel@nongnu.org; Mon, 20 Sep 2010 12:16:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Oxirh-0001ZH-77 for qemu-devel@nongnu.org; Mon, 20 Sep 2010 12:05:14 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17359) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Oxirg-0001Z6-VI for qemu-devel@nongnu.org; Mon, 20 Sep 2010 12:05:13 -0400 Message-ID: <4C978633.7060606@redhat.com> Date: Mon, 20 Sep 2010 18:05:07 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] block-queue: Delay and batch metadata writes References: <1284991010-10951-1-git-send-email-kwolf@redhat.com> <4C977028.3050602@codemonkey.ws> <4C9778EC.9060704@redhat.com> <4C978313.9060402@codemonkey.ws> In-Reply-To: <4C978313.9060402@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , qemu-devel@nongnu.org On 09/20/2010 05:51 PM, Anthony Liguori wrote: > On 09/20/2010 10:08 AM, Kevin Wolf wrote: >> >>> If you're comfortable with a writeback cache for metadata, then you >>> should also be comfortable with a writeback cache for data in which >>> case, cache=writeback is the answer. >> Well, there is a difference: We don't pollute the host page cache with >> guest data and we don't get a virtual "disk cache" as big as the host >> RAM, but only a very limited queue of metadata. > > Would it be a mortal sin to open the file twice and have a cache=none > version for data and cache=writeback for metadata? > > The two definitely aren't consistent with each other but I think the > whole point here is that we don't care. > > It opens up some other possibilities too like cache=none for data and > cache=writethrough for metadata which may be a useful combination. I've thought of this (and I think perhaps suggested it on this list). The question is whether the kernel doesn't slow direct io when page cache is present for the file (but in unconflicting ranges). I think it's considered a valid use case (backing up a database file while the database is O_DIRECTing into it) but I don't know if the code was actually updated to support this. -- error compiling committee.c: too many arguments to function