[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110104083132.GA4485@amd>
Date: Tue, 4 Jan 2011 19:31:32 +1100
From: Nick Piggin <npiggin@...nel.dk>
To: Nick Piggin <npiggin@...nel.dk>
Cc: Christoph Hellwig <hch@...radead.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [patch 8/8] fs: add i_op->sync_inode
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists