Re: Does btrfs filesystem defragment -r also include the trees?

[Qu Wenruo <wqu@suse.com>]

On 2023/4/21 06:42, David Sterba wrote:
> On Thu, Apr 20, 2023 at 08:37:07AM -0400, Remi Gauvin wrote:
>> I have recently experienced that btrfs defragment (by itself, without
>> -r) of a subvolume can dramatically improve performance when accessing
>> very large directories.  I would go so far as to call it critical
>> maintenance when working with gtk3 based file managers.
>>
>> What I am not clear on, however, does adding the -r *also* defragment
>> the subvolume extent tree, or do the two commands needs to be run
>> separately to get the full effect?
> 
> No, -r does not defragment the extent tree, so if you really want to
> defragment the extent tree, then you need to run it separately and
> without -r.

I did a quick glance, btrfs_defrag_root() only defrags the target 
subvolume, thus there is no way to defrag internal trees.

> 
> Originally there was only the extent tree defragmentation which was
> confusing when defrag got a directory as an argument, then it always
> defragmented the extent tree but did not descend recursively. Then the
> -r was added and the bare directory path discouraged. It still works
> though.

My another concern is, does metadata "defrag" make any sense?

Btree itself is never designed for sequential read anyway, and even we 
can pack all metadata into a sequential bytenr, what's the proper order? 
Breadth-first? Depth-first?

Thanks,
Qu

> 
> I've checked if this is documented, it seems to (btrfs-filesystem,
> section defrag):
> 
> "NOTE: Directory  arguments  without -r do not defragment files
> recursively but will defragment certain internal trees (extent tree and
> the subvolume tree). This has been confusing and could be re- moved in
> the future."
> 
> but if you think it's not clear enough please suggest in what way it
> could be extended or what's missing.