From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33626 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OE23Z-0003rW-9m for qemu-devel@nongnu.org; Mon, 17 May 2010 11:16:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OE23T-0001WI-Jx for qemu-devel@nongnu.org; Mon, 17 May 2010 11:16:36 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:60101) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OE23T-0001WB-AE for qemu-devel@nongnu.org; Mon, 17 May 2010 11:16:31 -0400 Received: by vws1 with SMTP id 1so879037vws.4 for ; Mon, 17 May 2010 08:16:30 -0700 (PDT) Message-ID: <4BF15DC8.8080104@codemonkey.ws> Date: Mon, 17 May 2010 10:16:24 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1274091292-4812-1-git-send-email-agraf@suse.de> <4BF13D5E.8090006@codemonkey.ws> <8397DB3E-B470-4FBD-903E-8B547631A825@suse.de> <4BF14007.2060603@codemonkey.ws> <095FC499-CB0E-4FB6-902F-0D64A62C8184@suse.de> <4BF1440E.9040209@codemonkey.ws> <4BF14CE9.5040907@suse.de> In-Reply-To: <4BF14CE9.5040907@suse.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Add cache=volatile parameter to -drive List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: kwolf@redhat.com, qemu-devel@nongnu.org, hch@lst.de On 05/17/2010 09:04 AM, Alexander Graf wrote: > Anthony Liguori wrote: > >> On 05/17/2010 08:17 AM, Alexander Graf wrote: >> >>> On 17.05.2010, at 15:09, Anthony Liguori wrote: >>> >>> >>> >>>> On 05/17/2010 08:02 AM, Alexander Graf wrote: >>>> >>>> >>>>>> My concern is that ext3 exaggerates the cost of fsync() which will >>>>>> result in diminishing value over time for this feature as people >>>>>> move to ext4/btrfs. >>>>>> >>>>>> >>>>>> >>>>> There will be ext3 file systems for years out. Just because people >>>>> can use better and faster file systems doesn't mean they do. And >>>>> I'm sure they can't always choose. If anything, I can try and see >>>>> what the numbers look like for xfs. >>>>> >>>>> >>>>> >>>> But ext3 with barrier=1 is pretty uncommon in practice. Another >>>> data point would be an ext3 host file system with barrier=0. >>>> >>>> >>> Who defines what is common and what not? To me, the SLES11 default is >>> common. In fact, the numbers in the referred mail were done on an >>> 11.1 system. >>> >>> >> But it wasn't the SLES10 default so there's a smaller window of >> systems that are going to be configured this way. But this is >> orthogonal to the main point. Let's quantify how important this >> detail is before we discuss the affected user base. >> > Alright. I took my Netbook (2GB of RAM) and a USB hard disk, so I can > easily remount the data fs the vmdk image is on. Here are the results: > > # mkfs.ext3 /dev/sdc1 > # mount /dev/sdc1 /mnt -obarrier=1 > > cache=writeback > > real 0m52.801s > user 0m16.065s > sys 0m6.688s > > cache=volatile > > real 0m47.876s > user 0m15.921s > sys 0m6.548s > > # mount /dev/sdc1 /mnt -obarrier=0 > > cache=writeback > > real 0m53.588s > user 0m15.901s > sys 0m6.576s > > cache=volatile > > real 0m48.715s > user 0m16.581s > sys 0m5.856s > > I don't see a difference between the results. Apparently the barrier > option doesn't change a thing. > Ok. I don't like it, but I can see how it's compelling. I'd like to see the documentation improved though. I also think a warning printed on stdio about the safety of the option would be appropriate. Regards, Anthony Liguori > > Alex > >