fail to mount after first reboot

I created a 1TB RAID1. So far it is just for testing, no important data on there.

After a reboot, I tried to mount it again

# mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg00-btrfsvol0_0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Then I did btrfsck - it reported no errors, but mounted OK:

# btrfsck /dev/mapper/vg00-btrfsvol0_0

Can anyone comment on this?

Also, df is reporting double the actual RAID1 volume size, and double the amount of data stored in this filesystem:

# df -lh .
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/vg00-btrfsvol0_0  1.9T   51G  1.8T   3% /mnt/btrfs0

I would expect to see Size=1T, Used=25G

# strace -v -e trace=statfs df -lh /mnt/btrfs0
statfs("/mnt/btrfs0", {f_type=0x9123683e, f_bsize=4096,
f_blocks=488374272, f_bfree=475264720, f_bavail=474749786, f_files=0,
f_ffree=0, f_fsid={2083217090, -1714407264}, f_namelen=255,
f_frsize=4096}) = 0
Filesystem                    Size  Used Avail Use% Mounted on
/dev/mapper/vg00-btrfsvol0_0  1.9T   51G  1.8T   3% /mnt/btrfs0

Quoted 6 lines · Daniel Pocock

I created a 1TB RAID1. So far it is just for testing, no important data on there.

Quoted 8 lines

After a reboot, I tried to mount it again

# mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg00-btrfsvol0_0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

With multi-volume btrfs filesystems, you have to run "btrfs dev
scan" before trying to mount it. Usually, the distribution will do this in the initrd (if you've installed its btrfs-progs package).

Quoted 3 lines

Then I did btrfsck - it reported no errors, but mounted OK:

# btrfsck /dev/mapper/vg00-btrfsvol0_0

[...]

The first thing that btrfsck does is to do a device scan.

[...]

Quoted 13 lines · Hugo Mills

Quoted 11 lines · Daniel Pocock

I created a 1TB RAID1. So far it is just for testing, no important data on there.

After a reboot, I tried to mount it again

# mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg00-btrfsvol0_0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Quoted 3 lines

With multi-volume btrfs filesystems, you have to run "btrfs dev
scan" before trying to mount it. Usually, the distribution will do this in the initrd (if you've installed its btrfs-progs package).

I'm running Debian, I've just updated the system from squeeze to wheezy (with 3.2 kernel) so I could try btrfs and do other QA testing on wheezy (as it is in the beta phase now)

I already had the btrfs-tools package installed, before creating the filesystem. So it appears Debian doesn't have an init script

It does have /lib/udev/rules.d/60-btrfs.rules:
SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION!="add|change", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
RUN+="/sbin/modprobe btrfs"
RUN+="/sbin/btrfs device scan $env{DEVNAME}"

LABEL="btrfs_end"

but I'm guessing that isn't any use to my logical volumes that are activated early in the boot sequence?

Could I be having this problem because I put my btrfs on logical volumes?

Here is the package version I have:

# dpkg --list | grep btrfs
ii  btrfs-tools                           0.19+20120328-7
       Checksumming Copy on Write Filesystem utilities

Here is a more thorough dmesg, since boot, does this suggest the scan was invoked? I remember seeing some message about checking for btrfs filesystems just after selecting the kernel in grub (root is ext3)

# dmesg | grep btrfs
[   40.677505] btrfs: setting nodatacow
[   40.677514] btrfs: turning off barriers
[17216.145092] device fsid c959d4a5-0713-4685-b572-8a679ec37e20 devid 1
transid 34 /dev/mapper/vg00-btrfsvol0_0
[17216.145639] btrfs: disk space caching is enabled

[17216.146987] btrfs: failed to read the system array on dm-100
[17216.147556] btrfs: open_ctree failed
[17310.978518] device fsid c959d4a5-0713-4685-b572-8a679ec37e20 devid 1
transid 34 /dev/mapper/vg00-btrfsvol0_0
[17310.993882] btrfs: disk space caching is enabled
[17598.736657] device fsid c959d4a5-0713-4685-b572-8a679ec37e20 devid 1
transid 37 /dev/mapper/vg00-btrfsvol0_0
[17598.750849] btrfs: disk space caching is enabled

Quoted 34 lines · Daniel Pocock

Quoted 13 lines · Hugo Mills

Quoted 11 lines · Daniel Pocock

I created a 1TB RAID1. So far it is just for testing, no important data on there.

After a reboot, I tried to mount it again

# mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg00-btrfsvol0_0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Quoted 3 lines

With multi-volume btrfs filesystems, you have to run "btrfs dev
scan" before trying to mount it. Usually, the distribution will do this in the initrd (if you've installed its btrfs-progs package).

I'm running Debian, I've just updated the system from squeeze to wheezy (with 3.2 kernel) so I could try btrfs and do other QA testing on wheezy (as it is in the beta phase now)

I already had the btrfs-tools package installed, before creating the filesystem. So it appears Debian doesn't have an init script

It does have /lib/udev/rules.d/60-btrfs.rules:
SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION!="add|change", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
RUN+="/sbin/modprobe btrfs"
RUN+="/sbin/btrfs device scan $env{DEVNAME}"

LABEL="btrfs_end"

Quoted 4 lines

but I'm guessing that isn't any use to my logical volumes that are activated early in the boot sequence?

Could I be having this problem because I put my btrfs on logical volumes?

Possibly. You may need the "Device mapper uevents" option in the
kernel (CONFIG_DM_UEVENT) to trigger that udev rule when you enable your VG(s). Not sure if it's available/enabled in your kernel.

Quoted 35 lines · Hugo Mills

Quoted 34 lines · Daniel Pocock

Quoted 13 lines · Hugo Mills

Quoted 11 lines · Daniel Pocock

I created a 1TB RAID1. So far it is just for testing, no important data on there.

After a reboot, I tried to mount it again

# mount /dev/mapper/vg00-btrfsvol0_0 /mnt/btrfs0
mount: wrong fs type, bad option, bad superblock on
/dev/mapper/vg00-btrfsvol0_0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Quoted 3 lines

With multi-volume btrfs filesystems, you have to run "btrfs dev
scan" before trying to mount it. Usually, the distribution will do this in the initrd (if you've installed its btrfs-progs package).

I'm running Debian, I've just updated the system from squeeze to wheezy (with 3.2 kernel) so I could try btrfs and do other QA testing on wheezy (as it is in the beta phase now)

I already had the btrfs-tools package installed, before creating the filesystem. So it appears Debian doesn't have an init script

It does have /lib/udev/rules.d/60-btrfs.rules:
SUBSYSTEM!="block", GOTO="btrfs_end"
ACTION!="add|change", GOTO="btrfs_end"
ENV{ID_FS_TYPE}!="btrfs", GOTO="btrfs_end"
RUN+="/sbin/modprobe btrfs"
RUN+="/sbin/btrfs device scan $env{DEVNAME}"

LABEL="btrfs_end"

Quoted 9 lines

Quoted 4 lines

but I'm guessing that isn't any use to my logical volumes that are activated early in the boot sequence?

Could I be having this problem because I put my btrfs on logical volumes?

Possibly. You may need the "Device mapper uevents" option in the
kernel (CONFIG_DM_UEVENT) to trigger that udev rule when you enable your VG(s). Not sure if it's available/enabled in your kernel.

I've created a Debian bug report for the issue:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685311

Thanks for the quick feedback about this