From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: JFYI: ext4 bug triggerable by kvm Date: Mon, 16 Aug 2010 15:34:12 -0500 Message-ID: <4C69A0C4.2080102@codemonkey.ws> References: <4C694483.5010903@msgid.tls.msk.ru> <4C694E7D.3060600@codemonkey.ws> <20100816184237.GA16579@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Tokarev , KVM list , Kevin Wolf To: Christoph Hellwig Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:54039 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932185Ab0HPUeS (ORCPT ); Mon, 16 Aug 2010 16:34:18 -0400 Received: by gyg10 with SMTP id 10so2015622gyg.19 for ; Mon, 16 Aug 2010 13:34:17 -0700 (PDT) In-Reply-To: <20100816184237.GA16579@infradead.org> Sender: kvm-owner@vger.kernel.org List-ID: On 08/16/2010 01:42 PM, Christoph Hellwig wrote: > On Mon, Aug 16, 2010 at 09:43:09AM -0500, Anthony Liguori wrote: > >>> Also, ext4 is _very_ slow on O_SYNC writes (which is >>> used in kvm with default cache). >>> >> Yeah, we probably need to switch to sync_file_range() to avoid the >> journal commit on every write. >> >> > No, we don't. sync_file_range does not actually provide any data > integrity. > What do you mean by data integrity? For each write in cache=writethrough, we don't have to ensure the data is on the platter. We really just need to ensure that the data has been sent to next level in the storage hierarchy and that it has been acknowledged as having been written. We don't need to actually inject a barrier. My understanding is that on ext4/btrfs, an O_SYNC write injects a barrier for every write which is not the behavior we're looking for. As I understand it, sync_file_range() would give us the above guarantee without the barrier and for explicit barriers, we would use fsync. Regards, Anthony Liguori