Re: [POC for v5.15 0/2] btrfs: defrag: what if v5.15 is doing proper defrag

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/2/4 19:05, François-Xavier Thomas wrote:
>> But one thing to mention is, the color scheme is little weird to me.
>
> Good point, here's a custom graph with just the write rate, that
> should be easier to read than the default graph with everything:
> https://i.imgur.com/vlRPOFr.png
>
> Waiting for your next update then. In the mean time are there other
> statistics I should collect that would make this easier to debug?

Here is my branch:

https://github.com/adam900710/linux/tree/autodefrag_fixes

This branch contains the following fixes which are not yet in misc-next
  branch:

("btrfs: defrag: bring back the old file extent search behavior")

   This addresses several problems exposed by Filipe, all related to the
   btrfs_get_extent() call which get heavily used in v5.16.

   Unfortunately, I don't yet have good idea on how to craft a pinpoint
   test case for it.

   Thus I'm not that confident whether this is the last piece.

("btrfs: populate extent_map::generation when reading from disk")

   And this problem is already there at least from v5.15.
   Thankfully it doesn't affect the autodefrag behavior yet.

("btrfs: defrag: allow defrag_one_cluster() to skip large extent which
is not a target")
("btrfs: defrag: make btrfs_defrag_file() to report accurate number of
defragged sectors")
("btrfs: defrag: use btrfs_defrag_ctrl to replace
btrfs_ioctl_defrag_range_args for btrfs_defrag_file()")
("btrfs: defrag: introduce btrfs_defrag_ctrl structure for later usage")
("btrfs: uapi: introduce BTRFS_DEFRAG_RANGE_MASK for later sanity check")

   This series has been sent the list, and is mostly a pure optimization
   to skip large extents faster, should not change the data write IO
   though.

("btrfs: defrag: remove an ambiguous condition for rejection")
("btrfs: defrag: don't defrag extents which is already at its max capacity")
("btrfs: defrag: don't try to merge regular extents with preallocated
extents")

   This series has been sent to the list, and is to address the old bad
   behavior around preallocated extents.

The base is misc-next branch from David, which is further based on
v5.17-rc2.

Thanks,
Qu


>
> Thanks,
> François-Xavier