Hi Michael,
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?
>
> where XYZ varied from line to line. I assume this is related to
> 91bb7b21f740d61cde2bb27da3dccb0afdd5a15b but I'm not sure about the
> implications. Is this something to worry about or some deliberate
> change of the on-disk format which was now braught up to date by fsck?
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.
Thanks,
>
> Best regards,
> Michael
>
>
>
>
>
> _______________________________________________
> 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
