SSd speed dropped to 20MBps from 800 MBps in Btrfs

avi2772 · 2026-05-15 09:41:10

Hey, i am using Arch with LUKS2 encrypted btrfs with subvolume home and root and my ssd was filled above 80% which i cleaned it and reduced usages to 75%.
Now whenever i read or write from ssd speed is around 20 MBps.

I checked home usages with

sudo btrfs filesystem usage /home

and it is showing 99% used even though i have 129GB unallocated space.

Overall:
    Device size:		472.92GiB
    Device allocated:		343.07GiB
    Device unallocated:		129.85GiB
    Device missing:		    0.00B
    Device slack:		    0.00B
    Used:			339.90GiB
    Free (estimated):		132.69GiB	(min: 67.77GiB)
    Free (statfs, df):		132.69GiB
    Data ratio:			     1.00
    Metadata ratio:		     2.00
    Global reserve:		448.08MiB	(used: 0.00B)
    Multiple profiles:		       no

Data,single: Size:339.01GiB, Used:336.17GiB (99.16%)
   /dev/mapper/root	339.01GiB

Metadata,DUP: Size:2.00GiB, Used:1.87GiB (93.43%)
   /dev/mapper/root	  4.00GiB

System,DUP: Size:32.00MiB, Used:80.00KiB (0.24%)
   /dev/mapper/root	 64.00MiB

Unallocated:
   /dev/mapper/root	129.85GiB

Then i enabled the ssd trim and run

sudo fstrim -v /

which trimmed 133 GB. And after that i run the btrfs balance command

sudo btrfs balance start -dusage=100 /home

which moved 320 chunks out of 340 but still above home usage is showing 99% and btrfs speed is around 20MBPS. I check the raw root speed which came over 800MBps for 20GB write. Also when i installed this arch i checked at that time using fio and btrfs speed was more than 800MBps.

My arch is working is fine. I was playing mortal kombat 11 which was working without any issue. Only the copy speed is around 20MBps. What is this issue.

fam007e · 2026-05-15 10:07:03

Root Cause: CoW Fragmentation from Near-Full State

Your hardware is fine (800 MB/s raw). This is a btrfs-level problem caused by running the filesystem near 100% capacity.
What happened: btrfs uses Copy-on-Write. When your drive was >80% full, every write had to find tiny scattered free spaces across packed chunks. Files got written in thousands of small extents spread across the disk. That fragmentation persists even after you deleted data. Now every sequential read/write is effectively random I/O → 20 MB/s.
Secondary concern: Your metadata is at 93.43% (1.87GiB / 2.00GiB). This alone can cause severe slowdowns and can eventually cause btrfs to stall or deadlock on writes.

Fix Steps potentially could be...

1. Balance metadata first (critical)

sudo btrfs balance start -v -musage=50 /home

Forces btrfs to consolidate metadata chunks and allocate fresh ones from your 129 GB unallocated space.
2. Defragment to fix CoW fragmentation (the actual speed fix)

sudo btrfs filesystem defragment -r -v /home

Rewrites file extents contiguously. Temporarily increases space usage (CoW creates new extents before deleting old ones). With 132 GB free you are fine.
If you use compression:

sudo btrfs filesystem defragment -r -v -czstd /home

3. Run data balance after defrag

sudo btrfs balance start -v -dusage=75 /home

Lower threshold than your previous -dusage=100 — consolidates partially-used chunks more aggressively, freeing allocated-but-sparse chunk space back to unallocated.

Why Your Previous Balance Did Nothing

-dusage=100 tells btrfs to relocate chunks up to 100% full — so it relocated nearly everything, but just shuffled the same 336 GB of data into different 339 GB of allocation. The data-to-allocated ratio barely changed. You need to defragment first so data compacts, then balance so empty chunks get released back to unallocated.

Going Forward

Keep btrfs usage below 70-75%. CoW + metadata overhead degrades badly above that threshold.
Also add these mount options in

/etc/fstab

if not already present:

noatime,compress=zstd,space_cache=v2,discard=async

-discard=async — replaces manual fstrim runs.
-space_cache=v2 — more reliable than v1 for large filesystems.
-compress=zstd — reduces effective space usage and can improve throughput on compressible data.

avi2772 · 2026-05-15 11:54:29

Followed above step but still same 99% used is showing. Also i already have

noatime,compress=zstd,space_cache=v2,discard=async

in fstab. Is there anything else which can solve this issue.

WorMzy · 2026-05-15 15:20:38

fam007e, please refrain from posting LLM-generated text here. These forums are for humans.

avi2772 · 2026-05-24 02:25:32

Issue is resolved. First i have to defragment the whole root / then after that i had to balance the btrfs then speed recovered to 850MBps. Use the below commands to fix the issue.

sudo btrfs filesystem defragment -r ~/
sudo btrfs balance start -dusage=50 /

seth · 2026-05-24 07:18:34

\o/
Please always remember to mark resolved threads by editing your initial posts subject - so others will know that there's no task left, but maybe a solution to find.
Thanks.

topcat01 · 2026-05-24 22:48:31

Nice to know it's solved. However, I don't think it was a btrfs issue. Some SSDs need the data to be refreshed, otherwise reads become slow. When you ran defrag, it rewrote all the data, which makes them read fast again. See, for example, this answer. Sometimes rereading the whole disk can cause the controller to rewrite the degraded cells, which can be triggered by a scrub.

Arch Linux

#1 2026-05-15 09:41:10