Skip to contentSkip to conversation

btrfs raid1 degraded does not mount or fsck

DISCUSSION Vladi Gergov 5 participants 5 messages Oct 29, 2010 – Sep 17, 2012 Btrfs file system

lore
Share & tools
lore
#0 lore raw

kernel: scratch git repo from today 10.29.10 @ 14:30 PST Btrfs v0.19-35-g1b444cd-dirty

Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfs filesystem show

Label: 'das4' uuid: d0e5137f-e5e7-49da-91f6-a9c4e4e72c6f
Total devices 3 FS bytes used 1.38TB
devid 3 size 1.82TB used 0.00 path /dev/sdb
devid 2 size 1.82TB used 1.38TB path /dev/sdc
*** Some devices missing

Btrfs v0.19-35-g1b444cd-dirty

Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo mount -o degraded /dev/sdc das3/

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

[  684.577540] device label das4 devid 2 transid 107954 /dev/sdc
[  684.595150] btrfs: allowing degraded mounts
[  684.595594] btrfs: failed to read chunk root on sdb
[  684.604110] btrfs: open_ctree failed
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfsck /dev/sdc

btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed.

any help please?

Signature · 4 lines
,-| Vladi
`-| Gergov

!DSPAM:4ccb39a9191821603519226!
#1 lore raw
Quoted 24 lines · Vladi Gergov

kernel: scratch git repo from today 10.29.10 @ 14:30 PST Btrfs v0.19-35-g1b444cd-dirty

Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfs filesystem show

Label: 'das4' uuid: d0e5137f-e5e7-49da-91f6-a9c4e4e72c6f
Total devices 3 FS bytes used 1.38TB
devid 3 size 1.82TB used 0.00 path /dev/sdb
devid 2 size 1.82TB used 1.38TB path /dev/sdc
*** Some devices missing

Btrfs v0.19-35-g1b444cd-dirty

Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo mount -o degraded /dev/sdc das3/

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

[  684.577540] device label das4 devid 2 transid 107954 /dev/sdc
[  684.595150] btrfs: allowing degraded mounts
[  684.595594] btrfs: failed to read chunk root on sdb
[  684.604110] btrfs: open_ctree failed
Quoted 4 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfsck /dev/sdc

btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed.

any help please?

did you execute

btrfs dev scan

before trying to mount the filesystem ?

Quoted 13 lines
Signature · 10 lines
,-| Vladi
`-| Gergov

!DSPAM:4ccb39a9191821603519226!


--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Signature · 2 lines
gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <[email protected]>
Key fingerprint = 4769 7E51 5293 D36C 814E  C054 BF04 F161 3DC5 0512
#2 lore raw
In reply to Vladi Gergov

Excerpts from Vladi Gergov's message of 2010-10-29 16:53:42 -0400:

Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo mount -o degraded /dev/sdc das3/

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

Quoted 7 lines
[  684.577540] device label das4 devid 2 transid 107954 /dev/sdc
[  684.595150] btrfs: allowing degraded mounts
[  684.595594] btrfs: failed to read chunk root on sdb
[  684.604110] btrfs: open_ctree failed
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfsck /dev/sdc

btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed.

Ok, I dug through this and found the bug responsible for your unmountable FS. When we're mounted in degraded mode, and we don't have enough drives available to do raid1,10, we're can use the wrong raid level for new allocations.

I'm fixing the kernel side so this doesn't happen anymore, but I'll need to rebuild the chunk tree (and probably a few others) off your good disk to fix things.

I've got it reproduced here though, so I'll make an fsck that can scan for the correct trees and fix it for you.

Since you're basically going to be my first external fsck customer, is there anyway you can do a raw device based backup of the blocks? This way if I do mess things up we can repeat the experiment.

-chris

#3 lore raw
Quoted 26 lines · Chris Mason <chris.mason <at> oracle.com> writes:

Excerpts from Vladi Gergov's message of 2010-10-29 16:53:42 -0400:

Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo mount -o degraded /dev/sdc das3/

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

Quoted 7 lines
[  684.577540] device label das4 devid 2 transid 107954 /dev/sdc
[  684.595150] btrfs: allowing degraded mounts
[  684.595594] btrfs: failed to read chunk root on sdb
[  684.604110] btrfs: open_ctree failed
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfsck /dev/sdc

btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed.

Ok, I dug through this and found the bug responsible for your unmountable FS. When we're mounted in degraded mode, and we don't have enough drives available to do raid1,10, we're can use the wrong raid level for new allocations.

I'm fixing the kernel side so this doesn't happen anymore, but I'll need to rebuild the chunk tree (and probably a few others) off your good disk to fix things.

Quoted 8 lines

I've got it reproduced here though, so I'll make an fsck that can scan for the correct trees and fix it for you.

Since you're basically going to be my first external fsck customer, is there anyway you can do a raw device based backup of the blocks? This way if I do mess things up we can repeat the experiment.

-chris

I'm seeing this same error, uname -a shows:
2.6.38-11-generic
although, my fs went down a month or so ago so it could have been a slightly earlier Ubuntu kernel. Is this the same issue? Is that very targeted fsck available somewhere? I've got my replacement disk ready to add, I just need to get the other 3 mounted. Data and metadata are both raid10. I really need to start tracking the kernel again :(. Thanks for any help.

-Larry

#4 lore raw

btrfs raid1 degraded in need of chuck tree rebuild

In reply to Vladi Gergov

Below is my original post about my fs. Just wondering if anyone knows if I can at this point get my data back or cut my losses. Is an fsck cable of getting this fixed close or has my 2 year wait been in vain. Thanks in advance!

Excerpts from Vladi Gergov's message of 2010-10-29 16:53:42 -0400:

Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo mount -o degraded /dev/sdc das3/

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

Quoted 8 lines
[  684.577540] device label das4 devid 2 transid 107954 /dev/sdc
[  684.595150] btrfs: allowing degraded mounts
[  684.595594] btrfs: failed to read chunk root on sdb
[  684.604110] btrfs: open_ctree failed
Quoted 1 line
Quoted 1 line
Quoted 1 line

gypsyops @ /mnt > sudo btrfsck /dev/sdc

btrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)' failed.

Ok, I dug through this and found the bug responsible for your unmountable FS. When we're mounted in degraded mode, and we don't have enough drives available to do raid1,10, we're can use the wrong raid level for new allocations.

I'm fixing the kernel side so this doesn't happen anymore, but I'll need to rebuild the chunk tree (and probably a few others) off your good disk to
fix things.

I've got it reproduced here though, so I'll make an fsck that can scan for the correct trees and fix it for you.

Since you're basically going to be my first external fsck customer, is there anyway you can do a raw device based backup of the blocks? This way if I do mess things up we can repeat the experiment.

-chris

Signature · 2 lines
,-| Vladi
`-| Gergov