| Message ID | 1369346021-20041-2-git-send-email-smayhew@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Scott, On Thu, 2013-05-23 at 17:53 -0400, Scott Mayhew 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)) { Can we put this condition into a helper function? I started with the "nfs_write_pageuptodate()" thingy, but now we're starting to add in extra complications... Thanks! Trond > count = max(count + offset, nfs_page_length(page)); > offset = 0;
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?
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. - Walking the lock list on every write can quickly get painful if we have lots of small locks. However it may make a lot of sense to look at whether or not we hold a NFSv4 write delegation.
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.
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;
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(-)