I have the run the check command, which reported a variety of errors. 
The output is attached.

Are any recommendations available to attempt restoring the volume?

Thanks.

On Mon, Apr 27 2026 at 11:35:28 AM +09:30:00, Qu Wenruo 
<quwenruo.btrfs@gmx.com> wrote:
> 
> 
> 在 2026/4/27 09:22, brainchild@mailbox.org 写道:
>> Hello.
>> 
>> I am struggling with a poorly behaved BTRFS volume.
>> 
> [...]
>> ---
>> 
>> No errors are reported in the kernel log, only warnings about 
>> skipping the swap file during scrub.
> 
> If you assume the fs has some corruption, none of the above is really 
> useful.
> A full "btrfs check" is strongly recommended.
> 
>> 
>> 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.
> 
> The lag is mostly caused by qgroup.
> You have a lot of snapshots (shown by the super large snapshot id), 
> every time a large snapshot/subvolume is deleted, btrfs will try to 
> disable qgroup to avoid such lag, but if whatever script/tool decides 
> to rescan qgroup when the snapshot/subvolume deleting is still under 
> going, the lag will be re-introduced.
> 
>> 
>> 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.
> 
> "btrfs check" first, if no error, disable qgroup if you have frequent 
> snapshot creation/deletion.
> 
> Thanks,
> Qu
> 
>> 
>> Thank you.
>> 
>