BTRFS critical, corrupt leaf (can't read superblock on /dev/sda2)


somehow, my btrfs partition with my operation system got corrupted.

I think it was caused by system freeze during the btrfs balancing operation.
As several users of this forum, I've experienced system freezes, forcing me to hard restart every time they occur. So I've decided to balance the file system and then switch to the lts kernel.
Unfortunately, a freeze occurred during the balancing procedure.

When I boot, the error "BTRF critical (device sda2(?)) corrupt leaf" quickly flashes on screen and then the garuda update screen (the one with the logo in an animated circle) comes up.
I've let it run for 10 hours without any changes.

I did search for the error online, yet did not find a conclusive answer.
When I try to access the partition via a live usb, I get the following error message:

An error occurred while accessing 'Home', the system responded: The requested operation has failed: Error mounting /dev/sda2 at /run/media/garuda/8b782b3f-9cd5-4d15-8596-8ef5e81954cf: can't read superblock on /dev/sda2

As I've looked for it, I found the


command, which according to its man page appears to be exactly what I'm looking for.
Should I do it?
And do you need any extra information from my current state?

Here is my inxi which I receive when booting from a live usb:

inxi -Faz
System:    Kernel: 5.14.8-zen1-1-zen x86_64 bits: 64 compiler: gcc v: 11.1.0  
parameters: BOOT_IMAGE=/boot/vmlinuz-x86_64 lang=en_US keytable=us tz=UTC misobasedir=garuda  
misolabel=GARUDA_DR460NIZEDGAMING_HARPYEAG quiet systemd.show_status=1 driver=free
nouveau.modeset=1 i915.modeset=1 radeon.modeset=1
Desktop: KDE Plasma 5.22.5 tk: Qt 5.15.2 info: latte-dock wm: kwin_x11 vt: 1 dm: SDDM  
Distro: Garuda Linux base: Arch Linux  
Machine:   Type: Desktop Mobo: Micro-Star model: Z370 PC PRO (MS-7B49) v: 1.0 serial: <filter>  
UEFI: American Megatrends v: 1.00 date: 09/04/2017  
CPU:       Info: 6-Core model: Intel Core i5-8600K bits: 64 type: MCP arch: Kaby Lake note: check  
family: 6 model-id: 9E (158) stepping: A (10) microcode: EA cache: L2: 9 MiB  
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 43200  
Speed: 4264 MHz min/max: 800/4300 MHz Core speeds (MHz): 1: 4264 2: 4276 3: 4281 4: 4203  
5: 4200 6: 4254  
Vulnerabilities: Type: itlb_multihit status: KVM: VMX disabled  
Type: l1tf mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled  
Type: mds mitigation: Clear CPU buffers; SMT disabled  
Type: meltdown mitigation: PTI  
Type: spec_store_bypass mitigation: Speculative Store Bypass disabled via prctl and seccomp  
Type: spectre_v1 mitigation: usercopy/swapgs barriers and __user pointer sanitization  
Type: spectre_v2  
mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: disabled, RSB filling  
Type: srbds mitigation: Microcode  
Type: tsx_async_abort mitigation: TSX disabled  
Graphics:  Device-1: NVIDIA GP106 [GeForce GTX 1060 6GB] vendor: Micro-Star MSI driver: nouveau v: kernel  
bus-ID: 01:00.0 chip-ID: 10de:1c03 class-ID: 0300  
Display: x11 server: X.Org 1.20.13 compositor: kwin_x11 driver: loaded: nouveau  
unloaded: modesetting alternate: fbdev,nv,vesa display-ID: :0 screens: 1  
Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.0x11.2") s-diag: 582mm (22.9")  
Monitor-1: DP-2 res: 1920x1080 hz: 60 dpi: 94 size: 521x293mm (20.5x11.5") diag: 598mm (23.5")  
OpenGL: renderer: NV136 v: 4.3 Mesa 21.2.2 direct render: Yes  
Audio:     Device-1: Intel 200 Series PCH HD Audio vendor: Micro-Star MSI driver: snd_hda_intel v: kernel  
bus-ID: 00:1f.3 chip-ID: 8086:a2f0 class-ID: 0403  
Device-2: NVIDIA GP106 High Definition Audio vendor: Micro-Star MSI driver: snd_hda_intel  
v: kernel bus-ID: 01:00.1 chip-ID: 10de:10f1 class-ID: 0403  
Device-3: C-Media CM108 Audio Controller type: USB driver: hid-generic,snd-usb-audio,usbhid  
bus-ID: 1-4:3 chip-ID: 0d8c:013c class-ID: 0300  
Sound Server-1: ALSA v: k5.14.8-zen1-1-zen running: yes  
Sound Server-2: JACK v: 1.9.19 running: no  
Sound Server-3: PulseAudio v: 15.0 running: no
Sound Server-4: PipeWire v: 0.3.37 running: yes
Network:   Device-1: Intel Ethernet I219-V vendor: Micro-Star MSI driver: e1000e v: kernel port: f000
bus-ID: 00:1f.6 chip-ID: 8086:15b8 class-ID: 0200
IF: enp0s31f6 state: down mac: <filter>
Device-2: Qualcomm Atheros AR93xx Wireless Network Adapter driver: ath9k v: kernel port: e000
bus-ID: 04:00.0 chip-ID: 168c:0030 class-ID: 0280
IF: wlp4s0 state: down mac: <filter>
Drives:    Local Storage: total: 2.3 TiB used: 0 KiB (0.0%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/sda maj-min: 8:0 vendor: Crucial model: CT500MX500SSD1 size: 465.76 GiB block-size:
physical: 512 B logical: 512 B speed: 6.0 Gb/s type: SSD serial: <filter> rev: 023 scheme: GPT
ID-2: /dev/sdb maj-min: 8:16 vendor: Toshiba model: DT01ACA200 size: 1.82 TiB block-size:
physical: 4096 B logical: 512 B speed: 6.0 Gb/s type: HDD rpm: 7200 serial: <filter> rev: ABB0
scheme: GPT
ID-3: /dev/sdc maj-min: 8:32 type: USB vendor: Intenso model: Ultra Line size: 29.3 GiB
block-size: physical: 512 B logical: 512 B type: N/A serial: <filter> scheme: MBR
SMART Message: Unknown USB bridge. Flash drive/Unsupported enclosure?
Swap:      Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default)
ID-1: swap-1 type: zram size: 31.31 GiB used: 0 KiB (0.0%) priority: 100 dev: /dev/zram0
Sensors:   System Temperatures: cpu: 29.8 C mobo: 27.8 C gpu: nouveau temp: 43.0 C
Fan Speeds (RPM): N/A gpu: nouveau fan: 0
Info:      Processes: 204 Uptime: 46m wakeups: 0 Memory: 31.31 GiB used: 3.26 GiB (10.4%) Init: systemd
v: 249 tool: systemctl Compilers: gcc: 11.1.0 clang: 12.0.1 Packages: pacman: 1706 lib: 500
Shell: fish v: 3.3.1 default: Bash v: 5.1.8 running-in: konsole inxi: 3.3.06

Hello. Try mount FS with -o recovery. And write the result.

1 Like

Is this the right way of using it? (edited)

[🔴] × sudo mount -o recovery /dev/sda2 /mnt
mount: /mnt: can't read superblock on /dev/sda2.

... Try offline check (btrfs check)

1 Like
[🔴] × sudo btrfs check /dev/sda2
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: 8b782b3f-9cd5-4d15-8596-8ef5e81954cf
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
root 257 inode 296 errors 200, dir isize wrong
root 257 inode 2272337 errors 1, no inode item
unresolved ref dir 296 index 15876 namelen 32 name Dr460nized - 2.layout.latte.lock filetype 1 errors 5, no dir item, no inode ref
ERROR: errors found in fs roots
found 177300512768 bytes used, error(s) found
total csum bytes: 165439396
total tree bytes: 1692434432
total fs tree bytes: 1370996736
total extent tree bytes: 119144448
btree space waste bytes: 295090317
file data blocks allocated: 258113986560
referenced 240352952320

Repeat check with --repair option.
Try reboot after repair.

[🔴] × sudo btrfs check --repair /dev/sda2 
enabling repair mode

Do not use --repair unless you are advised to do so by a developer
or an experienced user, and then only after having accepted that no
fsck can successfully repair all types of filesystem corruption. Eg.
some software or hardware bugs can fatally damage a volume.
The operation will start in 10 seconds.
Use Ctrl-C to stop it.
10 9 8 7 6 5 4 3 2 1
Starting repair.
Opening filesystem to check...
Checking filesystem on /dev/sda2
UUID: 8b782b3f-9cd5-4d15-8596-8ef5e81954cf
repair mode will force to clear out log tree, are you sure? [y/N]: y
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
super bytes used 177300578304 mismatches actual used 177300512768
No device size related problem found
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
[4/7] checking fs roots
Deleting bad dir index [296,96,15876] root 257
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups
Counts for qgroup id: 0/257 are different
our:            referenced 120609329152 referenced compressed 120609329152
disk:           referenced 120623104000 referenced compressed 120623104000
diff:           referenced -13774848 referenced compressed -13774848
our:            exclusive 120609329152 exclusive compressed 120609329152
disk:           exclusive 120623104000 exclusive compressed 120623104000
diff:           exclusive -13774848 exclusive compressed -13774848
Counts for qgroup id: 0/655 are different
our:            referenced 16130064384 referenced compressed 16130064384
disk:           referenced 16125706240 referenced compressed 16125706240
diff:           referenced 4358144 referenced compressed 4358144
our:            exclusive 221184 exclusive compressed 221184
disk:           exclusive 221184 exclusive compressed 221184
Counts for qgroup id: 0/835 are different
our:            referenced 16130064384 referenced compressed 16130064384
disk:           referenced 16125706240 referenced compressed 16125706240
diff:           referenced 4358144 referenced compressed 4358144
our:            exclusive 184320 exclusive compressed 184320
disk:           exclusive 184320 exclusive compressed 184320
Repair qgroup 0/257
Repair qgroup 0/655
Repair qgroup 0/835
Repair qgroup status item
found 354601107456 bytes used, no error found
total csum bytes: 330878792
total tree bytes: 3384950784
total fs tree bytes: 2741993472
total extent tree bytes: 238370816
btree space waste bytes: 590261594
file data blocks allocated: 516227973120
referenced 480705904640

Rebooting now. Wish me luck!

You are a magician! It worked!

1 Like

Now do btrfs scrub, defrag and balance. And everything will be fine if the power does not go out or the PC does not freeze during this process.

1 Like

In process!
To retrace the steps: when should I use the repair mode?
Or should I steer clear off it, unless told otherwise?

If you can mount the filesystem via liveusb, then don't btrfs check. In this case, do btrfs scrub via chroot. Otherwise, do btrfs check --repair (if the file system is not mounted. Also btrfs check --repair is not a 100% safe recovery method, in case of physical damage to the disk (badblocks), it can cause data loss).


You should diagnose this before you break your filesystem again.


I'm pretty sure it is the same issue as in

So far I've experienced no ussues when using the lts kernel. If there are no ussues in a week then I'll do the balancing.

1 Like

This suggests there is some sort of regression in 5.14, so using 5.10 for now is a good option. You could also try the standard linux kernel rather than linux-zen to see if it's something in the Zen sauce that's causing an issue.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.