Re: Strange behavior with scrub, quotas, and snapshots

[brainchild@mailbox.org]

I am simply reporting on my observations.

Deleting all instances of the file corresponding to the identified 
inode, across all subvolumes, has resolved the problem with nbytes, but 
fix-device-size reported no action, and the super mismatch remains.

In case you have any further thoughts on finding a resolution, I am 
eager for any suggestions. I would like the volume to be fully healthy.

On Tue, Apr 28 2026 at 12:43:51 PM +09:30:00, Qu Wenruo <wqu@suse.com> 
wrote:
> 
> 
> 在 2026/4/28 12:03, brainchild 写道:
>> With swap disabled, the scrub operation seems to reach completion, 
>> with no errors found.
>>   \x7fHowever, the check operation still discovers the same errors.
> 
> Scrub is not a fsck, from man page of btrfs-scrub:
> 
> Note:
>         Scrub is not a filesystem checker (fsck, btrfs-check(8)). It 
> can only detect filesystem damage using the checksum validation, and 
> it can only repair filesystem damage by copying from other known good 
> replicas.
> 
>         btrfs-check(8) performs more exhaustive checking and can 
> sometimes be used, with expert guidance, to rebuild certain corrupted 
> filesystem structures in the absence of any good replica.
> 
> 
>>   \x7fThe output of `rescue fix-device-size' is "No device size related 
>> problem found".
>>   \x7fAfter, check still reports the same errors, including the super 
>> mismatch.
> 
> If you do not want to manually fix the nbytes mismatch, go "btrfs 
> check --repair", which may also help to fix the super block size 
> mismatch.