做UFS开发这几年我发现自己跟同事聊得最多的不是顺序读能跑到多少MB/s而是一个看起来特别基础的话题逻辑单元Logical Unit到底该怎么管。有一次调试主机侧往LUN 0发了一个READ(16)设备直接返回CHECK CONDITION日志里只剩一行看不懂的Sense Key。排查了半天才发现那颗UFS的LUN 0被配置成了Boot LU而我在Query Request里读回来的Unit Descriptor显示它的bBootLunID等于1——这颗芯片根本没有我想象中那种“默认LUN 0就是用户数据区”的布局。这个经历让我意识到UFS逻辑单元管理不是一个“看一遍规范就会”的知识点它牵扯到协议层的地址映射、配置描述符的时序约束、厂商私有实现、甚至是维修工具在读全镜像时对LU寻址的理解差异。这篇东西我会从概念讲到底层配置再穿插实际调试中踩过的坑尽量做到既有体系、又能直接拿来用。1. 逻辑单元不是“分区”是UFS的骨架1.1 从LUN字段讲起为什么不能想当然发命令UFS主机和设备之间是靠UPIUUFS Protocol Information Unit通信的每个命令类UPIU的头部都有一个LUN字段。这个字段只有4个bit理论上能表示0到15一共16个普通LUN地址。很多资料里说UFS支持最多8个LU对应LUN 0到7原因是早期的Device Descriptor里bNumberLU字段能表达的数和实际配置描述符数组长度受到约束JEDEC规范里对配置描述符中的Unit Descriptor数量有明确上限常见实现是8个一些厂商扩展到更多。但问题在于LUN字段不只是普通地址。JEDEC为一些特殊功能定义了Well-Known LUN它们用的是0x01、0xB0、0xC4、0xD0这类高地址。也就是说你在初始化时如果只按LUN 0、1、2这种“顺序思维”去下发命令很容易访问到完全不是你想操作的那个实体。地址类型用途0x00 - 0x07普通LU常规数据LU对应配置描述符里的Unit Descriptor0x01Well-Known LUNReport LUNs用来枚举当前使能的LU列表0xB0Well-Known LUNBoot LU访问引导代码的入口0xC4Well-Known LUNRPMB安全认证区域0xD0Well-Known LUNUFS Device用于设备级控制和状态查询调试的时候最容易犯的错就是把Report LUNs当成一个普通LU去读或者把RPMB的0xC4当成普通分区地址去格式化。轻则命令失败重则把不该碰的认证区写坏。1.2 LU与LUN映射关系设备内部如何找到目标主机侧看到的是LUN设备内部真正干活的是LU。硬件上每个LU有独立的逻辑块寻址空间、独立的写保护属性和独立的坏块管理策略。所谓“独立”不只是概念上的隔离而是Flash Translation LayerFTL里每个LU有自己的一套逻辑到物理映射表一个LU的GC垃圾回收不会直接去回收另一个LU的物理块。设备收到UPIU后会先解析LUN字段然后通过内部的LU索引表找到对应的Unit Descriptor和FTL上下文。这个索引表在设备出厂或配置描述符变更时构建。所以“配置描述符改完后必须复位”不是厂商刁难人而是因为索引表已经实例化不重新初始化就不会按新配置重建。给一个生活化类比UFS芯片像一个小区LU是里面的楼栋LUN是门牌号FTL映射表是每栋楼的住户登记册。你改了好几栋楼的用途但物业的系统不重启刷新管家还是按旧册子找房。这种情况下你命令发得再对设备也不知道你找的是哪一户。2. LU的“户口登记”配置描述符与Provisioning2.1 一个LU的完整“身份信息”需要哪些字段UFS把LU配置放在Configuration Descriptor里具体是其中的Unit Descriptor数组。主机可以通过Query Request去读写这些描述符。我这里挑几个实际开发中最常碰到的字段列一下顺便说清楚它们各自管什么。字段含义实操注意点bLUEnable该LU是否使能置0后该LU不向主机暴露但配置描述符里位置还在bBootLunID指定它是哪个Boot LU只能取0、1、2且要与物理位置匹配否则引导失败bLUWriteProtect写保护等级0不保护1是永久保护2是上电保护3是Set Session后保护dLUNum该Unit Descriptor对应的LUN编号并不是数组下标就一定等于LUN号需要以这个字段为准qLogicalBlockSize逻辑块大小常见512B或4096B修改前必须确认文件系统兼容性qLogicalBlockCount逻辑块总数决定了LU容量改小后可用空间直接缩水bBootLunIDBoot LU优先级多个Boot LU时引导部件按这个ID决定读取顺序配置描述符的结构是“一个配置描述符头 若干个Unit Descriptor”。修改时先要把bConfigDescriptorUpdate置1然后写整段描述符写完以后再发命令让设备复位。这里的坑是有些UFS设备支持在运行状态下直接更新配置并立即生效有些则必须power cycle。你不能把某一颗芯片的“性格”套到所有芯片上量产前一定要把目标厂商的datasheet翻清楚。2.2 为什么改动LU配置后经常不生效我遇到过不止一次“配置明明写进去了重启后就是没变”的情况。排查下来通常是这三个原因之一没有做Device Reset或完整掉电。部分设备只响应软复位你发的是UFS Reset实际上只是链路复位设备固件并没有重新解析配置描述符。修改的字段超出操作权限。例如出厂已经设置了Permanent Write Protection你再改bLUWriteProtect就无效甚至整个配置描述符写入都会被拒。没有先备份原配置描述符。设备对配置有校验和机制如果你改动后长度对不上或某个字段值非法配置会被整体丢弃设备继续跑默认配置。第二种情况尤其常见。厂商为了防止量产后的误操作会把一部分LU的写保护做成永久锁定。你回读描述符时看到bLUWriteProtect是1还想改成0那基本是白费力气。这时正确的思路是把数据写到别的没保护的LU而不是去跟永久保护硬刚。2.3 特殊LUBoot LU、RPMB LU和Well-Known LU的边界普通LU的事好查特殊LU才是翻车重灾区。Boot LU通常是UFS最前面的几个LU之一要通过bBootLunID标记为0、1或2引导代码放在这个LU的前几个block里。需要注意的是Boot LU有一个“Boot Well-Known LUN”的访问入口0xB0也有普通LUN形式比如LUN 0。上电早期主机用Boot Well-Known LUN读取引导镜像加载完再切成普通LUN访问整个LU。如果你把Boot LU配置在很靠后的位置或者没有把bBootLunID设置成有效值那SoC根本找不到引导代码无限重启就是这么来的。RPMB则是另一个极端它独立迷你又安全。地址0xC4访问RPMB时所有读写都要附带MAC校验密钥存在芯片内部OTP区域。主机要先把密钥写入RPMB的Write Counter区域之后每次读写都要用密钥算HMAC才能通过认证。普通LUN管理对它不起作用它不参与容量统计也不会出现在Report LUNs的正常LU列表里。最要命的是它的写计数器只能增加不能减少如果你把RPMB写爆了这颗芯片的RPMB区域基本就废了只能换片。3. 多LU方案设计容量、性能与可靠性的平衡3.1 典型产品里的LU划分实例别看手机上显示一个“内部存储”背后往往是好几个LU在协同工作。一个典型的嵌入式系统可能是这样划分的LU存放内容典型属性为什么这么分LU 0Bootloader、TEE镜像bBootLunID0可启动SoC上电后最先访问独立LU可以单独保护LU 1系统分区、kernel、rootfs只读或半保护系统坏了直接OTA整LU重刷不影响用户数据LU 2用户数据区可读写支持Trim用户频繁写删独立LU避免GC干扰系统区LU 3日志、cache等热数据可精简配置或独立分区写入频率高、生命周期短方便单独回收这样划分的核心逻辑是隔离故障域和隔离GC压力。用户频繁写删造成的碎片和垃圾回收如果和系统分区混在一起最直接的后果就是系统启动变慢、应用随机读写掉速。分LU后每个LU的FTL映射表独立GC只在用户数据LU内发生系统分区的读性能基本不受到干扰。3.2 WriteBooster与LU的绑定门道UFS 3.1以后引入WriteBooster这个特性本质是划出一块SLC缓存来加速写入。但WriteBooster Buffer不是凭空存在的它通常映射到一个专门的LU上或者是某一个LU内部预留的隐藏区域。厂商在配置描述符里会用类似dWriteBoosterBufferType、dWriteBoosterBufferSize这类字段来指定缓冲区的类型和大小再通过设置让它与某个目标LU绑定。很多人以为只要把WriteBooster开关打开写性能就会立刻上去。实际调试中我发现如果绑定的LU没有实际挂载文件系统或者绑定的LU容量太小WriteBooster会被频繁刷写性能增益非常有限。还有一个细节是WriteBooster Buffer在被主机访问到之前要先通过一条专门命令激活。类似地如果缓冲区本身被配置成只读或者分配给它的物理块数量不足控制器会退回普通TLC直写模式这时你读WriteBooster状态寄存器是“已使能”实测速度却很难看。所以真正靠谱的做法是配置完WriteBooster相关字段后跑一轮全盘顺序写和随机写把稳态写入速度拉出来看而不是只看刚开始那几百MB的突发成绩。突发快不代表一切稳态才决定体验。3.3 Thin Provisioning省容量但别踩中隐藏的雷Thin Provisioning精简配置是UFS支持的一种LU类型简单说就是LU声明了一个很大的逻辑容量但物理块是按需分配的。写入时才真正分配物理页删除时通过UNMAP把块释放回FTL资源池。对日志类、缓存类数据这个特性很实用因为很多日志文件写一次就没用了精简配置能让物理空间利用率大幅提升。但坑也很明确。第一如果文件系统不支持discard或没有周期性drop那些“逻辑上删除”的块永远不会触发UNMAP精简池会被耗尽表现出来就是明明LU还剩几十GB逻辑空间写入却直接失败。第二Thin Provisioning的LU在掉电后恢复逻辑比较复杂如果设备固件在崩溃恢复时没有处理好映射关系可能出现逻辑块能读但物理页已经回收的尴尬状态。第三生产环境里不要把Thin Provisioning用于系统关键分区它更适合“丢了不心疼”的数据。我个人的习惯是日志LU可以用Thin Provisioning用户不可再生数据一律用固定容量宁可最开始多预留一点也不冒写穿物理资源池的风险。4. “UFS有没有Trim命令”——从UNMAP到Discard的实现真相4.1 先纠正一个概念UFS是怎么做Trim的很多人从eMMC时代转过来习惯性地问“UFS的TRIM命令是哪个opcode”。严格说UFS协议层没有一个叫“TRIM”的命令它继承了SCSI命令集使用UNMAP命令来实现trim。到了UFS 4.0阶段JEDEC又加入了更专门的Discard特性在FTL里明确标记一个LBA范围的数据为无效让垃圾回收知道哪些页可以直接回收。手机系统层面最常见的触发方式是文件系统周期性执行fstrim。运行fstrim -v /data最终就是往底层块设备发一个discard请求。UFS驱动收到后把它翻译成UNMAP再封装成UPIU发给UFS设备。所以下次有人问“UFS支持Trim吗”答案不是简单“有”或“没有”而是“它走UNMAPUFS 4.0又进一步做成了显式Discard”。4.2 一条fstrim命令的完整旅程我想用一个更直观的方式把整条链路捋一遍用户在命令行执行fstrim -v /dataVFS层遍历指定文件系统的所有空闲块区间文件系统通过blkdev_issue_discard把这些区间打包成block层的discard bioUFS驱动识别到REQ_OP_DISCARD后将bio的LBA和长度转换为UNMAP CDBCDB被塞进UPIU发给UFS设备UFS设备把对应逻辑块标记为可回收状态设备FTL在随后的垃圾回收中优先回收这些物理块全链路看起来很长但数据面并不搬移用户内容只传递“这些块没用了”的元信息所以fstrim执行一般不会太久除非驱动没实现discard或者设备对UNMAP响应异常慢。那为什么Trim对UFS这么重要因为闪存不能原地覆盖。写入新数据前必须先擦除物理块。如果FTL不知道哪些页是“死”的垃圾回收就只能把整块有效页搬走、无效页丢弃。有了TrimFTL能精确识别死页减少搬移量降低写放大同时让空闲块保持在健康水位。提示如果你的产品使用的是UFS 3.1及以下又没有在挂载参数里开启discard也不定期执行fstrim那么删除大量文件之后短时间内随机写入性能下降是非常正常的不是“设备坏了”。4.3 排查Trim不生效的三个方向我自己遇到过“fstrim跑完一点效果都没有”的情况最后是三板斧解决的排查方向具体做法典型原因文件系统查看mount参数是否带discard或者确认有没有定时fstrim服务挂载时没有discard块层根本不会生成discard bio驱动层抓trace看UFS驱动是否处理了REQ_OP_DISCARD并发出UNMAP旧内核或厂商裁剪驱动可能没实现discard转发设备端查询设备是否宣称支持UNMAP响应是否带check condition部分低端UFS芯片的UNMAP实现有bug需要固件修复举个例子某次抓trace发现驱动层确实收到了discard bio但cdb却没发出去。查代码发现厂商把block层请求的discard粒度设成了对齐到erase block size而文件系统传下来的bio sector数不足一个对齐单位直接return 0。这种“假成功”最容易迷惑人看起来操作正常实际上一个UNMAP都没发出。解决方法是把设备max_discard_sectors和discard_granularity暴露给块层让上层能正确合并请求。5. 实践中最容易出问题的LU管理场景5.1 新UFS上电后读出来的容量总是不对经常有人问我标称128GB的UFS上电后Linux只能看到110GB剩下的空间去哪了这不只是GB和GiB的进制换算问题。真正要做的是把每个使能LU的qLogicalBlockCount乘以qLogicalBlockSize把所有LU容量加起来再对比设备宣称的物理容量。两边差别通常来自这几个地方WriteBooster Buffer占用的SLC区域它可能不暴露给主机。厂商保留块用于替换出厂坏块和运行时坏块增长。被bLUEnable0隐藏起来的LU配置描述符里占着位置但不响应访问。RPMB和其他系统保留区域。所以“容量对不上”不必惊慌但在量产测试里要记录下来形成基线。如果你的产品对可用容量有最低要求选型阶段就要把这些隐藏开销算进去而不是光看标称值。5.2 维修场景里“读UFS”的本质直接对话逻辑单元手机维修圈子里经常出现“蛋蛋读UFS”这种工具它能直接读取UFS芯片内的分区镜像用来备份字库、修复变砖手机。抛开工具界面花哨的部分它做的事本质上就是在协议层绕过操作系统直接对UFS的各个逻辑单元发起读请求再按LUN顺序把数据拼成完整镜像。这些工具面对的其实就是逻辑单元管理问题哪个分区落在哪个LU的哪个偏移哪些区域是Boot LU、哪些是用户数据LU、哪些是RPMB。维修人员口中的“全字库”备份通常是把Boot LU和系统LU完整读出其中包含的正是UFS的配置描述符、引导代码、文件系统等多层面的内容。这里必须提醒一句RPMB在维修工具里通常只能读计数器或做有限操作普通接口无法直接读写RPMB数据因为它有独立的认证体系。如果你手里的工具声称能绕过RPMB认证直接读内容要么是针对特定芯片漏洞要么就是唬人。维修操作最怕的就是往RPMB里写了一堆错误数据这个区域一旦故障常规手段难以恢复。5.3 把普通LU硬改成Boot LU的教训有一次我为了省事把用户数据LU直接改成了Boot LU想着“反正bBootLunID设成1就能从它启动”。结果上电后SoC根本没找到引导镜像代码卡死在连接引导阶段。原因不复杂Boot LU不仅在逻辑上要被标记成可引导它的物理摆放位置还有讲究通常必须占用起始几个LU而且引导代码要放在LU的特定偏移处。SoC的Boot ROM只会按固定顺序去探测Boot LU你随便指定一个后面的LU它根本不会去。后来我的做法是Boot LU保持出厂默认绝不到量产后再去动。如果非要在新设计里自研分区布局也要先确认SoC的Boot ROM支持从哪个LUN引导、对Boot LU有什么约束再让UFS厂商配合把配置描述符一次性生成好尽量避免通过软件在量产阶段去改。还有一点值得强调在生产测试过程中修改配置描述符务必保留一份出厂时的完整配置描述符镜像。一旦后续操作把配置搞坏可以用烧录器或厂商工具把原配置刷回去。我见过有人把整颗芯片的配置描述符清零后没有备份结果只能回炉重写文件系统数据和引导代码全丢代价非常大。如果让我总结一条最宝贵的经验就是拿到一颗UFS芯片第一件事不是跑benchmark而是把Device Descriptor和Configuration Descriptor完整读一遍存档留底。每次改动配置之前先备份改完以后不要急着复位回读验证一遍字段没问题再进行power cycle。这套习惯救过我很多次比任何调试技巧都实在。