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 [email protected] https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
