华为心声社区日前刊登了《拒绝手机“卡卡卡”，我们打造了华为自己的超级文件系统》的文章，介绍了华为开发和优化F2FS文件系统的全过程。如果在手机上打开一张图片，要默念三秒才能显现，很多消费者估计都炸毛了。不幸的是，几乎每一部安卓手机用了一段时间，都难逃“越来越卡”的命运。高清的照片、视频占用的空间越来越大，手机剩余的存储空间也就越来越少。这其中的原因当然很多，但文件系统的“先天不足”是最重要的因素之一。安卓默认的文件系统EXT4,最初设计是基于磁盘式的存储结构，随着手机用户的频繁使用，手机存储空间的碎片越来越多，应用程序读写数据就越来越慢。

此外，文章还提到了华为开发和优化F2FS文件系统的全过程。相比EXT4,F2FS文件系统“聪明”多了，不仅会主动帮你收拾房间，而且扔垃圾也不那么简单粗暴了，先分清楚是“干垃圾”、“湿垃圾”之类，过段时间再集中处理。如果能用F2FS替代原有文件系统，是否就能极大提升手机运行效率，解决“越用越慢”的问题呢？但是此时，我们手里只有一个F2FS文件系统的开源原型，是国外的一名工程师在技术社区用业余时间开发出来的。由于不确定性大，哪个安卓厂商也不敢随便用。而最早使用F2FS的M厂商只因一次尝试就让上千台手机变成“砖头”被退货。

希望这些信息能够帮到你！

BG软件部总裁王博打破沉默，提议大家讨论并表决：“大家都说说想法吧，我们先讨论，再表决！”尽管听到这个方案，F2FS的JKim和社区maintainer老俞都热血沸腾，但他们也提出疑问：“我们对现有的风险是不是已经有了全面的认识，是不是最懂的专家已经参与进来了？虽然细节很重要，但是不是要澄清一下？”

“这个开源模型，连S厂商都没敢用，确实风险大。不过如果我们做成了，对软件领域，乃至整个行业来说，都是不可估量的贡献啊！”会议进行了几个小时，大家在革命性的创新和技术风险的权衡中反复讨论。最后一致认为，CBG软件部需要这样的突破：“产品到了这个阶段，如果我们不做成一些别人不敢做的事情，消费者凭什么一直选择我们？用户体验最佳也不应该仅仅是一道标语！”

为了保证最终的方案能得到充分验证，且风险可控，TMT管理团队最后达成共识：首次在手机项目中采用商用实验项目的方式，即小规模商用以控制风险，并进行跟踪管理。这批手机一旦送到维修中心，会第一时间送回分析。

会后王博让我把相关的专家组织起来，再做一次风险评估，并在纸件上签字，让我们每个人都明白在这样一个系统中自己的责任。“签字画押”之后，我们就开干了！

各个部门也派出了精兵强将，投入到这一场大仗中。OS部自不必说，CBG的软工、硬工、2012内核实验室、海思的硬件工程部、海思存储芯片团队都积极投入资源全力配合。接下来，就看我们的了！

三大难题，难于上青天

要用F2FS替换现有文件系统，就好比器官移植手术。每一根神经和血管的接驳都马虎不得，只有都搞对了，才能重新恢复心跳、血压和呼吸。获得新“器官”的手机，也将具备更强劲的运动和思维能力。

项目组分工协作，按照一开始评估的风险，开始了对“三大难题”的攻克。第一个难题是性能。碎片整理本身会带来消耗，这种消耗甚至对前台的用户体验产生影响。如何让F2FS聪明而省力地工作，是我们首先要考虑的。项目组先是做修补的工作，针对F2FS的一些不合理的设计进行优化。这些修补工作尽管必不可少，却无法在性能上有大的突破。后来我们发现，当手机剩余空间越来越小的时候，写入存储的性能会下降，尤其是存储空间碎片多的情况下会急剧下降，有可能下降到原来的1/10,甚至5%。用户会察觉到，往手机里存一张照片、一段视频要用的时间明显增加了，忍不住吐槽“好卡”。

华为手机文件系统的可靠性提高方法有很多，其中包括多通道并发设计、基于故障模型打免疫针、寿命预测模型等。这些方法的实施可以使得存储的性能提升6倍，同时保证了系统可靠性。

在安卓手机中，F2FS文件系统只是解决了用户数据区的问题。然而，手机中还有较大的空间留给了系统分区，这个“大房间”不打扫，整体性能还是没法达到最佳，系统分区里的剩余空间用户也没办法使用。

尽管文件系统上线前，我们已经进行了大量的测试和分析，但真正上线后，却还是经历了一次次的“惊心动魄”。例如，P9上市一个月后，有商用实验用户反馈说自己手机里的照片都没了，所有人都怀疑是不是F2FS文件系统出了问题。一时间，整个文件系统的好手都被重新召集到上海来攻关。大家反复查代码并比照故障现场日志，鏖战了3个昼夜，却感觉不像是文件系统能够导致的问题。正当我们不断尝试却一筹莫展的时候，问题在我们手里复现了！大家赶紧扑上来，重复之前的操作，找到了复现的规律。通过查看底层日志确定，原来是有应用主动发出了删除的命令，错误地清理了用户的照片。顺藤摸瓜，我们最终抓到了这个“流氓”应用。

类似的问题还有很多。例如，Mate20上市前，我们投放了少量的机器做Beta。刚用没几天，“用户”老卞就打来电话反馈微信出现严重卡顿。我们通过日志发现微信陷入F2FS文件系统时等待时间特别长，正常应该是微秒级现在却恶化了1万倍！要定位问题就要获取更多的故障机。在PDU测试同事小李的帮助下我们将复制的Beta版本单独推给用户一旦问题复现就请用户及时反馈第二天凌晨1点多有个Beta用户说问题复现了并且同意我们即时上门取故障机阿杜连夜驱车几十公里赶往用户所在地拿到了这台“宝贵”的故障机但是折腾一晚上还是没找到原因到了上午9点多又出来一台大家就打了一个小热补丁由此拿到了一个关键变量的数据同时反复查了几十份日志......终于分析出了原因并成功复现原来在谷歌更新版本之后部分应用出现了兼容性问题如果手机解密之前应用去访问了未解密的文件这个问题就可能发生针对这个情况我们在底层增加了加密访问失败后的处理机制有效避免了异常操作带来的卡顿

以上内容来自CSDN博客。

我们无法阻止系统文件的增大，但如果想要使其更具灵活性和更小巧，最有效的方法仍然是压缩。尽管在业界这并非独创之举，S厂商早在2012年就开发了一个压缩文件系统，但由于性能损失过大，甚至没有进入开源社区。G厂商在2016年推出的AB升级机制也要求占用双倍分区来保存系统文件，因此也在大力推广压缩文件系统Squashfs。

那么，Squashfs是否是我们的机会呢？经过研究发现，这个系统确实存在较大的原生性能问题，这大概也是未能广泛推广的原因。但在用户场景上进行了初步测试后，我们认为其代价与收益是可以接受的。于是，我向DRB(设计评审委员会)推荐了Squashfs,并充满信心地告诉大家：“Squashfs可以用！可以带来正向的收益！”然而，会议结束后不久，我发现在系统应用场景，特别是像Camera这样的重性能应用场景中，手机每进行100次拍照后，会有5/6次出现慢1~2秒延迟，这是用户所不能接受的。

于是，我第二次向DRB汇报情况时，尴尬地说：“Squashfs用不了。”说这话时，我心里想，这就是传说中的“光速打脸”啊！丢人丢大了！但我们仍不想放弃。我们请教了港城大的薛春和史亮教授，帮助我们研究压缩文件系统的先进理论，以论证压缩应该如何进行、解压缩应该如何进行以及如何避免对性能的影响等。

只读文件压缩文件系统主要受益于低端机，因为低端机的空间更小。两个G的节约对用户来说感知非常明显。但同时，低端机对性能的要求也最苛刻。一旦性能有所减弱，它就无法使用。然而，这个问题G厂商在大空间的高端机上仍未解决，我们该如何突破？

有一天晚上，组里的兄弟们聊天时，小翔突然说：“我们可以将内存和磁盘结构改造一下，这样问题就可以解决了吗？”这句话让我们恍然大悟！

这就好比我们要给一个房间的物品打包。按以前的思路，就是把所有东西装进一个巨大的箱子里。要找任何一样物品，都需要在箱子里“大海捞针”。但如果转换一下思路，提供N个1L容量的箱子，把东西分别装进这些箱子，那找起来就简单得多了。

沿着这个思路，我们设计了新的压缩方式，并将其提交到LZ4开源社区。maintainer看到后表示很支持，很快就合入主线了。真没想到，困扰我们这么长时间的难题，竟然如此轻易地解决了。华为P30发布时，系统文件分区采用了我们最新的文件系统。

在这个过程中，我们彼此信任、默契合作。感谢每一个兄弟部门的协作。若非大家的精诚合作和风险共担，我们不可能打造出自己的超级文件系统。

前文提到的多通道并发设计方案，实际上是一个充满风险的策略。我清楚地记得海思的阿彪曾对我说过：“喜渝，我很担忧，我们是否应该把这个方案整合进去。”于是，我们决定一起研究，看看在哪些场景下可能出现问题。尽管文件系统本身无法解决所有问题，但从操作系统层面来看，我们可以系统性地解决大部分问题。对于少数方案，我们需要进行底层驱动架构的调整。海思团队从未退缩，一起努力寻找解决方案。

如果团队之间缺乏互信，如果每个人都只关注自己的业务利益而不顾整体风险，那么这种具有很大风险的技术突破是很难实现的。与中软的合作更是如此。还记得当时定位P9“丢文件”问题时，大家都一起住在公司熬夜查找原因，实在困得不行就在旁边打个盹儿。那时，睡在我旁边的兄弟就是中软文件系统的PL斌田和他组里的云蕾。大家熬了两夜，却始终找不到问题的根源，困得直打哈欠。云蕾突然拿着手机躺着模拟问题出现的情形，突然大叫一声，把我们几个吓得跳了起来！原来他居然“躺着”就把问题复现了！大家赶紧从躺椅上爬起来，围着他一顿狂问，最后终于找到了问题的规律。从此这位兄弟被我们称为“金手指”，因为他成功证明了文件系统并非“罪魁祸首”。

这些故事还有很多很多。我们一起克服了种种困难，解决了一个又一个难题。我相信，这段相互信任的日子将在时间的长河中闪耀。展望未来，我们将继续致力于为消费者提供最佳体验，打造更多优秀的作品！