Hello.

I am struggling with a poorly behaved BTRFS volume.

It is a simple volume, consuming only one partition, with no redundancy 
for data. The underlying media, which is NVME, appears to be completely 
healthy, according to SMART.

Several weeks ago, the volume became unwriteable, with false reports 
generated that no space was available, whenever would be attempted the 
creation of a new file.

After a chaotic intermix of balance and scrub operations, as well as 
the deletion of many snapshots and a few large files, a message 
eventually appeared in the kernel log reporting the discovery of 
corruption in the space cache, that had since been resolved.

After, the volume again was usable, with no problems writing files.

Incidentally, I later upgraded to space cache version 2.

Although the episode of complete dysfunction has ended, problems 
remain. In particular are two observations.

First, scrub operations complete almost immediately, reporting a status 
of "finished", with no errors found.

However, as seen also seen in the following console capture, the 
reported amount of total data scanned is only a fraction of the total 
used space:

---
$ btrfs --version
btrfs-progs v6.6.3

$ btrfs fi show
Label: none uuid: bbac86e5-eaba-45bf-bbaa-c2494e11831a
 Total devices 1 FS bytes used 671.85GiB
 devid 1 size 831.26GiB used 831.26GiB path /dev/nvme0n1p5

$ sudo btrfs filesystem df /
Data, single: total=813.13GiB, used=662.49GiB
System, DUP: total=32.00MiB, used=144.00KiB
Metadata, DUP: total=9.03GiB, used=6.26GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

$ sudo btrfs scrub start -B /
Starting scrub on devid 1
scrub done for bbac86e5-eaba-45bf-bbaa-c2494e11831a
Scrub started: Sun Apr 26 19:24:02 2026
Status: finished
Duration: 0:00:11
Total to scrub: 23.37GiB
Rate: 2.12GiB/s
Error summary: no errors found
---

No errors are reported in the kernel log, only warnings about skipping 
the swap file during scrub.

Second, within the logs generated for Timeshift, a concerning pattern 
recurs, as in the attached example. Further, during the periods in 
which are generated logs such as the one attached, the entire system 
lags considerably. It is clear that the volume is not healthy.

I was using a recent 6.x kernel, I believe one of 6.18.x, when the 
problem emerged. I upgraded by to 7.0, finding no improvement in the 
operation of the volume.

Also, I tried initiating the scrub through the most recent static build 
of the user-space utility (i.e. btrfs-progs), with no improvement.

I would like some suggestions for restoring the volume to health, to 
avoid the need to provision a new volume from scratch.

Thank you.