* [f2fs-dev] f2fs_symlink bug @ 2019-08-12 12:01 Chao Yu 2019-08-21 8:36 ` Chao Yu 0 siblings, 1 reply; 6+ messages in thread From: Chao Yu @ 2019-08-12 12:01 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel 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? _______________________________________________ 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] 6+ messages in thread
* Re: [f2fs-dev] f2fs_symlink bug 2019-08-12 12:01 [f2fs-dev] f2fs_symlink bug Chao Yu @ 2019-08-21 8:36 ` Chao Yu 2019-08-22 19:49 ` Jaegeuk Kim 0 siblings, 1 reply; 6+ messages in thread From: Chao Yu @ 2019-08-21 8:36 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel 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? > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > . > _______________________________________________ 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] 6+ messages in thread
* Re: [f2fs-dev] f2fs_symlink bug 2019-08-21 8:36 ` Chao Yu @ 2019-08-22 19:49 ` Jaegeuk Kim 2019-08-23 1:39 ` Chao Yu 0 siblings, 1 reply; 6+ messages in thread From: Jaegeuk Kim @ 2019-08-22 19:49 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 > > Linux-f2fs-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > > . > > _______________________________________________ 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] 6+ messages in thread
* Re: [f2fs-dev] f2fs_symlink bug 2019-08-22 19:49 ` Jaegeuk Kim @ 2019-08-23 1:39 ` Chao Yu 2019-08-23 15:04 ` Jaegeuk Kim 0 siblings, 1 reply; 6+ messages in thread From: Chao Yu @ 2019-08-23 1:39 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel On 2019/8/23 3:49, Jaegeuk Kim wrote: > 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? It can with below script, which is actually existed case in fsstress. #!/bin/bash for (( i = 0; i < 4095; i++ )); do if [ $((i % 255)) -eq 0 ] then filename=$filename"/" else filename=$filename"0" fi done ln -s $filename /f2fs_mount_point/symlink > If it's fitted in inline_data, it's more easy to guarantee that, right? If the length of symlink is 4095, not sure inline space is enough even we can compress symlink... Thanks, > >>> >>> >>> _______________________________________________ >>> Linux-f2fs-devel mailing list >>> Linux-f2fs-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>> . >>> > . > _______________________________________________ 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] 6+ messages in thread
* Re: [f2fs-dev] f2fs_symlink bug 2019-08-23 1:39 ` Chao Yu @ 2019-08-23 15:04 ` Jaegeuk Kim 2019-08-23 15:48 ` Chao Yu 0 siblings, 1 reply; 6+ messages in thread From: Jaegeuk Kim @ 2019-08-23 15:04 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel On 08/23, Chao Yu wrote: > On 2019/8/23 3:49, Jaegeuk Kim wrote: > > 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? > > It can with below script, which is actually existed case in fsstress. > > #!/bin/bash > > for (( i = 0; i < 4095; i++ )); do > if [ $((i % 255)) -eq 0 ] > then > filename=$filename"/" > else > filename=$filename"0" > fi > done > > ln -s $filename /f2fs_mount_point/symlink > > > If it's fitted in inline_data, it's more easy to guarantee that, right? > > If the length of symlink is 4095, not sure inline space is enough even we can > compress symlink... I meant real usecases larger than 3.5KB. There's no posix rule to guarantee this. IOWs, it's known behavior across filesystems. > > Thanks, > > > > >>> > >>> > >>> _______________________________________________ > >>> Linux-f2fs-devel mailing list > >>> Linux-f2fs-devel@lists.sourceforge.net > >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > >>> . > >>> > > . > > _______________________________________________ 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] 6+ messages in thread
* Re: [f2fs-dev] f2fs_symlink bug 2019-08-23 15:04 ` Jaegeuk Kim @ 2019-08-23 15:48 ` Chao Yu 0 siblings, 0 replies; 6+ messages in thread From: Chao Yu @ 2019-08-23 15:48 UTC (permalink / raw) To: Jaegeuk Kim, Chao Yu; +Cc: linux-f2fs-devel On 2019-8-23 23:04, Jaegeuk Kim wrote: > On 08/23, Chao Yu wrote: >> On 2019/8/23 3:49, Jaegeuk Kim wrote: >>> 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? >> >> It can with below script, which is actually existed case in fsstress. >> >> #!/bin/bash >> >> for (( i = 0; i < 4095; i++ )); do >> if [ $((i % 255)) -eq 0 ] >> then >> filename=$filename"/" >> else >> filename=$filename"0" >> fi >> done >> >> ln -s $filename /f2fs_mount_point/symlink >> >>> If it's fitted in inline_data, it's more easy to guarantee that, right? >> >> If the length of symlink is 4095, not sure inline space is enough even we can >> compress symlink... > > I meant real usecases larger than 3.5KB. There's no posix rule to guarantee > this. IOWs, it's known behavior across filesystems. Correct, it looks not a big deal that whether we truncate i_size of symlink to zero or not? how about avoiding such assert in fsck? Thanks, > >> >> Thanks, >> >>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Linux-f2fs-devel mailing list >>>>> Linux-f2fs-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel >>>>> . >>>>> >>> . >>> > > > _______________________________________________ > Linux-f2fs-devel mailing list > Linux-f2fs-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel > _______________________________________________ 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] 6+ messages in thread
end of thread, other threads:[~2019-08-23 15:49 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-08-12 12:01 [f2fs-dev] f2fs_symlink bug Chao Yu 2019-08-21 8:36 ` Chao Yu 2019-08-22 19:49 ` Jaegeuk Kim 2019-08-23 1:39 ` Chao Yu 2019-08-23 15:04 ` Jaegeuk Kim 2019-08-23 15:48 ` Chao Yu
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).