Re: Balance metadata

---- From: Jorge Bastos [off-list ref] -- Sent: 2021-12-19 - 14:59 ----

Hello, I remember reading in the mailing list that we should avoid
balancing metadata, I have a filesystem that acts exclusive as receive
side for daily btrfs incremental snapshots from a couple of btrfs
filesystems containing 3 Windows VMs, it's composed of 5 HDDs in raid5
(raid1 metadata), the snapshots appear to be very metadata heavy, not
much data is changed daily, I noticed that the script was starting to
take much longer than in the beginning, it usually took a couple of
hours or so but I've been using for many months and it kept taking
longer and longer, especially in the last month, these are just some
examples from the last few days:


Script Starting Dec 06, 2021  02:30.01
Script Finished Dec 06, 2021  06:13.50

Script Starting Dec 12, 2021  02:30.01
Script Finished Dec 12, 2021  09:30.11

Script Starting Dec 16, 2021  02:30.01
Script Finished Dec 16, 2021  10:59.36

I'd like to keep this script limited to the night hours, so I thought
to try raid10 for metadata to see if it would help, and this was the
result:

Script Starting Dec 18, 2021  02:30.01
Script Finished Dec 18, 2021  03:52.21

Seeing this, I thought no way just raid10 would make such a big
difference, so I rebalanced the metadata to raid1 and this was the
result:

Script Starting Dec 19, 2021  02:30.01
Script Finished Dec 19, 2021  03:50.09

So it looks to me like that, at least in some cases, a metadata
balance can be beneficial, so I thought to share.

Regards,
Jorge Bastos

You might benefit from a general data balance too because balancing is really a free space defragmentation.

Space_cache=v2 mount option can help because it is more performant with free space fragmentation.

Another option is to defragment the metadata and extent trees.
 
Example :
# btrfs fi defrag -v /media/backup/
WARNING: directory specified but recursive mode not requested: /media/backup WARNING: a directory passed to the defrag ioctl will not process the files recursively but will defragment the subvolume tree and the extent tree. If this is not intended, please use option -r .

You would have to do this for each subvolume. It can't be done for read-only snapshots though.