I can''t mount RAID-1 btrfs after reboot (well, sort of). Using 2.6.31-rc5 and btrfs-progs 0.19, I created a RAID-1 fileystem using these command line options: # mkfs.btrfs -L btrfs-data -m raid1 -d raid1 /dev/sda4 /dev/sdb4 After which I was able to mount the filesystem with either of the below (or both): # mount /dev/sda4 /mnt/btrfs-sda4 # mount /dev/sdb4 /mnt/btrfs-sdb4 After a reboot, I''m no longer able to mount the filesystem from /dev/sda4: # mount /dev/sda4 /mnt/btrfs/ Mount command complains and doesn''t mount it and says I can find more info in dmesg: Btrfs loaded device label btrfs-data devid 1 transid 67 /dev/sda4 btrfs: failed to read the system array on sda4 btrfs: open_ctree failed I''m able to mount the filesystem by using /dev/sdb4: # mount /dev/sdb4 /mnt/btrfs/ After which I can unmount it, and use /dev/sda4 to mount the filesystem: # umount /dev/sdb4 # mount /dev/sda4 /mnt/btrfs/ Does it make sense? It behaved like this also with some earlier kernels. -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Aug 14 2009, Tomasz Chmielewski wrote:> I can''t mount RAID-1 btrfs after reboot (well, sort of). > > Using 2.6.31-rc5 and btrfs-progs 0.19, I created a RAID-1 fileystem > using these command line options: > > # mkfs.btrfs -L btrfs-data -m raid1 -d raid1 /dev/sda4 /dev/sdb4 > > > After which I was able to mount the filesystem with either of the below > (or both): > > # mount /dev/sda4 /mnt/btrfs-sda4 > > # mount /dev/sdb4 /mnt/btrfs-sdb4 > > > After a reboot, I''m no longer able to mount the filesystem from /dev/sda4: > > # mount /dev/sda4 /mnt/btrfs/ > > Mount command complains and doesn''t mount it and says I can find more > info in dmesg: > > Btrfs loaded > device label btrfs-data devid 1 transid 67 /dev/sda4 > btrfs: failed to read the system array on sda4 > btrfs: open_ctree failed > > > I''m able to mount the filesystem by using /dev/sdb4: > > # mount /dev/sdb4 /mnt/btrfs/ > > After which I can unmount it, and use /dev/sda4 to mount the filesystem: > > # umount /dev/sdb4 > # mount /dev/sda4 /mnt/btrfs/Try btrfsctl -a first. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Jens Axboe wrote:>> I''m able to mount the filesystem by using /dev/sdb4: >> >> # mount /dev/sdb4 /mnt/btrfs/ >> >> After which I can unmount it, and use /dev/sda4 to mount the filesystem: >> >> # umount /dev/sdb4 >> # mount /dev/sda4 /mnt/btrfs/ > > Try btrfsctl -a first.It seems to do the trick. I suppose longer term, doing "btrfsctl -a" before mounting a (RAID) btrfs filesystem shouldn''t be needed, or? -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 2009-08-31 at 01:09 +0200, Tomasz Chmielewski wrote:> Jens Axboe wrote: > > >> I''m able to mount the filesystem by using /dev/sdb4: > >> > >> # mount /dev/sdb4 /mnt/btrfs/ > >> > >> After which I can unmount it, and use /dev/sda4 to mount the filesystem: > >> > >> # umount /dev/sdb4 > >> # mount /dev/sda4 /mnt/btrfs/ > > > > Try btrfsctl -a first. > > It seems to do the trick. > > I suppose longer term, doing "btrfsctl -a" before mounting a (RAID) > btrfs filesystem shouldn''t be needed, or?Shorter term, writing a udev rule along the lines of ENV{ID_FS_TYPE}=="btrfs", RUN+="/sbin/btrfsctl -A %N" (put it in /etc/udev/rules.d/64-btrfs-scan.rules or so) will cause your btrfs to be scanned when found. Possibly something like this could be distributed with btrfsprogs? -- Calvin Walton <calvin.walton@gmail.com> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html