Re: Help with data recovering

[Liu Bo <liubo2009@cn.fujitsu.com>]

On 06/04/2012 09:43 AM, Maxim Mikheev wrote:

> Hi Liu,
> 
> thanks for advice. I tried it before btrfsck. results are here:
> max@s0:~$ sudo mount /tank -o recovery
> [sudo] password for max:
> mount: wrong fs type, bad option, bad superblock on /dev/sdf,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 
> max@s0:~$ sudo mount -o recovery /tank
> mount: wrong fs type, bad option, bad superblock on /dev/sdf,
>        missing codepage or helper program, or other error
>        In some cases useful info is found in syslog - try
>        dmesg | tail  or so
> 


Two possible ways:

1)
I noticed that your btrfs had 5 partitions in all:
mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

Can you try to mount other disk partitions instead by hand, like:
mount /dev/sdb /tank
mount /dev/sdc /tank
mount /dev/sdd /tank
mount /dev/sde /tank
mount /dev/sdf /tank

2)
use btrfs's scrub to resort to metadata backups created by RAID1.

thanks,
liubo

> dmesg after boot before mount -o recovery:
> [   51.829352] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [   51.841153] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [   51.841603] btrfs read error corrected: ino 1 off 5468060241920 (dev
> /dev/sdb sector 2143292648)
> [   51.841610] Failed to read block groups: -5
> [   51.848057] btrfs: open_ctree failed
> ..............................
> dmesg after both mounts:
> 
> [  123.687773] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5
> transid 9096 /dev/sdf
> [  123.733678] btrfs: use lzo compression
> [  123.733683] btrfs: enabling auto recovery
> [  123.733686] btrfs: disk space caching is enabled
> [  131.699910] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [  131.714018] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [  131.715059] btrfs read error corrected: ino 1 off 5468060241920 (dev
> /dev/sdb sector 2143292648)
> [  131.715072] Failed to read block groups: -5
> [  131.727176] btrfs: open_ctree failed
> [  161.697873] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5
> transid 9096 /dev/sdf
> [  161.746345] btrfs: use lzo compression
> [  161.746354] btrfs: enabling auto recovery
> [  161.746358] btrfs: disk space caching is enabled
> [  169.720823] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [  169.732048] parent transid verify failed on 5468060241920 wanted 9096
> found 7621
> [  169.732611] btrfs read error corrected: ino 1 off 5468060241920 (dev
> /dev/sdb sector 2143292648)
> [  169.732623] Failed to read block groups: -5
> [  169.743437] btrfs: open_ctree failed
> 
> So It does not work. I have seen in some posts command:
> 
> sudo mount -s 2 -o recovery /tank
> Should I try it?
> 
> Please help me, I need to get this data ASAP.
> 
> Regards,
>    Max
> 
> On 06/03/2012 09:22 PM, Liu Bo wrote:
>> On 06/02/2012 09:43 PM, Maxim Mikheev wrote:
>>
>>> Repair was not helpful.
>>> Is any other ways to get access to data?
>>>
>>> Please help....
>>>
>>
>> Hi Maxim,
>>
>> Besides btrfsck --repair, we also have a recovery mount option to deal
>> with your situation,
>> maybe you can try mount xxx -o recovery and see if it helps?
>>
>>
>> thanks,
>> liubo
>>
>>> On 05/30/2012 11:15 PM, Michael K wrote:
>>>> Let it run to completion. There is little you can do other than hope
>>>> and wait.
>>>>
>>>> On May 30, 2012 9:02 PM, "Maxim Mikheev"<mikhmv@gmail.com
>>>> <mailto:mikhmv@gmail.com>>  wrote:
>>>>
>>>>      btrfsck --repair running already for 26 hours.
>>>>
>>>>      Is it have sense to wait more?
>>>>
>>>>      Thanks
>>>>
>>>>      On 05/29/2012 07:36 PM, cwillu wrote:
>>>>
>>>>          On Tue, May 29, 2012 at 5:24 PM, Maxim
>>>>          Mikheev<mikhmv@gmail.com<mailto:mikhmv@gmail.com>>   wrote:
>>>>
>>>>              Thank you for your answer.
>>>>
>>>>
>>>>              The system kernel was and now:
>>>>
>>>>              Linux s0 3.4.0-030400-generic #201205210521 SMP Mon May 21
>>>>              09:22:02 UTC 2012
>>>>              x86_64 x86_64 x86_64 GNU/Linux
>>>>
>>>>              the raid was created by:
>>>>              mkfs.btrfs /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
>>>>
>>>>              Disk are connected through RocketRaid 2670.
>>>>
>>>>              for mounting I used line in fstab:
>>>>              UUID=c9776e19-37eb-4f9c-bd6b-04e8dde97682    /tank
>>>>               btrfs
>>>>               defaults,compress=lzo    0    1
>>>>
>>>>              On machine was running several Virtual machines. Only one
>>>>              was actively using
>>>>              disks.
>>>>
>>>>              VM has active several threads:
>>>>              1. 2 threads reading big files (50GB each)
>>>>              2. reading from 50 files and writing one big file
>>>>              3. The kernel panic happens when I run another program
>>>>              with 30 threads of
>>>>              reading/writing of small files.
>>>>
>>>>              Virtual Machine accessed to underline btrfs through 9-p
>>>>              file system which
>>>>              actively used xattr.
>>>>
>>>>              After reboot system was in this stage.
>>>>
>>>>              I hope that btrfsck --repair will not make it worse, It is
>>>>              now running.
>>>>
>>>>          **twitch**
>>>>
>>>>          Well, I also hope it won't make it worse.  Do not cancel it
>>>>          now, let
>>>>          it finish (aborting it will  make things worse), but I suggest
>>>>          waiting
>>>>          until a few more people have weighed in before attempting
>>>> anything
>>>>          beyond that.
>>>>
>>>>      --
>>>>      To unsubscribe from this list: send the line "unsubscribe
>>>>      linux-btrfs" in
>>>>      the body of a message to majordomo@vger.kernel.org
>>>>      <mailto: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
>>>
>>
> -- 
> 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
>