On Wed, Jun 03, 2015 at 02:59:54PM +0530, Chandan Rajendra wrote: > max_to_defrag represents the number of pages to defrag rather than the last > page of the file range to be defragged. Fix this.
Please update the changelog and describe the buggy behaviour. From a brief look I think that the defrag batch will be much higher than desired. Elsewhere the defrag batch is 1024, the page indexes used here are always large numbers. I guess this could (partially) explain high load during defrag that people report. ACK for the fix, I'll stick a reviewed-by to v2. > > Signed-off-by: Chandan Rajendra <[email protected]> > --- > fs/btrfs/ioctl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c > index ca5d968..2a45026 100644 > --- a/fs/btrfs/ioctl.c > +++ b/fs/btrfs/ioctl.c > @@ -1318,7 +1318,7 @@ int btrfs_defrag_file(struct inode *inode, struct file > *file, > i = range->start >> PAGE_CACHE_SHIFT; > } > if (!max_to_defrag) > - max_to_defrag = last_index + 1; > + max_to_defrag = last_index - i + 1; > > /* > * make writeback starts from i, so the defrag range can be > -- > 2.1.0 > > -- > 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 -- 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
