Re: Strange behavior with scrub, quotas, and snapshots

[brainchild@mailbox.org]

Further to the comments in the previous message, I have also found some 
messages in the kernel log, from the balance operations, which may be 
relevant.

As the console output of the command is "ERROR: error during balancing 
'/': No space left on device", the kernel messages are as shown below.

---

balance: start -musage=50 -susage=50
BTRFS info (device nvme0n1p5): relocating block group 4126692868096 
flags metadata|dup
BTRFS info (device nvme0n1p5): found 9279 extents, stage: move data 
extents
BTRFS info (device nvme0n1p5): relocating block group 4126155997184 
flags metadata|dup
BTRFS info (device nvme0n1p5): found 6365 extents, stage: move data 
extents
BTRFS info (device nvme0n1p5): relocating block group 4125149364224 
flags metadata|dup
BTRFS info (device nvme0n1p5): found 10145 extents, stage: move data 
extents
BTRFS info (device nvme0n1p5): relocating block group 4124612493312 
flags metadata|dup
BTRFS info (device nvme0n1p5): found 11487 extents, stage: move data 
extents
BTRFS info (device nvme0n1p5): 1 enospc errors during balance
BTRFS info (device nvme0n1p5): balance: ended with status: -28


On Tue, Apr 28 2026 at 03:30:00 PM -04:00:00, brainchild@mailbox.org 
wrote:
> 
> 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 
>> \x7falready experienced the limit on scrub, and I believe a lot of end 
>> \x7fusers are not aware of all the limits when using swap file on 
>> btrfs, \x7fplease check the long long list of limitations in "SWAPFILE 
>> SUPPORT" \x7fof 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, 
>> \x7fwhich 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, \x7fmetadata 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 
>> \x7fstrongly recommended to remove unused snapshots to free up space.
>> 
>> After freeing up enough space, then try to balance data block groups 
>> \x7fto 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.
>