I thought the reason we wait for flush completion on close() was to report errors. 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 -- 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
