I watched a production box crawl to a halt last week during a heavy write cycle. On the surface, the disks looked fine, and iostat didn’t show anything catastrophic. But the kernel was thrashing because Btrfs was trying to balance block groups while I was hammering the filesystem with a massive database dump. It’s a classic case of the filesystem trying to be helpful at the worst possible moment.

Why background balance is eating your IOPS

When Btrfs runs its automatic balance or metadata chunk allocation, it doesn’t always care if your application needs that disk bandwidth. Most people think their disk is just full or fragmented, but often the culprit is the kernel thread fighting for control over the write lock. If you aren’t monitoring the actual block group usage, you’re flying blind while the kernel manages space behind your back.

btrfs filesystem usage /mountpoint

• Check if you have unallocated space that could be manually pre-allocated
• Watch for block group fragmentation that triggers background reclaims
• Consider disabling autodefrag if you are running heavy sequential writes

If you see your write latency spiking during these automated background tasks, you might need to limit the balance speed or move those operations to a scheduled cron job during off-peak hours. Take control of the reclaim process, because the default behavior is optimized for general use, not for keeping your database alive under load. You’ll thank yourself the next time you have a midnight push and your system actually remains responsive.