Bug 1018607 - Fails to mount btrfs that 3.10.14-100 mounts fine [NEEDINFO]
Fails to mount btrfs that 3.10.14-100 mounts fine
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-10-13 15:00 EDT by Andrew Potter
Modified: 2014-03-17 14:45 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-03-17 14:45:26 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jforbes: needinfo?

Attachments (Terms of Use)
journalctl with systemd.log_level=debug enforcing=0 (259.11 KB, text/plain)
2013-11-07 17:52 EST, Andrew Potter
no flags Details
dmesg from "btrfs device scan" attempt (75.36 KB, text/plain)
2013-11-28 17:02 EST, Andrew Potter
no flags Details

  None (edit)
Description Andrew Potter 2013-10-13 15:00:27 EDT
Description of problem:
I just upgraded to Fedora 19 and my btrfs raid1 on devices /dev/sdb and /dev/sdc fails to mount when using 3.11.3-201. I am not using any encryption or LVM, just straight btrfs on an unpartitioned sdb and sdc.

mount returns a "no such file" type error, and the only thing dmesg says is open_ctree failed.

Rebooting into my old F18 kernel 3.10.14-100, it mounts fine and all my files are there.

In 3.11.3-201, I was able to use btrfs command to set the label of /dev/sdb, but it still wouldn't mount. I also ran btrfsck --repair but that didn't do anything. I also ran btrfs chunk-recover for a few hours but eventually ^C'd it. After doing all those things I probably shouldn't have, 3.10.14-100 still mounts the drive fine (yay). 

Version-Release number of selected component (if applicable):

How reproducible:
Every time I try to boot into 3.11.3-201

Steps to Reproduce:
1. Boot
2. systemd drops me into emergency mode because it can't mount /home
3. Trying to manually mount the drive fails.

Actual results:
Doesn't mount

Expected results:
Mount the subvolume and access my files

Additional info:
This is the relevent dmesg from when it mounts ok on 3.10.14-100. I think the "corrupt 2" error has been there for a while:
[   16.142465] device label fedorahomebackup devid 1 transid 3101419 /dev/sdb
[   16.143344] btrfs: disk space caching is enabled
[   16.173528] device label fedorahomebackup devid 1 transid 3101419 /dev/sdb
[   16.204718] btrfs: bdev /dev/sdc errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[   16.204825] btrfs: bdev /dev/sdb errs: wr 0, rd 0, flush 0, corrupt 2, gen 0

When booting in 3.11.3-201, the only difference is the addition of:
btrfs: open_ctree failed
Comment 1 Andrew Potter 2013-11-07 15:44:06 EST
This problem persists in 3.11.6-201.
Comment 2 Andrew Potter 2013-11-07 17:52:19 EST
Created attachment 821331 [details]
journalctl with systemd.log_level=debug enforcing=0
Comment 3 Andrew Potter 2013-11-27 21:05:58 EST
fedup to Fedora 20 today. Kernel 3.11.9-300 is also unable to mount this btrfs volume. To reiterate, Fedora 18-era 3.10.14-100 continues to be able to mount the volume fine.
Comment 4 birger 2013-11-28 16:45:43 EST
Try doing a "btrfs device scan" and see if that enables you to mount the volume. Is this a dracut bug? Has it forgotten that for multi device btrfs volumes a btrfs device scan must be done before mounting?
Comment 5 Andrew Potter 2013-11-28 17:02:56 EST
Created attachment 830400 [details]
dmesg from "btrfs device scan" attempt
Comment 6 Andrew Potter 2013-11-28 17:05:27 EST
"btrfs device scan" "btrfs device scan --all-devices" "btrfs device scan /dev/sdb /dev/sdc" do not help. mount still returns "No such file or directory" error.

dmesg has this message when scanning:
[  168.122910] device label fedorahomebackup devid 1 transid 3124102 /dev/sdb
[  168.155961] device label fedorahomebackup devid 2 transid 3124102 /dev/sdc

And mounting has this message:
[  109.724311] btrfs: disk space caching is enabled
[  109.794074] btrfs: bdev /dev/sdc errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[  109.794081] btrfs: bdev /dev/sdb errs: wr 0, rd 0, flush 0, corrupt 2, gen 0
[  114.927690] btrfs: open_ctree failed

The full dmesg from this experiment is in comment 5 (which is still 3.11.9-300)
Comment 7 Justin M. Forbes 2014-02-24 09:05:30 EST
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.13.4-200.fc20.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 8 Justin M. Forbes 2014-03-17 14:45:26 EDT
*********** MASS BUG UPDATE **************

This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.

Note You need to log in before you can comment on or make changes to this bug.