* Salvage files from broken btrfs
@ 2018-10-30 20:11 Mirko Klingmann
2018-10-31 0:03 ` Qu Wenruo
2018-10-31 4:56 ` Chris Murphy
0 siblings, 2 replies; 9+ messages in thread
From: Mirko Klingmann @ 2018-10-30 20:11 UTC (permalink / raw)
To: linux-btrfs
Hi all,
my btrfs root file system on a SD card broke down and did not mount anymore.
In retrospective, I think it reached its endurance, so I know that there
is nothing to repair. All I want to do is to salvage some configuration
and data files from the remains left in my ISO file copy. The SD card is
no longer readable, so all I have is the 30GB "dd" copy of the btrfs
partition.
I also tried some things on the ISO file I later found I shouldn't have
done with the "btrfs" tools, which I think broke the file system in it
even more.
So at this stage, this is the "dmesg" output when trying to mount the
ISO file, which then fails:
[ 249.239883] BTRFS: device fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c
devid 1 transid 1757933 /dev/loop2
[ 249.241504] BTRFS info (device loop2): disk space caching is enabled
[ 249.275950] BTRFS error (device loop2): bad tree block start 0 20987904
[ 249.280936] BTRFS error (device loop2): bad tree block start 0 20987904
[ 249.280946] BTRFS error (device loop2): failed to read chunk root
[ 249.336291] BTRFS error (device loop2): open_ctree failed
Output of "uname -a":
Linux desinfect 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5
16:43:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Output of "btrfs --version":
btrfs-progs v4.4
When reading the ISO file with "Active@ Disk Editor" (a hex file editor)
I find a super block at offset 0x10000 that looks like this:
B8E15DD7000000000000000000000000000000000000000000000000000000004235AA4F77214E7397F07FE0E9A3CE9C000001000000000001000000000000005F42485266535F4DEDD21A00000000000040FF3400000000004040010000000000000E350000000000000000000000000000E02307000000006092F1030000000600000000000000010000000000000000100000004000000040000000100000E2000000A6380E0000000000000000000000000000000000000000006100000000000000000000000001000000000000000000E023070000000000E0230700000000100000001000000010000000000000000000000000000000000000000000000000000000000000000090185CF6B93749BBB19191D08677EE224235AA4F77214E7397F07FE0E9A3CE9C
The super block at offset 0x4000000 is zeroed out.
When looking at the addresses of chunk root (0x1404000), root of tree
root (0x34FF4000) and log tree root (0x350E0000) in the first super
block they are all zeroed out as well. So I think I understand why the
error "failed to read chunk root" crops up.
If I try to "restore" using "btrfs restore sdcard.iso /outdir" I get
this output:
checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
bytenr mismatch, want=20987904, have=0
Couldn't read chunk root
Could not open root, trying backup super
No valid Btrfs found on sdcard.iso
Could not open root, trying backup super
Superblock bytenr is larger than device size
Could not open root, trying backup super
And, finally, I can see "/etc" someplace near "fstab" in the ISO which
looks like a directory listing as well as content of files I remember,
which tells me, that the data I still in there somewhere.
So, what can I do to get the files I need out of this blob. I am willing
to follow data pointers as described in
https://btrfs.wiki.kernel.org/index.php/On-disk_Format in the hex editor
and copy the data from there.
Can anyone give me any pointers into the ISO file (maybe starting from
the super block) to help me extract the data I need?
Cheers,
Mirko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-10-30 20:11 Salvage files from broken btrfs Mirko Klingmann
@ 2018-10-31 0:03 ` Qu Wenruo
2018-11-02 14:30 ` M. Klingmann
2018-10-31 4:56 ` Chris Murphy
1 sibling, 1 reply; 9+ messages in thread
From: Qu Wenruo @ 2018-10-31 0:03 UTC (permalink / raw)
To: Mirko Klingmann, linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 5190 bytes --]
On 2018/10/31 上午4:11, Mirko Klingmann wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
>
> In retrospective, I think it reached its endurance, so I know that there
> is nothing to repair. All I want to do is to salvage some configuration
> and data files from the remains left in my ISO file copy. The SD card is
> no longer readable, so all I have is the 30GB "dd" copy of the btrfs
> partition.
>
> I also tried some things on the ISO file I later found I shouldn't have
> done with the "btrfs" tools, which I think broke the file system in it
> even more.
Not exactly.
For your case, your best friend would be btrfs-restore + some way to
recover chunk tree.
Unless you want to do all salvage manually.
>
> So at this stage, this is the "dmesg" output when trying to mount the
> ISO file, which then fails:
>
> [ 249.239883] BTRFS: device fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c
> devid 1 transid 1757933 /dev/loop2
> [ 249.241504] BTRFS info (device loop2): disk space caching is enabled
> [ 249.275950] BTRFS error (device loop2): bad tree block start 0 20987904
> [ 249.280936] BTRFS error (device loop2): bad tree block start 0 20987904
> [ 249.280946] BTRFS error (device loop2): failed to read chunk root
> [ 249.336291] BTRFS error (device loop2): open_ctree failed
>
> Output of "uname -a":
>
> Linux desinfect 4.13.0-39-generic #44~16.04.1-Ubuntu SMP Thu Apr 5
> 16:43:10 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
>
> Output of "btrfs --version":
>
> btrfs-progs v4.4
>
> When reading the ISO file with "Active@ Disk Editor" (a hex file editor)
> I find a super block at offset 0x10000 that looks like this:
That's the primary super block.
BTW, you could use just 'grep' to locate btrfs superblock:
# grep -obUaP "\x5F\x42\x48\x52\x66\x53\x5F\x4D" <device>
It's better to use "btrfs ins dump-super -fFa" to show the superblock
info in a human readable way.
>
> B8E15DD7000000000000000000000000000000000000000000000000000000004235AA4F77214E7397F07FE0E9A3CE9C000001000000000001000000000000005F42485266535F4DEDD21A00000000000040FF3400000000004040010000000000000E350000000000000000000000000000E02307000000006092F1030000000600000000000000010000000000000000100000004000000040000000100000E2000000A6380E0000000000000000000000000000000000000000006100000000000000000000000001000000000000000000E023070000000000E0230700000000100000001000000010000000000000000000000000000000000000000000000000000000000000000090185CF6B93749BBB19191D08677EE224235AA4F77214E7397F07FE0E9A3CE9C
>
> The super block at offset 0x4000000 is zeroed out.
>
> When looking at the addresses of chunk root (0x1404000), root of tree
> root (0x34FF4000) and log tree root (0x350E0000) in the first super
> block they are all zeroed out as well. So I think I understand why the
> error "failed to read chunk root" crops up.
Not a big problem really.
We can still find the chunk root just using the system chunk array (and
some time) easily, since normally system chunks are small and we can
afford checking all tree blocks in that range.
That's why I'm recommended to use "btrfs ins dump-super" to inspect the
superblock, as that allow us to inspect system chunk array.
IIRC btrfs-find-root is pretty good at such job, if that works.
>
> If I try to "restore" using "btrfs restore sdcard.iso /outdir" I get
> this output:
>
> checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
> checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
> checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
> checksum verify failed on 20987904 found E4E3BDB6 wanted 00000000
> bytenr mismatch, want=20987904, have=0
> Couldn't read chunk root
> Could not open root, trying backup super
> No valid Btrfs found on sdcard.iso
> Could not open root, trying backup super
> Superblock bytenr is larger than device size
> Could not open root, trying backup super
My plan for such recovery is:
1) btrfs ins dump-super to make sure system chunk array is valid
2) btrfs-find-root to find any valid chunk tree blocks
3) pass that chunk tree bytenr to btrfs-restore
Unfortunately, btrfs-restore doesn't support specifying chunk root
yet. But it's pretty easy to add such support.
So, please provide the "btrfs ins dump-super -Ffa" output to start with.
>
> And, finally, I can see "/etc" someplace near "fstab" in the ISO which
> looks like a directory listing as well as content of files I remember,
> which tells me, that the data I still in there somewhere.
>
> So, what can I do to get the files I need out of this blob. I am willing
> to follow data pointers as described in
> https://btrfs.wiki.kernel.org/index.php/On-disk_Format in the hex editor
> and copy the data from there.
If there is something that a hex editor is really needed, it means we
should add a new function in btrfs-progs. :)
Thanks,
Qu
>
> Can anyone give me any pointers into the ISO file (maybe starting from
> the super block) to help me extract the data I need?
>
> Cheers,
>
> Mirko
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-10-30 20:11 Salvage files from broken btrfs Mirko Klingmann
2018-10-31 0:03 ` Qu Wenruo
@ 2018-10-31 4:56 ` Chris Murphy
2018-11-02 14:21 ` M. Klingmann
1 sibling, 1 reply; 9+ messages in thread
From: Chris Murphy @ 2018-10-31 4:56 UTC (permalink / raw)
To: Mirko Klingmann; +Cc: Btrfs BTRFS
On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann <m.klingmann@gmx.de> wrote:
> Hi all,
>
> my btrfs root file system on a SD card broke down and did not mount anymore.
It might mount with -o ro,nologreplay
Typically an SD card will break in a way that it can't write, and
mount will just hang (with mmcblk errors). Mounting with both ro and
nologreplay will ensure no writes are needed, allowing the mount to
succeed. of course any changes that are in the log tree will be
missing so recent transactions may be unrecoverable but so far I've
had good luck recovering from broken SD cards this way.
--
Chris Murphy
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-10-31 4:56 ` Chris Murphy
@ 2018-11-02 14:21 ` M. Klingmann
0 siblings, 0 replies; 9+ messages in thread
From: M. Klingmann @ 2018-11-02 14:21 UTC (permalink / raw)
To: Chris Murphy; +Cc: linux-btrfs
On 31.10.2018 at 05:56 Chris Murphy wrote:
> On Tue, Oct 30, 2018 at 4:11 PM, Mirko Klingmann <m.klingmann@gmx.de> wrote:
>> Hi all,
>>
>> my btrfs root file system on a SD card broke down and did not mount anymore.
> It might mount with -o ro,nologreplay
>
> Typically an SD card will break in a way that it can't write, and
> mount will just hang (with mmcblk errors). Mounting with both ro and
> nologreplay will ensure no writes are needed, allowing the mount to
> succeed. of course any changes that are in the log tree will be
> missing so recent transactions may be unrecoverable but so far I've
> had good luck recovering from broken SD cards this way.
>
No luck with these options. The error still persists with same output in
"dmesg".
Thanks for your effort...
--
Mirko
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-10-31 0:03 ` Qu Wenruo
@ 2018-11-02 14:30 ` M. Klingmann
2018-11-02 14:45 ` Qu Wenruo
0 siblings, 1 reply; 9+ messages in thread
From: M. Klingmann @ 2018-11-02 14:30 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 7562 bytes --]
On 31.10.2018 at 01:03 Qu Wenruo wrote:
> My plan for such recovery is:
>
> 1) btrfs ins dump-super to make sure system chunk array is valid
> 2) btrfs-find-root to find any valid chunk tree blocks
> 3) pass that chunk tree bytenr to btrfs-restore
> Unfortunately, btrfs-restore doesn't support specifying chunk root
> yet. But it's pretty easy to add such support.
>
> So, please provide the "btrfs ins dump-super -Ffa" output to start with.
Following your plan, I did 1) and 2).
As 2) failed (see below), is there anything I can do to find the tree
bytenr to supply btrfs-restore with it?
1) Here's the output given by "btrfs-show-super -Ffa":
superblock: bytenr=65536, device=sdcard.iso
---------------------------------------------------------
csum 0xb8e15dd7 [match]
bytenr 65536
flags 0x1
( WRITTEN )
magic _BHRfS_M [match]
fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c
label
generation 1757933
root 889143296
sys_array_size 226
chunk_root_generation 932006
root_level 0
chunk_root 20987904
chunk_root_level 0
log_root 890109952
log_root_transid 0
log_root_level 0
total_bytes 30666653696
bytes_used 16937803776
sectorsize 4096
nodesize 16384
leafsize 16384
stripesize 4096
root_dir 6
num_devices 1
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x61
( MIXED_BACKREF |
BIG_METADATA |
EXTENDED_IREF )
csum_type 0
csum_size 4
cache_generation 1757933
uuid_tree_generation 149
dev_item.uuid 90185cf6-b937-49bb-b191-91d08677ee22
dev_item.fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c [match]
dev_item.type 0
dev_item.total_bytes 30666653696
dev_item.bytes_used 30666653696
dev_item.io_align 4096
dev_item.io_width 4096
dev_item.sector_size 4096
dev_item.devid 1
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
sys_chunk_array[2048]:
item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 0)
chunk length 4194304 owner 2 stripe_len 65536
type SYSTEM num_stripes 1
stripe 0 devid 1 offset 0
dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
chunk length 8388608 owner 2 stripe_len 65536
type SYSTEM|DUP num_stripes 2
stripe 0 devid 1 offset 20971520
dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
stripe 1 devid 1 offset 29360128
dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
backup_roots[4]:
backup 0:
backup_tree_root: 889143296 gen: 1757933 level: 0
backup_chunk_root: 20987904 gen: 932006 level: 0
backup_extent_root: 888881152 gen: 1757933 level: 2
backup_fs_root: 889716736 gen: 1757934 level: 2
backup_dev_root: 307560448 gen: 1673227 level: 0
backup_csum_root: 887898112 gen: 1757934 level: 2
backup_total_bytes: 30666653696
backup_bytes_used: 16937803776
backup_num_devices: 1
backup 1:
backup_tree_root: 882311168 gen: 1757930 level: 0
backup_chunk_root: 20987904 gen: 932006 level: 0
backup_extent_root: 879738880 gen: 1757931 level: 2
backup_fs_root: 883097600 gen: 1757931 level: 2
backup_dev_root: 307560448 gen: 1673227 level: 0
backup_csum_root: 883212288 gen: 1757931 level: 2
backup_total_bytes: 30666653696
backup_bytes_used: 16943640576
backup_num_devices: 1
backup 2:
backup_tree_root: 881082368 gen: 1757931 level: 0
backup_chunk_root: 20987904 gen: 932006 level: 0
backup_extent_root: 879738880 gen: 1757931 level: 2
backup_fs_root: 883654656 gen: 1757932 level: 2
backup_dev_root: 307560448 gen: 1673227 level: 0
backup_csum_root: 883703808 gen: 1757932 level: 2
backup_total_bytes: 30666653696
backup_bytes_used: 16943722496
backup_num_devices: 1
backup 3:
backup_tree_root: 887865344 gen: 1757932 level: 0
backup_chunk_root: 20987904 gen: 932006 level: 0
backup_extent_root: 888881152 gen: 1757933 level: 2
backup_fs_root: 888750080 gen: 1757933 level: 2
backup_dev_root: 307560448 gen: 1673227 level: 0
backup_csum_root: 888832000 gen: 1757933 level: 2
backup_total_bytes: 30666653696
backup_bytes_used: 16937803776
backup_num_devices: 1
superblock: bytenr=67108864, device=sdcard.iso
---------------------------------------------------------
csum 0x00000000 [DON'T MATCH]
bytenr 0
flags 0x0
magic ........ [DON'T MATCH]
fsid 00000000-0000-0000-0000-000000000000
label
generation 0
root 0
sys_array_size 0
chunk_root_generation 0
root_level 0
chunk_root 0
chunk_root_level 0
log_root 0
log_root_transid 0
log_root_level 0
total_bytes 0
bytes_used 0
sectorsize 0
nodesize 0
leafsize 0
stripesize 0
root_dir 0
num_devices 0
compat_flags 0x0
compat_ro_flags 0x0
incompat_flags 0x0
csum_type 0
csum_size 4
cache_generation 0
uuid_tree_generation 0
dev_item.uuid 00000000-0000-0000-0000-000000000000
dev_item.fsid 00000000-0000-0000-0000-000000000000 [match]
dev_item.type 0
dev_item.total_bytes 0
dev_item.bytes_used 0
dev_item.io_align 0
dev_item.io_width 0
dev_item.sector_size 0
dev_item.devid 0
dev_item.dev_group 0
dev_item.seek_speed 0
dev_item.bandwidth 0
dev_item.generation 0
sys_chunk_array[2048]:
backup_roots[4]:
2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed".
> Thanks,
> Qu
Thank you for your quick response and help.
--
Mirko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-11-02 14:30 ` M. Klingmann
@ 2018-11-02 14:45 ` Qu Wenruo
2018-11-02 17:18 ` M. Klingmann
0 siblings, 1 reply; 9+ messages in thread
From: Qu Wenruo @ 2018-11-02 14:45 UTC (permalink / raw)
To: M. Klingmann; +Cc: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 7054 bytes --]
On 2018/11/2 下午10:30, M. Klingmann wrote:
>
> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>> My plan for such recovery is:
>>
>> 1) btrfs ins dump-super to make sure system chunk array is valid
>> 2) btrfs-find-root to find any valid chunk tree blocks
>> 3) pass that chunk tree bytenr to btrfs-restore
>> Unfortunately, btrfs-restore doesn't support specifying chunk root
>> yet. But it's pretty easy to add such support.
>>
>> So, please provide the "btrfs ins dump-super -Ffa" output to start with.
> Following your plan, I did 1) and 2).
> As 2) failed (see below), is there anything I can do to find the tree
> bytenr to supply btrfs-restore with it?
>
> 1) Here's the output given by "btrfs-show-super -Ffa":
>
> superblock: bytenr=65536, device=sdcard.iso
> ---------------------------------------------------------
> csum 0xb8e15dd7 [match]
> bytenr 65536
> flags 0x1
> ( WRITTEN )
> magic _BHRfS_M [match]
> fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c
> label
> generation 1757933
> root 889143296
> sys_array_size 226
> chunk_root_generation 932006
> root_level 0
> chunk_root 20987904
> chunk_root_level 0
> log_root 890109952
> log_root_transid 0
> log_root_level 0
> total_bytes 30666653696
> bytes_used 16937803776
> sectorsize 4096
> nodesize 16384
> leafsize 16384
> stripesize 4096
> root_dir 6
> num_devices 1
> compat_flags 0x0
> compat_ro_flags 0x0
> incompat_flags 0x61
> ( MIXED_BACKREF |
> BIG_METADATA |
> EXTENDED_IREF )
> csum_type 0
> csum_size 4
> cache_generation 1757933
> uuid_tree_generation 149
> dev_item.uuid 90185cf6-b937-49bb-b191-91d08677ee22
> dev_item.fsid 4235aa4f-7721-4e73-97f0-7fe0e9a3ce9c [match]
> dev_item.type 0
> dev_item.total_bytes 30666653696
> dev_item.bytes_used 30666653696
> dev_item.io_align 4096
> dev_item.io_width 4096
> dev_item.sector_size 4096
> dev_item.devid 1
> dev_item.dev_group 0
> dev_item.seek_speed 0
> dev_item.bandwidth 0
> dev_item.generation 0
> sys_chunk_array[2048]:
> item 0 key (FIRST_CHUNK_TREE CHUNK_ITEM 0)
> chunk length 4194304 owner 2 stripe_len 65536
> type SYSTEM num_stripes 1
> stripe 0 devid 1 offset 0
> dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
> item 1 key (FIRST_CHUNK_TREE CHUNK_ITEM 20971520)
> chunk length 8388608 owner 2 stripe_len 65536
> type SYSTEM|DUP num_stripes 2
This chunk looks pretty OK.
And it's DUP, so it improves the possibility to recover.
> stripe 0 devid 1 offset 20971520
> dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
> stripe 1 devid 1 offset 29360128
> dev uuid: 90185cf6-b937-49bb-b191-91d08677ee22
> backup_roots[4]:
> backup 0:
> backup_tree_root: 889143296 gen: 1757933 level: 0
> backup_chunk_root: 20987904 gen: 932006 level: 0
> backup_extent_root: 888881152 gen: 1757933 level: 2
> backup_fs_root: 889716736 gen: 1757934 level: 2
> backup_dev_root: 307560448 gen: 1673227 level: 0
> backup_csum_root: 887898112 gen: 1757934 level: 2
> backup_total_bytes: 30666653696
> backup_bytes_used: 16937803776
> backup_num_devices: 1
>
> backup 1:
> backup_tree_root: 882311168 gen: 1757930 level: 0
> backup_chunk_root: 20987904 gen: 932006 level: 0
> backup_extent_root: 879738880 gen: 1757931 level: 2
> backup_fs_root: 883097600 gen: 1757931 level: 2
> backup_dev_root: 307560448 gen: 1673227 level: 0
> backup_csum_root: 883212288 gen: 1757931 level: 2
> backup_total_bytes: 30666653696
> backup_bytes_used: 16943640576
> backup_num_devices: 1
>
> backup 2:
> backup_tree_root: 881082368 gen: 1757931 level: 0
> backup_chunk_root: 20987904 gen: 932006 level: 0
> backup_extent_root: 879738880 gen: 1757931 level: 2
> backup_fs_root: 883654656 gen: 1757932 level: 2
> backup_dev_root: 307560448 gen: 1673227 level: 0
> backup_csum_root: 883703808 gen: 1757932 level: 2
> backup_total_bytes: 30666653696
> backup_bytes_used: 16943722496
> backup_num_devices: 1
>
> backup 3:
> backup_tree_root: 887865344 gen: 1757932 level: 0
> backup_chunk_root: 20987904 gen: 932006 level: 0
> backup_extent_root: 888881152 gen: 1757933 level: 2
> backup_fs_root: 888750080 gen: 1757933 level: 2
> backup_dev_root: 307560448 gen: 1673227 level: 0
> backup_csum_root: 888832000 gen: 1757933 level: 2
> backup_total_bytes: 30666653696
> backup_bytes_used: 16937803776
> backup_num_devices: 1
[snip]
> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed".
It's not plain "btrfs-find-root" but "btrfs-find-root -o 5".
And you should use btrfs-progs v4.17.1, not the old v4.4.
The ability to continue search even if chunk tree get corrupted is added
in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of
fixes and extra debug output.
If you can't find any handy way to update btrfs-progs, you could use
Archlinux iso as a rescue OS to use the latest btrfs-progs.
For 3), I could easily add such feature btrfs-restore, or just use
manually patching your superblock to continue.
So as soon as your "btrfs-find-root -o 5" gets some valid output, I
could continue the work.
Thanks,
Qu
>
>> Thanks,
>> Qu
>
> Thank you for your quick response and help.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-11-02 14:45 ` Qu Wenruo
@ 2018-11-02 17:18 ` M. Klingmann
2018-11-03 1:05 ` Qu Wenruo
0 siblings, 1 reply; 9+ messages in thread
From: M. Klingmann @ 2018-11-02 17:18 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 2252 bytes --]
On 02.11.2018 at 15:45 Qu Wenruo wrote:
> On 2018/11/2 下午10:30, M. Klingmann wrote:
>> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>>> My plan for such recovery is:
>>>
>>> 1) btrfs ins dump-super to make sure system chunk array is valid
>>> 2) btrfs-find-root to find any valid chunk tree blocks
>>> 3) pass that chunk tree bytenr to btrfs-restore
>>> Unfortunately, btrfs-restore doesn't support specifying chunk root
>>> yet. But it's pretty easy to add such support.
>>>
>>> So, please provide the "btrfs ins dump-super -Ffa" output to start with.
>> Following your plan, I did 1) and 2).
>> As 2) failed (see below), is there anything I can do to find the tree
>> bytenr to supply btrfs-restore with it?
>>
>> 1) Here's the output given by "btrfs-show-super -Ffa":
>>
>> superblock: bytenr=65536, device=sdcard.iso
>> ---------------------------------------------------------
>> csum 0xb8e15dd7 [match]
[snip]
>> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed".
> It's not plain "btrfs-find-root" but "btrfs-find-root -o 5".
>
> And you should use btrfs-progs v4.17.1, not the old v4.4.
> The ability to continue search even if chunk tree get corrupted is added
> in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of
> fixes and extra debug output.
>
> If you can't find any handy way to update btrfs-progs, you could use
> Archlinux iso as a rescue OS to use the latest btrfs-progs.
Using Archlinux in fact is the easiest way to use version 4.17.1
(Archlinux for 2018-11-01).
Here's the output from "btrfs-find-root sdcard.iso":
WARNING: cannot read chunk root, continue anyway
Superblock thinks the generation is 1757933
Superblock thinks the level is 0
Here's the output using "btrfs-find-root -o 5 sdcard.iso":
WARNING: cannot read chunk root, continue anyway
Superblock doesn't contain generation info for root 5
Superblock doesn't contain the level info for root 5
> For 3), I could easily add such feature btrfs-restore, or just use
> manually patching your superblock to continue.
> So as soon as your "btrfs-find-root -o 5" gets some valid output, I
> could continue the work.
>
Thank you.
--
Mirko
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Salvage files from broken btrfs
2018-11-02 17:18 ` M. Klingmann
@ 2018-11-03 1:05 ` Qu Wenruo
2018-11-05 13:22 ` M. Klingmann
0 siblings, 1 reply; 9+ messages in thread
From: Qu Wenruo @ 2018-11-03 1:05 UTC (permalink / raw)
To: M. Klingmann; +Cc: linux-btrfs
[-- Attachment #1.1: Type: text/plain, Size: 2557 bytes --]
On 2018/11/3 上午1:18, M. Klingmann wrote:
> On 02.11.2018 at 15:45 Qu Wenruo wrote:
>> On 2018/11/2 下午10:30, M. Klingmann wrote:
>>> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>>>> My plan for such recovery is:
>>>>
>>>> 1) btrfs ins dump-super to make sure system chunk array is valid
>>>> 2) btrfs-find-root to find any valid chunk tree blocks
>>>> 3) pass that chunk tree bytenr to btrfs-restore
>>>> Unfortunately, btrfs-restore doesn't support specifying chunk root
>>>> yet. But it's pretty easy to add such support.
>>>>
>>>> So, please provide the "btrfs ins dump-super -Ffa" output to start with.
>>> Following your plan, I did 1) and 2).
>>> As 2) failed (see below), is there anything I can do to find the tree
>>> bytenr to supply btrfs-restore with it?
>>>
>>> 1) Here's the output given by "btrfs-show-super -Ffa":
>>>
>>> superblock: bytenr=65536, device=sdcard.iso
>>> ---------------------------------------------------------
>>> csum 0xb8e15dd7 [match]
> [snip]
>>> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed".
>> It's not plain "btrfs-find-root" but "btrfs-find-root -o 5".
>>
>> And you should use btrfs-progs v4.17.1, not the old v4.4.
>> The ability to continue search even if chunk tree get corrupted is added
>> in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of
>> fixes and extra debug output.
>>
>> If you can't find any handy way to update btrfs-progs, you could use
>> Archlinux iso as a rescue OS to use the latest btrfs-progs.
>
> Using Archlinux in fact is the easiest way to use version 4.17.1
> (Archlinux for 2018-11-01).
>
> Here's the output from "btrfs-find-root sdcard.iso":
>
> WARNING: cannot read chunk root, continue anyway
> Superblock thinks the generation is 1757933
> Superblock thinks the level is 0
>
> Here's the output using "btrfs-find-root -o 5 sdcard.iso":
>
> WARNING: cannot read chunk root, continue anyway
> Superblock doesn't contain generation info for root 5
> Superblock doesn't contain the level info for root 5
No other output at all?
That means the whole 8M range of system chunk get corrupted.
Thus really no way to get any meaningful data out of the filesystem,
unfortunately.
Thanks,
Qu
>
>> For 3), I could easily add such feature btrfs-restore, or just use
>> manually patching your superblock to continue.
>> So as soon as your "btrfs-find-root -o 5" gets some valid output, I
>> could continue the work.
>>
> Thank you.
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Salvage files from broken btrfs
2018-11-03 1:05 ` Qu Wenruo
@ 2018-11-05 13:22 ` M. Klingmann
0 siblings, 0 replies; 9+ messages in thread
From: M. Klingmann @ 2018-11-05 13:22 UTC (permalink / raw)
To: Qu Wenruo; +Cc: linux-btrfs
On 03.11.2018 at 02:05 Qu Wenruo wrote:
> On 2018/11/3 上午1:18, M. Klingmann wrote:
>> On 02.11.2018 at 15:45 Qu Wenruo wrote:
>>> On 2018/11/2 下午10:30, M. Klingmann wrote:
>>>> On 31.10.2018 at 01:03 Qu Wenruo wrote:
>>>>> My plan for such recovery is:
>>>>>
>>>>> 1) btrfs ins dump-super to make sure system chunk array is valid
>>>>> 2) btrfs-find-root to find any valid chunk tree blocks
>>>>> 3) pass that chunk tree bytenr to btrfs-restore
>>>>> Unfortunately, btrfs-restore doesn't support specifying chunk root
>>>>> yet. But it's pretty easy to add such support.
>>>>>
>>>>> So, please provide the "btrfs ins dump-super -Ffa" output to start with.
>>>> Following your plan, I did 1) and 2).
>>>> As 2) failed (see below), is there anything I can do to find the tree
>>>> bytenr to supply btrfs-restore with it?
>>>>
>>>> 1) Here's the output given by "btrfs-show-super -Ffa":
>>>>
>>>> superblock: bytenr=65536, device=sdcard.iso
>>>> ---------------------------------------------------------
>>>> csum 0xb8e15dd7 [match]
>> [snip]
>>>> 2) "btrfs-find-root" yields "Couldn't read chunk root; Open ctree failed".
>>> It's not plain "btrfs-find-root" but "btrfs-find-root -o 5".
>>>
>>> And you should use btrfs-progs v4.17.1, not the old v4.4.
>>> The ability to continue search even if chunk tree get corrupted is added
>>> in v4.5, and I strongly recommend to use latest (v4.17.1) for a lot of
>>> fixes and extra debug output.
>>>
>>> If you can't find any handy way to update btrfs-progs, you could use
>>> Archlinux iso as a rescue OS to use the latest btrfs-progs.
>> Using Archlinux in fact is the easiest way to use version 4.17.1
>> (Archlinux for 2018-11-01).
>>
>> Here's the output from "btrfs-find-root sdcard.iso":
>>
>> WARNING: cannot read chunk root, continue anyway
>> Superblock thinks the generation is 1757933
>> Superblock thinks the level is 0
>>
>> Here's the output using "btrfs-find-root -o 5 sdcard.iso":
>>
>> WARNING: cannot read chunk root, continue anyway
>> Superblock doesn't contain generation info for root 5
>> Superblock doesn't contain the level info for root 5
> No other output at all?
>
> That means the whole 8M range of system chunk get corrupted.
> Thus really no way to get any meaningful data out of the filesystem,
> unfortunately.
>
> Thanks,
> Qu
That's a pity. So I'm back to the hex editor.
I hope to find another angle before searching for file content.
Thank you for your efforts anyway.
Cheers,
Mirko
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-11-05 13:22 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-30 20:11 Salvage files from broken btrfs Mirko Klingmann
2018-10-31 0:03 ` Qu Wenruo
2018-11-02 14:30 ` M. Klingmann
2018-11-02 14:45 ` Qu Wenruo
2018-11-02 17:18 ` M. Klingmann
2018-11-03 1:05 ` Qu Wenruo
2018-11-05 13:22 ` M. Klingmann
2018-10-31 4:56 ` Chris Murphy
2018-11-02 14:21 ` M. Klingmann
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.