Re: Help with data recovering

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Arne,

Can you advice how can I recover data?
I tried almost everything what I found on https://btrfs.wiki.kernel.org

/btrfs-restore restored some files but it is not what was stored.

I have seen this command

--------------------------------------------------
In case of a corrupted superblock, start by asking btrfsck to use an alternate copy of the superblock instead of the superblock #0. This is achieved via the -s option followed by the number of the alternate copy you wish to use. In the following example we ask for using the superblock copy #2 of /dev/sda7:

# ./btrfsck -s 2 /dev/sd7

-----------------------------------------
but it gave me:
$ sudo btrfsck -s 2 /dev/sdb
btrfsck: invalid option -- 's'
usage: btrfsck dev
Btrfs Btrfs v0.19

What can I do more?


On 06/04/2012 07:32 AM, Arne Jansen wrote:
On 04.06.2012 13:30, Maxim Mikheev wrote:
How can I mount it at the first?
Let me state it differently: If you can't mount it, you can't scrub it.

On 06/04/2012 04:18 AM, Arne Jansen wrote:
On 04.06.2012 04:59, 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

Even to scrub a single device, the filesystem has to be mounted.

(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@xxxxxxxxx
<mailto:mikhmv@xxxxxxxxx>>     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@xxxxxxxxx<mailto:mikhmv@xxxxxxxxx>>
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@xxxxxxxxxxxxxxx
        <mailto:majordomo@xxxxxxxxxxxxxxx>
        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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux