btrfs raid1 degraded needs chunk root rebuild
Any ideas if currently I can still recover data from this volume? I have tried the new btrfs tools with btrfs rescue chunk-recover without much success. Any ideas if i can recover any of the data? - Forwarded message from Chris Mason <chris.ma...@oracle.com> - From: Chris Mason <chris.ma...@oracle.com> Subject: Re: btrfs raid1 degraded does not mount or fsck To: Vladi Gergov <vger...@gmail.com> Cc: linux-btrfs <linux-btrfs@vger.kernel.org> Date: Tue, 16 Nov 2010 16:50:58 -0500 User-Agent: Sup/git 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 !DSPAM:4ce2fd55191821234852255! - End forwarded message - -- ,-| Vladi `-| Gergov -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs raid1 degraded does not mount or fsck
Anyone know if there is currently with updated kernel and tools a way to recover the data on this? I have tried btrfs chunk-recovery with not luck. Anything else I can do to try and get the data off at least? Thanks in advance! On Tuesday, 16.11.10 at 16:50, Chris Mason wrote: > 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 > > !DSPAM:4ce2fd55191821234852255! > > -- ,-| Vladi `-| Gergov -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2 year old raid1 issue chunk-recovery help
Hi, Not sure if my previous email was received as I sent it from my phone. I had to dd the disk off and then losetup mount the image. What do you mean by erase the data on loop7? I have tried to mount separately without success. On Friday, 17.01.14 at 10:27, Miao Xie wrote: On Thu, 16 Jan 2014 10:20:42 -0800, Vladi Gergov wrote: Thanks Miao, I have tried to mount it with -o degraded and -o recovery here is the outputs: [216094.269443] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216094.281965] btrfs: device label das1 devid 7 transid 1168964 /dev/sdi [216094.313419] btrfs: device label das4 devid 3 transid 107954 /dev/sdj [216113.887503] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216113.888690] btrfs: allowing degraded mounts [216113.889440] btrfs: failed to read chunk root on loop7 [216113.905742] btrfs: open_ctree failed [216135.144739] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216135.145996] btrfs: enabling auto recovery [216135.146783] btrfs: failed to read chunk root on loop7 [216135.155985] btrfs: open_ctree failed any other suggestions? Thanks again. Is loop7 used to instead of the bad device /dev/sdi? If so, I think we should erase the data in the loop7, and then # mount dev -o degraded mnt # btrfs replace start missing new_dev Thanks Miao On Thursday, 16.01.14 at 10:10, Miao Xie wrote: On wed, 15 Jan 2014 11:40:09 -0800, Vladi Gergov wrote: Hi, in 2010 i had an issue with my raid1 when one drive failed and i added another drive to the array and tried to rebuild. Here is what bug I hit according to Chris Mason http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06868.html I have since updated to lastes btrfs-tools 3.12 + kernel 3.13-rc7 and attempted an chunk recovery which failed with this http://bpaste.net/show/168445/ If anyone can help me get at least some of the data off this bad boy it would be great! I am cc'ing Miao since his name was thrown under the bus in irc :). Thanks in advance! Chunk recover command can only recover the case that the devices are good, only the chunk tree is corrupted. So it is not suitable to fix your issue. I think you can try the replace function if you can mount the device successfully, just like: # mount dev -o degraded mnt # btrfs replace start missing new_dev Thanks Miao -- ,-| Vladi `-| Gergov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2 year old raid1 issue chunk-recovery help
Thanks Miao, I have tried to mount it with -o degraded and -o recovery here is the outputs: [216094.269443] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216094.281965] btrfs: device label das1 devid 7 transid 1168964 /dev/sdi [216094.313419] btrfs: device label das4 devid 3 transid 107954 /dev/sdj [216113.887503] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216113.888690] btrfs: allowing degraded mounts [216113.889440] btrfs: failed to read chunk root on loop7 [216113.905742] btrfs: open_ctree failed [216135.144739] btrfs: device label das4 devid 2 transid 107954 /dev/loop7 [216135.145996] btrfs: enabling auto recovery [216135.146783] btrfs: failed to read chunk root on loop7 [216135.155985] btrfs: open_ctree failed any other suggestions? Thanks again. On Thursday, 16.01.14 at 10:10, Miao Xie wrote: On wed, 15 Jan 2014 11:40:09 -0800, Vladi Gergov wrote: Hi, in 2010 i had an issue with my raid1 when one drive failed and i added another drive to the array and tried to rebuild. Here is what bug I hit according to Chris Mason http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06868.html I have since updated to lastes btrfs-tools 3.12 + kernel 3.13-rc7 and attempted an chunk recovery which failed with this http://bpaste.net/show/168445/ If anyone can help me get at least some of the data off this bad boy it would be great! I am cc'ing Miao since his name was thrown under the bus in irc :). Thanks in advance! Chunk recover command can only recover the case that the devices are good, only the chunk tree is corrupted. So it is not suitable to fix your issue. I think you can try the replace function if you can mount the device successfully, just like: # mount dev -o degraded mnt # btrfs replace start missing new_dev Thanks Miao -- ,-| Vladi `-| Gergov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
2 year old raid1 issue chunk-recovery help
Hi, in 2010 i had an issue with my raid1 when one drive failed and i added another drive to the array and tried to rebuild. Here is what bug I hit according to Chris Mason http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg06868.html I have since updated to lastes btrfs-tools 3.12 + kernel 3.13-rc7 and attempted an chunk recovery which failed with this http://bpaste.net/show/168445/ If anyone can help me get at least some of the data off this bad boy it would be great! I am cc'ing Miao since his name was thrown under the bus in irc :). Thanks in advance! -- ,-| Vladi `-| Gergov -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs raid1 degraded in need of chuck tree rebuild
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
btrfs raid1 degraded does not mount or fsck
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 devid3 size 1.82TB used 0.00 path /dev/sdb devid2 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? -- ,-| Vladi `-| Gergov !DSPAM:4ccb39a9191821603519226! -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
