From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [rfc] fsync_range? Date: Wed, 21 Jan 2009 04:59:21 +0000 Message-ID: <20090121045921.GA3944@shareable.org> References: <20090120164726.GA24891@wotan.suse.de> <20090120183120.GD27464@shareable.org> <20090121012900.GD24891@wotan.suse.de> <20090121031500.GA2354@shareable.org> <20090121041604.GI24891@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org To: Nick Piggin Return-path: Received: from mail2.shareable.org ([80.68.89.115]:49469 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756329AbZAUE7X (ORCPT ); Tue, 20 Jan 2009 23:59:23 -0500 Content-Disposition: inline In-Reply-To: <20090121041604.GI24891@wotan.suse.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Nick Piggin wrote: > 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). Oh, I agree about that. (Different meaning of metadata, btw. That's the term used in O_SYNC vs. O_DSYNC documentation for other unixes that I've read, that's why I used it in that flag, for consistency with other unixes.) > This is just another reason why I prefer to just try to evolve the > traditional fsync interface slowly. But sync_file_range() has a bug, which you've pointed out - the missing _data-retrieval_ metadata isn't synced. In other words, it's completely useless. If that bug isn't going to be fixed, delete sync_file_range() altogether. There's no point keeping it if it's broken. And if it's fixed, it'll do what your fsync_range() does, so why have both? -- Jamie