Understanding and resolving super mismatch error

Understanding and resolving super mismatch error

[brainchild]

I would like to resize a Btrfs volume, as I normally would do through 
Gparted.

Unfortunately, the check utility is reporting a problem:

---
[1/8] checking log skipped (none written)
[2/8] checking root items
[3/8] checking extents
super bytes used 756613705728 mismatches actual used 753279578112
ERROR: errors found in extent allocation tree or chunk allocation
[4/8] checking free space tree
[5/8] checking fs roots
[6/8] checking only csums items (without verifying data)
[7/8] checking root refs
[8/8] checking quota groups skipped (not enabled on this FS)
Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p5
UUID: bbac86e5-eaba-45bf-bbaa-c2494e11831a
found 753279516672 bytes used, error(s) found
total csum bytes: 483872008
total tree bytes: 8971255808
total fs tree bytes: 7809040384
total extent tree bytes: 558678016
btree space waste bytes: 1983819676
file data blocks allocated: 12001362440192
 referenced 1022445051904
---

I tried to resolve using `rescue fix-device-size`, but the results were 
unhelpful:

----
No device size related problem found
---

Gparted, as I recall, normally will not proceed to resize a partition 
that fails basic checks.

More importantly, I do not want to proceed while the health of the 
partition reduces the safety of the operation.

The system is using btrfs-progs version 6.6.3, though the check and 
rescue operations were performed in a recovery environment using 
version 6.17.1

Further information is reported below.

I would like some advice in regard to a few questions:

1. Does the super mismatch indicate an elevated risk of loss during a 
resize operation?

2. How can the error be resolved, so that the check succeeds, and the 
volume is fully healthy?

---

$ uname -a
Linux *** 7.0.2-070002-generic #202604271502 SMP PREEMPT_DYNAMIC Mon 
Apr 27 15:35:55 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

$ btrfs fi show
Label: none uuid: bbac86e5-eaba-45bf-bbaa-c2494e11831a
 Total devices 1 FS bytes used 703.67GiB
 devid 1 size 831.26GiB used 723.38GiB path /dev/nvme0n1p5

$ btrfs fi df /
Data, single: total=701.19GiB, used=692.17GiB
System, DUP: total=32.00MiB, used=144.00KiB
Metadata, DUP: total=11.06GiB, used=8.40GiB
GlobalReserve, single: total=512.00MiB, used=0.00B

Re: Understanding and resolving super mismatch error

[brainchild]

I hope it is not objectionable that I bump my question, first asked 
several weeks ago.

I also hope someone might try to offer some answers or suggestions.

I would like to be able to use the file system normally and safely, by 
resolving the errors, and I know of no channels for such support other 
than the mailing list.

Thank you.

On Fri, May 1 2026 at 05:17:20 PM -04:00:00, brainchild@mailbox.org 
wrote:
> I would like to resize a Btrfs volume, as I normally would do through 
> Gparted.
> 
> Unfortunately, the check utility is reporting a problem:
> 
> ---
> [1/8] checking log skipped (none written)
> [2/8] checking root items
> [3/8] checking extents
> super bytes used 756613705728 mismatches actual used 753279578112
> ERROR: errors found in extent allocation tree or chunk allocation
> [4/8] checking free space tree
> [5/8] checking fs roots
> [6/8] checking only csums items (without verifying data)
> [7/8] checking root refs
> [8/8] checking quota groups skipped (not enabled on this FS)
> Opening filesystem to check...
> Checking filesystem on /dev/nvme0n1p5
> UUID: bbac86e5-eaba-45bf-bbaa-c2494e11831a
> found 753279516672 bytes used, error(s) found
> total csum bytes: 483872008
> total tree bytes: 8971255808
> total fs tree bytes: 7809040384
> total extent tree bytes: 558678016
> btree space waste bytes: 1983819676
> file data blocks allocated: 12001362440192
> referenced 1022445051904
> ---
> 
> I tried to resolve using `rescue fix-device-size`, but the results 
> were unhelpful:
> 
> ----
> No device size related problem found
> ---
> 
> Gparted, as I recall, normally will not proceed to resize a partition 
> that fails basic checks.
> 
> More importantly, I do not want to proceed while the health of the 
> partition reduces the safety of the operation.
> 
> The system is using btrfs-progs version 6.6.3, though the check and 
> rescue operations were performed in a recovery environment using 
> version 6.17.1
> 
> Further information is reported below.
> 
> I would like some advice in regard to a few questions:
> 
> 1. Does the super mismatch indicate an elevated risk of loss during a 
> resize operation?
> 
> 2. How can the error be resolved, so that the check succeeds, and the 
> volume is fully healthy?
> 
> ---
> 
> $ uname -a
> Linux *** 7.0.2-070002-generic #202604271502 SMP PREEMPT_DYNAMIC Mon 
> Apr 27 15:35:55 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
> 
> $ btrfs fi show
> Label: none uuid: bbac86e5-eaba-45bf-bbaa-c2494e11831a
> Total devices 1 FS bytes used 703.67GiB
> devid 1 size 831.26GiB used 723.38GiB path /dev/nvme0n1p5
> 
> $ btrfs fi df /
> Data, single: total=701.19GiB, used=692.17GiB
> System, DUP: total=32.00MiB, used=144.00KiB
> Metadata, DUP: total=11.06GiB, used=8.40GiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
> 
> 
>