在这篇文章中,我不打算带入以往的恩怨,而是直接明了的阐述这个事情是什么、他可能带来的影响,以及对于小米几篇公关通稿的反驳和质疑.
这篇文章不是给小白亦或是某些二极管看的,也不是为了让小米名誉扫地或是为某些东西洗地,如果你想看到我在这篇文章中把小米批得一文不值,那我建议你赶紧离开.
另外,鉴于之前一堆水军和半桶水对我的攻击,我不接受任何没有对闪存业界有过了解、还在拿着厂商通稿和奇葩文章做出的狗屁言论,换言之,我只接受以IEEE论文、原厂报告和SNIA/FMS展示作为论据的驳斥和反推.而作为对等,我在这篇文章中的一切论据都会标注来源,做到公信力.
PART1：你需要了解什么
1.1什么是REW读改写?
REW,READ-ERASE-WRITE.这个可以称之为读改写.当然你也可以用copy-modify-write去称呼他,这是等效的:在NAND层面.
我们在这里简短的说一下为什么它会产生: 固态的擦除是以block为单位、读写以page为单位,nand的物理特性决定了他不能覆盖写入.因此如果我们要对一个已有数据的page进行写入,那么必须先要把这个page所在的block中的数据读出,block清空后再把所有数据写进去.这个过程就是Read-Erase-Write
上面这个图片是我自己做的,如果你对我表示怀疑,下面这个这是来自WD在FMS 2020的报告: How Zoned Namespaces Improve SSD Lifetime, Throughput, and Latency
这个过程出现在脏盘态下:在FOB也就是空盘状态下,所有的PAGE与BLOCK都是干净的,自然没有REW过程.但这种情况在手机上是不可能出现的:即使你刚买回来开机,他也不是FOB态:你的手机预装了操作系统,SLC cache经历了一轮写入与释放,已经有足够多的block和page处于脏盘状态.
而在文件操作与写入上,不及时的GC回收与相对懒惰的TRIM机制、大量log小粒度文件的写入,这些都加剧了脏盘状态:不是你看到256G剩余100G他就没有脏盘.而这东西的分析绝大多数人包括我都没有能力:必须要原厂或者有能力修改FTL的厂商进行适配并测试.
1.2 WAF,写放大
写放大的来源有两种:
第一种是File size文件粒度与Page size的不对齐造成的:由于我们只能向一整个page写入文件,在没有数据打包和压缩的前提下,无论这个文件是4KB还是512b,他都会占用这一整个Page,这也造成了所谓的存储空间大小虚标:你看起来的256G固态剩余150G,但实际上只有合计50G的block/page是干净,其他空间要使用,你都要进行实时的GC回收.
这里由于太过低级,我懒得找图片和论文了
第二种是高负载下经常出现的:在高度脏盘状态下我们写入文件,往往会面临着大量REW改写,而此时为了删除它我们不得不去对多个块进行GC回收,这增加了主控的负担与NAND的损耗.
这个图片来自IEEE的A closed-form expression for Write Amplification in NAND Flash
在实际情况中,我们为了写入一个16KB的文件,可能需要对多个块进行REW改写,以腾挪出足够的空间.还是一样来自于IEEE的A closed-form expression for Write Amplification in NAND Flash:
下面这个图片来自于MEMBLAZE的技术文章:企业级 SSD 寿命要怎么看？
不同的文件写入粒度、不同的GC策略、不同的SLC cache算法,都会得到不一样的WAF曲线,但毫无疑问的:对手机这种低级的UFS闪存系统,WAF必然比enterprise要严重很多
1.3OP是什么,为什么有OP?
OP,即Over Provisioning.我们一般说的enterprise的7%、28%、33%的OP比,实际上是指二级OP.
由于这个定义太过初级,我就懒得赘述了
图片来源于Understanding SSD Over Provisioning,于FMS2012
我们来看看二级OP对于性能的影响
这个数据来源于Over-Provisioning NAND-Based Intel® SSDs for Better Endurance
这个数据来源于Validating Analytic Write Amplification Models,于FMS2016
这个数据来源于Understanding SSD Over Provisioning,于FMS2012
这个数据来源于IEEE的A closed-form expression for Write Amplification in NAND Flash
但在更加原理的层面,即使所谓的client SSD,他们在事实上也是有OP的,我们把它称之为一级预留或者是一级OP,这部分数据就是操作系统中显示与实际容量的差值.小米这次引发争议的就是在动用一级OP上.
1.4坏块预留是什么?
任何SSD都有可能损坏,无论是出场的block中被屏蔽的部分,还是在使用中磨损过度与出现异常的部分.这些部分需要被补齐,因此除了一级OP之外,SSD还会有一定的空间预留以应对这种情况.
1.5不就是动一下块映射吗?为什么你们反应那么大?
与绝大多数人想的所谓简简单单分个区不同,由于FTL交替非线性映射的特性,无法和HDD一样简单的用户层级的区块的重映射与屏蔽.
例如我们要对某几个新增加的块进行映射（我们先不讨论这个块是哪来的）,必须要在工程模式下将所有的物理区块与文件引索重新标记与映射,这个过程就是重建FTL表.
在这个规程中,无论是意外断电或者极小概率的电荷翻转,都会导致数据丢失甚至整个闪存系统变砖不可用.这也就是为什么WD、INTEL、MICRON、SAMSUNG等原厂在固件升级时都会直接写上可能存在小概率数据丢失风险的原因：即使没有软件层面的BUG,各种不可知的意外都会造成严重的后果.
PART2：小米做了什么
这里不会涉及任何的解读,仅仅做出必要的参数
[我们与存储器厂商进行了紧密的协作.首先,我们修改了空间管理策略,将OP区占用的空间从6.9%压缩至约3%.这个过程需要深入了解存储器的工作原理,以确保在压缩OP区空间的同时,不会影响到存储器的性能和寿命.在多次的测试和优化后,我们找到了一个理想的平衡点. ]
小米承认了修改一级OP,从7%/6.9%缩减到3%
来源于
https://card.weibo.com/article/m/show/id/2309404962180771742222?id=2309404962180771742222
[我们除了根据用户习惯来预留充足的空间外, 还优化Cache的管理以减少擦写及坏块的产生, 并同时支持在长时间使用后根据用户情况来云控调整坏块预留区, 保证系统的稳定性.]
小米使用了经过修改的slc cache策略,并支持通过OTA和云控调整坏块预留区,这其中会涉及FTL的重建.
来源于https://m.weibo.cn/status/4962498407302086?jumpfrom=weibocom
是的,根据小米目前透露的消息,结合我对于闪存系统的认知,他就有这两点.
PART3：为什么我对这个东西充满怀疑和担忧
我在这里先摆明立场：我对于小米卖得好不好、其他厂商卖得好不好没有任何兴趣,作为一个存储爱好者和前YMTC临时工,我没有任何与小米利益相关的立场,无论是支持或是反对.
我只是表明了我对这一技术的怀疑与担忧,我衷心希望这个技术不会带来更多的问题、不会造成大面积的翻车：就如同888之于MI11一样.
小米这样做,可能带来的两个巨大问题：
1 使用了大量的一级OP与备用块作为存储空间,无非就是讨好部分容量需求大的用户.而一旦占用空间过高,以UFS闪存的主控能力与固件优化,本来就会存在大量的性能缺陷、延迟飙升和零点.在一级OP被占用的场景下,性能估计是堪忧的.
由于上文已经阐述了二级OP与性能、寿命之间的关系,这里就不再赘述.
数据来源于Reliability of 3D NAND Flash for Future Storage Systems (Invited),IEEE
而小米动用的一级OP,其性能与寿命的关系函数关系不能直接用二级OP去推导：我们随着二级OP的减少,可以看这是一条反比例函数.而更加底层的一级OP,提供了必要的REW读改写所需要的备用区块,根据Intel的于8年前的内部报告,每减少1%的一级OP,寿命是指数级下降,而性能是一条相对反常的曲线,到了0%和1%一级OP预留时,闪存系统已经实质上不可用：使用128K填盘之后的4K稳态性能,在1% 一级OP时已经存在极大的延迟波动,到后期直接是一条零点直线：此时已经没有空间进行读改写,自然没有任何性能.
上面这个报告受限于NDA与各种因素我无法发出,如果不相信我也没办法,这也是本文中唯一一个无法提供出处的论据.
2 小米现在特别喜欢开SWAP,在造成SLC cache重复读写、write back惩罚的情况下,这一小聪明是否会带来更多的性能低位与过度磨损?甚至严重点说：会不会出现几年前中端机因为硬盘IO太差,用一下就卡顿的情况?
3 为什么不能用顺序写入测试?
答案很简单,因为128K的读写负载在Android上是极少存在的.
现实中的client workload是9R1W的4k/8k块负载,而在page size=16k的今天,这种负载会带来严重的写放大.使用128k负载进行测试,无法还原出脏盘状态下的真实性能,更与手机存在大量4k为单位的log日记写入情况不符合.
PART4：对小米通稿的驳斥与疑问
“技术原理是啥?UFS会不会有寿命风险?完全不会,大家放心使用,要相信小米和芯片厂商的专业程度,也不要被带节奏”
没有任何数据、没有任何原厂公开站台,是谁在带节奏?至于专业程度,任何一级OP与备用块的动用和调整,之前在事实上都是不可见的：由于他的重要性和底层性,除了原厂内部报告之外没有任何文章讨论他的影响.一个小米说他没问题就没问题了?MIUI12什么情况、888什么情况、小米金融什么情况?
“我们除了根据用户习惯来预留充足的空间外, 还优化Cache的管理以减少擦写及坏块的产生,并同时支持在长时间使用后根据用户情况来云控调整坏块预留区, 保证系统的稳定性.”
小米知道自己在说什么吗?云控调整坏块预留区！?这个人是不是不知道他在说什么.
如果小米真的做了,那么只需要一个OTA的BUG,就可以瞬间摧毁所有的数据安全！并且毫无后悔药可言.
FTL对物理区块的映射是非线性的,一旦变动就需要进行整体的重新调整,在任何的FW固件更新之前所有的厂商都会告诉你可能存在的丢失数据的风险,并且在没有BUG的前提下极少进行FW固件的调整与升级.
所有的坏块统计和测试,都是一种推测、都是不完全可信的,Samsung和YMTC的0E事件已经向我们证明了这点.而小米在调整坏块预留区的过程势必会进行FTL重建与升级,而之前的标记的坏块时候还被正确屏蔽、磨损平衡是否还生效?这些全部都是未知数！
我再说一次,这个事情没有任何原厂、没有任何例如金士顿、dapustor和memblaze之类的高级第三方曾经做过,据我所知业界也完全没有对这方面的研究.小米这样做的潜在风险如何解决?甚至激进点说,出了问题谁背锅?
“按照目前重度用户的模型来评估, 在每天写入40GB数据的条件下, 256GB的扩容芯片依然可以保证超过10年, 512GB可以超过20年, 请大家放心.”
“重度用户的模型是什么?”,剩余可用空间多大、已写入数据的随机度如何?
“每天写入40G数据的条件下”,写入40G什么数据,是BS=4K的随机零碎文件还是BS=1m的大块顺序文件?这两者造成的WAF以及性能下降完全不一样！完全没有可比的价值！
“256GB的扩容芯片依然可以保证超过10年”,用什么模型推测的,依然可以保证超过10年是按照JEDEC218B进行的测试、还是平均速度明显下滑就算不可用,亦或者是能点亮就算成功?
“要保障最佳的存储体验,需要实现主机文件系统和UFS的深度协同,这在之前FBO焕新存储功能已经体现过,相同的理念,小米在主机端也基于文件管理深度介入了UFS的资源管理,通过软件实现“数据非必要不写入(UFS)”,通过软件+固件实现“写入数据非必要不迁移”,减少写入量的同时也实现了更好的wear-leveling和WAF”
前者是写到DRAM里面,是一个好事,这点值得表扬！
后者是SLC cache释放不积极,在手机这个极小容量、实时回收极差的情况下,用户可能下载几个视频就直接面临slc cache write back惩罚,导致速度的极度下滑.当然,具体的策略是小米来定夺.SLC释放的积极程度是一个无解的难题：正如同股东SLC cache与全盘模拟的争论一样,是一把双刃剑.
在这段中,没有什么毛病,尽管他还是一样没有展示出任何的数据,但最起码没有那么吹牛了.
“为了供应链安全,我们采购了多家存储芯片,虽然小米向供应商share了所有的技术,但有些厂商还没来得及适配, 其实上市前几天还有反对意见,最后是雷总拍板：好技术不要浪费,给大家讲清楚就行,多8G/16G就当是享受技术带来的快乐,没有也是正常的,希望大家理解.
在小米的推动下, 国内外主流存储芯片厂商会陆续适配.”
画大饼环节来了：有些厂商没有来得及适配、会陆续适配,这不就是领导画大病时候的经典再现吗?原厂们谁打算适配、谁打算支持、谁打算跟进,把名字写出来,一起发论文、发展示,不要把这些东西停留在通稿的吹牛上！
“这个技术别的厂商可以用吗?小米已经把标准贡献给了UFS协会组织,为了尊重原创,我们要求芯片厂商做了一点时间保护期, 不久的将来,各大手机厂商应该都会适配这个功能.”
继续画大饼,应该都会适配,说话留余地的艺术来了：我努力一下应该可以上清华,我在未来可能拿到诺贝尔奖,我们组明年不出意外的话应该可以发114514篇SCI.语言的艺术就是如此,他的确没有欺骗你,但和你想的也不一样.
当然,我不认识做UFS那边的朋友,我会通过我的消息来源与关系询问YMTC、Samsung、KIOXIA、solidigm的朋友,看看这个所谓的新技术,是否能在JEDEC上通过.
这些骗骗小白的东西,别把自己骗进去了,没有任何明确的数据、没有任何明确的指向,是不是小米在手机圈这种水平的洼地混久只会发通稿,忘记了到底什么叫做科技公司、半导体厂商应该做些什么?
通稿好发,当然可以请KOL一顿乱吹,毕竟所有的手机厂商都是那么做的：IQOO的独显、华为的GPU tubro、小米的摄影、Sony的拍摄电影感、一加的游戏针对优化.但那些技术、事实不会因为通稿而改变,科学只看论文、只看有公信力的报告和展示,不会相信那些无意义的、充斥着营销和欺骗的通稿.
https:///SUPERNAND (二维码自动识别)
