Hi Ju Hyung,
On 2019/4/16 10:10, Ju Hyung Park wrote:
> Hi Chao,
>
> On Tue, Apr 16, 2019 at 10:58 AM Chao Yu <[email protected]> wrote:
>> I knew this works in scenario cell phone suffers sudden power-cut frequently,
>> actually, in a normal case, if there is race in between checkpoint() and
>> quota
>> updater, checkpoint() may suffer longer delay than before.
>
> This was actually not a sudden power-cut scenario.
> After passing the setup wizard
> (the quota flush timeout might have happened during initial dex2oat process)
> and simply rebooting, I always see "quota file may be corrupted, skip
> loading it".
>
> I personally investigated this quota corruption issue as I frequently
> saw it on my
> daily driver phone even when I never had sudden power-cuts.
Okay.
>
>> So I suggest we keep the logic as it is, since sudden power-cut is not a
>> common
>> case,
>
> As I said, the issue is caused from a totally normal scenario.
> A solution must be implemented imo.
> Feel free to suggest a better idea/patch for me to test with.
retry_flush_quotas:
if (__need_flush_quota(sbi)) {
int locked;
if (++cnt > DEFAULT_RETRY_QUOTA_FLUSH_COUNT) {
set_sbi_flag(sbi, SBI_QUOTA_SKIP_FLUSH);
f2fs_lock_all(sbi);
goto retry_flush_dents;
}
/* maximum retry quota flush count */
#define DEFAULT_RETRY_QUOTA_FLUSH_COUNT 8
I added above flush count number to limit cycle index, so that we won't be stuck
for long time once we are under heavy racy in between checkpoint() and quota
updating.
Once we skip flushing quota, in current checkpoint, quota sysfile may be
corrupted, but if there is no sudden power-cut, I expect we can have chance to
flush all data of quota file in next checkpoint, then the quota file is
integrated again.
So could you track the root cause why we set the CP_QUOTA_NEED_FSCK_FLAG flag in
checkpoint() from umount?
Do we skip flush quota due to flush count exceeds the
DEFAULT_RETRY_QUOTA_FLUSH_COUNT?
>
>> even in such case, quota sysfile is corrupted, we have another chance to
>> repair it with fsck-tools, right?
>
> This is an another potential issue. Android does fsck.f2fs -a on boot
> and it does not
> restore quota. Doing a run with -f fixes it, but not with -a.
Could you check your source code? did you apply dfede78aa918 ("fsck.f2fs: detect
and recover corrupted quota file")? This patch can enable fsck to repair quota
file corruption once kernel set CP_QUOTA_NEED_FSCK_FLAG flag.
Thanks,
>
> This ultimately led the storage settings under the settings app to misbehave.
>
> Thanks.
> .
>
_______________________________________________
Linux-f2fs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
