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.

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

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

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

Reply via email to