On 08/21, Chao Yu wrote: > Ping, > > On 2019/8/12 20:01, Chao Yu wrote: > > Hi Jaegeuk, > > > > In por_fsstress testcase, fsck reports below inconsistent status, I found > > one > > path can cause this case. > > > > [FIX] (fsck_chk_inode_blk:1002) --> Symlink: recover 0x1425 with > > i_size=4096 > > [ASSERT] (fsck_chk_inode_blk:1030) --> ino: 0x1425 chksum:0x6983d47, but > > calculated one is: 0xdb284b35 > > [FIX] (fsck_chk_inode_blk:1036) --> ino: 0x1425 recover, i_inode_checksum= > > 0x6983d47 -> 0xdb284b35 > > > > - f2fs_symlink > > - page_symlink failed -> f2fs_write_failed() will truncate size to zero > > - f2fs_unlink failed -> symlink inode w/o data will remain in fs > > > > Not sure, but one choice of fix is to treat symlink as fs meta like we did > > for > > directory, so that checkpoint can take care of all data/node of symlink, any > > thoughts?
Hmm, how's the possible to get very long path name requiring another data block? If it's fitted in inline_data, it's more easy to guarantee that, right? > > > > > > _______________________________________________ > > Linux-f2fs-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > > _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
