Re: [PATCH v4 0/3] btrfs: fixes for defrag_check_next_extent()

[Filipe Manana <fdmanana@kernel.org>]

On Fri, Jan 28, 2022 at 03:21:19PM +0800, Qu Wenruo wrote:
> That function is reused between older kernels (v5.15) and the refactored
> defrag code (v5.16+).
> 
> However that function has one long existing bugs affecting defrag to
> handle preallocated range.
> 
> And it can not handle compressed extent well neither.
> 
> Finally there is an ambiguous check which doesn't make much sense by
> itself, and can be related by enhanced extent capacity check.
> 
> This series will fix all the 3 problem mentioned above.
> 
> Changelog:
> v2:
> - Use @extent_thresh from caller to replace the harded coded threshold
>   Now caller has full control over the extent threshold value.
> 
> - Remove the old ambiguous check based on physical address
>   The original check is too specific, only reject extents which are
>   physically adjacent, AND too large.
>   Since we have correct size check now, and the physically adjacent check
>   is not always a win.
>   So remove the old check completely.
> 
> v3:
> - Split the @extent_thresh and physicall adjacent check into other
>   patches
> 
> - Simplify the comment 
> 
> v4:
> - Fix the @em usage which should be @next.
>   As it will fail the submitted test case.
> 
> Qu Wenruo (3):
>   btrfs: defrag: don't try to merge regular extents with preallocated
>     extents
>   btrfs: defrag: don't defrag extents which is already at its max
>     capacity
>   btrfs: defrag: remove an ambiguous condition for rejection
> 
>  fs/btrfs/ioctl.c | 35 ++++++++++++++++++++++++++++-------
>  1 file changed, 28 insertions(+), 7 deletions(-)

There's something screwed up in the series:

$ b4 am cover.1643354254.git.wqu@suse.com
Looking up https://lore.kernel.org/r/cover.1643354254.git.wqu%40suse.com
Grabbing thread from lore.kernel.org/all/cover.1643354254.git.wqu%40suse.com/t.mbox.gz
Analyzing 5 messages in the thread
Checking attestation on all messages, may take a moment...
---
  [PATCH v4 1/3] btrfs: defrag: don't try to merge regular extents with preallocated extents
    + Reviewed-by: Filipe Manana <fdmanana@suse.com>
  [PATCH v4 2/3] btrfs: defrag: don't defrag extents which is already at its max capacity
  [PATCH v4 3/3] btrfs: defrag: remove an ambiguous condition for rejection
  ---
  NOTE: install dkimpy for DKIM signature verification
---
Total patches: 3
---
Cover: ./v4_20220128_wqu_btrfs_fixes_for_defrag_check_next_extent.cover
 Link: https://lore.kernel.org/r/cover.1643354254.git.wqu@suse.com
 Base: not specified
       git am ./v4_20220128_wqu_btrfs_fixes_for_defrag_check_next_extent.mbx

$ git am ./v4_20220128_wqu_btrfs_fixes_for_defrag_check_next_extent.mbx
Applying: btrfs: defrag: don't try to merge regular extents with preallocated extents
Applying: btrfs: defrag: don't defrag extents which is already at its max capacity
error: patch failed: fs/btrfs/ioctl.c:1229
error: fs/btrfs/ioctl.c: patch does not apply
Patch failed at 0002 btrfs: defrag: don't defrag extents which is already at its max capacity
hint: Use 'git am --show-current-patch=diff' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

Trying to manually pick patches 1 by 1 from patchwork, also results in the
same failure when applying patch 2/3.

Not sure why it failed, but I was able to manually apply the diffs.

Thanks.

> 
> -- 
> 2.34.1
>