"Invalid argument" when mounting a btrfs raid1 filesystem

I'm trying to install current Debian testing (=kernel version 3.2) with btrfs as the root file system. There is also a small ext3 /boot partition.

I create a btrfs raid1 file system with the command

mkfs.btrfs -d raid1 /dev/sda2 /dev/sdb2

Then I can mount it and finish the installation successfully. Booting doesn't work, however: initrd complains that it cannot mount /dev/sda2:
"Invalid argument".

The funny thing is, that in the initrd console I can mount /dev/sdb2! So I changed the kernel parameter in grub.cfg to mount /dev/sdb2 instead, but the problem persists: Now I can mount /dev/sda2 in the initrd console!

In fact, when I boot a rescue system from a thumbdrive, the same thing happens:

# mount -t btrfs /dev/sda2 /mnt
mount: mounting /dev/sda2 on /mnt failed: Invalid argument
# mount -t btrfs /dev/sdb2 /mnt
#

When I keep trying to mount the same device, it keeps failing. When I start mounting /dev/sdb2, it works for /dev/sda2...

Isn't this very weird? Any ideas?

Hello,

I'm trying to install current Debian testing (=kernel version 3.2) with btrfs as the root file system. There is also a small ext3 /boot partition.

I create a btrfs raid1 file system with the command

mkfs.btrfs -d raid1 /dev/sda2 /dev/sdb2

Then I can mount it and finish the installation successfully. Booting doesn't work, however: initrd complains that it cannot mount /dev/sda2:
"Invalid argument".

The funny thing is, that in the initrd console I can mount /dev/sdb2! So I changed the kernel parameter in grub.cfg to mount /dev/sdb2 instead, but the problem persists: Now I can mount /dev/sda2 in the initrd console!

In fact, when I boot a rescue system from a thumbdrive, the same thing happens:

# mount -t btrfs /dev/sda2 /mnt
mount: mounting /dev/sda2 on /mnt failed: Invalid argument
# mount -t btrfs /dev/sdb2 /mnt
#

When I keep trying to mount the same device, it keeps failing. When I start mounting /dev/sdb2, it works for /dev/sda2...

Isn't this very weird? Any ideas?

Basically, the kernel needs to know which devices hold which btrfs
filesystems (organised by UUID) before it tries to mount them. So, there's an ioctl that is used for sending that data to the kernel, and a userspace tool (btrfs dev scan) that enumerates all of the block devices it can see, looks for a btrfs superblock on them, and tells the kernel.

Hugo.

Quoted 8 lines

Basically, the kernel needs to know which devices hold which btrfs
filesystems (organised by UUID) before it tries to mount them. So, there's an ioctl that is used for sending that data to the kernel, and a userspace tool (btrfs dev scan) that enumerates all of the block devices it can see, looks for a btrfs superblock on them, and tells the kernel.

Hugo.

If you install the package btrfs-tools (currently dated 5 November 2011 in unstable), it'll set up the necessary.

As Sadner says, you have to run "btrfs dev scan" before you try to
mount the FS. If you have root on btrfs, this will have to go in an initrd; otherwise, it can go in your initscripts anywhere before the non-root filesystem mounts.

Basically, the kernel needs to know which devices hold which btrfs
filesystems (organised by UUID) before it tries to mount them. So, there's an ioctl that is used for sending that data to the kernel, and a userspace tool (btrfs dev scan) that enumerates all of the block devices it can see, looks for a btrfs superblock on them, and tells the kernel.

Quoted 11 lines · Hugo Mills

As Sadner says, you have to run "btrfs dev scan" before you try to
mount the FS. If you have root on btrfs, this will have to go in an initrd; otherwise, it can go in your initscripts anywhere before the non-root filesystem mounts.

Basically, the kernel needs to know which devices hold which btrfs
filesystems (organised by UUID) before it tries to mount them. So, there's an ioctl that is used for sending that data to the kernel, and a userspace tool (btrfs dev scan) that enumerates all of the block devices it can see, looks for a btrfs superblock on them, and tells the kernel.

Please, move all this logic to udev rules where we already scans all devices. It's really bad to scan all device more than once. We spent years to fix this problem for LVM, I don't think that btrfs has to repeat the same mistakes.

Quoted 2 lines · Hugo Mills

Quoted 1 line

As Sadner says, you have to run "btrfs dev scan" before you tr=

Quoted 3 lines

Quoted 3 lines

to
=20
mount the FS. If you have root on btrfs, this will have to go in =

Quoted 7 lines

Quoted 7 lines

initrd; otherwise, it can go in your initscripts anywhere before the non-root filesystem mounts.
=20
Basically, the kernel needs to know which devices hold which btrfs
=20
filesystems (organised by UUID) before it tries to mount them. So=

Quoted 1 line

Quoted 1 line

there's an ioctl that is used for sending that data to the kernel=

Quoted 5 lines

Quoted 3 lines

and a userspace tool (btrfs dev scan) that enumerates all of the block devices it can see, looks for a btrfs superblock on them, and tells the kernel.

=20
Please, move all this logic to udev rules where we already scans a=

Quoted 1 line

devices. It's really bad to scan all device more than once. We spe=

Quoted 2 lines

years to fix this problem for LVM, I don't think that btrfs has to repeat the same mistakes.

=20
Oh, this is already possible to do with udev rules, quite easily. In fact, dracut ships with the appropriate udev rules, which it uses to initialize btrfs filesystems in the initramfs:
=20
http://git.kernel.org/?p=3Dboot/dracut/dracut.git;a=3Dblob;f=3Dmodule=

rfs/80-btrfs.rules;hb=3DHEAD
=20
which would be suitable with minor modifications for use in a system udev installation as well.