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
