Why I bothered making this an alias at all

Btrfs needs a bit more active maintenance than ext4 or XFS … it’s got its own checksumming, its own way of allocating chunks across a volume, and if you never touch it, things can quietly degrade in ways you won’t notice until something actually breaks. I got tired of typing three separate commands in the right order every time, so I turned it into one alias that does all three, in sequence, with actual visible output so I know what stage it’s on.

alias scrub='
sudo -v && \
echo -e "${YELLOW}\n─── 🔍 Starting Btrfs Scrub... ───────────────────────────────────────────────${NC}" && \
sudo btrfs scrub start -B / && echo "✅ Scrub done." && \
echo -e "${YELLOW}\n─── 🔄 Running Btrfs Balance (dusage=75, musage=75)... ─────────────────────────────${NC}" && \
sudo btrfs balance start -dusage=75 -musage=75 -v / && echo "✅ Balance done." && \
echo -e "${YELLOW}\n─── ✂️ Trimming Filesystems... ─────────────────────────────────────────────────${NC}" && \
sudo fstrim -av && echo "🚀 Trim completed."
'

Breaking down each piece

sudo -v … asks for the sudo password once, up front, before any of the actual work starts. Everything after this in the chain uses the cached credential instead of prompting mid-scrub. Small thing, but it means the whole alias runs uninterrupted once you’ve typed your password, instead of stopping to ask again partway through a long scrub.

btrfs scrub start -B / … this is the actual data integrity check. Btrfs reads every block, verifies its checksum, and automatically repairs anything that doesn’t match, using redundant copies if you’re on RAID1 or similar. -B runs it in the foreground instead of backgrounding it … I want to actually watch it happen and know exactly when it’s finished, not have it silently running while I do something else and forget about it.

btrfs balance start -dusage=75 -musage=75 -v / … this is the one most people skip, and the one that actually matters over time. Btrfs allocates storage in “chunks,” and as you delete and rewrite files, chunks can end up mostly empty but still allocated, wasting space and fragmenting your actual usable capacity.

-dusage=75 tells balance to only touch data chunks that are 75% full or less … meaning it consolidates the genuinely underused chunks and leaves the ones that are already efficiently packed alone. -musage=75 does the same thing for metadata chunks specifically.

I picked 75 deliberately, not the more aggressive numbers some guides throw around. A full, unrestricted balance (btrfs balance start / with no usage filter) rewrites everything, which on a real filesystem with real data takes a genuinely long time and hammers the disk the whole way through. Filtering at 75% means it only touches chunks that actually need consolidating, finishes in a fraction of the time, and does exactly the useful part of the job without the wasted effort on chunks that were already fine.

-v just gives verbose output … I want to see it actually working, not stare at a blank terminal wondering if it’s frozen or just slow.

fstrim -av … last step, and the simplest. Tells the SSD which blocks are no longer in use so the drive’s own controller can erase them ahead of time, keeping write performance from degrading over the drive’s life. -a runs it against every mounted filesystem that supports it, not just root … -v again just so I can see it actually did something rather than running silently.

Why in that specific order

Scrub first, because there’s no point balancing or trimming a filesystem that might have silent corruption sitting in it … fix data integrity before doing anything else. Balance second, because consolidating chunks before trimming means fstrim has a cleaner, more accurate picture of what’s actually free to trim, rather than trimming around a bunch of half-empty chunks that balance is about to rewrite anyway. Trim last, since it’s cheap and there’s no reason to do it before the more disruptive operations are done.

Running it

scrub

That’s it … the whole point of wrapping it in an alias. One word, three maintenance jobs, correct order, and coloured section headers so I can tell at a glance which stage it’s on without reading closely.

The thing I’d tell anyone copying this

Don’t blindly copy the 75 numbers without thinking about your own filesystem. On a mostly-static filesystem that doesn’t rewrite much data, a higher usage filter (say 90) means balance barely touches anything, since most chunks are already well-packed. On a filesystem that churns a lot … lots of file creation and deletion … a lower number does more consolidating work each run. 75 was the right middle ground for how I actually use my own machine, not a universal correct answer.