From: brainchild@mailbox.org
To: linux-btrfs@vger.kernel.org
Subject: Understanding and resolving super mismatch error
Date: Fri, 01 May 2026 17:17:20 -0400 [thread overview]
Message-ID: <W4NDET.0Z0BXQT4DXWY2@mailbox.org> (raw)
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
reply other threads:[~2026-05-01 21:17 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=W4NDET.0Z0BXQT4DXWY2@mailbox.org \
--to=brainchild@mailbox.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox