Re: Strange behavior with scrub, quotas, and snapshots

[brainchild@mailbox.org]

On Wed, 2026-04-29 at 07:53 +0930, Qu Wenruo wrote:
> 

> >Then how did the problem of failing to create new files happen?

It began suddenly, with no clear cause.

The Timeshift snapshots had been causing serious lag since a few weeks 
earlier, but investigating had not yet become a top priority.

One similarity for the two times the problem has occurred is that I was 
running file searches across the whole system using 'find'. Perhaps 
something about these searches triggered the more immediate problem.

> >Any extra output when that happened?
> >Just returning -ENOSPC error messages but the fs is still read-write?

Yes, the FS is still RW.

> >Because you have no unallocated space so metadata can not be expanded
> >anymore.
> >
>> 
> >Meanwhile all the free space is inside data block groups, you need to
> >balance *only* data block groups to free up space for metadata.
> >
> >Not the opposite.

I already tried balancing just data, but there is no longer any 
benefit. It seems all of the data is already balanced. Otherwise, 
balance is failing to do its job.

Attempts to balance data now instantly complete, reporting nothing to 
do:

---
$ time sudo btrfs balance start -dusage=95 /
Done, had to relocate 0 out of 833 chunks

real 0m0.059s
user 0m0.000s
sys 0m0.013s
---

The only hint of any problem is from the kernel log:

---
_btrfs_printk: 788 callbacks suppressed
---

The other messages relate only to reporting blocks as skipped due to 
the swap file.

Earlier the more aggressive balance operations were failing, reporting 
no available space. From this situation, I started with -dusage=5, and 
then reached 95, in increments of 5. Each of the calls lasted no more 
than a few minutes, and in total only about ten blocks were reported as 
moved.

I would consider removing the swap file, but it would require shrinking 
the Btrfs partition, to make room for another partition dedicated to 
swap. I wonder whether it is safe to resize the volume, considering its 
unstable condition.
> 

Also, since the swap file is so small compared to the size of the 
volume, I doubt that it is causing the serious problems.