Re: Strange behavior with scrub, quotas, and snapshots

[Qu Wenruo <wqu@suse.com>]

在 2026/4/29 07:49, 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

 From the dmesg, you're relocating only metadata block groups.

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.

> 
> 
> 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.
>>
> 
> 
>