8

I have an external drive formatted with BTRFS that seems refuses to mount:

$ sudo mount -vs -t btrfs  -o ro,recovery,errors=continue /dev/sdb2 /media/user/dir
mount: /dev/sdb2: can't read superblock

However, when BTRFS thinks that all the superblocks are okay:

$ sudo btrfs rescue super-recover -v /dev/sdb2                 
All Devices:
        Device: id = 1, name = /dev/sdb2

Before Recovering:
        [All good supers]:
                device name = /dev/sdb2
                superblock bytenr = 65536

                device name = /dev/sdb2
                superblock bytenr = 67108864

                device name = /dev/sdb2
                superblock bytenr = 274877906944

        [All bad supers]:

All supers are valid, no need to recover

And if I try specifying sb=$((67108864/4)) (mount uses 1k units, so you have to divide by 4 on a system with 4k blocks) to use one of the alternative superblocks, I get the same error. btrfs restore also seems to have no trouble reading data from the drive, and btrfs check complains only about an invalid cache entry (and clear_cache doesn't help when mounting). This has happened once before on another drive and btrfs check --repair also didn't work.[1] As there is a large amount of data on this drive, I'm a bit reluctant to copy everything elsewhere with btrfs restore (which also means finding space elsewhere), reformat, and copy everything back.

Is there a way to fix this issue? Is there a way to invoke btrfs directly so that it performs the mount instead of relying on mount? I couldn't find a mount.btrfs.

[1] I'm a bit reluctant to use btrfs check --repair as it is comes with lots of warnings about being a measure of last resort, especially after it not working previously.

Livius
  • 241
  • 2
  • 5
  • Did you try without dividing? `man mount` only says to divide in the `ext2` section – Tom Hale Sep 07 '17 at 11:31
  • 1
    @Tom-Hale I got the division bit from the btrfs wiki, if I recall correctly. The problem took care of itself during a later reboot (with the drive attached, if I recall correctly), but that's not really an "answer" because it doesn't address what went wrong nor how the mount operation during reboot differs from the mount operation on a booted system. – Livius Sep 08 '17 at 08:52
  • I've had issues because of `umount -l` with btrfs. Did you use that perchance? – Tom Hale Sep 08 '17 at 11:25

2 Answers2

3

I have Btrfs as rootfs and experienced a similar issue on Ubuntu 18.04 after a system freeze. The Btrfs failed to mount on the next boot. I use Ubuntu LiveUSB to boot and btrfs rescue zero-log fixed the issue for me.

Detail:

$ sudo mount -o ro /dev/nvme0n1p2 /2
mount: /2: can't read superblock on /dev/nvme0n1p2.

(First, I backup the partition with dd to external storage device.)

btrfs check --check-data-csum indicates everything is fine. btrfs inspect-internal dump-super says superblock is fine, and btrfs rescue super-recover indicates there is nothing to repair.

But I noticed the following kernel message after mount attempt

BTRFS info (device nvme0n1p2): start tree-log replay
BTRFS critical (device nvme0n1p2): corrupt leaf: root=18446744073709551610 block=1252150951936 slot=129 ino=7029 file_offset=164888576, file extent end range (169345024) goes beyond start offset (168624128) of the next file extent
BTRFS error (device nvme0n1p2): block=1252150951936 read time tree block corruption detected
BTRFS: error (device nvme0n1p2) in btrfs_replay_log:2281: errno=-5 IO failure (Failed to recover log tree)
BTRFS info (device nvme0n1p2): delayed_refs has NO entry
BTRFS error (device nvme0n1p2): open_ctree failed

It seems the tree log is corrupted. I find btrfs rescue --help says

btrfs rescue zero-log <device>
    Clear the tree log. Usable if it's corrupted and prevents mount.

and btrfs rescue zero-log fixed the issue.

$ sudo btrfs rescue zero-log /dev/nvme0n1p2
Clearing log on /dev/nvme0n1p2, previous log_root 1252152229888, level 0
Orange Kao
  • 31
  • 2
1

Simply Reboot

Looks like Btrfs has issues with changing block device file names (like /dev/sda). I've had the same problem:

Created a Btrfs filesystem, wrte some data, unmounted, removed the disk from my system (it's a 2.5" SATA drive). A week later I reconnected the drive with hotswap, and I was unable to mount it. Can't read superblock. btrfs rescue super-recover said all is good. I've even done btrfs check and it also confirmed all is well.

I am running an older Kernel: 4.15 - I think this is already resolved in the newer version of Btrfs (newer Kernels),but for the old ones - just reboot.

The system will enumarete the drives and your Btrfs filesystem should mount without issues.

If it doesn't work - try upgrading the Kernel.

Community
  • 1
unfa
  • 1,715
  • 3
  • 23
  • 34