Re: Salvaging the performance of a high-metadata filesystem

[Matt Corallo <blnxfsl@bluematt.me>]

On 3/4/23 12:24 AM, Forza wrote:
> Unless you need to, replace relatime with noatime. This makes a big difference when you have lots of 
> reflinks or snapshots as it avoids de-duplication of metadata when the atimes are updated.

Yea, I've done that now, thanks. I'm vaguely surprised this big a footgun is the default, and not 
much more aggressively in the subvolume manpage, at least.

> Not sure if running with multiple profiles will cause issues or slowness, but it might be good to 
> try to convert the old raid1c3 data chunks into raid1 over time. You can use balance filters to 
> minimise the work each run.

I don't think that's really an option. It took something like six months or a year to get as much 
raid1c3 as there is, and the filesystem has slowed down considerably since. Trying to rate-limit 
going back just means it'll take forever instead.

> # btrfs balance start -dconvert=raid1,soft,limit=10 /bigraid
> 
> This will avoid balancing blockgroups already in RAID1 (soft option) and limit to only balance 10 
> block groups. You can then schedule this during times with less active I/O.
> 
> It is also possible to defragment the subvolume and extent trees[*]. This could help a little, 
> though if the filesystem is frequently changing it might only be a temporary thing. It can also take 
> a long time to complete.

IIUC that can de-share the metadata from subvolumes though, no? Which is a big part of the 
(presumed) problem currently.

> # btrfs filesystem defragment /path/to/subvolume-root
> 
> [*] https://wiki.tnonline.net/w/Btrfs/Defrag#Defragmenting_the_subvolume_and_extent_trees
>