From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jeff Garzik <jeff@garzik.org>
Subject: Re: [ANNOUNCE] Native Linux KVM tool v2
Date: Fri, 17 Jun 2011 03:21:56 -0400
Message-ID: <4DFB0094.7010605@garzik.org>
References: <7A30A509-47AA-4E72-ABF3-937005900F9D@suse.de> <4DF93010.1040006@codemonkey.ws> <4DF935C1.4020000@codemonkey.ws> <BANLkTikmUpF_fsZcpiuMzZQZa17U-cPQAw@mail.gmail.com> <BANLkTi=mS43KwRG13ROmZX+HmbrPMVgV=g@mail.gmail.com> <20110616092429.GA5484@infradead.org> <BANLkTinnSW=EEunCu_d51Mapiv=V03ncQw@mail.gmail.com> <20110616094810.GA19965@infradead.org> <BANLkTikoMZCFzA6jUw+ddHZ3x2cvO_NzhA@mail.gmail.com> <20110616100239.GA29262@infradead.org> <20110616112230.GD26110@elte.hu>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
	format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: Christoph Hellwig <hch@infradead.org>,
	Pekka Enberg <penberg@kernel.org>,
	Anthony Liguori <anthony@codemonkey.ws>,
	Alexander Graf <agraf@suse.de>,
	Prasad Joshi <prasadjoshi124@gmail.com>,
	Avi Kivity <avi@redhat.com>, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Sasha Levin <levinsasha928@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Asias He <asias.hejun@gmail.com>,
	Jens Axboe <jaxboe@fusionio.com>
To: Ingo Molnar <mingo@elte.hu>
Return-path: <linux-kernel-owner@vger.kernel.org>
In-Reply-To: <20110616112230.GD26110@elte.hu>
Sender: linux-kernel-owner@vger.kernel.org
List-Id: kvm.vger.kernel.org

On 06/16/2011 07:22 AM, Ingo Molnar wrote:
>
> * Christoph Hellwig<hch@infradead.org>  wrote:
>
>> On Thu, Jun 16, 2011 at 12:57:36PM +0300, Pekka Enberg wrote:
>>> Uh-oh. Someone needs to apply this patch to sync_file_range():
>>
>> There actually are a few cases where using it makes sense. [...]
>
> Such as? I don't think apps can actually know whether disk blocks
> have been 'instantiated' by a particular filesystem or not, so the
> manpage:
>
>     Some details
>         None  of these operations write out the file=E2=80=99s metada=
ta.  Therefore, unless the appli-
>         cation is strictly performing overwrites of already-instantia=
ted  disk  blocks,  there
>         are no guarantees that the data will be available after a cra=
sh.
>
> is rather misleading. This is a dangerous (and rather pointless)
> syscall and this should be made much clearer in the manpage.

Not pointless at all -- see Linus's sync_file_range() examples in "Re:=20
Unexpected splice "always copy" behavior observed" thread from May 2010=
=2E

Apps like MythTV may use it for streaming data to disk, basically=20
shoving the VM out of the way to give the app more fine-grained writeou=
t=20
control.

Just don't mistake sync_file_range() for a data integrity syscall.

	Jeff