BTRFS volume mount failure

[oshunluvr]

This is the first time since I began using btrfs I've run into a problem I couldn't fix. I don't think it's related to btrfs per se but I wanted to report it in case someone runs into this or is setting up to use btrfs for the first time.

I had a btrfs file system on an old drive I hadn't used in many months - it was a second backup location that I just didn't bother using. I run daily off of two SSDs in btrfs RAID and backup to two hard drives. This was on the second hard drive.

I attempted to mount it to see what was on it, and it returned an error. dmesg reported "BTRFS error (device sdb3): open_ctree failed"
Knowing there was nothing of value on there, I tried:

• btrfs check - reported no errors
• btrfs check --repair - proceeded but made no difference
• booted into an older kernel to see if a kernel change had caused it - no
• wiped the file system with wipefs and recreated it - no errors on creation but still no mount
• used dd to write zeros to the entire partition and then reformatted it yet again - no change
• discovered the partition wasn't correctly aligned so I re partition using optimal alignment - no change

Finally, I force-formatted the partition to ext4, verified it worked, then force-formatted it back to btrfs and it worked. My best-guess is that the partition table or header got damaged somewhere along the way and changing it to ext4 re-wrote enough to fix it. A btrfs developer also told be that btrfs is very sensitive to proper alignment and the partition had been not-properly aligned, well, forever.

Hard to say what caused this; ghost in the machine or shear age - this drive has almost 72,000 hours of power-on time so it's well past it's expiration date.

The take-away from this is always backup anything you don't want to loose!

[mr_raider]

I had similar issue long ago. This was ext4 partition that had been converted to btrfs, then later at some point resized using gparted (back in the Trusty Tahr days). It would periodically through errors on mounting but still work. Eventually one day it refused to mount. I had to wipe and re-create. I always suspected it was due to the resize.

[GreyGeek]

I had a 320Gb USB Passport HD that did the same thing. I used it as my second backup. It began failing to boot until it got warm. All the stuff you did I did but eventually it permanently failed to boot.

[oshunluvr]

I just discovered another bit of info about this issue: I get the "open_ctree failed" issue when I attempt to mount this way:

mount /backup2

This should work because "...noauto,user..." are in the fstab entry. However, if I issue:

sudo mount /dev/sdb3 /backup2

it mounts without error. However, these fail:

sudo mount /backup2
sudo mount /dev/sdb3

It seemed that an fstab option was causing the issue. Here they are:

rw,noauto,user,noatime,space_cache,compress=lzo,autodefrag

I edited the fstab entry, removing all options except "noauto" which I changed to "auto" and then this would mount it:

sudo mount /backup2

So I changed it back to "noauto,user" and I could mount it again as my user. Then I added back all the other options, one at a time, expecting it to fail at some point. But it never did. Now I can mount it again, with all the options in fstab, just using:

mount /backup2

Weird to say the least.

[oshunluvr]

So, being btrfs, I went back to my snapshot and compare character to character to the newly edited fstab and guess what? There was a TYPO; A period instead of a comma between two of the options.

[GreyGeek]

Exasperation 101
Attended that class ... failed it.
I didn't know about any mounting shortcuts fstab would allow.


Being dumb has its advantages ...
I have always used mount with a device name and a mount point despite what is in fstab.

[oshunluvr]

Using the "user" or "users" option allows the user to mount the device without sudo powers but still using the fstab mount options. I reserve it for devices that I may want to mount, but don't need to at boot time. Like backup or "playground" partitions. Saves a lot of typing when I'm in the terminal - where I usually am.