Error in `btrfs': double free or corruption (fasttop)

English Applications
1

The btrfs on my OpenSUSE root partition ran out of space. Ran K4DirStats from my Ubuntu partition. The total file space used by the various directories came no where near 15 gigabytes, and yet Dolphin was reporting less than a megabyte of free space. Perplexing. I thought about where could that missing space be? So, I thought about it and decided that this looks like a file system error.

Out of curiosity, I used btrfs when I installed OpenSUSE on my only available partition. The installation suffered from mysterious freezes and lockups from day 1. I thought it was probably because Tumbleweed hadn’t been tested as thoroughly, so problems are not unexpected. I ended up running btrfsck under Ubuntu. Here’s the output:

xxxxx@wily-beast:~$ su
Password:
root@wily-beast:/home/xxxxx# btrfsck --repair /dev/sdb1
enabling repair mode
Checking filesystem on /dev/sdb1
UUID: 19a60e17-a5f1-4fc6-9fb4-95b1db21540f
checking extents
Fixed 0 roots.
checking free space cache
cache and super generation don’t match, space cache will be invalidated
checking fs roots
*** Error in `btrfs check’: double free or corruption (fasttop): 0x0000000004ee3d70 ***
Aborted (core dumped)
root@wily-beast:/home/xxxxx#

My googling for

btrfs “double: free or corruption (fasttop)”
showed 3 posts results with the search limited to the past year with the latest result dating from July. From what I made out from reading through the results is that it this is a bug with a released patch. I was last able to update the installation earlier this month. Is there a work abound or bug fix that I missed?

I’ll see if I can run zypper from the command line to update the installation. If that doesn’t result in a semi-miraculous fix and nothing helpful is posted here in the next 2 or 3 days, I’ll have no choice but to reinstall.

Now it won’t even boot to the KDE desktop or even to the graphical login screen. If OpenSUSE were my main production installation, I could probably get away with mounting OpenSUSE’s /tmp to /tmp on my Wily Ubuntu root partition in /etc/fstab, at least until I had time to reinstall & reconfigure.

On the plus side, I now know my OpenSUSE installation was so flaky.

2

Hi
If your at single user mode, try and zero the log;


btrfs-zero-log

Also have a look through here;
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ

3

I tried

btrfs-zero-log /dev/sdb1

No joy. I looked through the FAQ that you recommended. Nothing remotely relevant or even to try out of desperation. Thanks anyway.

At this point I’m pretty much resigned to reinstallation. I get internet access through a usb-tether to my phone. And of course, there’s a data cap for tethered connections. I’ll have to wait until I can get to the local library to download a new tumbleweed ISO.

In the meantime I’m willing to be reckless with the data on the partition. I’m up for anything that won’t result in harm to hardware or data on other partitions. It’s been a long time since I’ve been in a situation like this where I could maybe learn something by royally messing with a more or less working Linux installation.

4

Hi
OK, since you might have to re-install, run wipefs /dev/sdb and /dev/sdb1 to see which has the superblock, scan the device and post back the info.

5

Here you go:


root@wily-beast:/home/XXXX# wipefs /dev/sdb
offset               type
----------------------------------------------------------------
0x1fe                dos   [partition table]

root@wily-beast:/home/tim# wipefs /dev/sdb1
offset               type
----------------------------------------------------------------
0x1fe                dos   [partition table]

0x10040              btrfs   [filesystem]
                     LABEL: tumbleweed-root
                     UUID:  19a60e17-a5f1-4fc6-9fb4-95b1db21540f

root@wily-beast:/home/XXXX#