All of lore.kernel.org
 help / color / mirror / Atom feed
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: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-01 21:17 brainchild [this message]
2026-05-14 19:38 ` Understanding and resolving super mismatch error brainchild

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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.