Re: Recover files from broken btrfs

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

 



On Sun, Jun 23, 2019 at 7:23 AM Robert <robertgt4@xxxxxxxxx> wrote:
>
> root@Dyskietka:~# uname -a
> Linux Dyskietka 4.4.116.armada.1 #1 SMP Mon Feb 19 22:05:00 PST 2018
> armv7l GNU/Linux
> root@Dyskietka:~# btrfs --version
> btrfs-progs v4.12


Old kernel, old progs. Definitely do not use 'btrfs check --repair'





> root@Dyskietka:~# btrfs fi show
> Label: '2fe4f8e6:data'  uuid: 0970e8c4-fd47-43d3-aa93-593006e3d0c3
>         Total devices 1 FS bytes used 8.11TiB
>         devid    1 size 10.90TiB used 8.11TiB path /dev/md127
>
> root@Dyskietka:~# btrfs fi df /dev/md127
> ERROR: not a btrfs filesystem: /dev/md127

That command won't work on an unmount device, so that's normal.



> [Sat Jun  1 13:18:53 2019] BTRFS: device label 2fe4f8e6:data devid 1
> transid 155439 /dev/md127
> [Sat Jun  1 13:18:53 2019] BTRFS info (device md127): setting nodatasum

*shrug* I guess some attempt to make it more like ext4 but with
metadata checksums and snapshots, but it renders a lot of the data
guarantees of Btrfs moot.


> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS critical (device md127): unable to
> find logical 62139990016 len 4096
> [Sat Jun  1 13:18:54 2019] BTRFS error (device md127): failed to read chunk root
> [Sat Jun  1 13:18:54 2019] BTRFS error (device md127): open_ctree failed

a. Don't modify the volume at all, as in do not try to repair it. You
need to see if a developer has any advice first.

b. Realize that this list is about development of btrfs, not
maintaining old versions of it. The maintenance job is for the vendor
who chose to use and keep using a 4.4.x kernel and 4.12 btrfs-progs.
So it's really their responsibility. This list is upstream
development: linux-next, mainline, and most recent stable kernels.

c. The most likely chance of success, even though it will take a long
time, is to use 'btrfs restore' to scrape data off the volume.
Hopefully you have a backup and you only have to try and scrape recent
data.
https://btrfs.wiki.kernel.org/index.php/Restore

d. I don't know that a newer kernel or progs will magically tell us
what's going on, or fix things. So I wouldn't necessarily go to the
trouble of imaging the Btrfs volume from md127, onto a big enough
single drive, so that you can stick it in a computer that's running
newer kernel and progs. But it's an option. And at the least,
btrfs-progs 5.1.1 for restore to scrape data off the disk should have
a better chance of success if it doesn't work with 4.12.



-- 
Chris Murphy



[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