From: Maxim Mikheev <mikhmv@gmail.com>
To: Liu Bo <liubo2009@cn.fujitsu.com>
Cc: linux-btrfs@vger.kernel.org,
Jan Schmidt <list.btrfs@jan-o-sch.net>,
Arne Jansen <sensille@gmx.net>
Subject: Re: Help with data recovering
Date: Sun, 03 Jun 2012 23:13:49 -0400 [thread overview]
Message-ID: <4FCC27ED.9040503@gmail.com> (raw)
In-Reply-To: <4FCC2496.6070805@cn.fujitsu.com>
I tried:
max@s0:~$ sudo btrfs-restore /dev/sdb ~/restored
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
parent transid verify failed on 5468060241920 wanted 9096 found 7621
Ignoring transid failure
leaf parent key incorrect 5468060241920
parent transid verify failed on 5333392302080 wanted 9096 found 4585
parent transid verify failed on 5333392302080 wanted 9096 found 4585
Root objectid is 5
ret is -3
max@s0:~$ ls -lahs restored/Irina/
total 12K
4.0K drwxr-xr-x 3 root root 4.0K Jun 3 23:12 .
4.0K drwxrwxr-x 3 max max 4.0K Jun 3 23:12 ..
4.0K drwxr-xr-x 2 root root 4.0K Jun 3 23:12 .idmapdir2
max@s0:~$ ls -lahs restored/Irina/.idmapdir2/
total 8.0K
4.0K drwxr-xr-x 2 root root 4.0K Jun 3 23:12 .
4.0K drwxr-xr-x 3 root root 4.0K Jun 3 23:12 ..
0 -rw-r--r-- 1 root root 0 Jun 3 23:12 4.bucket.lock
0 -rw-r--r-- 1 root root 0 Jun 3 23:12 7.bucket
max@s0:~$
dmesg:
[ 4764.795798] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 2
transid 9096 /dev/sdb
[ 4764.796901] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 3
transid 9095 /dev/sdd
[ 4764.797888] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 1
transid 9096 /dev/sda
[ 4764.799309] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 4
transid 9096 /dev/sde
[ 4764.801220] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5
transid 9096 /dev/sdf
Command:
sudo btrfs-find-root /dev/sdb
gave me many lines like these:
Well block 4046409486336 seems great, but generation doesn't match,
have=9087, want=9096
Well block 4046414626816 seems great, but generation doesn't match,
have=9088, want=9096
Well block 4148447113216 seems great, but generation doesn't match,
have=7618, want=9096
Well block 4148522024960 seems great, but generation doesn't match,
have=9089, want=9096
Well block 4148539457536 seems great, but generation doesn't match,
have=9090, want=9096
Well block 4455562448896 seems great, but generation doesn't match,
have=9092, want=9096
Well block 4455568302080 seems great, but generation doesn't match,
have=9091, want=9096
Well block 4848395739136 seems great, but generation doesn't match,
have=9093, want=9096
Well block 4923796594688 seems great, but generation doesn't match,
have=9094, want=9096
Well block 4923798065152 seems great, but generation doesn't match,
have=9095, want=9096
max@s0:~$ sudo btrfs-restore -t 4923798065152 /dev/sdb ~/restored
parent transid verify failed on 4923798065152 wanted 9096 found 9095
parent transid verify failed on 4923798065152 wanted 9096 found 9095
parent transid verify failed on 4923798065152 wanted 9096 found 9095
parent transid verify failed on 4923798065152 wanted 9096 found 9095
Ignoring transid failure
Root objectid is 5
ret is -3
On 06/03/2012 10:59 PM, Liu Bo wrote:
> On 06/04/2012 10:18 AM, Maxim Mikheev wrote:
>
>> Hi Liu,
>>
>> 1) all of them not working (see dmesg at the end)
>> 2)
>> max@s0:~$ sudo btrfs scrub start /dev/sdb
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>> max@s0:~$ sudo btrfs scrub start /dev/sda
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>> max@s0:~$ sudo btrfs scrub start /dev/sdd
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>> max@s0:~$ sudo btrfs scrub start /dev/sde
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>> max@s0:~$ sudo btrfs scrub start /dev/sdf
>> ERROR: getting dev info for scrub failed: Inappropriate ioctl for device
>>
>
> (add Jan and Arne to cc, they are authors of scrub)
>
> I'm not an expert on scrub, and I'm not clear how to scrub a device directly :(
>
> btw, have you tried restore (for attempting to recover data from an unmountable filesystem):
>
> https://btrfs.wiki.kernel.org/index.php/Restore
>
> thanks,
> liubo
>
>
>> dmesg after all operations:
>> [ 2183.864056] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 2
>> transid 9096 /dev/sdb
>> [ 2183.916128] btrfs: disk space caching is enabled
>> [ 2191.863409] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2191.872937] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2191.873666] btrfs read error corrected: ino 1 off 5468060241920 (dev
>> /dev/sdb sector 2143292648)
>> [ 2191.873678] Failed to read block groups: -5
>> [ 2191.884636] btrfs: open_ctree failed
>> [ 2222.910225] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 3
>> transid 9095 /dev/sdd
>> [ 2222.959128] btrfs: disk space caching is enabled
>> [ 2231.264285] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2231.274306] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2231.275194] btrfs read error corrected: ino 1 off 5468060241920 (dev
>> /dev/sdd sector 2143292648)
>> [ 2231.275207] Failed to read block groups: -5
>> [ 2231.288795] btrfs: open_ctree failed
>> [ 2240.624691] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 4
>> transid 9096 /dev/sde
>> [ 2240.671344] btrfs: disk space caching is enabled
>> [ 2248.916772] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2248.928106] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2248.929091] btrfs read error corrected: ino 1 off 5468060241920 (dev
>> /dev/sdd sector 2143292648)
>> [ 2248.929105] Failed to read block groups: -5
>> [ 2248.939081] btrfs: open_ctree failed
>> [ 2253.829071] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 5
>> transid 9096 /dev/sdf
>> [ 2253.879940] btrfs: disk space caching is enabled
>> [ 2261.754357] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2261.767118] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2261.767929] btrfs read error corrected: ino 1 off 5468060241920 (dev
>> /dev/sdb sector 2143292648)
>> [ 2261.767942] Failed to read block groups: -5
>> [ 2261.778219] btrfs: open_ctree failed
>> [ 2309.831415] device fsid c9776e19-37eb-4f9c-bd6b-04e8dde97682 devid 1
>> transid 9096 /dev/sda
>> [ 2309.904520] btrfs: disk space caching is enabled
>> [ 2318.286463] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2318.302991] parent transid verify failed on 5468060241920 wanted 9096
>> found 7621
>> [ 2318.304000] btrfs read error corrected: ino 1 off 5468060241920 (dev
>> /dev/sdd sector 2143292648)
>> [ 2318.304013] Failed to read block groups: -5
>> [ 2318.314587] btrfs: open_ctree failed
>>
>> On 06/03/2012 10:16 PM, Liu Bo wrote:
>>> 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
>>>>
>> --
>> 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
>>
>
next prev parent reply other threads:[~2012-06-04 3:13 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-29 22:14 Help with recover data Maxim Mikheev
2012-05-29 22:40 ` Help with data recovering Maxim Mikheev
2012-05-29 23:11 ` cwillu
2012-05-29 23:24 ` Maxim Mikheev
2012-05-29 23:36 ` cwillu
2012-05-31 2:02 ` Maxim Mikheev
[not found] ` <CA+WRLO-mRoSXkdd6_ydc2py3JJCnoM4avQNanxDWWntde2Ah0A@mail.gmail.com>
2012-06-01 21:15 ` Maxim Mikheev
[not found] ` <CAGJTRcibT_pufU4tKqbBpBfm8QiuW=dhQ8BAGzQnpxMCa-dOCQ@mail.gmail.com>
2012-06-02 13:43 ` Maxim Mikheev
2012-06-04 1:22 ` Liu Bo
2012-06-04 1:43 ` Maxim Mikheev
2012-06-04 2:16 ` Liu Bo
2012-06-04 2:18 ` Maxim Mikheev
2012-06-04 2:59 ` Liu Bo
2012-06-04 3:13 ` Maxim Mikheev [this message]
2012-06-04 4:27 ` Maxim Mikheev
2012-06-04 8:18 ` Arne Jansen
2012-06-04 11:30 ` Maxim Mikheev
2012-06-04 11:32 ` Arne Jansen
2012-06-04 11:43 ` Maxim Mikheev
2012-06-04 11:49 ` Hugo Mills
2012-06-04 12:01 ` Maxim Mikheev
2012-06-04 12:11 ` Hugo Mills
2012-06-04 12:28 ` Maxim Mikheev
2012-06-04 12:34 ` Hugo Mills
2012-06-04 12:37 ` Maxim Mikheev
2012-06-04 16:24 ` Maxim Mikheev
2012-06-04 17:04 ` Hugo Mills
2012-06-04 17:09 ` Hugo Mills
2012-06-04 18:02 ` Michael
2012-06-04 18:03 ` Maxim Mikheev
2012-06-04 18:37 ` Michael
2012-06-06 16:25 ` Maxim Mikheev
2012-06-07 3:27 ` Maxim Mikheev
2012-06-05 9:55 ` Martin Steigerwald
2012-06-05 9:57 ` Martin Steigerwald
2012-06-04 14:54 ` Ryan C. Underwood
2012-06-04 16:49 ` Maxim Mikheev
2012-06-05 9:59 ` Martin Steigerwald
2012-06-05 10:23 ` Martin Steigerwald
2012-06-05 11:07 ` Helmut Hullen
2012-05-29 23:37 ` Maxim Mikheev
2012-05-29 23:14 ` Help with recover data Felix Blanke
2012-05-29 23:19 ` cwillu
2012-06-04 12:24 ` Stefan Behrens
2012-06-04 12:26 ` Maxim Mikheev
2012-06-04 13:03 ` Stefan Behrens
[not found] ` <4FCCC176.1020007@gmail.com>
2012-06-04 15:01 ` Maxim Mikheev
2012-06-04 15:02 ` Stefan Behrens
2012-06-04 15:08 ` Maxim Mikheev
2012-06-04 15:11 ` Stefan Behrens
2012-06-04 15:26 ` Maxim Mikheev
2012-06-04 17:35 ` Maxim Mikheev
2012-06-04 18:08 ` Stefan Behrens
2012-06-04 18:15 ` Ryan C. Underwood
2012-06-04 12:31 ` Maxim Mikheev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4FCC27ED.9040503@gmail.com \
--to=mikhmv@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
--cc=liubo2009@cn.fujitsu.com \
--cc=sensille@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).