Re: [f2fs-dev] F2fs mount cost long time due to waiting f2fs gc with f2fs checkpoint disabled

[Chao Yu <yuchao0@huawei.com>]

Hello,

Sorry for the delay reply.

On 2019/11/21 18:48, 王矛 wrote:
> Hi Chao,
> 
> Recently I encounter an issue that f2fs mount cost quite a long time(the longest time i met is almost 4min to mount f2fs completely).
> Below is a typical log:
> 01-24 18:42:09.825     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:15.369     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:20.952     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:26.510     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:32.288     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:37.843     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:42:43.476     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> ...
> 01-24 18:44:48.873     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:44:54.606     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:45:23.337     0     0 I init    : [libfs_mgr]Retrying mount (source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=-1(11): Try again
> 01-24 18:45:29.065     0     0 W F2FS-fs (mmcblk0p80): Start checkpoint disabled!
> 01-24 18:45:29.077     0     0 I F2FS-fs (mmcblk0p80): Mounted with checkpoint version = 249f83f
> 01-24 18:45:29.082     0     0 I init    : [libfs_mgr]__mount(source=/dev/block/bootdevice/by-name/userdata,target=/data,type=f2fs)=0: Try again
> 01-24 18:45:29.082     0     0 I init    : [libfs_mgr]/data is file encrypted
> 01-24 18:45:29.082     0     0 I init    : [libfs_mgr]Successfully mounted /data with file system type 'f2fs.: Try again
> 
> The related patch is: https://android-review.googlesource.com/c/platform/system/core/+/875538
> <https://android-review.googlesource.com/c/platform/system/core/+/875538>
> My question is:
> a) Is there any reason that f2fs gc must be done within 5s in the procedure of disable f2fs checkpoint?
>    code related:  f2fs_disable_checkpoint(sbi):
>           while (!f2fs_time_over(sbi, DISABLE_TIME))  //5s
>                  f2fs_gc(sbi, true, false, NULL_SEGNO);

I think we need to use this timeout mechanism to avoid mount being hanged too long
time if GC need many time to handle fragment migration.

> b) Why there is a condition test as below in f2fs_disable_cp_again()?

IIUC，we need to consider extreme case, e.g. if all fragmented segment's type is
data, and there is no free segment, then we may fail to find any free space for
newly written node, vice versa.

So during mount, we are trying to trigger GC to migrate fragmented block as much as
possible, to get enough free segment for later data/node written.

>      if (holes[DATA] > ovp || holes[NODE] > ovp)
>             return -EAGAIN;  <<<<---- mount will return here
>     My this issue is the code return in above code and fs_mgr will mount userdata again and again.
> 
> Can u kindly help to comment my above questions? 
> And is there is any solution to avoid or improve this scenario since if this happen, will impact the end user experience(end user may think phone get corrupted...). 

Checkpoint disabling is only used for upgrading of data partition, user can bear that
as upgrading usually takes long time.

Thanks,

> 
> Thanks,
> Mao
> 
> 
>  
> 


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