Re: [PATCH RFC 1/1] NFS: Allow nfs_updatepage to extend a write to cover a full page when we have a lock that covers the entire file

[Jeff Layton <jlayton@redhat.com>]

On Thu, 23 May 2013 22:30:10 +0000
"Myklebust, Trond" <Trond.Myklebust@netapp.com> wrote:

> On Thu, 2013-05-23 at 18:24 -0400, Jeff Layton wrote:
> > On Thu, 23 May 2013 17:53:41 -0400
> > Scott Mayhew <smayhew@redhat.com> wrote:
> > 
> > > Currently nfs_updatepage allows a write to be extended to cover a full
> > > page only if we don't have a byte range lock on the file... but if we've
> > > got the whole file locked, then we should be allowed to extend the
> > > write.
> > > 
> > > Signed-off-by: Scott Mayhew <smayhew@redhat.com>
> > > ---
> > >  fs/nfs/write.c | 7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/nfs/write.c b/fs/nfs/write.c
> > > index a2c7c28..f35fb4f 100644
> > > --- a/fs/nfs/write.c
> > > +++ b/fs/nfs/write.c
> > > @@ -908,13 +908,16 @@ int nfs_updatepage(struct file *file, struct page *page,
> > >  		file->f_path.dentry->d_name.name, count,
> > >  		(long long)(page_file_offset(page) + offset));
> > >  
> > > -	/* If we're not using byte range locks, and we know the page
> > > +	/* If we're not using byte range locks (or if the range of the
> > > +	 * lock covers the entire file), and we know the page
> > >  	 * is up to date, it may be more efficient to extend the write
> > >  	 * to cover the entire page in order to avoid fragmentation
> > >  	 * inefficiencies.
> > >  	 */
> > >  	if (nfs_write_pageuptodate(page, inode) &&
> > > -			inode->i_flock == NULL &&
> > > +			(inode->i_flock == NULL ||
> > > +			(inode->i_flock->fl_start == 0 &&
> > > +			inode->i_flock->fl_end == OFFSET_MAX)) &&
> > >  			!(file->f_flags & O_DSYNC)) {
> > >  		count = max(count + offset, nfs_page_length(page));
> > >  		offset = 0;
> > 
> > Sounds like a reasonable proposition, but I think you might need to do
> > more vetting of the locks...
> > 
> > For instance, does it make sense to do this if it's a F_RDLCK? Also,
> > you're only looking at the first lock in the i_flock list. Might it
> > make more sense to walk the list and see whether the page might be
> > entirely covered by a lock that doesn't extend over the whole file?
> > 
> 
> I'm guessing that the answer is to both these questions are "no":
> - Anybody who is writing while holding a F_RDLCK is likely doing
> something wrong.

Right, so I think we ought to be conservative here and not extend the
write if this is an F_RDLCK.

> - Walking the lock list on every write can quickly get painful if we
> have lots of small locks.
> 

True, but it's probably still preferable to do that than to do a bunch
of small I/Os to the server. But, that's an optimization that can be
done later. Hardly anyone does real byte-range locking so I'm fine with
this approach for now.

> However it may make a lot of sense to look at whether or not we hold a
> NFSv4 write delegation.
> 

Yes, that would be a good thing too. Having a helper function like you
suggested should make it easier to encapsulate that logic sanely.

-- 
Jeff Layton <jlayton@redhat.com>