From mboxrd@z Thu Jan  1 00:00:00 1970
From: Nick Piggin <npiggin@suse.de>
Subject: Re: [rfc] fsync_range?
Date: Wed, 21 Jan 2009 05:16:04 +0100
Message-ID: <20090121041604.GI24891@wotan.suse.de>
References: <20090120164726.GA24891@wotan.suse.de> <20090120183120.GD27464@shareable.org> <20090121012900.GD24891@wotan.suse.de> <20090121031500.GA2354@shareable.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: linux-fsdevel@vger.kernel.org
To: Jamie Lokier <jamie@shareable.org>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from ns2.suse.de ([195.135.220.15]:46344 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1755601AbZAUEQG (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Tue, 20 Jan 2009 23:16:06 -0500
Content-Disposition: inline
In-Reply-To: <20090121031500.GA2354@shareable.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Jan 21, 2009 at 03:15:00AM +0000, Jamie Lokier wrote:
> Nick Piggin wrote:
> An additional couple of flags to sync_file_range() would sort out the
> API:
> 
>    SYNC_FILE_RANGE_METADATA
> 
>       Commit the file metadata such as modification time and
>       attributes.  Think fsync() versus fdatasync().

Note that the problems with sync_file_range is not that it lacks a
metadata flag like fsync vs fdatasync. It is that it does not even
sync the metadata required to retrieve the data (which of course
fdatasync must do, otherwise it would be useless).

This is just another reason why I prefer to just try to evolve the
traditional fsync interface slowly.