小米14存储扩容功能探讨

看了小米发布会雷总发布的重大发现，UFS存储器256GB可以多出来8GB，变成256GB+8GB，一时搞不明白这个减少UFS器件内部保留空间的优化为什么会和小米有关。难道是小米的工程师和UFS厂家一起优化了UFS的Firmware，采用了更先进的算法？不过UFS厂家对Firmware的保密程度历来都是非常高的，轻易是不会让终端厂商染指的。正在百思不得其解的时候，小米的官方声明来了，还有一些网上的文章把这个问题给解释清楚了。

简单来说，小米的UltraSpace 存储扩容应该是这样的实现的

UFS必须使用支持FBO的器件，FBO是UFS 4.0的标准，这是硬件基础

小米在Host端的UFS驱动里面实现了FBO特性的支持

小米宣称还实现了"数据非必要不写入UFS"（不过现在Linux不就是这样吗？不过小米既然宣称，估计也应该是做了一点改进）

小米宣称还实现了在固件配合下"写入数据非必要不迁移"（应该还是FBO的功能，在平时不做整理，由host主动发起整理，可以减少一些写放大）

更详细信息可以参考如下文献包含了小米的官方声明

小米 14 手机额外 8GB 存储扩容:老机型不支持，后续向友商开放 - IT之家

FBO作为UFS 4.0的一个扩展协议，概括下来就是：主机和设备一起配合，把文件数据从“物理不连续”转换成“物理连续”，以提升文件数据的读取性能。

具体来说，系统空闲的时候（比如夜深人静的时候），主机把需要性能优化的某个（或某些）文件的LBA信息告诉存储设备，让存储设备去检查这些LBA在闪存块上是否连续。设备会查询这些LBA的映射关系，通过这些LBA在闪存上的物理地址，来分析该文件在闪存空间上是否物理连续，以及不连续的程度（物理碎片化程度），然后把这些信息返回给主机。主机根据设备反馈信息，来指示存储设备下一步动作：如果该文件在闪存空间上很分散，就要叫存储设备把这些不连续的数据块都搬到连续的地方去。在设备接到指示后，便会执行数据的整理：将不连续的数据集中写到新的连续闪存块位置。FBO通过主机和设备的这种协作，就能够解决文件数据在存储空间的“碎片化”问题，从而改善文件的读取性能。

FBO把文件数据从物理不连续整理成物理连续

简单一句话，FBO旨在解决文件物理碎片化问题，即让逻辑地址连续的区域保证物理上也连续，这个过程需要Host和Device配合一起完成。

更详细的解释请参考如下文献

深度解读UFS 4.0的FBO特性 | 电子创新元件网

当小米和西数把FBO的特性和Patch提交到Linux社区后，社区的维护者Christoph Hellwig直接拒绝了这个patch，认为FBO这个功能考虑不周，因为文件是一个逻辑概念，文件在磁盘上的存储位置是经常变化的（因为有碎片整理，垃圾回收等操作）。下面是原文

详细信息可以参考如下文献

UFS File-Based Optimization Patches For Linux: Shot Down As "Complete & Utter Madness"

为了证实这个信息，我查看了Linux的最新代码，至少在6.6版本上面没有包含FBO相关的Patch。

以下是我个人的几点理解，仅供参考，如有不同意见欢迎探讨。

从FBO本身的功能没有看出和雷总所说的减少预留空间的必然联系，至少不是强相关。一种可能的原因是UFS平时不做或者少做整理，而等Host发送FBO的命令对指定区域做整理，这样就可以减少预留的空间了。但是这样是否就意味着一款支持FBO功能的UFS，在Host支持FBO功能之后提升了UFS性能，达到或者超过原来包含预留空间的效果，在Host不使能FBO功能时，UFS器件的性能就要比原来正常的差呢？

FBO的作用是让逻辑地址连续的区域物理地址连续，这个过程还需要Host参与，并且还有点复杂。不过UFS对外部而言只有逻辑地址，那么保证逻辑连续的区域的物理地址连续不是UFS的FW本来就应该保证的吗？为什么还一定要让Host给指定区域呢？现在的文件系统挂载都会有Discard选项，也就是说UFS和Host都知道那个逻辑地址上面有数据，哪个地址是空闲的。即使有一些碎片，在做GC和WL的时候也可以一起整理了，就像江波龙所提的Smart GC技术一样。如果UFS不知道在什么时间整理合适，倒是可以让Host主动发送一个整理命令就可以了。

如果有人说FBO可以指定更长的逻辑连续区域这样可以取得更好的性能，我认为UFS的固件也许可以默认就实现这样的特性，例如可以保证每个小块的逻辑连续区域的物理连续，比如做到每个16MB或32MB对齐的逻辑地址连续区域对应的物理地址连续，这样就不需要Host做更复杂的干预了，最终的性能差异也不会太大。

UFS对外提供逻辑地址，把垃圾整理和写平衡等FTL层的操作都在内部实现，这是很好的封装，让Host的实现变得简单了很多。FBO则让Host又要关心器件内部的状态，这就又提升了系统的复杂性，这就出现了一个平衡问题，究竟FBO能带来多大的收益？是否值得？因为没有看到量化数据也不好做进一步的评论。不过目前Linux社区的态度可能也是一个参考。

综上从技术角度来看，FBO特性的采用需要UFS器件的支持和Host软件的支持，Linux社区对此功能还有一些争议，目前FBO patch没有合入主线，另外还需要有量化数据来支撑FBO优化效果。

坚决支持雷总和小米公司以及其他中国公司积极参与到国际标准的制定当中。这次小米和西数一起开发FBO特性的意义已经超过了FBO技术本身带来的价值。

从技术角度如何看待小米发布会上提出的“256GB+8GB”存储创新技术? - 知乎

mp.weixin.qq.com"独家揭秘｜小米14魔改存储芯片多出8GB空间背后的秘诀"

小米 14 手机额外 8GB 存储扩容:老机型不支持，后续向友商开放 - IT之家

UFS File-Based Optimization Patches For Linux: Shot Down As "Complete & Utter Madness"

深度解读UFS 4.0的FBO特性 | 电子创新元件网