f2fs文件系统相关性能优化工作

一 文件系统缺陷导致的开机慢问题

1)定位原因：
文件系统做cp时，如果flush quota data不成功，就会在f2fs的cp区域设置了CP_QUOTA_NEED_FSCK_FLAG这个flag。

而这个flag一旦被设置，就永远清除不了，下次开机就会做耗时的quota修复工作，这样就会导致开机慢问题出现。

这个开机慢原因是原生Android的行为导致的。

 

2)解决思路：

因为fsck中的quota修复工作耗时是不可避免的，很难优化。所以只能尽量避免做开机后的quota修复工作。

 

上面的一旦设置了CP_QUOTA_NEED_FSCK_FLAG这个flag，就清除不了，这个是有问题的。

因为f2fs做某次cp时，flush quota data不成功，设置了CP_QUOTA_NEED_FSCK_FLAG这个flag。但是下次cp时，flush quota data成功时，

就应该要及时清除之前设置的这个CP_QUOTA_NEED_FSCK_FLAG。

 

因为该原生Android内核版本是4.14的，所以查看下面分支的git log

https://kernel.googlesource.com/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable/+log/refs/heads/linux-4.14.y/fs/f2fs

发现已经有修复change:

https://kernel.googlesource.com/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable/+/bef48bd28828407aa60407c284d892060473f98b

但是修复changes除了做及时清除CP_QUOTA_NEED_FSCK_FLAG之外，还多做了一个工作：

强制设置sb->s_qcop为f2fs_quotactl_ops。

 

这个工作在f10 android q上据我分析还不能做, 原因在于：

1) 因为f10-q上使能quota功能，应该是通过f2fs文件系统的sysfile来完成的，并不是通过special file来完成的。

2) f2fs_quotactl_ops为special file对应的ops，并不是f10-q想要的quotactl ops。

 

所以综合上面原因，虽然谷歌社区里面有修复change,但是里面做的设置sb->s_qcop为f2fs_quotactl_ops工作，f10-q里面还不能做。

所以目前需要做的是参考社区修复change, 及时clear这个CP_QUOTA_NEED_FSCK_FLAG就行了.

 

3)测试验证

带上面740767和738061这两个changes，在f10-q机型上做对比打包验证。

不带修复changes时：

手机任意启3-4个app后，立刻关机重启7-8次，发现做quota修复工作导致开机慢的有5-6次。

 

带修复changes时：

手机任意启3-4个app后，立刻关机重启7-8次，没有一次做quota修复工作了，f2fs做check的工作也不耗时了。

并且启动aging_test这个app,在后台做文件删除创建工作的同时，关机重启手机若干次，也没有一次做quota修复工作，f2fs做check的工作也不耗时。

 

4)需要重点关注的是

本修复change和社区的修复change不一样，不一样的地方需要重点review下，看看有无带来稳定性方面的负作用。

二：F2FS Fsync checkpoint 条件优化

1 问题来源：

f2fs 中，fsync 调用在满足特定条件时触发 checkpoint ，而checkpoint 会带来很大开销。

我们统计了 fsync 做 checkpoint 的原因，发现 sb need cp（CP_SB_NEED_CP）的次数占到总数的70%以上。

通过追踪代码，发现这是由于如下 change 导致的。

f2fs: fix lost xattrs of directories

This patch enhances the xattr consistency of dirs from suddern power-cuts.
Possible scenario would be:
1. dir->setxattr used by per-file encryption
2. file->setxattr goes into inline_xattr
3. file->fsync

In that case, we should do checkpoint for #1.
Otherwise we'd lose dir's key information for the file given #2.

该 change 保证了意外断电后目录 xattr 的一致性。在每次对目录设置 xattr 时，都会设置 SBI_NEED_CP flag。当 fsync 任意文件，is_sbi_flag_set(sbi, SBI_NEED_CP) 成立，从而做 checkpoint。

这样虽然保证了一致性，但某些情况下会给 fsync 带来了额外的开销，假设如下场景：

1. 1. 进程1：dir_a → setxattr
   2. 进程2：dir_b/file_b → fsync

根据 FSYNC(2)，fsync 语义只保证 file_b 的所有数据被写入磁盘即可，考虑到xattr丢失的情况，也只应在 dir_b 被设置 xattr 时做 checkpoint 。但因为 dir_a 被设置了 xattr，fsync file_b 时会因为 SBI_NEED_CP flag 被设置而做 checkpoint 。

考虑到原 change 给出的场景只存在于 dir 为 file 的父目录时才会出现 xattr 丢失的现象，故可以只在父目录被设置 xattr 时做 checkpoint 。

2 解决方案

base:

在每次对目录设置 xattr 时，都会设置 SBI_NEED_CP flag。当 fsync 任意文件，is_sbi_flag_set(sbi, SBI_NEED_CP) 成立，从而做 checkpoint。

patch: f2fs: avoid needless checkpoint during fsync
在设置目录 xattr 时，将 inode 添加到链表中。取消原change里的设置 SBI_NEED_CP flag。在f2fs superblock 数据结构中添加一个链表。

• • 若 fsync 时检测到文件所在目录的 inode 在链表中，则做 checkpoint 。
  • checkpoint 完成后，所有 xattr 信息都被写入磁盘，链表被清空。
  • 当删除目录时，若其 inode 在链表中，则从链表中删除。