From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nick Piggin Subject: Re: [patch 8/8] fs: add i_op->sync_inode Date: Tue, 4 Jan 2011 19:31:32 +1100 Message-ID: <20110104083132.GA4485@amd> References: <20101218014634.943276411@kernel.dk> <20101218015117.759480620@kernel.dk> <20101229151246.GA22033@infradead.org> <20110104062725.GD3402@amd> <20110104065736.GA8013@infradead.org> <20110104080323.GC4090@amd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Andrew Morton To: Nick Piggin Return-path: Content-Disposition: inline In-Reply-To: <20110104080323.GC4090@amd> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Jan 04, 2011 at 07:03:23PM +1100, Nick Piggin wrote: > On Tue, Jan 04, 2011 at 01:57:37AM -0500, Christoph Hellwig wrote: > > > Also giving filesystems the flexibility to do the data writeout can > > > be more optimal by doing all writeout at once or ordering to suit their > > > writeback patterns. Having range data could give some performance > > > advantages writing back mappings or commit operations over network. I > > > don't see it as a big complexity. It gives a chance to do range fsyncs > > > and sync_file_range and such properly too. > > > > We currently do all that just fine before calling into ->fsync. > > What do you mean we do all that just fine? A filesystem can't schedule > data submission and waiting optimally versus metadata, it can't do > metadata operations or remote commits corresponding to data ranges, and > it doesn't support nfs sync operations. And actually I think it is much better to have sync_inode, which means we'll be able to get rid of commit_metadata (which should be an inode operation anyway, not an export operation which really should deal with exporting filesystems to a non-vfs namespace, not nfsd hacks). commit_metadata would just be sync_inode with a null range or no data sync flag set.