From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ingo Molnar <mingo@elte.hu>
Subject: Re: [ANNOUNCE] Native Linux KVM tool v2
Date: Thu, 16 Jun 2011 13:22:30 +0200
Message-ID: <20110616112230.GD26110@elte.hu>
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>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: QUOTED-PRINTABLE
Cc: 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: Christoph Hellwig <hch@infradead.org>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx3.mail.elte.hu ([157.181.1.138]:45965 "EHLO mx3.mail.elte.hu"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754356Ab1FPLWr (ORCPT <rfc822;kvm@vger.kernel.org>);
	Thu, 16 Jun 2011 07:22:47 -0400
Content-Disposition: inline
In-Reply-To: <20110616100239.GA29262@infradead.org>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>


* 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():
>=20
> There actually are a few cases where using it makes sense. [...]

Such as? I don't think apps can actually know whether disk blocks=20
have been 'instantiated' by a particular filesystem or not, so the=20
manpage:

   Some details
       None  of these operations write out the file=E2=80=99s metadata.=
  Therefore, unless the appli-
       cation is strictly performing overwrites of already-instantiated=
  disk  blocks,  there
       are no guarantees that the data will be available after a crash.

is rather misleading. This is a dangerous (and rather pointless)=20
syscall and this should be made much clearer in the manpage.

Thanks,

	Ingo