Does btrfs filesystem defragment -r also include the trees?

Does btrfs filesystem defragment -r also include the trees?

[Remi Gauvin]

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?

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

[David Sterba]

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.

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.

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.

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

[Qu Wenruo]

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.

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

[Remi Gauvin]

On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
> 

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

It did *something* that allows Nautilus and Nemo to navigate a large
directory structure without stalling for > 10 seconds when moving back
and forth between subdirectories.

Unfortunately, I did not expect I would have to replicate this... I'll
see if I have an older snapshot and can do some kind of before and after
comparison.

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

[waxhead]

> On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
>>
> 
>>
>> I did a quick glance, btrfs_defrag_root() only defrags the target
>> subvolume, thus there is no way to defrag internal trees.
>>
> 
> It did *something* that allows Nautilus and Nemo to navigate a large
> directory structure without stalling for > 10 seconds when moving back
> and forth between subdirectories.
> 
Are you sure that it is not just files being cached?

If you run something like find -type f | parallel md5sum{} on the 
directory/subvolume you can see if it has the same effect.

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

[Forza]

On 2023-04-21 19:41, waxhead wrote:
>> On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
>>>
>>
>>>
>>> I did a quick glance, btrfs_defrag_root() only defrags the target
>>> subvolume, thus there is no way to defrag internal trees.
>>>
>>
>> It did *something* that allows Nautilus and Nemo to navigate a large
>> directory structure without stalling for > 10 seconds when moving back
>> and forth between subdirectories.
>>
> Are you sure that it is not just files being cached?
> 
> If you run something like find -type f | parallel md5sum{} on the 
> directory/subvolume you can see if it has the same effect.

Defragmenting the metadata/extent trees could reduce amount of seeks or 
the seek distance, which would reduce latency on HDDs.

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

[Remi Gauvin]

On 2023-04-21 1:41 p.m., waxhead wrote:

>>
> Are you sure that it is not just files being cached?
> 
> If you run something like find -type f | parallel md5sum{} on the
> directory/subvolume you can see if it has the same effect.

It's a problem I was observing for a very long time, and I'm positive
cache did not help.

However, I can not replicate it now on an older snapshot.  I think
something else mush have resolved the issue and I mistakenly gave credit
to experimenting with defrag.

Sorry for the noise, but to clarify:

btrfs filesystem defrag on a subvolume is *not* expected to have any
benefit without the -r switch?  It does spend several moments reading
and writing data.

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

[joshua]

On Friday, April 21, 2023 10:41 PDT, waxhead <waxhead@dirtcellar.net> wrote:

> > On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
> >>
> > 
> >>
> >> I did a quick glance, btrfs_defrag_root() only defrags the target
> >> subvolume, thus there is no way to defrag internal trees.
> >>
> > 
> > It did *something* that allows Nautilus and Nemo to navigate a large
> > directory structure without stalling for > 10 seconds when moving back
> > and forth between subdirectories.
> > 
> Are you sure that it is not just files being cached?
> 
> If you run something like find -type f | parallel md5sum{} on the 
> directory/subvolume you can see if it has the same effect.

It's definitely not ONLY files being cached.

I have a large array with 13 HDD's in it, and a total of 53GB of metadata.
I constantly have issues with the mount time being so long that Linux times out and drops to recovery mode.

However, if I regularly run `btrfs fi defrag` on each of my sub-volumes and the root volume, it makes a noticeable difference to mount time.  (Though still bad enough I gave up trying to have systemd mount my array and start my services.)

-- 
--Joshua Villwock

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

[Qu Wenruo]

On 2023/4/22 05:40, joshua wrote:
> On Friday, April 21, 2023 10:41 PDT, waxhead <waxhead@dirtcellar.net> wrote:
> 
>>> On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
>>>>
>>>
>>>>
>>>> I did a quick glance, btrfs_defrag_root() only defrags the target
>>>> subvolume, thus there is no way to defrag internal trees.
>>>>
>>>
>>> It did *something* that allows Nautilus and Nemo to navigate a large
>>> directory structure without stalling for > 10 seconds when moving back
>>> and forth between subdirectories.
>>>
>> Are you sure that it is not just files being cached?
>>
>> If you run something like find -type f | parallel md5sum{} on the
>> directory/subvolume you can see if it has the same effect.
> 
> It's definitely not ONLY files being cached.
> 
> I have a large array with 13 HDD's in it, and a total of 53GB of metadata.
> I constantly have issues with the mount time being so long that Linux times out and drops to recovery mode.

Then bg tree would be the ultimate solution.

> 
> However, if I regularly run `btrfs fi defrag` on each of my sub-volumes and the root volume, it makes a noticeable difference to mount time.  (Though still bad enough I gave up trying to have systemd mount my array and start my services.)
> 

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

[joshua]

For my situation, (and others with large arrays) yes definitely.
It's definitely the feature I'm most interested in patiently waiting for....

-- 
--Joshua Villwock

On Friday, April 21, 2023 15:55 PDT, Qu Wenruo <wqu@suse.com> wrote:

> 
> 
> On 2023/4/22 05:40, joshua wrote:
> > On Friday, April 21, 2023 10:41 PDT, waxhead <waxhead@dirtcellar.net> wrote:
> > 
> >>> On 2023-04-21 3:57 a.m., Qu Wenruo wrote:
> >>>>
> >>>
> >>>>
> >>>> I did a quick glance, btrfs_defrag_root() only defrags the target
> >>>> subvolume, thus there is no way to defrag internal trees.
> >>>>
> >>>
> >>> It did *something* that allows Nautilus and Nemo to navigate a large
> >>> directory structure without stalling for > 10 seconds when moving back
> >>> and forth between subdirectories.
> >>>
> >> Are you sure that it is not just files being cached?
> >>
> >> If you run something like find -type f | parallel md5sum{} on the
> >> directory/subvolume you can see if it has the same effect.
> > 
> > It's definitely not ONLY files being cached.
> > 
> > I have a large array with 13 HDD's in it, and a total of 53GB of metadata.
> > I constantly have issues with the mount time being so long that Linux times out and drops to recovery mode.
> 
> Then bg tree would be the ultimate solution.
> 
> > 
> > However, if I regularly run `btrfs fi defrag` on each of my sub-volumes and the root volume, it makes a noticeable difference to mount time.  (Though still bad enough I gave up trying to have systemd mount my array and start my services.)
> >

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

[Qu Wenruo]

On 2023/4/22 07:25, joshua wrote:
> For my situation, (and others with large arrays) yes definitely.
> It's definitely the feature I'm most interested in patiently waiting for....
> 

You can already compile the current btrfs-progs release with 
experimental features, which enables the "btrfstune -b" command to 
convert your existing btrfs to the new feature.

I believe David would release the next btrfs-progs with bg tree moved to 
regular features.

And even better, the new bg-tree feature is compat_ro, meaning 
unsupported kernel can still mount the fs RO.

Thanks,
Qu

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

[waxhead]

> 
> On 2023/4/22 07:25, joshua wrote:
>> For my situation, (and others with large arrays) yes definitely.
>> It's definitely the feature I'm most interested in patiently waiting 
>> for....
>>
> 
> You can already compile the current btrfs-progs release with 
> experimental features, which enables the "btrfstune -b" command to 
> convert your existing btrfs to the new feature.
> 
> I believe David would release the next btrfs-progs with bg tree moved to 
> regular features.
> 
> And even better, the new bg-tree feature is compat_ro, meaning 
> unsupported kernel can still mount the fs RO.
> 
> Thanks,
> Qu

And for those of us that have BTRFS as root? Would we live happily ever 
after or would GRUB choke on this?

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

[Qu Wenruo]

On 2023/4/23 17:34, waxhead wrote:
>>
>> On 2023/4/22 07:25, joshua wrote:
>>> For my situation, (and others with large arrays) yes definitely.
>>> It's definitely the feature I'm most interested in patiently waiting 
>>> for....
>>>
>>
>> You can already compile the current btrfs-progs release with 
>> experimental features, which enables the "btrfstune -b" command to 
>> convert your existing btrfs to the new feature.
>>
>> I believe David would release the next btrfs-progs with bg tree moved 
>> to regular features.
>>
>> And even better, the new bg-tree feature is compat_ro, meaning 
>> unsupported kernel can still mount the fs RO.
>>
>> Thanks,
>> Qu
> 
> And for those of us that have BTRFS as root? Would we live happily ever 
> after or would GRUB choke on this?

Compat_ro feature means, any implementation, which only does read-only 
operations, would be fine.

Although for GRUB, I'm not that confident about their implementation...

Thanks,
Qu