一 文件系统缺陷导致的开机慢问题
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/pub/scm/linux/kernel/git/jaegeuk/f2fs-stable/+log/refs/heads/linux-4.14.y/fs/f2fs 发现已经有修复change: https://kernel.googlesource/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：dir_a → setxattr
- 进程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 在链表中，则从链表中删除。
发布者：admin，转转请注明出处：http://www.yc00.com/web/1754815439a5204101.html
评论列表（0条）