拒绝安卓“卡卡卡”：华为团队详谈打造手机超级文件系统全过程
华为心声社区日前刊登了《》的文章，介绍了华为开发和优化f2fs文件系统的全过程。
以下为全文：
拒绝“卡卡卡”
——手机超级文件系统的革新之路
如果在手机上打开一张图片，要默念三秒才能显现，很多消费者估计都炸毛了。不幸的是，几乎每一部安卓手机用了一段时间，都难逃“越来越卡”的命运。高清的照片、视频占用的空间越来越大，手机剩余的存储空间也就越来越少。
这其中的原因当然很多，但文件系统的“先天不足”是最重要的因素之一。安卓默认的文件系统ext4，最初设计是基于磁盘式的存储结构，随着手机用户的频繁使用，手机存储空间的碎片越来越多，应用程序读写数据就越来越慢。这就好比是刚搬新家，东西少，要找一个东西花不了几分钟，可住得越久，买的东西越多，又不收拾，要在满满当当的房间里找到你要的东西，就需要花更多时间。
如何能让手机如行云流水般流畅，如何在安卓文件系统领域做到最快、最强？这次，我们想做点不一样的事。
签字画押的“军令状”
我们首先想到的是f2fs文件系统。相比ext4，f2fs文件系统“聪明”多了，不仅会主动帮你收拾房间，而且扔垃圾也不那么简单粗暴了，先分清楚是“干垃圾”、“湿垃圾”之类，过段时间再集中处理。如果能用f2fs替代原有文件系统，是否就能极大提升手机运行效率，解决“越用越慢”的问题呢？
但此时，我们手里只有一个f2fs文件系统的开源原型，是国外的一名工程师在技术社区用业余时间开发出来的。由于不确定性大，哪个安卓厂商也不敢随便用。而最早使用f2fs的m厂商，只因一次尝试，就让上千台手机变成“砖头”被退货，错误数据多达好几个t。
面对着同样的风险，我们要不要走一回钢丝？
我们召集了相关领域的专家一起讨论使用f2fs模型的可行性。经过查阅社区的文档和技术达人的实验数据，大家一致认为，首先需要解决三类的风险：一是性能，怎样使碎片整理动作本身不被用户察觉，不影响手机原有的使用体验；二是可靠性，不能出现文件丢失或损坏，更不能出现手机发生频繁重启甚至开不了机的情况；最后是寿命，就是让文件系统不要“用脑过度”而影响寿命。
针对这三个风险，我们准备了初步的解决方案方向，等待上会评审。
当我在评审会上汇报完，让整个技术管理团队举手表决时，偌大的会议室里鸦雀无声，没有人举手。真的没有人敢举手啊！说白了，是越懂越害怕。
“大家都说说想法吧，我们先讨论，再表决！”cbg软件部总裁王博的一番话打破了沉默。
“我们对现有的风险是不是已经有了全面的认识，是不是最懂的专家已经参与进来了？虽然听到这个方案，我也热血沸腾，但细节是不是要澄清一下？”
f2fs的jkim和社区maintainer老俞都全程参与了设计和开发，已经是业内最强阵容了。”
“这个开源模型，连s厂商都没敢用，确实风险大。不过如果我们做成了，对软件领域，乃至整个行业来说，都是不可估量的贡献啊！”
……
几个小时过去了，大家在革命性的创新和技术风险的权衡中反复讨论。最后一致认为，cbg软件部需要这样的突破：“产品到了这个阶段，如果我们不做成一些别人不敢做的事情，消费者凭什么一直选择我们？用户体验最佳也不应该仅仅是一道标语！”
为了保证最终的方案能得到充分验证，且风险可控，tmt管理团队最后达成共识：首次在手机项目中采用商用实验项目的方式，即小规模商用以控制风险，并进行跟踪管理。这批手机一旦送到维修中心，会第一时间送回分析。
会后王博让我把相关的专家组织起来，再做一次风险评估，并在纸件上签字，让我们每个人都明白在这样一个系统中自己的责任。
“签字画押”之后，我们就开干了！
各个部门也派出了精兵强将，投入到这一场大仗中。os部自不必说，cbg的软工、硬工、2012内核实验室、海思的硬件工程部、海思存储芯片团队都积极投入资源全力配合。
接下来，就看我们的了！
三大难题，难于上青天
要用f2fs替换现有文件系统，就好比器官移植手术。每一根神经和血管的接驳都马虎不得，只有都搞对了，才能重新恢复心跳、血压和呼吸。获得新“器官”的手机，也将具备更强劲的运动和思维能力。
项目组分工协作，按照一开始评估的风险，开始了对“三大难题”的攻克。
第一个难题是性能。碎片整理本身会带来消耗，这种消耗甚至对前台的用户体验产生影响。如何让f2fs聪明而省力地工作，是我们首先要考虑的。项目组先是做修补的工作，针对f2fs的一些不合理的设计进行优化。
这些修补工作尽管必不可少，却无法在性能上有大的突破。后来我们发现，当手机剩余空间越来越小的时候，写入存储的性能会下降，尤其是存储空间碎片多的情况下会急剧下降，有可能下降到原来的1/10，甚至5%。用户会察觉到，往手机里存一张照片、一段视频要用的时间明显增加了，忍不住吐槽“好卡”。
为了解决这个问题，我们和海思一起做了多通道并发设计，通过芯片和软件相结合的技术，在保障了系统可靠性的前提下，将写入存储的性能提升了6倍。这个突破到现在，我们也是业界no.1。同时，我们跟芯片验证的同事一起，将相关性能指标放到了华为采购标准里，以保证我们对性能的追求。
第二个难题是可靠性。一般情况下，手机如果出现系统可靠性问题，最坏的可能也就是无故重启。但如果文件系统破损，手机开机时可能无法获取到相应的系统配置项，会导致反复重启，甚至开不了机，这可是重大的质量事故了！
最典型的一类导致文件破损的原因是ddr跳变。这就好比是一个突变基因，一旦碰撞到原始数据，就会“感染”导致这个文件破损，而如果恰好遇到系统性文件，就会开不了机了……真的就像定时炸弹一样，难以预测。这种不确定性，使我们没有办法穷举所有的可靠性问题。
怎么办？我们干脆反其道而行之——研究所有的故障模型，基于故障模型打免疫针，在故障还没有发生之前主动预防，阻断异常。
第三个难题有关寿命。文件系统频繁地整理，必然损耗闪存寿命。我们不贪心，不要求手机“长生不老”，只希望至少做到大家普遍能接受的三五年不坏。
影响寿命的原因有很多，核心原因之一是“过劳”——写放大。简单说就是，要在手机上“写”1兆字节的数据，为了避免掉电等异常造成的文件破损，操作系统就必须“写”进去5兆甚至是10兆的数据。我们想了很多给它减负的办法，比如通过文件系统和数据库的联合优化，让数据库和文件系统在写之前先通个气，这样它俩就不必再做重复的工作了，也就自然延长了寿命。
同时，为了准确地预估出手机的存储芯片寿命，我们还做了一个寿命预测模型。最早做出来的模型受限于采集数据渠道的影响，不够准确。有领导曾挑战过我们：“这个xx系数怎么算出来的？怎么能说这个产品发货后一年半就要出现问题呢？而且又没给出解决方案！” 但是随着更多的大数据介入后，寿命预测模型也具备了参考价值。在这个基础上，我们还有额外的一招拯救措施，比如，如果在大数据上看到这批机器的寿命确实老化得比较快，就可以推动升级，避免继续恶化。
经过这些努力，即便是在最差情况下，f2fs都可以保证存储的寿命在可接受范围内。
很快，我们在emui5.0正式首发文件系统。mate8用户升级emui5.0后，在运行速度方面，用户的满意度有了明显改善。
和“疑难杂症”斗智斗勇
尽管文件系统上线前，我们已经进行了大量的测试和分析，但真正上线后，却还是经历了一次次的“惊心动魄”。
p9上市一个月后，有商用实验用户反馈说自己手机里的照片都没了，所有人都怀疑是不是f2fs文件系统出了问题。一时间，整个文件系统的好手都被重新召集到上海来攻关。大家反复查代码并比照故障现场日志，鏖战了3个昼夜，却感觉不像是文件系统能够导致的问题。
正当我们不断尝试却一筹莫展的时候，问题在我们手里复现了！大家赶紧扑上来，重复之前的操作，找到了复现的规律。通过查看底层日志确定，原来是有应用主动发出了删除的命令，错误地清理了用户的照片。顺藤摸瓜，我们最终抓到了这个“流氓”应用。
大家总算松了一口气，虽说确实不是文件系统的问题，但这也给我们提了个醒：为了避免类似的事故再次发生，我们从底层入手，提供了强大的安全保护机制，限制了“流氓”应用对用户的数据的破坏。这下把这个问题彻底解决了。
这样的“疑难杂症”还有很多。
mate20上市前，我们投放了少量的机器做beta,刚用没几天，“用户”老卞就打来电话，反馈微信出现严重卡顿。我们通过日志发现，微信陷入这个文件系统的时候，等待时间特别长，正常应该是微秒级，现在却恶化了1万倍！
要定位问题就要获取更多的故障机。在pdu测试同事小李的帮助下，我们将复制的beta版本单独推给用户，一旦问题复现，就请用户及时反馈。
第二天凌晨1点多，有个beta用户说问题复现了，并且同意我们即时上门取故障机。阿杜连夜驱车几十公里赶往用户所在地，拿到了这台“宝贵”的故障机。但是折腾一晚上，还是没找到原因，到了上午9点多，又出来一台，大家就打了一个热补丁，由此拿到了一个关键变量的数据，同时反复查了几十份日志……终于分析出了原因，并成功复现。
原来，在谷歌更新版本之后，部分应用出现了兼容性问题，如果手机解密之前，应用去访问了未解密的文件，这个问题就可能发生。针对这个情况，我们在底层增加了加密访问失败后的处理机制，有效避免了异常操作带来的卡顿。
其实，还有很多这种极难定位的问题，都是多个部门第一时间紧密配合完成的。
还能更快吗？drb会议的“光速打脸”
对于安卓手机来说，f2fs只是解决了用户数据区的问题，可是手机里有较大的空间留给了系统分区，这个“大房间”不打扫，整体性能还是没法达到最佳，系统分区里的剩余空间用户也没办法使用。
我们不能阻止系统文件的增大，但如果要它更灵活一点、小一点，最好的办法还是压缩。
这个想法在业界不算独创，s厂商早在2012年就做了一个压缩文件系统，但由于性能损失太大甚至没有进入开源社区。g厂商在2016年推出的ab升级机制，由于需要占用双倍的分区来保存系统文件，所以也在力推压缩文件系统squashfs。
squashfs是不是我们的机会呢？
经过研究发现，这个系统确实存在比较大的原生性能问题，这大概也是没能广泛推广的原因。但我们在用户场景上进行了初步测试，认为其代价相比收益还是可以接受的。于是，我上了drb（设计评审委员会），信心满满地告诉大家：“squashfs可以用！可以带来正向的收益！”但下了会没多久，我就发现，在系统应用场景，特别是像camera这样的重性能应用场景，手机每进行100次拍照后，会有5/6次出现慢1~2秒延迟，这是用户所不能接受的。
于是，我第二次上了drb，灰溜溜地告诉大家：“squashfs用不了。”说这话时，我心里想，这就是传说中的“光速打脸”啊！丢人丢大了！
但我们还是不想放弃。下来找了港城大的薛春和史亮教授，帮助我们研究压缩文件系统的先进理论，去论证压缩到底怎么压，解压缩怎么解，怎样避免对性能的影响等。
只读文件压缩文件系统，主要是低端机受益，低端机的空间更小，两个g的节约对用户来说感知就非常明显了。但同时低端机对性能的要求也最苛刻，稍有减弱，就没法用了。可是，这个问题g厂商在大空间的高端机上都没解决，我们如何突破？
有一天晚上，组里的兄弟们聊天时，小翔突然说：“我们把内存和磁盘结构改造一下，这个问题是不是就可以搞定了？”这句话让我们恍然大悟！
这就好比，我们要给一个房间的物品打包，如果按以前的思路，就是把所有东西装进一个巨大的箱子里。要找任何一样物品，都需要在箱子里“大海捞针”。但如果转化一下思路，提供n个1l容量的箱子，把东西分别装进这些箱子，那找起来就简单得多了。
沿着这个思路，我们设计了新的压缩方式，提交到lz4开源社区里，maintainer看到很支持，很快就合到主线里面去了。真没想到，困扰我们这么长时间的难题，就这么解决了。华为p30发布时，系统文件分区就采用了我们最新的文件系统。
彼此信任的默契
回顾文件系统的开发历程，感谢每一个兄弟部门的协作。如果没有大家的精诚合作、风险共担，我们不可能打造出自己的超级文件系统。
前文提到的多通道并发设计的方案，其实是一个有风险的方案。我记得海思的阿彪曾跟我说：“喜渝，我很害怕，这东西到底敢不敢合进去。”我们就一起去看，到底有可能在哪些场景出现问题。的确文件系统本身无法面面俱到解决这个问题，但从操作系统层面，所有场景都可以系统地来弥补。还有少部分方案需要我们当前做底层的驱动架构调整，海思的兄弟们也从未退缩，一起想办法解决。如果不是互信的团队，如果大家都只站在自己的业务田里做利弊权衡，这种有很大风险的技术突破很难做成。
和中软的合作更是如此。记得定位p9“丢文件”问题的时候，大家都一起住在公司熬夜定位，实在熬不住就在旁边睡会儿。当时，睡在我旁边椅子上的兄弟就是中软文件系统的pl斌田和他组里的云蕾。大家经历两天两夜，没有找到根因，犯困又睡不着，云蕾就开始拿着手机躺着复现问题，突然听他大叫一声，把我们几个吓了一跳！原来他居然“躺着”把问题复现了！大家一股脑从躺椅上爬起来，围着他一顿狂问，终于找到了复现规律。从此这位兄弟被我们称作“金手指”，是他洗清了文件系统的“嫌疑”。
这些故事还有很多很多。我们一起克服了种种困难，解决了一个又一个难题， 我想，这些彼此信任的日子会在时光中闪耀。
展望未来，我们将致力于最佳的消费者体验，做出更多牛逼的作品！