On Wed, Jan 25, 2017 at 01:49:09PM +0530, Chandan Rajendra wrote: > On Tuesday, January 24, 2017 03:58:51 PM Liu Bo wrote: > > Commit "d0b7da88 Btrfs: btrfs_page_mkwrite: Reserve space in sectorsized > > units" > > did this, but btrfs_lookup_ordered_range expects a 'length' rather than a > > 'page_end'. > > > > Signed-off-by: Liu Bo <[email protected]> > > --- > > Is this a candidate for stable? > > > > fs/btrfs/inode.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c > > index 4e02426..366cf0b 100644 > > --- a/fs/btrfs/inode.c > > +++ b/fs/btrfs/inode.c > > @@ -9023,7 +9023,7 @@ int btrfs_page_mkwrite(struct vm_area_struct *vma, > > struct vm_fault *vmf) > > * we can't set the delalloc bits if there are pending ordered > > * extents. Drop our locks and wait for them to finish > > */ > > - ordered = btrfs_lookup_ordered_range(inode, page_start, page_end); > > + ordered = btrfs_lookup_ordered_range(inode, page_start, PAGE_SIZE); > > if (ordered) { > > unlock_extent_cached(io_tree, page_start, page_end, > > &cached_state, GFP_NOFS); > > > > Thanks for fixing this, > Reviewed-by: Chandan Rajendra <[email protected]> > > As for the question about whether this commit should be merged into the stable > trees ... I am not sure about that since I don't notice any sort of filesystem > corruption that can be caused by the current code i.e. With the existing code, > apart from any ordered extents that map the page in question, we are most > likely to be *unnecessarily* starting i/o on ordered extents that don't map > the file offset range covered by the page. Chris, Josef or David, Please let > us know your thoughts on this.
It could be a performance regression which causes fault writes have unnecessary waits instead of a real corruption. Thanks, -liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
