* Corrupt F2FS partition - fsck is useless
@ 2018-08-24 4:31 Luke Dashjr
2018-08-24 13:08 ` Chao Yu
2018-08-28 7:37 ` Jaegeuk Kim
0 siblings, 2 replies; 9+ messages in thread
From: Luke Dashjr @ 2018-08-24 4:31 UTC (permalink / raw)
To: linux-f2fs-devel
One of my phones recently decided to corrupt its /data partition. I managed to
copy it to my PC before wiping the phone completely, but efforts to mount or
otherwise recover data from it have proven futile.
Mounting fails with dmesg showing:
[433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
[433918.995566] F2FS-fs (loop0): Failed to read root inode
[433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
[433919.003598] F2FS-fs (loop0): Failed to read root inode
f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
(NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz )
#0 0x0000555555559911 in memcpy (__len=18446744072369571950,
__src=0x5555557d644c, __dest=0x7fffffffd2d0)
at /usr/include/bits/string_fortified.h:34
#1 convert_encrypted_name (
name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
[\227\266\221R1\332\331!
\004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006|
\333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005!
\200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b!
\361\241\213\370\336
{\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized
out>)
at fsck.c:1132
#2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
node=0x5555557d63f0, name=1) at mount.c:183
#3 0x000055555556424f in print_node_info (sbi=<optimized out>,
node_block=<optimized out>, verbose=<optimized out>)
at mount.c:277
#4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>,
nid=nid@entry=2875, force=force@entry=1)
at dump.c:520
#5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568
#6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569
#7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726
If I tell it NOT to recover lost+found, it completes, but mounting still
fails:
(NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
[434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
[434361.825628] F2FS-fs (loop0): Failed to read root inode
[434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
[434361.840620] F2FS-fs (loop0): Failed to read root inode
Any ideas on how to get at least some data recovered from this?
(Particularly the encryption key(s) Android stores at /data/misc/vold/*.key)
Thanks,
Luke
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr
@ 2018-08-24 13:08 ` Chao Yu
2018-08-24 14:38 ` Luke Dashjr
2018-08-28 7:37 ` Jaegeuk Kim
1 sibling, 1 reply; 9+ messages in thread
From: Chao Yu @ 2018-08-24 13:08 UTC (permalink / raw)
To: Luke Dashjr, linux-f2fs-devel
Hi Luke,
I think the problem here is that we don't even start to traverse and check all
directories and files due to we encounter root inode sanity check failure.
[ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
footer.ino[0x30333238]
Could you dump root node info with below command:
dump.f2fs -i 3 -d 1 <your_device_path>
Thanks,
On 2018/8/24 12:31, Luke Dashjr wrote:
> One of my phones recently decided to corrupt its /data partition. I managed to
> copy it to my PC before wiping the phone completely, but efforts to mount or
> otherwise recover data from it have proven futile.
>
> Mounting fails with dmesg showing:
>
> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433918.995566] F2FS-fs (loop0): Failed to read root inode
> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433919.003598] F2FS-fs (loop0): Failed to read root inode
>
> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>
> (NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz )
> #0 0x0000555555559911 in memcpy (__len=18446744072369571950,
> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
> at /usr/include/bits/string_fortified.h:34
> #1 convert_encrypted_name (
> name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
> [\227\266\221R1\332\331!
> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006|
> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005!
> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b!
> \361\241\213\370\336
> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized
> out>)
> at fsck.c:1132
> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
> node=0x5555557d63f0, name=1) at mount.c:183
> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
> node_block=<optimized out>, verbose=<optimized out>)
> at mount.c:277
> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>,
> nid=nid@entry=2875, force=force@entry=1)
> at dump.c:520
> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568
> #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569
> #7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726
>
> If I tell it NOT to recover lost+found, it completes, but mounting still
> fails:
>
> (NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.825628] F2FS-fs (loop0): Failed to read root inode
> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>
> Any ideas on how to get at least some data recovered from this?
> (Particularly the encryption key(s) Android stores at /data/misc/vold/*.key)
>
> Thanks,
>
> Luke
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-24 13:08 ` Chao Yu
@ 2018-08-24 14:38 ` Luke Dashjr
2018-08-24 15:59 ` Chao Yu
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2018-08-24 14:38 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-f2fs-devel
Info: Debug level = 1
Info: Segments per section = 1
Info: Sections per zone = 1
Info: sector size = 512
Info: total sectors = 12597656 (6151 MB)
Info: MKFS version
"Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc
version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016"
Info: FSCK version
from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
(Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
(Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
+--------------------------------------------------------+
| Super block |
+--------------------------------------------------------+
magic [0xf2f52010 : 4076150800]
major_ver [0x 1 : 1]
volum_name []
minor_ver [0x 2 : 2]
log_sectorsize [0x 9 : 9]
log_sectors_per_block [0x 3 : 3]
log_blocksize [0x c : 12]
log_blocks_per_seg [0x 9 : 9]
segs_per_sec [0x 1 : 1]
secs_per_zone [0x 1 : 1]
checksum_offset [0x 0 : 0]
block_count [0x 13ffe0 : 1310688]
section_count [0x 9e9 : 2537]
segment_count [0x 9fe : 2558]
segment_count_ckpt [0x 2 : 2]
segment_count_sit [0x 2 : 2]
segment_count_nat [0x c : 12]
segment_count_ssa [0x 5 : 5]
segment_count_main [0x 9e9 : 2537]
segment0_blkaddr [0x 200 : 512]
cp_blkaddr [0x 200 : 512]
sit_blkaddr [0x 600 : 1536]
nat_blkaddr [0x a00 : 2560]
ssa_blkaddr [0x 2200 : 8704]
main_blkaddr [0x 2c00 : 11264]
root_ino [0x 3 : 3]
node_ino [0x 1 : 1]
meta_ino [0x 2 : 2]
cp_payload [0x 0 : 0]
version Linux version 4.17.11-gentoo (root@ishibashi)
(gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29
04:07:16 UTC 2018
Info: total FS sectors = 10485504 (5119 MB)
Info: CKPT version = 1f339f
+--------------------------------------------------------+
| Checkpoint |
+--------------------------------------------------------+
checkpoint_ver [0x 1f339f : 2044831]
user_block_count [0x 127a00 : 1210880]
valid_block_count [0x bfc23 : 785443]
rsvd_segment_count [0x 30 : 48]
overprov_segment_count [0x ac : 172]
free_segment_count [0x 30 : 48]
alloc_type[CURSEG_HOT_NODE] [0x 0 : 0]
alloc_type[CURSEG_WARM_NODE] [0x 0 : 0]
alloc_type[CURSEG_COLD_NODE] [0x 0 : 0]
cur_node_segno[0] [0x 4bc : 1212]
cur_node_segno[1] [0x 552 : 1362]
cur_node_segno[2] [0x 912 : 2322]
cur_node_blkoff[0] [0x bc : 188]
cur_node_blkoff[1] [0x 79 : 121]
cur_node_blkoff[2] [0x 169 : 361]
alloc_type[CURSEG_HOT_DATA] [0x 0 : 0]
alloc_type[CURSEG_WARM_DATA] [0x 0 : 0]
alloc_type[CURSEG_COLD_DATA] [0x 0 : 0]
cur_data_segno[0] [0x 576 : 1398]
cur_data_segno[1] [0x 665 : 1637]
cur_data_segno[2] [0x 66e : 1646]
cur_data_blkoff[0] [0x 0 : 0]
cur_data_blkoff[1] [0x 0 : 0]
cur_data_blkoff[2] [0x 0 : 0]
ckpt_flags [0x 4 : 4]
cp_pack_total_block_count [0x 3 : 3]
cp_pack_start_sum [0x 1 : 1]
valid_node_count [0x 5e52 : 24146]
valid_inode_count [0x 5c97 : 23703]
next_free_nid [0x 35c78 : 220280]
sit_ver_bitmap_bytesize [0x 40 : 64]
nat_ver_bitmap_bytesize [0x 180 : 384]
checksum_offset [0x ffc : 4092]
elapsed_time [0x183e8f20f43 : 1666060521283]
sit_nat_version_bitmap[0] [0x 9 : 9]
[dump_node: 500] Node ID [0x3]
[dump_node: 501] nat_entry.block_addr [0x11fa0e]
[dump_node: 502] nat_entry.version [0x0]
[dump_node: 503] nat_entry.ino [0x3]
[dump_node: 510] node_blk.footer.ino [0x30333238]
[dump_node: 511] node_blk.footer.nid [0x30352c30]
[print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or
indirect node.
[0] [0x3933332c : 959656748]
[1] [0x3633322c : 909324844]
[2] [0x30303030 : 808464432]
[3] [0x3134312c : 825504044]
[4] [0x2c303639 : 741357113]
[5] [0x3636322d : 909521453]
[6] [0x2c363331 : 741749553]
[7] [0x31303432 : 825242674]
[8] [0x2c303030 : 741355568]
[9] [0x472c3532 : 1194079538]
[10] [0x2c646f6f : 744779631]
Invalid (i)node block
Info: checkpoint state = 4 : compacted_summary sudden-power-off
Done.
On Friday 24 August 2018 13:08:30 Chao Yu wrote:
> Hi Luke,
>
> I think the problem here is that we don't even start to traverse and check
> all directories and files due to we encounter root inode sanity check
> failure.
>
> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
> footer.ino[0x30333238]
>
> Could you dump root node info with below command:
>
> dump.f2fs -i 3 -d 1 <your_device_path>
>
> Thanks,
>
> On 2018/8/24 12:31, Luke Dashjr wrote:
> > One of my phones recently decided to corrupt its /data partition. I
> > managed to copy it to my PC before wiping the phone completely, but
> > efforts to mount or otherwise recover data from it have proven futile.
> >
> > Mounting fails with dmesg showing:
> >
> > [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
> > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
> >82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read
> > root inode
> > [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
> > node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
> >82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read
> > root inode
> >
> > f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
> >
> > (NOTE: fsck output at
> > https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0
> > 0x0000555555559911 in memcpy (__len=18446744072369571950,
> > __src=0x5555557d644c, __dest=0x7fffffffd2d0)
> > at /usr/include/bits/string_fortified.h:34
> > #1 convert_encrypted_name (
> > name=name@entry=0x5555557d644c
> > "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
> > [\227\266\221R1\332\331!
> > \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3
> >52\032i\222]\326Ӌ\027^\030\226\005&\006|
> > \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006
> >g\034u]\003\002)\005!
> > \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di
> >\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21
> >4\b! \361\241\213\370\336
> > {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
> > 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
> > new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035",
> > enc_name=<optimized out>)
> > at fsck.c:1132
> > #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
> > node=0x5555557d63f0, name=1) at mount.c:183
> > #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
> > node_block=<optimized out>, verbose=<optimized out>)
> > at mount.c:277
> > #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0
> > <gfsck>, nid=nid@entry=2875, force=force@entry=1)
> > at dump.c:520
> > #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at
> > fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0
> > <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized
> > out>) at main.c:726
> >
> > If I tell it NOT to recover lost+found, it completes, but mounting still
> > fails:
> >
> > (NOTE: fsck output
> > https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196]
> > F2FS-fs (loop0): Found nat_bits in checkpoint
> > [434361.825628] F2FS-fs (loop0): Failed to read root inode
> > [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
> > [434361.840620] F2FS-fs (loop0): Failed to read root inode
> >
> > Any ideas on how to get at least some data recovered from this?
> > (Particularly the encryption key(s) Android stores at
> > /data/misc/vold/*.key)
> >
> > Thanks,
> >
> > Luke
> >
> > -------------------------------------------------------------------------
> >----- Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-24 14:38 ` Luke Dashjr
@ 2018-08-24 15:59 ` Chao Yu
2018-08-28 9:28 ` Chao Yu
0 siblings, 1 reply; 9+ messages in thread
From: Chao Yu @ 2018-08-24 15:59 UTC (permalink / raw)
To: Luke Dashjr; +Cc: linux-f2fs-devel
On 2018/8/24 22:38, Luke Dashjr wrote:
> Info: Debug level = 1
> Info: Segments per section = 1
> Info: Sections per zone = 1
> Info: sector size = 512
> Info: total sectors = 12597656 (6151 MB)
> Info: MKFS version
> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc
> version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016"
> Info: FSCK version
> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
> to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
> Info: superblock features = 0 :
> Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
>
> +--------------------------------------------------------+
> | Super block |
> +--------------------------------------------------------+
> magic [0xf2f52010 : 4076150800]
> major_ver [0x 1 : 1]
> volum_name []
> minor_ver [0x 2 : 2]
> log_sectorsize [0x 9 : 9]
> log_sectors_per_block [0x 3 : 3]
> log_blocksize [0x c : 12]
> log_blocks_per_seg [0x 9 : 9]
> segs_per_sec [0x 1 : 1]
> secs_per_zone [0x 1 : 1]
> checksum_offset [0x 0 : 0]
> block_count [0x 13ffe0 : 1310688]
> section_count [0x 9e9 : 2537]
> segment_count [0x 9fe : 2558]
> segment_count_ckpt [0x 2 : 2]
> segment_count_sit [0x 2 : 2]
> segment_count_nat [0x c : 12]
> segment_count_ssa [0x 5 : 5]
> segment_count_main [0x 9e9 : 2537]
> segment0_blkaddr [0x 200 : 512]
> cp_blkaddr [0x 200 : 512]
> sit_blkaddr [0x 600 : 1536]
> nat_blkaddr [0x a00 : 2560]
> ssa_blkaddr [0x 2200 : 8704]
> main_blkaddr [0x 2c00 : 11264]
> root_ino [0x 3 : 3]
> node_ino [0x 1 : 1]
> meta_ino [0x 2 : 2]
> cp_payload [0x 0 : 0]
> version Linux version 4.17.11-gentoo (root@ishibashi)
> (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29
> 04:07:16 UTC 2018
> Info: total FS sectors = 10485504 (5119 MB)
> Info: CKPT version = 1f339f
>
> +--------------------------------------------------------+
> | Checkpoint |
> +--------------------------------------------------------+
> checkpoint_ver [0x 1f339f : 2044831]
> user_block_count [0x 127a00 : 1210880]
> valid_block_count [0x bfc23 : 785443]
> rsvd_segment_count [0x 30 : 48]
> overprov_segment_count [0x ac : 172]
> free_segment_count [0x 30 : 48]
> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0]
> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0]
> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0]
> cur_node_segno[0] [0x 4bc : 1212]
> cur_node_segno[1] [0x 552 : 1362]
> cur_node_segno[2] [0x 912 : 2322]
> cur_node_blkoff[0] [0x bc : 188]
> cur_node_blkoff[1] [0x 79 : 121]
> cur_node_blkoff[2] [0x 169 : 361]
> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0]
> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0]
> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0]
> cur_data_segno[0] [0x 576 : 1398]
> cur_data_segno[1] [0x 665 : 1637]
> cur_data_segno[2] [0x 66e : 1646]
> cur_data_blkoff[0] [0x 0 : 0]
> cur_data_blkoff[1] [0x 0 : 0]
> cur_data_blkoff[2] [0x 0 : 0]
> ckpt_flags [0x 4 : 4]
> cp_pack_total_block_count [0x 3 : 3]
> cp_pack_start_sum [0x 1 : 1]
> valid_node_count [0x 5e52 : 24146]
> valid_inode_count [0x 5c97 : 23703]
> next_free_nid [0x 35c78 : 220280]
> sit_ver_bitmap_bytesize [0x 40 : 64]
> nat_ver_bitmap_bytesize [0x 180 : 384]
> checksum_offset [0x ffc : 4092]
> elapsed_time [0x183e8f20f43 : 1666060521283]
> sit_nat_version_bitmap[0] [0x 9 : 9]
>
>
> [dump_node: 500] Node ID [0x3]
> [dump_node: 501] nat_entry.block_addr [0x11fa0e]
> [dump_node: 502] nat_entry.version [0x0]
> [dump_node: 503] nat_entry.ino [0x3]
> [dump_node: 510] node_blk.footer.ino [0x30333238]
> [dump_node: 511] node_blk.footer.nid [0x30352c30]
> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or
> indirect node.
> [0] [0x3933332c : 959656748]
> [1] [0x3633322c : 909324844]
> [2] [0x30303030 : 808464432]
> [3] [0x3134312c : 825504044]
> [4] [0x2c303639 : 741357113]
> [5] [0x3636322d : 909521453]
> [6] [0x2c363331 : 741749553]
> [7] [0x31303432 : 825242674]
> [8] [0x2c303030 : 741355568]
> [9] [0x472c3532 : 1194079538]
> [10] [0x2c646f6f : 744779631]
It looks like this block contains normal characters instead of fields of regular
inode structure, so I think root inode's block or nat_entry.blkaddr may be
corrupted.
Let me think about the way to rebuild root inode.
Thanks,
> Invalid (i)node block
>
> Info: checkpoint state = 4 : compacted_summary sudden-power-off
>
> Done.
>
>
> On Friday 24 August 2018 13:08:30 Chao Yu wrote:
>> Hi Luke,
>>
>> I think the problem here is that we don't even start to traverse and check
>> all directories and files due to we encounter root inode sanity check
>> failure.
>>
>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
>> footer.ino[0x30333238]
>>
>> Could you dump root node info with below command:
>>
>> dump.f2fs -i 3 -d 1 <your_device_path>
>>
>> Thanks,
>>
>> On 2018/8/24 12:31, Luke Dashjr wrote:
>>> One of my phones recently decided to corrupt its /data partition. I
>>> managed to copy it to my PC before wiping the phone completely, but
>>> efforts to mount or otherwise recover data from it have proven futile.
>>>
>>> Mounting fails with dmesg showing:
>>>
>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
>>> 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read
>>> root inode
>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
>>> 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read
>>> root inode
>>>
>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>>>
>>> (NOTE: fsck output at
>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0
>>> 0x0000555555559911 in memcpy (__len=18446744072369571950,
>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
>>> at /usr/include/bits/string_fortified.h:34
>>> #1 convert_encrypted_name (
>>> name=name@entry=0x5555557d644c
>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
>>> [\227\266\221R1\332\331!
>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3
>>> 52\032i\222]\326Ӌ\027^\030\226\005&\006|
>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006
>>> g\034u]\003\002)\005!
>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di
>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21
>>> 4\b! \361\241\213\370\336
>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035",
>>> enc_name=<optimized out>)
>>> at fsck.c:1132
>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
>>> node=0x5555557d63f0, name=1) at mount.c:183
>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
>>> node_block=<optimized out>, verbose=<optimized out>)
>>> at mount.c:277
>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0
>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1)
>>> at dump.c:520
>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at
>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0
>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized
>>> out>) at main.c:726
>>>
>>> If I tell it NOT to recover lost+found, it completes, but mounting still
>>> fails:
>>>
>>> (NOTE: fsck output
>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196]
>>> F2FS-fs (loop0): Found nat_bits in checkpoint
>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode
>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>>>
>>> Any ideas on how to get at least some data recovered from this?
>>> (Particularly the encryption key(s) Android stores at
>>> /data/misc/vold/*.key)
>>>
>>> Thanks,
>>>
>>> Luke
>>>
>>> -------------------------------------------------------------------------
>>> ----- Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr
2018-08-24 13:08 ` Chao Yu
@ 2018-08-28 7:37 ` Jaegeuk Kim
2018-08-28 7:49 ` Luke Dashjr
1 sibling, 1 reply; 9+ messages in thread
From: Jaegeuk Kim @ 2018-08-28 7:37 UTC (permalink / raw)
To: Luke Dashjr; +Cc: linux-f2fs-devel
On 08/24, Luke Dashjr wrote:
> One of my phones recently decided to corrupt its /data partition. I managed to
> copy it to my PC before wiping the phone completely, but efforts to mount or
> otherwise recover data from it have proven futile.
>
> Mounting fails with dmesg showing:
>
> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433918.995566] F2FS-fs (loop0): Failed to read root inode
> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433919.003598] F2FS-fs (loop0): Failed to read root inode
>
> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>
> (NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz )
> #0 0x0000555555559911 in memcpy (__len=18446744072369571950,
> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
> at /usr/include/bits/string_fortified.h:34
> #1 convert_encrypted_name (
> name=name@entry=0x5555557d644c "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
> [\227\266\221R1\332\331!
> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006|
> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005!
> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b!
> \361\241\213\370\336
> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035", enc_name=<optimized
> out>)
> at fsck.c:1132
> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
> node=0x5555557d63f0, name=1) at mount.c:183
> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
> node_block=<optimized out>, verbose=<optimized out>)
> at mount.c:277
> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0 <gfsck>,
> nid=nid@entry=2875, force=force@entry=1)
> at dump.c:520
> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at fsck.c:2568
> #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0 <gfsck>) at main.c:569
> #7 main (argc=<optimized out>, argv=<optimized out>) at main.c:726
>
> If I tell it NOT to recover lost+found, it completes, but mounting still
> fails:
>
> (NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.825628] F2FS-fs (loop0): Failed to read root inode
> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>
> Any ideas on how to get at least some data recovered from this?
> (Particularly the encryption key(s) Android stores at /data/misc/vold/*.key)
Are you using dm-crypt under f2fs? Did you decrypt the raw image?
v3.10 is too much old, and I quit to backport recent patches as well.
Is there a chance to upgrade the kernel?
>
> Thanks,
>
> Luke
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-28 7:37 ` Jaegeuk Kim
@ 2018-08-28 7:49 ` Luke Dashjr
0 siblings, 0 replies; 9+ messages in thread
From: Luke Dashjr @ 2018-08-28 7:49 UTC (permalink / raw)
To: Jaegeuk Kim; +Cc: linux-f2fs-devel
On Tuesday 28 August 2018 07:37:35 Jaegeuk Kim wrote:
> Are you using dm-crypt under f2fs?
No.
> v3.10 is too much old, and I quit to backport recent patches as well.
> Is there a chance to upgrade the kernel?
The 3.10 was the Android/LineageOS phone that couldn't even boot.
I'm doing all the data recovery attempts on 4.17.11.
Thanks,
Luke
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-24 15:59 ` Chao Yu
@ 2018-08-28 9:28 ` Chao Yu
2018-08-28 9:47 ` Luke Dashjr
0 siblings, 1 reply; 9+ messages in thread
From: Chao Yu @ 2018-08-28 9:28 UTC (permalink / raw)
To: Chao Yu, Luke Dashjr; +Cc: linux-f2fs-devel
Hi Luke,
Do you have tried Sheng Yong's patch?
BTW, before recovering root inode, it needs to backup your entire image.
On 2018/8/24 23:59, Chao Yu wrote:
> On 2018/8/24 22:38, Luke Dashjr wrote:
>> Info: Debug level = 1
>> Info: Segments per section = 1
>> Info: Sections per zone = 1
>> Info: sector size = 512
>> Info: total sectors = 12597656 (6151 MB)
>> Info: MKFS version
>> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc
>> version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016"
>> Info: FSCK version
>> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
>> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
>> to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
>> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018"
>> Info: superblock features = 0 :
>> Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
>>
>> +--------------------------------------------------------+
>> | Super block |
>> +--------------------------------------------------------+
>> magic [0xf2f52010 : 4076150800]
>> major_ver [0x 1 : 1]
>> volum_name []
>> minor_ver [0x 2 : 2]
>> log_sectorsize [0x 9 : 9]
>> log_sectors_per_block [0x 3 : 3]
>> log_blocksize [0x c : 12]
>> log_blocks_per_seg [0x 9 : 9]
>> segs_per_sec [0x 1 : 1]
>> secs_per_zone [0x 1 : 1]
>> checksum_offset [0x 0 : 0]
>> block_count [0x 13ffe0 : 1310688]
>> section_count [0x 9e9 : 2537]
>> segment_count [0x 9fe : 2558]
>> segment_count_ckpt [0x 2 : 2]
>> segment_count_sit [0x 2 : 2]
>> segment_count_nat [0x c : 12]
>> segment_count_ssa [0x 5 : 5]
>> segment_count_main [0x 9e9 : 2537]
>> segment0_blkaddr [0x 200 : 512]
>> cp_blkaddr [0x 200 : 512]
>> sit_blkaddr [0x 600 : 1536]
>> nat_blkaddr [0x a00 : 2560]
>> ssa_blkaddr [0x 2200 : 8704]
>> main_blkaddr [0x 2c00 : 11264]
>> root_ino [0x 3 : 3]
>> node_ino [0x 1 : 1]
>> meta_ino [0x 2 : 2]
>> cp_payload [0x 0 : 0]
>> version Linux version 4.17.11-gentoo (root@ishibashi)
>> (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29
>> 04:07:16 UTC 2018
>> Info: total FS sectors = 10485504 (5119 MB)
>> Info: CKPT version = 1f339f
>>
>> +--------------------------------------------------------+
>> | Checkpoint |
>> +--------------------------------------------------------+
>> checkpoint_ver [0x 1f339f : 2044831]
>> user_block_count [0x 127a00 : 1210880]
>> valid_block_count [0x bfc23 : 785443]
>> rsvd_segment_count [0x 30 : 48]
>> overprov_segment_count [0x ac : 172]
>> free_segment_count [0x 30 : 48]
>> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0]
>> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0]
>> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0]
>> cur_node_segno[0] [0x 4bc : 1212]
>> cur_node_segno[1] [0x 552 : 1362]
>> cur_node_segno[2] [0x 912 : 2322]
>> cur_node_blkoff[0] [0x bc : 188]
>> cur_node_blkoff[1] [0x 79 : 121]
>> cur_node_blkoff[2] [0x 169 : 361]
>> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0]
>> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0]
>> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0]
>> cur_data_segno[0] [0x 576 : 1398]
>> cur_data_segno[1] [0x 665 : 1637]
>> cur_data_segno[2] [0x 66e : 1646]
>> cur_data_blkoff[0] [0x 0 : 0]
>> cur_data_blkoff[1] [0x 0 : 0]
>> cur_data_blkoff[2] [0x 0 : 0]
>> ckpt_flags [0x 4 : 4]
>> cp_pack_total_block_count [0x 3 : 3]
>> cp_pack_start_sum [0x 1 : 1]
>> valid_node_count [0x 5e52 : 24146]
>> valid_inode_count [0x 5c97 : 23703]
>> next_free_nid [0x 35c78 : 220280]
>> sit_ver_bitmap_bytesize [0x 40 : 64]
>> nat_ver_bitmap_bytesize [0x 180 : 384]
>> checksum_offset [0x ffc : 4092]
>> elapsed_time [0x183e8f20f43 : 1666060521283]
>> sit_nat_version_bitmap[0] [0x 9 : 9]
>>
>>
>> [dump_node: 500] Node ID [0x3]
>> [dump_node: 501] nat_entry.block_addr [0x11fa0e]
>> [dump_node: 502] nat_entry.version [0x0]
>> [dump_node: 503] nat_entry.ino [0x3]
>> [dump_node: 510] node_blk.footer.ino [0x30333238]
>> [dump_node: 511] node_blk.footer.nid [0x30352c30]
>> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or
>> indirect node.
>> [0] [0x3933332c : 959656748]
>> [1] [0x3633322c : 909324844]
>> [2] [0x30303030 : 808464432]
>> [3] [0x3134312c : 825504044]
>> [4] [0x2c303639 : 741357113]
>> [5] [0x3636322d : 909521453]
>> [6] [0x2c363331 : 741749553]
>> [7] [0x31303432 : 825242674]
>> [8] [0x2c303030 : 741355568]
>> [9] [0x472c3532 : 1194079538]
>> [10] [0x2c646f6f : 744779631]
>
> It looks like this block contains normal characters instead of fields of regular
> inode structure, so I think root inode's block or nat_entry.blkaddr may be
> corrupted.
>
> Let me think about the way to rebuild root inode.
>
> Thanks,
>
>> Invalid (i)node block
>>
>> Info: checkpoint state = 4 : compacted_summary sudden-power-off
>>
>> Done.
>>
>>
>> On Friday 24 August 2018 13:08:30 Chao Yu wrote:
>>> Hi Luke,
>>>
>>> I think the problem here is that we don't even start to traverse and check
>>> all directories and files due to we encounter root inode sanity check
>>> failure.
>>>
>>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
>>> footer.ino[0x30333238]
>>>
>>> Could you dump root node info with below command:
>>>
>>> dump.f2fs -i 3 -d 1 <your_device_path>
>>>
>>> Thanks,
>>>
>>> On 2018/8/24 12:31, Luke Dashjr wrote:
>>>> One of my phones recently decided to corrupt its /data partition. I
>>>> managed to copy it to my PC before wiping the phone completely, but
>>>> efforts to mount or otherwise recover data from it have proven futile.
>>>>
>>>> Mounting fails with dmesg showing:
>>>>
>>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
>>>> 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to read
>>>> root inode
>>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016424
>>>> 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to read
>>>> root inode
>>>>
>>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>>>>
>>>> (NOTE: fsck output at
>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0
>>>> 0x0000555555559911 in memcpy (__len=18446744072369571950,
>>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
>>>> at /usr/include/bits/string_fortified.h:34
>>>> #1 convert_encrypted_name (
>>>> name=name@entry=0x5555557d644c
>>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
>>>> [\227\266\221R1\332\331!
>>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\3
>>>> 52\032i\222]\326Ӌ\027^\030\226\005&\006|
>>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006
>>>> g\034u]\003\002)\005!
>>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di
>>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\21
>>>> 4\b! \361\241\213\370\336
>>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
>>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
>>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035",
>>>> enc_name=<optimized out>)
>>>> at fsck.c:1132
>>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0 <gfsck>,
>>>> node=0x5555557d63f0, name=1) at mount.c:183
>>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
>>>> node_block=<optimized out>, verbose=<optimized out>)
>>>> at mount.c:277
>>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0
>>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1)
>>>> at dump.c:520
>>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at
>>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0
>>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized
>>>> out>) at main.c:726
>>>>
>>>> If I tell it NOT to recover lost+found, it completes, but mounting still
>>>> fails:
>>>>
>>>> (NOTE: fsck output
>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz ) [434361.813196]
>>>> F2FS-fs (loop0): Found nat_bits in checkpoint
>>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode
>>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
>>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>>>>
>>>> Any ideas on how to get at least some data recovered from this?
>>>> (Particularly the encryption key(s) Android stores at
>>>> /data/misc/vold/*.key)
>>>>
>>>> Thanks,
>>>>
>>>> Luke
>>>>
>>>> -------------------------------------------------------------------------
>>>> ----- Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Linux-f2fs-devel mailing list
>>>> Linux-f2fs-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-28 9:28 ` Chao Yu
@ 2018-08-28 9:47 ` Luke Dashjr
2018-08-28 10:34 ` Chao Yu
0 siblings, 1 reply; 9+ messages in thread
From: Luke Dashjr @ 2018-08-28 9:47 UTC (permalink / raw)
To: Chao Yu; +Cc: linux-f2fs-devel
Yes, I did my best to rebase it:
https://paste.pound-python.org/show/nWshXUd5QSLbj5ZCugPy/
Unfortunately, it aborts:
[ASSERT] (sanity_check_nid: 391) --> nid[0x3] ino is 0
#0 sanity_check_nid (sbi=sbi@entry=0x555555782800 <gfsck>, nid=nid@entry=3,
node_blk=node_blk@entry=0x5555557d6fe0,
ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE,
ni=ni@entry=0x7fffffffd660) at fsck.c:392
#1 0x000055555555d853 in fsck_chk_fs (sbi=<optimized out>,
blk_cnt=0x7fffffffd6ec) at fsck.c:997
#2 0x000055555555675c in do_fsck (sbi=0x555555782800 <gfsck>) at main.c:565
#3 main (argc=<optimized out>, argv=<optimized out>) at main.c:725
Luke
On Tuesday 28 August 2018 09:28:57 Chao Yu wrote:
> Hi Luke,
>
> Do you have tried Sheng Yong's patch?
>
> BTW, before recovering root inode, it needs to backup your entire image.
>
> On 2018/8/24 23:59, Chao Yu wrote:
> > On 2018/8/24 22:38, Luke Dashjr wrote:
> >> Info: Debug level = 1
> >> Info: Segments per section = 1
> >> Info: Sections per zone = 1
> >> Info: sector size = 512
> >> Info: total sectors = 12597656 (6151 MB)
> >> Info: MKFS version
> >> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30)
> >> (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016"
> >> Info: FSCK version
> >> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
> >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC
> >> 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version
> >> 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16
> >> UTC 2018" Info: superblock features = 0 :
> >> Info: superblock encrypt level = 0, salt =
> >> 00000000000000000000000000000000
> >>
> >> +--------------------------------------------------------+
> >>
> >> | Super block |
> >>
> >> +--------------------------------------------------------+
> >> magic [0xf2f52010 : 4076150800]
> >> major_ver [0x 1 : 1]
> >> volum_name []
> >> minor_ver [0x 2 : 2]
> >> log_sectorsize [0x 9 : 9]
> >> log_sectors_per_block [0x 3 : 3]
> >> log_blocksize [0x c : 12]
> >> log_blocks_per_seg [0x 9 : 9]
> >> segs_per_sec [0x 1 : 1]
> >> secs_per_zone [0x 1 : 1]
> >> checksum_offset [0x 0 : 0]
> >> block_count [0x 13ffe0 : 1310688]
> >> section_count [0x 9e9 : 2537]
> >> segment_count [0x 9fe : 2558]
> >> segment_count_ckpt [0x 2 : 2]
> >> segment_count_sit [0x 2 : 2]
> >> segment_count_nat [0x c : 12]
> >> segment_count_ssa [0x 5 : 5]
> >> segment_count_main [0x 9e9 : 2537]
> >> segment0_blkaddr [0x 200 : 512]
> >> cp_blkaddr [0x 200 : 512]
> >> sit_blkaddr [0x 600 : 1536]
> >> nat_blkaddr [0x a00 : 2560]
> >> ssa_blkaddr [0x 2200 : 8704]
> >> main_blkaddr [0x 2c00 : 11264]
> >> root_ino [0x 3 : 3]
> >> node_ino [0x 1 : 1]
> >> meta_ino [0x 2 : 2]
> >> cp_payload [0x 0 : 0]
> >> version Linux version 4.17.11-gentoo
> >> (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP
> >> PREEMPT Sun Jul 29 04:07:16 UTC 2018
> >> Info: total FS sectors = 10485504 (5119 MB)
> >> Info: CKPT version = 1f339f
> >>
> >> +--------------------------------------------------------+
> >>
> >> | Checkpoint |
> >>
> >> +--------------------------------------------------------+
> >> checkpoint_ver [0x 1f339f : 2044831]
> >> user_block_count [0x 127a00 : 1210880]
> >> valid_block_count [0x bfc23 : 785443]
> >> rsvd_segment_count [0x 30 : 48]
> >> overprov_segment_count [0x ac : 172]
> >> free_segment_count [0x 30 : 48]
> >> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0]
> >> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0]
> >> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0]
> >> cur_node_segno[0] [0x 4bc : 1212]
> >> cur_node_segno[1] [0x 552 : 1362]
> >> cur_node_segno[2] [0x 912 : 2322]
> >> cur_node_blkoff[0] [0x bc : 188]
> >> cur_node_blkoff[1] [0x 79 : 121]
> >> cur_node_blkoff[2] [0x 169 : 361]
> >> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0]
> >> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0]
> >> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0]
> >> cur_data_segno[0] [0x 576 : 1398]
> >> cur_data_segno[1] [0x 665 : 1637]
> >> cur_data_segno[2] [0x 66e : 1646]
> >> cur_data_blkoff[0] [0x 0 : 0]
> >> cur_data_blkoff[1] [0x 0 : 0]
> >> cur_data_blkoff[2] [0x 0 : 0]
> >> ckpt_flags [0x 4 : 4]
> >> cp_pack_total_block_count [0x 3 : 3]
> >> cp_pack_start_sum [0x 1 : 1]
> >> valid_node_count [0x 5e52 : 24146]
> >> valid_inode_count [0x 5c97 : 23703]
> >> next_free_nid [0x 35c78 : 220280]
> >> sit_ver_bitmap_bytesize [0x 40 : 64]
> >> nat_ver_bitmap_bytesize [0x 180 : 384]
> >> checksum_offset [0x ffc : 4092]
> >> elapsed_time [0x183e8f20f43 : 1666060521283]
> >> sit_nat_version_bitmap[0] [0x 9 : 9]
> >>
> >>
> >> [dump_node: 500] Node ID [0x3]
> >> [dump_node: 501] nat_entry.block_addr [0x11fa0e]
> >> [dump_node: 502] nat_entry.version [0x0]
> >> [dump_node: 503] nat_entry.ino [0x3]
> >> [dump_node: 510] node_blk.footer.ino [0x30333238]
> >> [dump_node: 511] node_blk.footer.nid [0x30352c30]
> >> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or
> >> indirect node.
> >> [0] [0x3933332c : 959656748]
> >> [1] [0x3633322c : 909324844]
> >> [2] [0x30303030 : 808464432]
> >> [3] [0x3134312c : 825504044]
> >> [4] [0x2c303639 : 741357113]
> >> [5] [0x3636322d : 909521453]
> >> [6] [0x2c363331 : 741749553]
> >> [7] [0x31303432 : 825242674]
> >> [8] [0x2c303030 : 741355568]
> >> [9] [0x472c3532 : 1194079538]
> >> [10] [0x2c646f6f : 744779631]
> >
> > It looks like this block contains normal characters instead of fields of
> > regular inode structure, so I think root inode's block or
> > nat_entry.blkaddr may be corrupted.
> >
> > Let me think about the way to rebuild root inode.
> >
> > Thanks,
> >
> >> Invalid (i)node block
> >>
> >> Info: checkpoint state = 4 : compacted_summary sudden-power-off
> >>
> >> Done.
> >>
> >> On Friday 24 August 2018 13:08:30 Chao Yu wrote:
> >>> Hi Luke,
> >>>
> >>> I think the problem here is that we don't even start to traverse and
> >>> check all directories and files due to we encounter root inode sanity
> >>> check failure.
> >>>
> >>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
> >>> footer.ino[0x30333238]
> >>>
> >>> Could you dump root node info with below command:
> >>>
> >>> dump.f2fs -i 3 -d 1 <your_device_path>
> >>>
> >>> Thanks,
> >>>
> >>> On 2018/8/24 12:31, Luke Dashjr wrote:
> >>>> One of my phones recently decided to corrupt its /data partition. I
> >>>> managed to copy it to my PC before wiping the phone completely, but
> >>>> efforts to mount or otherwise recover data from it have proven futile.
> >>>>
> >>>> Mounting fails with dmesg showing:
> >>>>
> >>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
> >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016
> >>>>424 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to
> >>>> read root inode
> >>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
> >>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016
> >>>>424 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to
> >>>> read root inode
> >>>>
> >>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
> >>>>
> >>>> (NOTE: fsck output at
> >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0
> >>>> 0x0000555555559911 in memcpy (__len=18446744072369571950,
> >>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
> >>>> at /usr/include/bits/string_fortified.h:34
> >>>> #1 convert_encrypted_name (
> >>>> name=name@entry=0x5555557d644c
> >>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
> >>>> [\227\266\221R1\332\331!
> >>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\35
> >>>>2\3 52\032i\222]\326Ӌ\027^\030\226\005&\006|
> >>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\
> >>>>006 g\034u]\003\002)\005!
> >>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264
> >>>>-di
> >>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\20
> >>>>2\21 4\b! \361\241\213\370\336
> >>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
> >>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
> >>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035",
> >>>> enc_name=<optimized out>)
> >>>> at fsck.c:1132
> >>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0
> >>>> <gfsck>, node=0x5555557d63f0, name=1) at mount.c:183
> >>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
> >>>> node_block=<optimized out>, verbose=<optimized out>)
> >>>> at mount.c:277
> >>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0
> >>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1)
> >>>> at dump.c:520
> >>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at
> >>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0
> >>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized
> >>>> out>) at main.c:726
> >>>>
> >>>> If I tell it NOT to recover lost+found, it completes, but mounting
> >>>> still fails:
> >>>>
> >>>> (NOTE: fsck output
> >>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
> >>>> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
> >>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode
> >>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
> >>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode
> >>>>
> >>>> Any ideas on how to get at least some data recovered from this?
> >>>> (Particularly the encryption key(s) Android stores at
> >>>> /data/misc/vold/*.key)
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Luke
> >>>>
> >>>> ----------------------------------------------------------------------
> >>>>--- ----- Check out the vibrant tech community on one of the world's
> >>>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>>> _______________________________________________
> >>>> Linux-f2fs-devel mailing list
> >>>> Linux-f2fs-devel@lists.sourceforge.net
> >>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >>
> >> ------------------------------------------------------------------------
> >>------ Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> _______________________________________________
> >> Linux-f2fs-devel mailing list
> >> Linux-f2fs-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >
> > -------------------------------------------------------------------------
> >----- Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Corrupt F2FS partition - fsck is useless
2018-08-28 9:47 ` Luke Dashjr
@ 2018-08-28 10:34 ` Chao Yu
0 siblings, 0 replies; 9+ messages in thread
From: Chao Yu @ 2018-08-28 10:34 UTC (permalink / raw)
To: shengyong (A); +Cc: Luke Dashjr, linux-f2fs-devel
Hi Sheng,
Could you have a look at this? We need to skip calling sanity_check_nid again in
fsck_chk_fs?
On 2018/8/28 17:47, Luke Dashjr wrote:
> Yes, I did my best to rebase it:
>
> https://paste.pound-python.org/show/nWshXUd5QSLbj5ZCugPy/
>
> Unfortunately, it aborts:
>
> [ASSERT] (sanity_check_nid: 391) --> nid[0x3] ino is 0
>
> #0 sanity_check_nid (sbi=sbi@entry=0x555555782800 <gfsck>, nid=nid@entry=3,
> node_blk=node_blk@entry=0x5555557d6fe0,
> ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE,
> ni=ni@entry=0x7fffffffd660) at fsck.c:392
> #1 0x000055555555d853 in fsck_chk_fs (sbi=<optimized out>,
> blk_cnt=0x7fffffffd6ec) at fsck.c:997
> #2 0x000055555555675c in do_fsck (sbi=0x555555782800 <gfsck>) at main.c:565
> #3 main (argc=<optimized out>, argv=<optimized out>) at main.c:725
>
> Luke
>
>
> On Tuesday 28 August 2018 09:28:57 Chao Yu wrote:
>> Hi Luke,
>>
>> Do you have tried Sheng Yong's patch?
>>
>> BTW, before recovering root inode, it needs to backup your entire image.
>>
>> On 2018/8/24 23:59, Chao Yu wrote:
>>> On 2018/8/24 22:38, Luke Dashjr wrote:
>>>> Info: Debug level = 1
>>>> Info: Segments per section = 1
>>>> Info: Sections per zone = 1
>>>> Info: sector size = 512
>>>> Info: total sectors = 12597656 (6151 MB)
>>>> Info: MKFS version
>>>> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30)
>>>> (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016"
>>>> Info: FSCK version
>>>> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0
>>>> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC
>>>> 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version
>>>> 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16
>>>> UTC 2018" Info: superblock features = 0 :
>>>> Info: superblock encrypt level = 0, salt =
>>>> 00000000000000000000000000000000
>>>>
>>>> +--------------------------------------------------------+
>>>>
>>>> | Super block |
>>>>
>>>> +--------------------------------------------------------+
>>>> magic [0xf2f52010 : 4076150800]
>>>> major_ver [0x 1 : 1]
>>>> volum_name []
>>>> minor_ver [0x 2 : 2]
>>>> log_sectorsize [0x 9 : 9]
>>>> log_sectors_per_block [0x 3 : 3]
>>>> log_blocksize [0x c : 12]
>>>> log_blocks_per_seg [0x 9 : 9]
>>>> segs_per_sec [0x 1 : 1]
>>>> secs_per_zone [0x 1 : 1]
>>>> checksum_offset [0x 0 : 0]
>>>> block_count [0x 13ffe0 : 1310688]
>>>> section_count [0x 9e9 : 2537]
>>>> segment_count [0x 9fe : 2558]
>>>> segment_count_ckpt [0x 2 : 2]
>>>> segment_count_sit [0x 2 : 2]
>>>> segment_count_nat [0x c : 12]
>>>> segment_count_ssa [0x 5 : 5]
>>>> segment_count_main [0x 9e9 : 2537]
>>>> segment0_blkaddr [0x 200 : 512]
>>>> cp_blkaddr [0x 200 : 512]
>>>> sit_blkaddr [0x 600 : 1536]
>>>> nat_blkaddr [0x a00 : 2560]
>>>> ssa_blkaddr [0x 2200 : 8704]
>>>> main_blkaddr [0x 2c00 : 11264]
>>>> root_ino [0x 3 : 3]
>>>> node_ino [0x 1 : 1]
>>>> meta_ino [0x 2 : 2]
>>>> cp_payload [0x 0 : 0]
>>>> version Linux version 4.17.11-gentoo
>>>> (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP
>>>> PREEMPT Sun Jul 29 04:07:16 UTC 2018
>>>> Info: total FS sectors = 10485504 (5119 MB)
>>>> Info: CKPT version = 1f339f
>>>>
>>>> +--------------------------------------------------------+
>>>>
>>>> | Checkpoint |
>>>>
>>>> +--------------------------------------------------------+
>>>> checkpoint_ver [0x 1f339f : 2044831]
>>>> user_block_count [0x 127a00 : 1210880]
>>>> valid_block_count [0x bfc23 : 785443]
>>>> rsvd_segment_count [0x 30 : 48]
>>>> overprov_segment_count [0x ac : 172]
>>>> free_segment_count [0x 30 : 48]
>>>> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0]
>>>> alloc_type[CURSEG_WARM_NODE] [0x 0 : 0]
>>>> alloc_type[CURSEG_COLD_NODE] [0x 0 : 0]
>>>> cur_node_segno[0] [0x 4bc : 1212]
>>>> cur_node_segno[1] [0x 552 : 1362]
>>>> cur_node_segno[2] [0x 912 : 2322]
>>>> cur_node_blkoff[0] [0x bc : 188]
>>>> cur_node_blkoff[1] [0x 79 : 121]
>>>> cur_node_blkoff[2] [0x 169 : 361]
>>>> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0]
>>>> alloc_type[CURSEG_WARM_DATA] [0x 0 : 0]
>>>> alloc_type[CURSEG_COLD_DATA] [0x 0 : 0]
>>>> cur_data_segno[0] [0x 576 : 1398]
>>>> cur_data_segno[1] [0x 665 : 1637]
>>>> cur_data_segno[2] [0x 66e : 1646]
>>>> cur_data_blkoff[0] [0x 0 : 0]
>>>> cur_data_blkoff[1] [0x 0 : 0]
>>>> cur_data_blkoff[2] [0x 0 : 0]
>>>> ckpt_flags [0x 4 : 4]
>>>> cp_pack_total_block_count [0x 3 : 3]
>>>> cp_pack_start_sum [0x 1 : 1]
>>>> valid_node_count [0x 5e52 : 24146]
>>>> valid_inode_count [0x 5c97 : 23703]
>>>> next_free_nid [0x 35c78 : 220280]
>>>> sit_ver_bitmap_bytesize [0x 40 : 64]
>>>> nat_ver_bitmap_bytesize [0x 180 : 384]
>>>> checksum_offset [0x ffc : 4092]
>>>> elapsed_time [0x183e8f20f43 : 1666060521283]
>>>> sit_nat_version_bitmap[0] [0x 9 : 9]
>>>>
>>>>
>>>> [dump_node: 500] Node ID [0x3]
>>>> [dump_node: 501] nat_entry.block_addr [0x11fa0e]
>>>> [dump_node: 502] nat_entry.version [0x0]
>>>> [dump_node: 503] nat_entry.ino [0x3]
>>>> [dump_node: 510] node_blk.footer.ino [0x30333238]
>>>> [dump_node: 511] node_blk.footer.nid [0x30352c30]
>>>> [print_node_info: 283] Node ID [0x30352c30:808791088] is direct node or
>>>> indirect node.
>>>> [0] [0x3933332c : 959656748]
>>>> [1] [0x3633322c : 909324844]
>>>> [2] [0x30303030 : 808464432]
>>>> [3] [0x3134312c : 825504044]
>>>> [4] [0x2c303639 : 741357113]
>>>> [5] [0x3636322d : 909521453]
>>>> [6] [0x2c363331 : 741749553]
>>>> [7] [0x31303432 : 825242674]
>>>> [8] [0x2c303030 : 741355568]
>>>> [9] [0x472c3532 : 1194079538]
>>>> [10] [0x2c646f6f : 744779631]
>>>
>>> It looks like this block contains normal characters instead of fields of
>>> regular inode structure, so I think root inode's block or
>>> nat_entry.blkaddr may be corrupted.
>>>
>>> Let me think about the way to rebuild root inode.
>>>
>>> Thanks,
>>>
>>>> Invalid (i)node block
>>>>
>>>> Info: checkpoint state = 4 : compacted_summary sudden-power-off
>>>>
>>>> Done.
>>>>
>>>> On Friday 24 August 2018 13:08:30 Chao Yu wrote:
>>>>> Hi Luke,
>>>>>
>>>>> I think the problem here is that we don't even start to traverse and
>>>>> check all directories and files due to we encounter root inode sanity
>>>>> check failure.
>>>>>
>>>>> [ASSERT] (sanity_check_nid: 412) --> nid[0x3] footer.nid[0x30352c30]
>>>>> footer.ino[0x30333238]
>>>>>
>>>>> Could you dump root node info with below command:
>>>>>
>>>>> dump.f2fs -i 3 -d 1 <your_device_path>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> On 2018/8/24 12:31, Luke Dashjr wrote:
>>>>>> One of my phones recently decided to corrupt its /data partition. I
>>>>>> managed to copy it to my PC before wiping the phone completely, but
>>>>>> efforts to mount or otherwise recover data from it have proven futile.
>>>>>>
>>>>>> Mounting fails with dmesg showing:
>>>>>>
>>>>>> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
>>>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016
>>>>>> 424 82739,blkaddr:757872690] [433918.995566] F2FS-fs (loop0): Failed to
>>>>>> read root inode
>>>>>> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
>>>>>> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:40504801016
>>>>>> 424 82739,blkaddr:757872690] [433919.003598] F2FS-fs (loop0): Failed to
>>>>>> read root inode
>>>>>>
>>>>>> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>>>>>>
>>>>>> (NOTE: fsck output at
>>>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz ) #0
>>>>>> 0x0000555555559911 in memcpy (__len=18446744072369571950,
>>>>>> __src=0x5555557d644c, __dest=0x7fffffffd2d0)
>>>>>> at /usr/include/bits/string_fortified.h:34
>>>>>> #1 convert_encrypted_name (
>>>>>> name=name@entry=0x5555557d644c
>>>>>> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
>>>>>> [\227\266\221R1\332\331!
>>>>>> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\35
>>>>>> 2\3 52\032i\222]\326Ӌ\027^\030\226\005&\006|
>>>>>> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\
>>>>>> 006 g\034u]\003\002)\005!
>>>>>> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264
>>>>>> -di
>>>>>> \316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\20
>>>>>> 2\21 4\b! \361\241\213\370\336
>>>>>> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
>>>>>> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
>>>>>> new=new@entry=0x7fffffffd2d0 "3\036\021\004\035=]\035",
>>>>>> enc_name=<optimized out>)
>>>>>> at fsck.c:1132
>>>>>> #2 0x00005555555639d9 in print_inode_info (sbi=0x5555557817e0
>>>>>> <gfsck>, node=0x5555557d63f0, name=1) at mount.c:183
>>>>>> #3 0x000055555556424f in print_node_info (sbi=<optimized out>,
>>>>>> node_block=<optimized out>, verbose=<optimized out>)
>>>>>> at mount.c:277
>>>>>> #4 0x00005555555620c2 in dump_node (sbi=sbi@entry=0x5555557817e0
>>>>>> <gfsck>, nid=nid@entry=2875, force=force@entry=1)
>>>>>> at dump.c:520
>>>>>> #5 0x000055555555f58f in fsck_verify (sbi=<optimized out>) at
>>>>>> fsck.c:2568 #6 0x000055555555679b in do_fsck (sbi=0x5555557817e0
>>>>>> <gfsck>) at main.c:569 #7 main (argc=<optimized out>, argv=<optimized
>>>>>> out>) at main.c:726
>>>>>>
>>>>>> If I tell it NOT to recover lost+found, it completes, but mounting
>>>>>> still fails:
>>>>>>
>>>>>> (NOTE: fsck output
>>>>>> https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
>>>>>> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
>>>>>> [434361.825628] F2FS-fs (loop0): Failed to read root inode
>>>>>> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
>>>>>> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>>>>>>
>>>>>> Any ideas on how to get at least some data recovered from this?
>>>>>> (Particularly the encryption key(s) Android stores at
>>>>>> /data/misc/vold/*.key)
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Luke
>>>>>>
>>>>>> ----------------------------------------------------------------------
>>>>>> --- ----- Check out the vibrant tech community on one of the world's
>>>>>> most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Linux-f2fs-devel mailing list
>>>>>> Linux-f2fs-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>>
>>>> ------------------------------------------------------------------------
>>>> ------ Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Linux-f2fs-devel mailing list
>>>> Linux-f2fs-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>
>>> -------------------------------------------------------------------------
>>> ----- Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
>
> .
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2018-08-28 10:34 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-08-24 4:31 Corrupt F2FS partition - fsck is useless Luke Dashjr
2018-08-24 13:08 ` Chao Yu
2018-08-24 14:38 ` Luke Dashjr
2018-08-24 15:59 ` Chao Yu
2018-08-28 9:28 ` Chao Yu
2018-08-28 9:47 ` Luke Dashjr
2018-08-28 10:34 ` Chao Yu
2018-08-28 7:37 ` Jaegeuk Kim
2018-08-28 7:49 ` Luke Dashjr
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).