用声明式 I/O 突破 I/O 墙（OSDI 2026）

原题：Scaling the IO wall with Declarative IO

一句话总结：维护任务在六家超大规模服务商中占缓存后 HDD I/O 的 45%–70%，且跨任务数据复用常相隔数天；DINGO 让任务声明数据候选集合与截止时间，再集中安排读取和缓存，将 HDFS 原型的维护读取字节数减少 26%，并在限定维护带宽的仿真中把可支持盘容量从 36 TB 提高到 64 TB。

问题与动机

HDD 容量持续增长，寻道时间和传输带宽却没有同比改善。对存储集群而言，每 TB 可获得的 I/O 供给不断下降。即使数据变冷，完整性巡检（scrubbing）、故障重建、垃圾回收和冗余编码转换仍需读取数据，其工作量往往随存储容量增长。论文将容量还够、I/O 却已不足以完成维护的限制称为 I/O 墙。

扩大 SSD 缓存难以消除这一限制。前台热点请求较容易被缓存吸收，维护任务则常扫描大量低复用数据。作者结合六家服务商的交流和工作负载分析，得到维护任务占缓存后磁盘 I/O 的 45%–70% 这一范围；其中未识别出的上层维护还被归入应用 I/O，因此这些估计对各服务商是下界，而非统一采集口径下的精确总体比例（§3.2）。

任务之间其实会读取相同数据：巡检覆盖所有块，容量均衡也可以选择这些块搬迁。难点在于各任务由不同团队和软件层独立实现，读取时间可能相隔数天。DINGO 提供声明式 I/O（Declarative IO），用接口暴露任务可以延迟、重排和择取数据的余地，使存储层能够集中形成短时间内的复用。

关键观察 / 隐含假设

观察 1：长期复用存在，但靠保留缓存捕获它代价太大。 Google 轨迹中，24 小时观察窗口内约 24% 的缓存后读取重复，7 天窗口内约 42%；按 4 KB 块计算的 LRU 复用距离，要捕获一个 24 小时窗口的全部复用，1 EB 集群至少需增加 66.5 PB 缓存（§3.3、图 7）。
- 依赖假设：重复读取所属任务能把相关数据访问移动到相近时间。轨迹中的重复比例本身并不能证明这些请求都允许延后。
- 可能失效场景：重叠数据少、截止时间短，或跨层数据映射无法稳定关联到相同块。
观察 2：维护需求不能简单被更大的盘容量摊薄。 对服务商 B 的分析估计，每增加 1 TB HDD 容量，维护额外消耗约 0.9% 的磁盘时间（§3.3）。
- 依赖假设：巡检周期、故障率、编码策略和容量利用率处于相似范围。
- 可能失效场景：盘型、冗余策略或任务频率改变；该斜率不应直接推广为所有存储系统的硬件定律。
假设 1：延迟读取不破坏任务语义。 接口仅操作追加写系统中已封存、不可修改的块；声明之后的新增块不属于原声明，删除和权限变化由任务在实际读取时处理（§4.4）。这是正确性的适用条件，不是对任意可变文件系统的保证。
假设 2：收到回调的任务可以及时获得计算资源并读取。 缓存节省依赖多个任务在同一派发窗口消费数据。作者估计维护计算需求通常较低，但没有大规模计算资源争用实验；回调迟到虽不必导致错误，却可能导致缓存失效和重复读取。

核心方法

用声明表达三类自由度。 declare(read_sets, sets_needed, deadline, callback) 接收若干 BlockSet。每个 BlockSet 是任务需要一起取得的一组块，例如一个纠删码条带。集合之间可重排；截止时间表达可延后多久；sets_needed 允许系统只挑选所需数量的集合。例如容量均衡可以声明所有可搬迁块，再要求从中选择足够数量，而不预先指定具体搬哪些块（§4.1–4.3、图 8–10）。

回调给出读取时机，数据仍走原接口。 IO Planner 是保存声明、安排读取并派发回调的规划器。回调只携带选定的集合，不携带数据；维护任务收到回调后重新获取必要元数据，再执行原有命令式读取。权限检查、租约和读错误处理因此沿用现有路径。文件声明在提交时翻译成块集合，形成声明时刻的块列表，而非持续追踪后续追加的内容（§4.4、图 12）。

先按完成速率推进，再利用重叠节省 I/O。 最优复用调度是 NP-hard，DINGO 使用启发式。每个调度周期计算各声明为按期完成所需的读取速率，按速率从高到低安排工作，直到耗尽周期 I/O 配额。已安排过的块不重复计入物理读取；在一个声明内部，优先选择含有更多已安排块的集合。全部由这些块组成的集合也可以加入。若满足各声明速率后仍有配额，默认不提前消耗，以保留未来与新声明重叠的机会（§5.1、图 13）。

将长周期规划与短周期派发分开。 若要求一个调度周期内的复用数据全部留在缓存，周期越长，缓存越大；但频繁扫描全部声明又会增加规划成本。DINGO 把已调度集合分成较小的重叠组，分批调用回调。派发器按纠删码组维护访问索引，缩小重叠搜索范围；论文将其复杂度从朴素的已调度集合数平方降至线性，这依赖每组相关集合数量受控（§5.2）。

显式保留短期复用数据。 规划器发送缓存指令，要求被指定的块在读入后进入专用缓存区，并保留一个派发轮次，避免被普通淘汰策略过早驱逐或误判为长期热点。以维护速率 2 MB/s/TB、两分钟消费延迟估算，即使没有重叠也只需 240 MB/TB，即 1 EB 集群约 240 TB 专用缓存。该数值是基于速率和消费延迟的容量估算，不是生产集群实测上界（§5.2）。

设计取舍

接口改造换取跨层协调。 维护任务需要从自行迭代读取改为声明加回调，并处理新块、删除块和元数据变化。简单把每次原有读取包成小声明，无法暴露足够的时间和顺序自由度。
截止时间优先于最大复用。 速率启发式便于动态运行，但不是所有负载下都可满足截止时间的可行性证明。过载时回调携带 overloaded=true，任务可以回退到命令式读取。
读取优化没有覆盖整个资源链。 转码等任务仍会写盘、占用 CPU 和网络。读配额平稳不代表总磁盘负载平稳；原型已经出现集中转码写入推高前台延迟的情况。
集中规划减少独立限速的不协调，也增加控制面责任。 声明状态、派发进度、缓存指令需要协同；论文没有给出规划器故障恢复和多租户配额隔离的完整实现与验证。

实验与结果

原型主结果：维护读取减少 26%。 10 个 HDFS 节点，每节点 64 核、128 GB RAM、一个 3 TB HDD，限制每盘可用内存为 10 GB；初始容量使用率 80%。重建、巡检、均衡和转码四类任务按 24 TB 到 3 TB 的比例同时缩短时间与规模，运行 81 小时。相对仅增加转码支持的 HDFS 基线，DINGO 每个逻辑字节只需 0.74 个磁盘读取字节；规划预测节省 28%，实际节省 26%（§6.1–6.2、表 1、图 14）。
前台延迟平均改善，但并非每段时间都改善。 加入基于 Alibaba 块存储轨迹、贡献约 30% 磁盘读取 I/O 的前台负载后，平均客户端吞吐为 6.82 MB/s，基线为 6.36 MB/s。逐分钟统计的客户端 P50 读延迟指标平均为 86 ms 对 167 ms，P99 指标平均为 832 ms 对 1181 ms；这些不是整段请求合并后的单一分位数。部分窗口中 DINGO 因集中转码写入而更慢（§6.2、图 15）。
大盘支持来自仿真推算。 100 PB 集群、30 天、80% 容量利用率，使用 256 MB 块、三副本及两类纠删码，模拟八类维护任务。维护读取需求为 2 MB/s/TB、只允许使用一半磁盘带宽时，集群 A 可支持盘容量从 36 TB 增至 64 TB，集群 B 增至 58 TB；前者约为 1.7 倍。这不是 64 TB 实盘测试（§6.1–6.2、表 2、图 16）。
节省来源包括复用和消除已删除数据的工作。 模拟中数据选择灵活的均衡任务可以完全搭载其他任务的读取；巡检声明中约 26% 的读取因目标块后来删除而消失。不能将全部收益都归为缓存命中（§6.3、图 17）。
敏感性显示任务组合和期限影响收益。 在维护需求 1–3.5 MB/s/TB 的模拟范围内，集群 A 的维护磁盘磁头时间减少 39%–51%，B 减少 28%–46%。转码截止时间从 1 天放宽到 7 天时，作者报告集群磁盘利用率降低 7%；图 20b 显示利用率约从 37% 降到 34%，此处应理解为相对降幅，非 7 个百分点（§6.4、图 18、20）。
规划器扩展性是单机控制面测量。 对 1 EB、维护读取需求 2 MB/s/TB 的模拟状态，一台 240 GB RAM 的 Dell R640 在少于 15 分钟内找出一小时调度周期的全部派发组，峰值内存 205 GB。两类 100 PB 负载中的 I/O 距忽略截止时间和周期配额、已知全部未来声明的理论下界不足 5%；这只说明这些任务组合存在充足可用重叠（§6.2）。

论断—证据表

论断	证据	评测边界	置信度
维护 I/O 已是 HDD 负载的主要组成部分	§3.2、图 4–6：六家服务商范围为 45%–70%，三家给出任务分解	不同层级、时间窗口与统计口径；未识别维护仍计为应用	中至强
声明与集中协调能实际减少维护读取	§6.2、图 14：HDFS 每逻辑字节读取 0.74 字节，减少 26%	10 节点、四类任务、81 小时缩放实验	强
读取节省可使更大容量 HDD 在给定配额内可用	§6.2、图 16：36 TB 提高到 64/58 TB	100 PB 模拟，维护需求 2 MB/s/TB，占一半带宽预算	中
选择数据、等待数据删除也贡献收益	§6.3、图 17：均衡读取可全部复用，26% 巡检读取因删除而取消	选定任务频率、期限和数据生命周期；未做完整正交消融	中
集中规划在 EB 级状态上可运行	§6.2：205 GB 峰值内存，少于 15 分钟处理一小时派发组	单机模拟状态测量，不含生产控制面可用性验证	中

批判性分析

论证链条

生产工作负载解释了为何优化维护 I/O 值得投入，长期重复读取说明有可争取的空间，接口与原型则证明可以把部分长期复用转为短期缓存命中。这条链条成立，但每一步的证据来自不同环境：六家服务商的负载分解、Google 轨迹、HDFS 小集群和大规模仿真不能视为同一生产系统的端到端部署结果。

36 TB 的 I/O 墙和 64 TB 的突破位置由带宽预算、任务频率与设备模型共同决定。论文证明的是在这些条件下减少维护读需求可放宽容量限制，未证明存在适用于所有集群的固定容量门槛。

假设压力测试

按天放宽期限提高复用，但可能延迟发现潜在损坏、回收垃圾或降低冗余存储开销。表 2 中重建期限为 36 小时，巡检为 30 天，垃圾回收和转码为 5 天；不同系统是否接受这些期限，需要按各自可靠性和容量 SLO 判断。论文没有把节省量换算成数据丢失风险或垃圾积压分布。

相关磁盘故障需要紧急重建时，作者明确建议直接使用命令式请求。若集群容量规划已经依赖声明式复用，紧急回退会减少复用、抬高磁盘负载，并可能进一步造成截止时间失约。论文承认这一亚稳态故障风险，但没有用故障注入证明系统能稳定退出该状态。

实验可信度

原型测量覆盖真实磁盘与前台延迟，仿真也用相应 HDFS 场景校验，作者报告节省误差在 5% 以内。这支持模型在该配置附近的解释力。主基线却没有统一的维护限速器，因而前台延迟改善同时包含集中限速和读取复用的效果；不能只归因于声明式接口。

仿真列出了八类任务和期限，并提供需求、期限及供给变化的敏感性实验，但未全面隔离数据选择、回调省略、缓存指令和速率启发式的独立贡献。接近理论下界也不等于通用近似保证：该下界甚至不要求遵守截止时间。公开原型与模拟器有利于复现，生产规模收益仍需在线测量。

系统性缺陷

已观察到的缺陷是读调度可能把后续写入集中起来，使短时前台 P50 变差。潜在部署风险还包括回调计算资源不足、规划器宕机后的声明重放、重复回调的幂等处理，以及不受信任任务提交过大候选集合造成的状态膨胀。除计算资源不足的语义讨论外，这些风险没有对应的完整实验。

不可变块与沿用命令式读取简化了数据一致性，但任务仍需承担元数据刷新、删除处理和新增数据再声明的责任。因此接口兼容原有读语义，并不意味着迁移任务不需要重新审计其完成条件。

局限与后续工作

多资源调度：把读、写、CPU 和网络开销同时纳入配额，在相同前台负载下比较最差一分钟 P99、截止时间违约率和物理读写总量，检查能否消除转码写突发。
故障与回退稳定性：注入关联盘故障、规划器重启、缓存容量下降和回调延迟，记录复用率下降后的积压增长与恢复时间，确定维持稳定所需的备用 I/O 配额。
语义与收益的正交消融：分别关闭数据选择、删除回调省略、显式缓存保留和集中限速，保持任务工作量不变，区分读取节省与前台延迟收益的来源。
可靠性约束下的期限选择：联合改变巡检与重建期限，测量潜在损坏发现延迟、重建积压和 I/O 节省，避免只以带宽收益选择宽松期限。
大规模在线验证：在现有追加写集群中先对声明进行影子规划，再逐步迁移维护任务；比较预测与实际复用、控制面内存、迟到回调比例及每盘负载偏斜，验证单机规划结果能否推广到生产部署。

Awesome System Papers Wiki

探索

paper-osdi26-athlur