On Mon, 2012-05-07 at 10:48 -0400, Chuck Lever wrote: > I thought the reason we wait for flush completion on close() was to report errors. No. The reason why we wait is to ensure close-to-open cache consistency. Cheers Trond > Sent from my iPad > > On May 7, 2012, at 10:07 AM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: > > > If we hold a delegation then we know that it should be safe to continue > > to cache the data beyond the close(). However since the process that wrote > > the data may die after close(), we may still want to send the data to > > server before those RPCSEC_GSS credentials expire. We therefore compromise > > by starting writeback to the server, but don't wait for completion. > > > > Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> > > --- > > fs/nfs/file.c | 7 +++++++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/fs/nfs/file.c b/fs/nfs/file.c > > index aa9b709..8eda8a6 100644 > > --- a/fs/nfs/file.c > > +++ b/fs/nfs/file.c > > @@ -174,6 +174,13 @@ nfs_file_flush(struct file *file, fl_owner_t id) > > if ((file->f_mode & FMODE_WRITE) == 0) > > return 0; > > > > + /* > > + * If we're holding a write delegation, then just start the i/o > > + * but don't wait for completion (or send a commit). > > + */ > > + if (nfs_have_delegation(inode, FMODE_WRITE)) > > + return filemap_fdatawrite(file->f_mapping); > > + > > /* Flush writes to the server and return any errors */ > > return vfs_fsync(file, 0); > > } > > -- > > 1.7.7.6 > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
