Btrfs devel - Nov 2009 - Unable to mount loopback devices in RAID mode

Hi!
I recently tried to mount a filesystem in RAID1 mode using loopback devices. I
followed the instructions at [1]. Here''s exactly what I''ve
done:

$ dd if=/dev/zero of=raid1_0.img bs=1M count=500
$ dd if=/dev/zero of=raid1_1.img bs=1M count=500
$ mkfs.btrfs -m raid1 -d raid1 raid1_0.img raid1_1.img
$ losetup /dev/loop0 raid1_0.img
$ losetup /dev/loop1 raid1_1.img
$ mount -t btrfs /dev/loop0 /mnt/btrfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

$ dmesg
...
[  301.429030] Btrfs loaded
[  301.439361] device fsid 7347e7099a1ddaab-c4f037e2686afdbf devid 1 transid 7
/dev/loop0
[  301.444425] btrfs: failed to read the system array on loop0
[  301.444480] btrfs: open_ctree failed

Am I missing something? Or is the documentation outdated? The error is perfectly
reproducible, no matter what RAID type I specify (raid0, raid1 or raid10). I
used the latest version from the btrfs-unstable and btrfs-progs-unstable git
repositories. When using real block devices, however, everything works fine.

	Cheers,
		Andi

[1] http://btrfs.wiki.kernel.org/index.php/Using_Btrfs_with_Multiple_Devices
--
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

Andi Drebes wrote:
> Hi!
> I recently tried to mount a filesystem in RAID1 mode using loopback
devices. I followed the instructions at [1]. Here''s exactly what
I''ve done:
> 
> $ dd if=/dev/zero of=raid1_0.img bs=1M count=500
> $ dd if=/dev/zero of=raid1_1.img bs=1M count=500
> $ mkfs.btrfs -m raid1 -d raid1 raid1_0.img raid1_1.img
> $ losetup /dev/loop0 raid1_0.img
> $ losetup /dev/loop1 raid1_1.img
> $ mount -t btrfs /dev/loop0 /mnt/btrfs
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
The problem is btrfs randomly changes the "current master"
superblock of the filesystem.  Only 1 of the devices will
be mountable.  You just have to try the other ones, like:

 > $ mount -t btrfs /dev/loop0 /mnt/btrfs
 > mount: wrong fs type, bad option, bad superblock on /dev/loop0,

$ mount -t btrfs /dev/loop1 /mnt/btrfs

until you find one that works.  I''ve been testing 4 devices
and often have to try all 4.  Maybe someday we will fix this
so ANY raid member can start the mount (but this may need
a disk format change).

jim
--
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

Hi!
> The problem is btrfs randomly changes the "current master"
> superblock of the filesystem.  Only 1 of the devices will
> be mountable.  You just have to try the other ones, like:
> 
>  > $ mount -t btrfs /dev/loop0 /mnt/btrfs
>  > mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> 
> $ mount -t btrfs /dev/loop1 /mnt/btrfs
> 
> until you find one that works.
Thanks for the hint.

	Cheers,
		Andi
--
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

Hi Jim,

In the case of RAID1 (or even RAID10), what happens if loop0 is the
current master but is corrupted/dead and you want to mount loop1 to
recover your data?

Thanks,
JST.

On Fri, Nov 20, 2009 at 08:22:18PM +0100, Andi Drebes
wrote:
> Hi!
> 
> > The problem is btrfs randomly changes the "current master"
> > superblock of the filesystem.  Only 1 of the devices will
> > be mountable.  You just have to try the other ones, like:
> > 
> >  > $ mount -t btrfs /dev/loop0 /mnt/btrfs
> >  > mount: wrong fs type, bad option, bad superblock on /dev/loop0,
> > 
> > $ mount -t btrfs /dev/loop1 /mnt/btrfs
> > 
> > until you find one that works.
> Thanks for the hint.
> 
> 	Cheers,
> 		Andi
> --
> 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
> 
--
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

Jean-Sébastien Trottier wrote:
> In the case of RAID1 (or even RAID10), what happens if loop0 is the
> current master but is corrupted/dead and you want to mount loop1 to
> recover your data?
The problem does not occur with raid1.  In that case, both copies
are updated and either can mount.  For raid10, 2 of the 4 devices
should always be mountable (you still have to find which 2).

The "guess who is the mountable device" problem occurs on raid0
and on the (not yet in-tree) raid5/6. Better error recovery is
one of the projects that needs to be done.

jim
--
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, Nov 27, 2009 at 10:57:45AM -0500, jim owens
wrote:
> Jean-Sébastien Trottier wrote:
> >In the case of RAID1 (or even RAID10), what happens if loop0 is the
> >current master but is corrupted/dead and you want to mount loop1 to
> >recover your data?
> 
> The problem does not occur with raid1.  In that case, both copies
> are updated and either can mount.  For raid10, 2 of the 4 devices
> should always be mountable (you still have to find which 2).
Hmmm... But Andi''s original post shows he was having this problem with
RAID1, no?

JST.
> 
> The "guess who is the mountable device" problem occurs on raid0
> and on the (not yet in-tree) raid5/6. Better error recovery is
> one of the projects that needs to be done.
> 
> jim
--
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

Jean-Sébastien Trottier wrote:
> On Fri, Nov 27, 2009 at 10:57:45AM -0500, jim owens wrote:
>> Jean-Sébastien Trottier wrote:
>>> In the case of RAID1 (or even RAID10), what happens if loop0 is the
>>> current master but is corrupted/dead and you want to mount loop1 to
>>> recover your data?
>> The problem does not occur with raid1.  In that case, both copies
>> are updated and either can mount.  For raid10, 2 of the 4 devices
>> should always be mountable (you still have to find which 2).
> 
> Hmmm... But Andi''s original post shows he was having this problem
with
> RAID1, no?
Ah, yes, I missed the raid1 part on the original post.

So I do not understand why it does not work correctly for
him to mount either device.  Maybe this problem is not
what I see in my testing (using 32) with disk partitions
instead of loop.

With partitions, I only see the mount problem on raid0,
not on raid1.

jim
--
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

Hi!
> So I do not understand why it does not work correctly for
> him to mount either device.  Maybe this problem is not
> what I see in my testing (using 32) with disk partitions
> instead of loop.
> 
> With partitions, I only see the mount problem on raid0,
> not on raid1.
Without having looked at the code:
It seems as if this is a problem in mkfs. The first time, I mount the fresh
image I have to search the correct device. After having mounted it at least
once, I can use both devices interchangeably:

$ dd if=/dev/zero of=raid1_0.img bs=1M count=500
$ dd if=/dev/zero of=raid1_1.img bs=1M count=500
$ mkfs.btrfs -m raid1 -d raid1 raid1_0.img raid1_1.img
$ losetup /dev/loop0 raid1_0.img
$ losetup /dev/loop1 raid1_1.img
$ mount -t btrfs /dev/loop0 /mnt/btrfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so
$ mount -t btrfs /dev/loop1 /mnt/btrfs
#OK
$ umount /mnt/btrfs
$ mount -t btrfs -o ro /dev/loop0 /mnt/btrfs
#OK
$ umount /mnt/btrfs
$ mount -t btrfs -o ro /dev/loop1 /mnt/btrfs
#OK

So my guess is, that there''s something wrong with mkfs.

	Cheers,
		Andi
--
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

Hi,

It seems to me this error is caused by device control policy
of btrfs, not mkfs.

This error occures not only on loopback devices, but also
on normal block devices (with one difference in procedure).

# mkfs.btrfs -m raid1 -d raid1 /dev/hdc1 /dev/hdc2
# reboot (<- This is a difference.)
  (after reboot)
# mount -t btrfs /dev/hdc1 /mnt/
mount: wrong fs type, bad option, bad superblock on /dev/hdc1,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

Otherwise, when you do losetup before mkfs, it works even if
loopback devices.

# dd ~~~ (create files)
# losetup /dev/loop1 img1
# losetup /dev/loop2 img2
# mkfs.btrfs -m raid1 -d raid1 /dev/loop1 /dev/loop2
# mount -t btrfs /dev/loop1 /mnt/ (-> OK)

Btrfs collects block device information when mount or mkfs
(device_list_add in volumes.c), and know devid-device relation
by collected information. So, if we make filesystem on plain
file, btrfs cannot know devid-device relation. As a result,
btrfs cannot know which is ''devid=n'', and mount fails. Same as
this, if collected relation is cleared by shutdown, mount fails.

If we need to mount a filesystem without fail(cf, /etc/fstab line),
we should specify ''device'' options for every devices(except
mount
target device) like this.

# mount -t btrfs -o device=/dev/loop2,device=/dev/loop3,
  device=/dev/loop4 /dev/loop1 /mnt/
   (when a filesystem is constructed by /dev/loop[1-4])

Regards,
taruisi

Andi Drebes wrote:
> Hi!
> 
>> So I do not understand why it does not work correctly for
>> him to mount either device.  Maybe this problem is not
>> what I see in my testing (using 32) with disk partitions
>> instead of loop.
>>
>> With partitions, I only see the mount problem on raid0,
>> not on raid1.
> Without having looked at the code:
> It seems as if this is a problem in mkfs. The first time, I mount the fresh
image I have to search the correct device. After having mounted it at least
once, I can use both devices interchangeably:
> 
> $ dd if=/dev/zero of=raid1_0.img bs=1M count=500
> $ dd if=/dev/zero of=raid1_1.img bs=1M count=500
> $ mkfs.btrfs -m raid1 -d raid1 raid1_0.img raid1_1.img
> $ losetup /dev/loop0 raid1_0.img
> $ losetup /dev/loop1 raid1_1.img
> $ mount -t btrfs /dev/loop0 /mnt/btrfs
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> $ mount -t btrfs /dev/loop1 /mnt/btrfs
> #OK
> $ umount /mnt/btrfs
> $ mount -t btrfs -o ro /dev/loop0 /mnt/btrfs
> #OK
> $ umount /mnt/btrfs
> $ mount -t btrfs -o ro /dev/loop1 /mnt/btrfs
> #OK
> 
> So my guess is, that there''s something wrong with mkfs.
> 
> 	Cheers,
> 		Andi
> --
> 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

-- 
taruisi

--
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 Tue, Dec 1, 2009 at 6:56 AM, TARUISI Hiroaki
<taruishi.hiroak@jp.fujitsu.com> wrote:
> Btrfs collects block device information when mount or mkfs
> (device_list_add in volumes.c), and know devid-device relation
> by collected information. So, if we make filesystem on plain
> file, btrfs cannot know devid-device relation. As a result,
> btrfs cannot know which is ''devid=n'', and mount fails.
Same as
> this, if collected relation is cleared by shutdown, mount fails.
>
> If we need to mount a filesystem without fail(cf, /etc/fstab line),
> we should specify ''device'' options for every
devices(except mount
> target device) like this.
>
> # mount -t btrfs -o device=/dev/loop2,device=/dev/loop3,
>  device=/dev/loop4 /dev/loop1 /mnt/
>   (when a filesystem is constructed by /dev/loop[1-4])
>
> Regards,
> taruisi
Would this option ["mount -t btrfs -o device=/dev/sdb2 /dev/sda2
/mnt"] work on boot, bypasing the need for "btrfsctl -a" to mount
a
multi-device filesystem?
--
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

Yes. ''device'' options work good on boot.
(There may be trivial differences, perhaps.)

Both ''btrfsctl -a|A'' and device option of mount calls a same
device collection function, ''scan_one_device'' and by this
function btrfs knows devices for btrfs.

# But, there''s no mount option like ''btrfsctl -a'', so
# option string grows longer and longer as number of
# devices increases...

Leszek Ciesielski wrote:
> On Tue, Dec 1, 2009 at 6:56 AM, TARUISI Hiroaki
> <taruishi.hiroak@jp.fujitsu.com> wrote:
>> Btrfs collects block device information when mount or mkfs
>> (device_list_add in volumes.c), and know devid-device relation
>> by collected information. So, if we make filesystem on plain
>> file, btrfs cannot know devid-device relation. As a result,
>> btrfs cannot know which is ''devid=n'', and mount
fails. Same as
>> this, if collected relation is cleared by shutdown, mount fails.
>>
>> If wlee need to mount a filesystem without fail(cf, /etc/fstab line),
>> we should specify ''device'' options for every
devices(except mount
>> target device) like this.
>>
>> # mount -t btrfs -o device=/dev/loop2,device=/dev/loop3,
>>  device=/dev/loop4 /dev/loop1 /mnt/
>>   (when a filesystem is constructed by /dev/loop[1-4])
>>
>> Regards,
>> taruisi
> 
> Would this option ["mount -t btrfs -o device=/dev/sdb2 /dev/sda2
> /mnt"] work on boot, bypasing the need for "btrfsctl -a" to
mount a
> multi-device filesystem?
> --
> 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
-- 
taruisi

--
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