欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  移动技术

拒绝安卓“卡卡卡”:华为团队详谈打造手机超级文件系统全过程

程序员文章站 2022-04-02 18:23:20
华为心声社区日前刊登了《》的文章,介绍了华为开发和优化f2fs文件系统的全过程。 以下为全文: ​​拒绝“卡卡卡”...

华为心声社区日前刊登了《》的文章,介绍了华为开发和优化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斌田和他组里的云蕾。大家经历两天两夜,没有找到根因,犯困又睡不着,云蕾就开始拿着手机躺着复现问题,突然听他大叫一声,把我们几个吓了一跳!原来他居然“躺着”把问题复现了!大家一股脑从躺椅上爬起来,围着他一顿狂问,终于找到了复现规律。从此这位兄弟被我们称作“金手指”,是他洗清了文件系统的“嫌疑”。

这些故事还有很多很多。我们一起克服了种种困难,解决了一个又一个难题, 我想,这些彼此信任的日子会在时光中闪耀。

展望未来,我们将致力于最佳的消费者体验,做出更多牛逼的作品!