T33-大容量 SD 卡格式化慢：discard_max_bytes 过小导致 trim 被拆成海量小段

适用场景

        在 T33 系列平台（本例 T33V）使用大容量 SD 卡（如 512G）时，格式化/写前擦除异常缓慢（十几分钟级）。本文适用于排查这类「大容量卡明显比小容量卡慢」的 discard/trim 性能问题。

问题现象

        T33V 设备上 512G SD 卡格式化耗时十几分钟，明显异常。同类小容量卡（32G）正常。

根因分析

        格式化会向块设备下发大范围 discard/trim（例如按 4GB 粒度）。块设备会按队列的 discard_max_bytes（由 max_discard_sectors × 512 导出）把一次大范围请求拆成多段。

本例的关键数值差异：

    • 32G 卡：discard_max_bytes = 10028580864（约 19,587,072 个 512 字节扇区），单次可覆盖大范围。

    • 512G 卡：discard_max_bytes = 11264（约 22 个扇区）。

        512G 卡的 discard_max_bytes 异常地小，导致同一次大范围 trim 被拆成海量小段，系统调用与下层 IO 次数暴涨，整体耗时激增、出现超时。

排查与修复方法

        第一步，确认现象与容量相关。对比不同容量卡的格式化耗时与 cat /sys/block/mmc0/queue/discard_max_bytes 取值。

        第二步，定位 max_discard 的计算来源。本问题源于 max_discard 由 sdhci 的 default 超时时间 + erase 扇区时间计算，对大容量卡得到过小值。

        第三步，改用 SD 卡 erase size 决定 max_discard。使单次 discard 粒度与卡的实际擦除块匹配。

        第四步，校验擦除完成。配合读卡等待超时（接近 6S），确保大范围擦除完整完成。

        第五步，验证。对大容量卡执行格式化，确认耗时恢复正常、无超时。

验证结果

        补丁后可正常格式化 512G 卡，代码已入库，工单关闭。

使用建议

        排查大容量存储卡格式化/trim 慢时，先对比不同容量卡的 discard_max_bytes，关注 max_discard 是否过小导致请求被过度拆分；修复方向是让 discard 粒度与卡的 erase size 匹配，而非简单调大超时。