On 2018/11/27 8:04, Jaegeuk Kim wrote: > On 11/26, Chao Yu wrote: >> From: Chao Yu <[email protected]> >> >> As Michael reported: >> >> after updating to f2fs-tools 1.12.0, a routine fsck of my file systems >> took quite a while and output ten-thousands instances of the following >> line: >> >>> [FIX] (fsck_chk_inode_blk: 954) --> Regular: 0xXYZ reset i_gc_failures >>> from 0x1 to 0x00 >> >> In old kernel, we initialized i_gc_failures as 0x01, let's skip >> resetting such unchanged initialized value to avoid unnecessary >> repairing. >> >> Reported-by: Michael Laß <[email protected]> >> Signed-off-by: Chao Yu <[email protected]> >> --- >> fsck/fsck.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/fsck/fsck.c b/fsck/fsck.c >> index 970d150..db0e72f 100644 >> --- a/fsck/fsck.c >> +++ b/fsck/fsck.c >> @@ -941,7 +941,9 @@ skip_blkcnt_fix: >> } >> >> i_gc_failures = le16_to_cpu(node_blk->i.i_gc_failures); >> - if (ftype == F2FS_FT_REG_FILE && i_gc_failures) { >> + >> + /* old kernel initialized i_gc_failures as 0x01, skip repairing */ >> + if (ftype == F2FS_FT_REG_FILE && i_gc_failures > 1) { > > This will break the current implementation.
Yeah, but I doubt that after repairing i_gc_failures, old kernel can still continue creating inodes in where .i_gc_failures equals to 0x01, then fsck will report such info each time..., can we relief fsck in such condition? Thanks, > >> >> DBG(1, "Regular Inode: 0x%x [%s] depth: %d\n\n", >> le32_to_cpu(node_blk->footer.ino), en, >> -- >> 2.18.0 > > . > _______________________________________________ Linux-f2fs-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
