Thunderbird is another one -- it uses mbox files by default, and maildir support is still experimental. Unfortunately, these files are rewritten frequently and may fragment quite a bit as a result. Should users be directed to "chattr +C" their thunderbird profile? What happens to crash resilience if they do this?
An alternative is to add a systemd unit to periodically defragment ~/.thunderbird.
If using a hard drive (spinning) and no other significant database operations, then autodefrag mount option is a better way of avoiding seek and rotational latency due to many fragments.
autodefrag
For SSDs I wonder if it's really noticeable, whether it shows up with bcc-tools fileslower or btrfsslower. It may not be due to fragments at all, but the fsync pattern (if any). Many fragments don't necessarily always result in a noticeable performance impact. But if they do, we'd need to better understand what's going on before deciding how to optimize.
If it turns out there's a real performance impact on SSDs with workloads of this kind, I think Btrfs developers will be more inclined to narrowly optimize rather than restoring to nodatacow or using autodefrag on the entire file system.
Also note, there's significant fsync optimizations coming to Btrfs in kernel 5.9.
Some few useful (or not so) tools which could help with browser profiles and data bases stored on BTRFS ready for testing in Fedora:
Log in to comment on this ticket.