7

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.

  • Did you try without dividing? man mount only says to divide in the ext2 section – Tom Hale Sep 7 '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 8 '17 at 8:52
  • I've had issues because of umount -l with btrfs. Did you use that perchance? – Tom Hale Sep 8 '17 at 11:25
0

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.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.