From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [ANNOUNCE] Native Linux KVM tool v2 Date: Thu, 16 Jun 2011 07:51:56 -0400 Message-ID: <20110616115156.GA3766@infradead.org> References: <20110616092429.GA5484@infradead.org> <20110616094810.GA19965@infradead.org> <20110616100239.GA29262@infradead.org> <20110616112230.GD26110@elte.hu> <20110616112552.GA15816@infradead.org> <20110616114045.GA27060@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Pekka Enberg , Anthony Liguori , Alexander Graf , Prasad Joshi , Avi Kivity , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Andrew Morton , Linus Torvalds , Sasha Levin , Cyrill Gorcunov , Asias He , Jens Axboe To: Ingo Molnar Return-path: Content-Disposition: inline In-Reply-To: <20110616114045.GA27060@elte.hu> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org On Thu, Jun 16, 2011 at 01:40:45PM +0200, Ingo Molnar wrote: > Filesystems that cannot guarantee that should map their > sync_file_range() implementation to fdatasync() or so, right? Filesystems aren't even told about sync_file_range, it's purely a VM thing, which is the root of the problem. In-kernel we have all the infrastructure for a real ranged fsync/fdatasync, and once we get a killer users for that can triviall export it at the syscall level. I don't think mapping sync_file_range with it's weird set of flags and confusing behaviour to it is a good idea, though.