Hi,
> Am 26.11.2018 um 15:09 schrieb Chao Yu <c...@kernel.org>:
> On 2018-11-26 7:09, Michael Laß wrote:
>> Hi,
>>
>> 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
>
> Do you use -f or -p 1 option when doing fsck on image?
One of the devices was automatically checked during boot-up. As far as I can
see, the following command is issued inside the initrd:
fsck -Ta -C"$FSCK_FD" "$1”
where $1 is the device. The other one I checked manually calling fsck.f2fs
without any additional arguments. From my experience, the checks are always
performed when the last check was done with an older kernel version (which was
the case here).
> We start to support reseting .i_gc_failures's value to zero in fsck since
> 91bb7b21f740 ("f2fs-tools: fix to reset i_gc_failures offline"), this is
> because
> if .i_gc_failures continues increasing and exceed threshold, it can make f2fs
> break atomic_write semantics during GC, so I added that patch to avoid such
> condition.
>
> But the problem here is even .i_gc_failures's value is one which was
> initialized
> duing inode creation by old kernel, and it never be increased by GC flow, we
> will still trigger such fix in fsck. I think it's not necessary, anyway, let
> me
> send one patch to fix it.
This is a very likely cause. The filesystems are both from early 2015, so
probably were used with Linux 3.18 or 3.19 at that time.
Thanks for the explanation and the proposed patch!
Best regards,
Michael
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
