Bug 581204 - Btrfs raid cannot be mounted without btrfsctl -a
Btrfs raid cannot be mounted without btrfsctl -a
Product: Fedora
Classification: Fedora
Component: dracut (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2010-04-10 22:58 EDT by Matt
Modified: 2010-05-11 15:46 EDT (History)
2 users (show)

See Also:
Fixed In Version: dracut-005-2.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-11 15:46:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Module for dracut to scan for btrfs (1.15 KB, patch)
2010-04-10 22:58 EDT, Matt
no flags Details | Diff
0005-add-btrfs-module.patch with btrfsctl changes (1.94 KB, text/plain)
2010-04-16 02:43 EDT, Matt
no flags Details
Git patch for upstream (1.42 KB, text/plain)
2010-04-16 02:48 EDT, Matt
no flags Details
dmesg logs of different dracut btrfs modules on same system. (17.47 KB, application/x-gzip)
2010-04-27 16:51 EDT, Matt
no flags Details

  None (edit)
Description Matt 2010-04-10 22:58:46 EDT
Created attachment 405773 [details]
Module for dracut to scan for btrfs

Description of problem:

First, this only applies to the raid built into btrfs, _not_ md raid or the such.

Mounting a raid0/1/10 Btrfs partition requires the system to first scan(?) for btrfs partitions with 'btrfsctl -a'. This is in contrast to single btrfs partitions that do not require this scan.

Dracut currently does not do this scan, which causes the system to be unable to mount the partition (root or otherwise).

This is especially bad for systems with btrfs raid as their root, as they will be unable to boot.

How reproducible: 

Steps to Reproduce:
1. Make a raid btrfs partition
     mkfs.btrfs -d raid0 /dev/sdbX /dev/sdcX
2. Reboot system
3. Try to mount the partition
     mount /dev/sdbX /mount/point
4. The above will fail with a "wrong fs type", and the system logs will show "failed to read the system array [array]"
5  Run "btrfsctl -a"
6. Retry mounting partition, and it should mount.

Actual results:
Cannot mount without running 'btrfsctl -a'.

Expected results:
System boots and/or partitions are loaded like other partitions.

Additional info:
I made a dracut module to fix this and included it as a patch. It runs 'btrfsctl -a' just before mounting the partitions.

I am currently using it in a machine that has btrfs raid1 as the root partition and is running Fedora 12. Kernel updates appear to work just fine.

Note that in the patch, the btrfsctl scan is only added/run if btrfsctl is found (btrfs-progs).
Comment 1 Fedora Update System 2010-04-15 10:39:54 EDT
dracut-005-2.fc12 has been submitted as an update for Fedora 12.
Comment 2 Fedora Update System 2010-04-15 10:48:59 EDT
dracut-005-2.fc12 has been submitted as an update for Fedora 12.
Comment 3 Matt 2010-04-16 02:42:31 EDT
I appreciate your taking the time to add the btrfs module to the above update (dracut-005-2.fc12), but it did not fix the problem. I installed it, recreated the initram, rebooted, and when I tried mounting a btrfs raid filesystem, it gave me the same error as before.

After reading the changelog in the package, I think there may be some confusion here. This bug is _not_ about loading the btrfs module. Dracut already takes care of this. This bug is about using btrfsctl (btrfs control) to scan for devices, specifically for multi-devices (raid). Single devices take care of themselves.

When I say btrfs "raid," I am actually referring to btrfs multi-devices which are just btrfs filesystems using either mirroring and/or striping of data to multiple devices, exclusive of dmraid, lvm, or other methods. They are self contained.

You can refer to the btrfs wiki for more about btrfs multi-devices (raid).


I'll just say it's confusing. I don't know of another filesystem that works fine with single devices, but then requires a scan for filesystems using more than one device. It's usually one or the other.

Eventually they will fix it, according to the mailing list. For now we'll have to use this fix.

Here is an explanation of the fixes for 90btrfs, in both btrfsctl.git (git patch for upstream against commit 7f0066987 "nfs: fixed nsswitch.conf parsing") and updated 0005-add-module-btrfs.patch (for rpm):

1. Don't call 'btrfs' (a binary that does not exist) in the check, install, and udev files of 90btrfs. This should be btrfsctl. I got the udev info from http://article.gmane.org/gmane.comp.file-systems.btrfs/3589/match=btrfsctl+raid.

2. Changed the comment about "dmraid" in check. Probably just left in there, but still don't want to confuse the users and have dmraid get bug reports about btrfs.

Other things that still need fixing:

1. Both of the files 'check' and 'install' are getting the wrong perms of 644. The patch says they should be 755 (which is right), but installing and/or opening the dracut-005-2.fc12 rpm above shows 644.

2. The changelog in dracut.spec should show that this change is in reference to btrfsctl. Like,

 - Added btrfsctl scan for btrfs multi-devices (raid)
Comment 4 Matt 2010-04-16 02:43:24 EDT
Created attachment 407008 [details]
0005-add-btrfs-module.patch with btrfsctl changes
Comment 5 Matt 2010-04-16 02:48:20 EDT
Created attachment 407009 [details]
Git patch for upstream
Comment 6 Harald Hoyer 2010-04-16 12:14:44 EDT
$ rpm -qf /sbin/btrfs

$ /sbin/btrfs
	btrfs device scan [<device> [<device>..]
		Scan all device for or the passed device for a btrfs
Comment 7 Fedora Update System 2010-04-16 19:44:16 EDT
dracut-005-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update dracut'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/dracut-005-2.fc12
Comment 8 Matt 2010-04-17 08:08:11 EDT
It doesn't work.

Permissions of 90btrfs/check and 90btrfs/install are still 644 in the F12 and F13 rpms posted 2010-04-16 23:17:59 and 2010-04-16 23:19:17.

Trying it out on a F12 machine, I installed btrfs-progs 0.19-12 from Fedora 13 on Fedora 12, since the version for 12 does not include 'btrfs'. Then I installed the dracut update. Had to chmod the check and install files to 755 to get dracut to run the module. Recreated the initram, and rebooted.

Did about the same on F13.

It seems that the btrfs module is not being loaded properly, or is too late? I used my a script instead of udev (I don't know udev, and for me a script is easier to work with), and it gave the error "Cannot find /dev/btrfs-control. Unable to load filesystems" for each btrfs partition (5 in my case). But it doesn't make sense since the btrfs module is already loaded for this machine. It has a btrfs single root, and I was trying to get it to load a btrfs raid10 at /mnt/btrfs.

Using the scan script (instead of a udev file),

dracut_install btrfs
inst_hook mount 90 "$moddir/scan-btrfs.sh"

if [ -n "$root" -a -z "${root%%block:*}" ]; then
  modprobe btrfs
  btrfs device scan

That worked (remove 'modprobe btrfs' and it errors/fails with "Cannot find /dev/btrfs-control"). But we shouldn't have to reload the module. And it's strange that I do not have to do this on my current F12 system. Perhaps there was a change in the btrfs? Loading at the the wrong time? I'll have to look more into it later, or maybe some else knows. I'll post a debug later.

As far as the btrfs vs btrfsctl goes, yes, the 'btrfs' binary is in Fedora 13 and btrfs git, but not in the current Fedora 12 (btrfs-progs-19-9.fc12). A search for btrfs on the above updates page only shows updated rpm versions for Fedora 13. Will we get an updated version in 12?

I see no difference between btrfs and btrfsctl, except for their syntax. btrfs was commited only a month ago, and while it is useful, it's new and may have some bugs. And the commit made it sound like it was for 'ease of use'. There is a possibility of a syntax change, or of finding a bug. btrfsctl and btrfs may get merged.

But if you still would like to use it, that fine. I just want to make sure the pros and cons are stated.
Comment 9 Matt 2010-04-27 16:51:48 EDT
Created attachment 409585 [details]
dmesg logs of different dracut btrfs modules on same system.

Contains three logs of tests done on Fedora 13, with root as a multi-device btrfs, and one at /mnt/new. In each test I substituted btrfsctl instead on btrfs only because it gave errors where btrfs was failing silently. I used scripts in the ones that worked, but only to get it up and going. It would be much better to get udev to scan and load the devices, as that would be both dynamic and fast.

btrfs_current_udev: Current dracut-005-2.fc13.noarch rpm, with chmod changes and using btrfsctl. This fails to boot, with either btrfsctl or btrfs.

btrfs_btrfsctl_only: Used 'btrfsctl -a' instead of udev, as is in the attachment 'Module for dracut to scan for btrfs'. System booted fine, but from the log it appears that first it failed to mount root, and then succeeded.

: Same as above, except issued a 'modprobe btrfs' before the 'btrfsctl -a'. No errors.

Here's information on the system. If you need more info, or for me to try out something, let me know.

# Kernel command line for all three
ro root=UUID=8c224778-7427-423d-85bf-66ebca9cc0ae LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us vga=789 rdshell rdinitdebug

# /etc/fstab
UUID=8c224778-7427-423d-85bf-66ebca9cc0ae /          btrfs   defaults,compress        1 1
UUID=6c74eb99-aee6-4fcf-b3fb-3d118f730264 /boot      ext3    defaults        1 2
UUID=aef3df53-289f-420c-8ed1-a30413f27e9f /mnt/new   btrfs   defaults        1 2

# dmsetup ls --tree
No devices found

# blkid
/dev/sda1: UUID="6c74eb99-aee6-4fcf-b3fb-3d118f730264" TYPE="ext3" 
/dev/sdb1: UUID="aef3df53-289f-420c-8ed1-a30413f27e9f" UUID_SUB="65c80282-671f-42bd-bd32-3c9a90ed123b" TYPE="btrfs" LABEL="data_raid1" 
/dev/loop0: UUID="e92e4684-4731-4839-8b0f-6e3631d1f299" TYPE="swap" 
/dev/sda2: UUID="8c224778-7427-423d-85bf-66ebca9cc0ae" UUID_SUB="99043a48-b840-48cc-a2df-a74e66cbd62a" TYPE="btrfs" 
/dev/sdc1: UUID="8c224778-7427-423d-85bf-66ebca9cc0ae" UUID_SUB="10f54067-5832-44ac-a565-271175b040c7" TYPE="btrfs" 
/dev/sdd1: LABEL="data_raid1" UUID="aef3df53-289f-420c-8ed1-a30413f27e9f" UUID_SUB="6b3af8ff-d9e5-416d-be60-ed8071b29fdc" TYPE="btrfs" 

# blkid -o udev

# brtfs-show (both are raid1)
Label: none  uuid: 8c224778-7427-423d-85bf-66ebca9cc0ae
	Total devices 2 FS bytes used 1.76GB
	devid    1 size 7.23GB used 3.49GB path /dev/sda2
	devid    2 size 7.36GB used 3.47GB path /dev/sdc1

Label: data_raid1  uuid: aef3df53-289f-420c-8ed1-a30413f27e9f
	Total devices 2 FS bytes used 28.00KB
	devid    1 size 2.00GB used 1.83GB path /dev/sdb1
	devid    2 size 2.00GB used 1.81GB path /dev/sdd1

Btrfs Btrfs v0.19

Comment 10 Fedora Update System 2010-05-11 15:46:07 EDT
dracut-005-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

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