kernel: scratch git repo from today 10.29.10 @ 14:30 PST Btrfs v0.19-35-g1b444cd-dirty>>> gypsyops @ /mnt > sudo btrfs filesystem showLabel: ''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>>> 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>>> gypsyops @ /mnt > sudo btrfsck /dev/sdcbtrfsck: volumes.c:1367: btrfs_read_sys_array: Assertion `!(ret)'' failed. any help please? -- ,-| Vladi `-| Gergov !DSPAM:4ccb39a9191821603519226! -- 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 Friday, 29 October, 2010, Vladi Gergov wrote:> kernel: scratch git repo from today 10.29.10 @ 14:30 PST > Btrfs v0.19-35-g1b444cd-dirty > > >>> 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 > > >>> 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 > > >>> 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 ?> -- > > ,-| Vladi > `-| Gergov > > !DSPAM:4ccb39a9191821603519226! > > > -- > 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 >-- gpg key@ keyserver.linux.it: Goffredo Baroncelli (ghigo) <kreijack@inwind.it> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512 -- 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
Excerpts from Vladi Gergov''s message of 2010-10-29 16:53:42 -0400:> >>> 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 > > >>> 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 -- 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
Chris Mason <chris.mason <at> oracle.com> writes:> > Excerpts from Vladi Gergov''s message of 2010-10-29 16:53:42 -0400: > > >>> 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 > > > > >>> 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. > > -chrisI''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 -- 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
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:> >>> 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 > > >>> 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 -- ,-| Vladi `-| Gergov -- 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