fsck: reset i_gc_failures from 0x1 to 0x00

fsck: reset i_gc_failures from 0x1 to 0x00

[Michael Laß]

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

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?

Best regards,
Michael

Re: fsck: reset i_gc_failures from 0x1 to 0x00

[Chao Yu]

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

Re: fsck: reset i_gc_failures from 0x1 to 0x00

[Michael Laß]

Hi,

> Am 26.11.2018 um 15:09 schrieb Chao Yu <chao@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

Re: fsck: reset i_gc_failures from 0x1 to 0x00

[Jaegeuk Kim]

Hi Michael,

On 11/26, Michael Laß wrote:
> Hi,
> 
> > Am 26.11.2018 um 15:09 schrieb Chao Yu <chao@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.

Just in case, is this Android device? If you don't use ioctl(F2FS_PIN_FILE),
this onetime fix wont' hurt any filesystem metadata.

Thanks,

> 
> 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


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: fsck: reset i_gc_failures from 0x1 to 0x00

[Michael Laß]

Hi,

> Am 27.11.2018 um 01:08 schrieb Jaegeuk Kim <jaegeuk@kernel.org>:
> On 11/26, Michael Laß wrote:
>> 
>>> Am 26.11.2018 um 15:09 schrieb Chao Yu <chao@kernel.org>:
>>> 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.
> 
> Just in case, is this Android device? If you don't use ioctl(F2FS_PIN_FILE),
> this onetime fix wont' hurt any filesystem metadata.

no, it’s used on a regular GNU/Linux system, a Raspberry Pi running Arch Linux ARM to be more specific. The kernel is currently still at version 4.14.83 so as far as I can see that ioctl isn’t even available.

I guess I’ll see these messages again after new files have been created by that old kernel but should not worry about it.

Best regards,
Michael

_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel