Re: Strange behavior with scrub, quotas, and snapshots

[brainchild@mailbox.org]

On Tue, Apr 28 2026 at 04:11:05 PM +09:30:00, Qu Wenruo <wqu@suse.com> 
wrote:
> 
> I strongly don't recommend to use swap files on btrfs, as you have 
> already experienced the limit on scrub, and I believe a lot of end 
> users are not aware of all the limits when using swap file on btrfs, 
> please check the long long list of limitations in "SWAPFILE SUPPORT" 
> of btrfs(5).

Is it expected that the scrub operation cannot function properly if the 
volume has a swap file? I never before observed such a problem, nor 
find any mention in the documentation.

The specific restrictions, as documented, for the swap file, seem 
completely compatible with my use, a single partition with no data 
duplication. I have no need for spanning devices or duplicating data, 
on the particular system.

> Any dmesg of that RO flips? That indicates the fs flipped read-only, 
> which is a huge problem by itself.

No. There are no kernel messages that are errors for the file system, 
or switches to read-only.

> Especially with your initial info, there should be enough data space, 
> metadata space is less ideal but should be enough.

I have read that the space allocated for metadata is expanded as 
needed. Why would problems follow from too little space being allocated?

> Considering how many snapshots you have (triggering qgroup lag), I 
> strongly recommended to remove unused snapshots to free up space.
> 
> After freeing up enough space, then try to balance data block groups 
> to make space for future metadata usages.

The situation with balance is quite confused.

The problem with the reported lack of free space first occurred several 
weeks ago. At that time, I deleted snapshots, and ran balance 
operations with incrementally higher usage values for data and 
metadata. By the end, I had run the operation, without reported 
failure, with values as high as 95%. Normally, such an operation would 
be very long, but in my case it finished in less than a minute. Also by 
the end, only about ten blocks in total had actually been reported as 
moved.

Perhaps my installation of btrfsd has been successfully maintaining the 
balance for the volume. The system logs are not extensive enough for me 
to know when it last performed any operations.

Regardless, it seems that the general problems are not becoming 
resolved by invocations of balance.