进程把字节写进文件，只是存储工作的起点。字节可能先停在内存中，稍后才排队进入设备；命令已经返回，也不等于突然断电后还能读到它。本课从 Linux 的文件接口出发，把应用、文件系统、缓存、块层和设备串成可观察的路径。目标不是记住内核函数，而是能回答：时间花在哪里，数据承诺到哪一步，下一条命令应该采什么证据。
1 存储栈深入要打通哪几层
设想运维脚本定期收集进程状态，把结果追加到本地日志。白天运行正常，夜间备份启动后，脚本偶尔要等很久才能结束。此时只看日志所在目录，很容易把问题归给文件系统；只看磁盘型号，又容易把问题归给硬件。真正需要解释的是：脚本发起了什么操作，操作经过哪些等待点，哪个等待点在备份期间发生了变化。路径是定位框架，不是责任名单。
从进程看，常见入口有 open()、read()、write()、fsync() 和 close()。它们表达打开、读取、写入、同步、关闭等请求。系统调用返回值首先说明接口完成了多少工作；例如 write() 可能只写入部分字节，也可能因为空间不足返回错误。应用必须检查返回值。即使所有字节都已被接受，持久性仍要根据接口语义、文件系统和设备行为继续判断。
向下看，VFS 提供共同的文件接口，具体文件系统负责文件内容、目录、空间分配等组织工作，页缓存保存文件数据的内存副本，块层把需要访问块设备的工作组织为请求，设备执行读写。这个图只画常见的本地块存储路径。远程文件系统、特殊设备文件和某些直接访问方式会走不同路径，不能看到文件描述符就断言下面有同样的磁盘队列。
排查前先确定路径。findmnt -T /var/log 可以查看某个路径归属的挂载点、来源和文件系统类型；lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS 可以辅助理解块设备关系。在某些旧版工具中，需要把最后的列名换成 MOUNTPOINT。如果来源是网络挂载，应补充远端证据；如果下面存在逻辑卷、加密或软件阵列，就要记录映射关系，不能把最上层设备名当作物理介质。
再确定任务边界：哪个进程、哪个目录、什么时间、什么操作慢。把“存储卡顿”改写为“备份启动后的 30 秒内，采集进程的日志同步耗时升高”，才有可检验的对象。还要区分返回慢和数据不可靠：前者关注等待，后者关注持久性承诺；同样的缓存配置可能改善前者却改变后者。观察指标必须服务于具体问题。
本课把延迟理解为沿途各阶段等待和执行时间的组合。缓存命中可能让操作根本不访问设备，写回可能在原进程返回后才发生，多个相邻写入也可能在下面合并。所以不能把应用的每次调用与设备的每条请求直接配对。先明确观察的层，再谈次数、字节和时间，这是打通存储栈的基本方法。
2 VFS、页缓存与块层
VFS 可以理解为文件操作的共同入口：进程使用路径和文件描述符表达需求，具体文件系统再处理自己的组织方式。相同的 read() 接口可以读取不同文件系统上的文件，但相同接口不保证相同耗时。路径查找、权限检查、数据是否在缓存、是否需要读取元数据，都会影响实际工作。权限错误与设备读写慢属于不同问题，不能混在同样的“打开失败”描述里。
普通文件的缓冲读取通常先查看页缓存。需要的数据已经在内存中，就能减少设备读取；没有命中时，内核才需要取得相应数据，并可能预读后续内容。于是连续读取 1 个文件的第 2 次运行往往更快，但这不证明设备变快了。文件规模、可用内存、其他进程和运行顺序都会影响缓存状态。报告读取性能时，要说明是否重复读取以及缓存条件如何形成。
普通缓冲写入通常先把数据复制到页缓存，并把相关页面标记为脏页。这里的“脏”表示内存内容有更新，尚需写回到后面的存储。内核会根据时间、内存压力和脏数据量安排写回；应用也可以主动要求同步。写回期间，产生脏数据的进程与提交设备请求的执行上下文可能不同，因此“哪个进程写得多”和“此刻谁在提交请求”并非完全相同的问题。
write() 成功通常表示数据已按该调用的语义被接受，不能单凭它证明掉电安全。close() 也不是替代 fsync() 的持久性接口。fsync(fd) 请求同步该文件的数据及相关元数据，并等待相应过程完成，但应用仍须检查错误。创建新文件或通过重命名发布文件时，目录项是否持久化又涉及目录同步及具体文件系统语义，不能只同步文件内容就概括为所有更新都安全。
文件系统向下提交工作后，块层处理面向块设备的请求。这里的粒度未必等于应用缓冲区大小：请求可能被拆分或合并，文件数据写入也可能伴随元数据更新。应用写入 4 KiB，不意味着设备只收到 4 KiB 的全部工作；反过来，重复改写同一缓存页也可能减少最终写回次数。比较不同层的字节量时，要先说明它们分别统计什么。
O_DIRECT 提供另一类访问方式，通常减少文件数据经过页缓存的过程，但会带来对齐和文件系统支持等约束。它不等于自动同步，也不等于永远更快。入门阶段先掌握缓冲写、写回和同步的边界，再按实际应用接口分析。不要为了让测试“更真实”而随意切换模式，否则测试结果可能已经换成另一种工作负载。
用交互逐步观察时，应特别留意返回标记：缓冲写可以在设备写入前返回，同步请求则要等待相应的同步过程。图中每个方块只是逻辑阶段，并非固定的内核线程或严格串行的流水线。真实系统会并发处理不同请求，但这种简化足以解释为什么应用时间线与设备时间线看起来不同。
3 多队列与 I/O 调度边界
现代主机通常有多个 CPU，设备也可能支持同时处理多个请求。如果所有提交都挤在同样的入口，协调本身就可能成为额外负担。Linux 的多队列块层让请求提交和设备队列更好地衔接。这里先保留直觉：它改善并发组织方式，不会让介质响应时间消失，也不会使任何负载都随着队列数增加而加速。进一步的内部映射留到需要分析内核实现时再学。
队列深度表示某个观察范围内尚未完成的请求数量。必须同时写出范围：应用允许的并发数、块层排队数量和设备内部未完成数量不是同样的数。应用只有 1 个同步请求在等待时，增加设备队列上限可能毫无帮助；应用已经产生大量并发请求时，继续加深队列也可能只增加等待。设备规格中的最大能力不等于当前任务应该设置的参数。
吞吐量、IOPS 和延迟描述不同侧面。吞吐量表示单位时间搬运的字节，IOPS 表示单位时间完成的操作数量，延迟表示操作耗时。顺序的大块读取可以有较高吞吐量，零散的小块同步写可能在较低吞吐量下仍让应用明显变慢。比较报告至少应注明请求大小、读写比例、访问方式、并发和同步方式，不能只把最大的数字排在最前面。
I/O 调度器在块层的职责包括组织待处理请求，并在适用时对不同请求的服务顺序施加影响。不同内核、设备类型和运行环境提供的选择可能不同。可以用 cat /sys/block/vdb/queue/scheduler 查看示例设备的候选项及当前选择，实际设备名应来自前面的映射；输出中方括号通常表示当前项。该命令只是只读观察，不应照抄示例设备名去修改生产配置。
调度器的作用有边界：它不知道应用全部业务含义，也不能消除设备内部回收、远端存储或上层锁竞争造成的等待。如果应用在到达块层之前就因内存压力停住，调整块层顺序未必触及问题。若设备已经饱和，改变服务顺序可能改善某类请求的尾部延迟，同时让另一类请求等待更久。方案必须写清楚受益对象与代价承担者。
可以用稳定流量下的近似关系帮助建立直觉：平均在途请求数约等于完成速率乘以平均延迟。如果设备每秒完成 1000 个请求，平均延迟是 0.004 秒，平均在途数量约为 4。这里要求观察范围一致，而且使用平均值；不能把应用的 P99 延迟与设备 IOPS 相乘，再宣称得到了真实队列深度。这个关系用于检查数量级，不用于替代实测。
队列的实用原则是先找到能满足吞吐目标的并发范围，再看延迟是否仍在预算内。到达平台期以后，更多排队往往只延长等待。短时突发也可能被平均值掩盖，因此除了平均指标，还应查看业务延迟分布和按时间变化的曲线。不要只根据某个瞬间的队列值宣布系统健康或故障。
4 动手：用 blktrace/iotop 定位一层
本节选择“日志同步变慢”作为观察对象，只做有界采样，不向原始块设备写测试数据。先记录采样时间、主机、进程 PID、日志路径和挂载来源。确认工具可用以及账号具有对应观测权限；生产环境缺少权限时应走既有运维流程，不能为了观察而关闭访问控制。跟踪会带来开销，采样应尽量短，并把结果写到有容量余量的位置。
先用低成本视图确认现象。例如执行 iostat -xz 1 10，查看连续 10 轮的设备指标；常见实现的第 1 轮是开机以来的累计平均，应与后续区间区分。await 常反映该统计范围内请求从进入到完成的平均耗时，包含排队影响；它不是纯介质服务时间。%util 在并行设备上也不能单独证明剩余能力已经为 0。
接着用 sudo iotop -o -P -b -d 1 -n 10 采集有 I/O 活动的进程视图。不同版本的选项和可见字段可能不同，先按本机帮助调整。它可以帮助找到活动进程，但页缓存写回、内核记账方式和权限都会影响显示。某个进程当时显示的写入量较低，不能证明它之前没有产生大量脏数据；显示等待占比高，也还没有说明具体是哪类设备请求造成的。
需要更细的块层事件时，再使用 blktrace。假设已确认目标设备是 /dev/vdb，可以执行 sudo blktrace -d /dev/vdb -w 10 -o /tmp/s47-vdb。它记录短窗口内的请求事件，输出可能分成多个文件，前缀为 /tmp/s47-vdb。采样前需确认该前缀没有已有结果，并估计输出容量；高负载下，短窗口也可能产生较多记录。这里的设备名称仅为示例。
采集结束后，用 blkparse -i /tmp/s47-vdb 解析该前缀对应的记录。事件可帮助区分排队、下发、完成等阶段，但输出中的每行不是独立应用调用。请求可能合并、拆分或重新排队，不能把屏幕上相邻 2 行直接相减就称为设备延迟。先查看本机事件定义，再用能够正确关联请求的分析方式解释时间；本课不要求手工实现完整的请求关联器。
把时间窗对齐后再提出判断。如果应用同步变慢、块层请求下发到完成的区间也拉长，可以继续检查设备及其下方路径；如果应用慢但目标设备几乎没有对应活动，应回头检查是否采错设备、调用是否仍停留在上层、数据是否命中缓存。没有事件本身并不能证明没有存储问题，证据必须带上采样范围和工具可见性的限制。
最终记录应包含现象、命令、时间窗、设备映射和下一步。例如“同步延迟升高与备份写入重叠，目标设备平均等待同步升高，当前支持共享设备竞争假设，尚不能区分内部处理与下层等待”。这样的结论虽然保留未知，却能指导下一轮行动。比起截取 1 行最难看的数字，它更容易由其他值班人员复核。
5 缓存收益与一致性取舍
缓存的直接收益是避免重复读取、吸收短时写入，并把部分零散更新整理后再下发。对重复扫描的监控程序，页缓存可能显著减少设备工作；对突发日志，缓冲写可以缩短日常返回时间。但缓存占用内存，脏数据需要最终写回，突发持续太久时还可能引起回写压力和应用等待。收益不是免费的，也不能把短时间吸收流量误认为长期能力提高。
讨论一致性时，应把 3 个问题拆开：当前进程何时看到写入，其他读取者何时看到更新，崩溃后哪些更新仍然存在。本课重点是最后的持久性边界。数据已经对另一个读取者可见，仍可能只存在内存中；应用成功返回、文件系统恢复后目录能打开，也都不足以证明最新内容完整。可见性、文件系统结构可恢复、应用内容符合预期，需要分别验证。
可以把同步频率看作性能和持久性目标之间的可调条件。每次记录后都等待同步，通常增加等待次数；积累多条再同步，可能改善吞吐，但两次成功同步之间的数据面临更大的未确认窗口。这个窗口应从应用协议解释：在同步前就向调用者宣称“已持久保存”，还是先保留未完成状态，决定了故障时是否违背外部承诺。
交互用均匀写入与固定同步开销建立数量级直觉。它展示的是策略造成的同步次数和潜在未同步数据范围，不是生产设备预测器。真实系统会受写回、请求合并、同步实现和设备缓存影响；周期到期也不代表同步瞬间完成。如果同步本身变慢，尚未完成的数据窗口可能超过设置周期，因此承诺应落在“最近成功完成的同步”上。
除了主机页缓存，设备或外部存储也可能有写缓存。同步请求通常需要借助存储栈提供的刷新或等效持久化机制，才能落实承诺。文件系统提交了要求，不代表不符合要求的设备一定正确执行。具备掉电保护的缓存与依赖供电的易失缓存行为不同，不能仅凭“有缓存”判断风险；应查看实际接口保证和经过验证的运行条件。
另一个常见误区是“定时执行全局同步就能替代应用设计”。全局同步可能引入广泛 I/O，也难以对应某条记录的确认时刻。应用仍应在需要的接口位置检查同步结果，并处理错误。对于只作缓存、能够重新生成的数据，可以容许较长恢复窗口；对于必须保存的操作记录，应由需求明确确认规则。策略应该按数据价值和恢复目标选择。
先确定允许丢失什么，再选择何时确认和同步，最后测试成本。不要把平均写入变快作为降低持久性保证的唯一理由。若需要调整写缓存或挂载选项，应先在隔离环境验证，并明确恢复方法；复杂的日志机制和存储内部协议暂不展开，本课只要求识别保证经过哪些边界，以及哪个边界还缺证据。
6 常见坑：把设备延迟全怪文件系统
“换文件系统就能解决”常常是缺少分层证据时的直觉。相同的设备延迟可能来自上层同时写入过多、块层排队、设备内部处理、虚拟化后的共享资源或远端路径。反过来，应用等待也可能发生在文件路径查找、锁、内存回收或同步阶段。文件系统当然可能影响表现，但需要用工作负载与观测证据指出具体关联，而不是从目录位置直接跳到责任归属。
另一个坑是拿应用写入速率与设备吞吐量简单相减。应用可能更新同一片缓存很多次，设备可能还在写先前积累的脏页，文件系统还可能提交额外元数据。它们的时间窗口和统计对象都不同。若监控看到应用写入下降、设备仍忙，应先观察是否在清理积压，而不是立即认为存在未知进程偷写。把窗口拉齐，并解释缓存状态，差异才有意义。
还有“吞吐量低就说明设备空闲”的误解。大量小块随机访问或频繁同步可能让每次操作都较慢，却没有搬运很多字节。此时需要联合看请求大小、IOPS、延迟与并发。相反，顺序备份可能传输很多数据，却仍能给低延迟任务留下足够能力。是否构成干扰，最终要看目标任务在相同时间窗内的指标变化，不能只按数据量大小排序。
缓存测试也很容易得出相反结论。第 1 次读文件需要访问设备，第 2 次可能主要读内存；把后者作为设备读取能力，会夸大结果。为了制造冷缓存，在共享主机上随意清理系统缓存又会影响其他进程，并改变原本要观察的环境。更合适的做法是在隔离环境建立可说明的初始条件，或明确把结果标为重复读取场景，避免把实验条件藏起来。
多层设备映射会制造另一个错觉。应用使用逻辑卷时，上层设备与下层设备都可能出现统计，同样的工作不能直接相加为总吞吐。采集了错误的底层设备，也可能错过真正承载该目录的流量。容器中的路径和宿主机上的挂载关系还可能不同。排查记录必须保留路径到挂载源、再到相关块设备的映射，并注明观察视角。
工具输出中的平均值也不是事故全貌。短暂的同步长尾可能显著影响脚本结束时间，却被 1 分钟的均值冲淡。应先取得应用自己的慢操作时间戳，再对齐更短窗口的设备指标；如果只有平均数据，就明确不能据此排除短时异常。不要为补齐证据而无限增加跟踪范围，优先围绕受影响进程、目录和设备采样。
形成假设后，每次只改变能够解释的条件。例如暂停隔离环境中的竞争写入，观察目标延迟是否回落；保持访问模式不变，再比较同步策略。若同时更换文件系统、修改队列参数并增加内存，即使结果改善，也难以判断哪个变化有效。先缩小原因，再评估改动，才能让优化成为可迁移的方法。
7 案例：写屏障配置错误导致掉电丢数
下面是用于教学的事故模型。某主机把采集结果写入本地文件，应用在 fsync() 成功后记录“保存完成”。为了缩短同步耗时，维护人员依据别处的配置片段，在支持该选项的历史环境中关闭了相关写屏障或刷新保障。设备同时使用没有掉电保护的易失写缓存。平时读取一切正常，突然掉电后，最近已确认的记录缺失，部分文件需要恢复。
这里的关键不是某个选项名称，而是保证链被切断。写屏障相关机制用于约束需要的写入顺序，并结合刷新或等效机制满足文件系统的持久性要求。关闭保障后，应用看到成功返回的时点可能不再对应它以为的稳定存储状态。不同文件系统、内核和设备对选项的支持及语义不同，不能把历史配置字符串当作可跨环境使用的通用开关。
事故时间线可以分为几个节点：应用写入，发起同步，收到成功，设备仍有依赖供电的数据，供电中断，重启后检查发现内容不符。若只看到最后的文件缺失，无法单独证明屏障配置就是原因；设备故障、应用未检查错误、恢复脚本覆盖文件等也需排除。教学案例设定了风险条件，真实归因仍需要收集当时的配置和接口行为证据。
恢复阶段先保护现场。保留应用日志、内核存储错误、挂载配置、设备缓存与掉电保护信息、事故时间，以及备份和完整性检查结果。不要为了证明猜测，立即在原盘上反复挂载修复或做掉电实验。需要镜像、只读检查或恢复写入时，应按现有事故恢复流程执行。性能问题可以继续观察，数据完整性事故则要优先避免扩大覆盖范围。
分析时把“结构恢复成功”和“已确认记录都在”分开。文件系统能正常挂载，说明它完成了相应恢复过程，不意味着应用最后的所有内容都被保存。可以用应用序号、记录校验和及确认日志做交叉核对；确认日志如果位于同样的易失路径，也需要解释可靠性。证据应指出缺失范围，不能用“丢了最近一些数据”代替可核对的边界。
修复应恢复经支持的持久性配置，核实设备承诺，并检查应用是否正确使用同步及处理错误。在隔离环境中，按实际文件更新方式验证正常重启、进程终止和受控故障后的结果；不同故障覆盖不同边界，结束进程不能替代掉电验证。确需进行断电类测试时，应使用专门测试环境和既定流程，本课不提供对运行主机直接操作的步骤。
修复后的同步耗时可能上升，因为过去被跳过的等待重新出现了。这不应被简单视为性能回退，应先确认原有性能数字是否以降低保证为代价。可以在满足确认语义的前提下研究批量同步、减少无效写入和隔离竞争，但不能再次通过切断保证来达到指标。案例的教训是：配置优化必须同时说明速度和故障后的数据边界。
8 把存储栈证据写进性能方案
性能方案首先应描述可验证的用户影响。例如“采集进程每秒追加结果，周期同步的 P99 耗时超过 200 毫秒，使脚本完成时间超出预算”。再补上业务要求：哪些记录必须在返回前持久化，允许多久恢复，允许丢失的范围是什么。只有吞吐目标而没有确认语义，后续任何关闭同步的方案都可能看似成功，却改变了问题本身。
接下来说明环境和观测范围：内核与工具版本、文件系统与挂载选项、目标路径和设备映射、内存规模、共享负载，以及采样时间。无需罗列所有硬件参数，优先保留会改变解释的条件。特别是远端存储、虚拟设备和多层映射，要明确哪些层能看到、哪些层只能通过外部指标补充，避免把观测盲区写成确定结论。
指标应按层对应。应用层记录调用类型、请求量、耗时分布、返回值与错误；进程层记录 I/O 活动和同期任务；块层记录请求量、大小、等待及完成；数据层记录重启或故障后的完整性结果。所有指标使用相同或明确换算的时间窗，并标明单位。应用 P99 与设备平均值可以互相补充，但不能直接作为相同口径做差。
证据与推断要分开写。“备份期间目标设备等待升高”是观测，“共享写入使同步变慢”是待验证假设，“限制备份并发”是候选改动。方案应说清哪项证据支持该假设，还有哪些解释尚未排除。这样即使后续发现真正原因是下层存储波动，也能修改假设，而不用推翻整份没有层次的结论。
验证设计应保持主要负载条件一致，记录读写比例、块大小、文件规模、同步方式和并发。先取得基线，再实施单项改动，比较目标延迟、吞吐、错误和数据完整性。如果使用重复读取，说明缓存条件；如果使用合成负载，说明它与实际采集任务的差异。测试中出现空间不足、同步失败或数据校验错误，应单独处理，不能只统计成功请求。
回滚条件应在实施前写出。例如目标延迟没有改善、其他关键任务受影响、同步错误增加，或完整性检查失败，就恢复原配置并保留采样。参数原值、配置位置、生效方式和恢复步骤必须可追溯。对于涉及持久性语义的调整，不能只凭短期压测批准；还需要明确故障验证覆盖范围，以及哪些风险仍依赖设备或服务的承诺。
方案最终交付的是有边界的判断：在哪种工作负载、哪组配置和哪个故障假设下，达到了什么目标。把没有覆盖的情况写清楚，比宣称“存储已优化”更有用。下一位值班人员应能沿着同样的路径采集证据，判断环境是否变化，并知道什么时候需要升级到更深入的文件系统或设备分析。
9 从存储栈深入走向高性能网络（S48）
存储与网络都存在接口、缓冲、排队和完成通知。理解了缓冲写返回与持久化完成的区别，学习网络时就更容易追问：发送调用返回，表示数据到了哪里；对端是否收到，应用是否处理，需要什么额外证据。这是方法迁移，不能把存储同步语义直接套到网络接口上。具体发送、接收和确认边界将在 S48 逐步建立。
先用熟悉的运维场景连接起来。日志先写本地文件，再由进程读取并通过网络发送。如果远端接收变慢，发送进程可能积压待发送内容，本地日志继续增长，最终占用更多空间。此时“磁盘越来越满”不一定源于本地写入异常。要沿数据路径检查产生速度、读取进度、发送进度和远端处理状态，找出积压从哪里开始。
反过来，备份进程从本地读取，再经网络传输。网络发送速率下降，可能是本地读取等不到数据；本地读取变慢，也可能是远端处理不过来，使发送进程停止继续读取。单看网络吞吐量或磁盘吞吐量都难以判断方向。观察进程在哪个接口等待，再对齐本地块设备和网络连接的时间线，才能区分供给不足与下游限制。
当前阶段可以记录 ss -tin 的连接状态和相关 TCP 统计，并用 ip -s link 查看接口计数，同时保留应用的读取与发送进度。具体字段的含义、连接队列和协议行为留到后续课程。现在只要求认识到：接口计数是特定位置看到的现象，不能单凭某个计数变化证明对端应用已经完成处理，也不要把累计计数误当作当前速率。
存储课中的排队直觉也能迁移。适当并发可以提高资源利用，超过瓶颈后继续堆积往往增加延迟和内存占用。网络应用同样需要控制同时进行的工作，并观察尾部延迟。不过两类系统的错误、超时和恢复机制不同，不能仅凭“都有队列”就复用同样参数。先认识边界，再学习对应的控制方式，才能避免只追求最大缓冲区。
另一个迁移点是观测范围。容器内的路径不一定说明宿主机的物理设备，容器内的网络接口也未必直接对应外部链路。未来排查仍要先画路径，再选观察点。沿途每个点都要问：这里统计的是字节、请求还是连接；时间窗是否相同；有没有缓存、合并或重试改变数量。把这些问题问清楚，工具输出才会成为证据。
进入 S48 前，可以用自己的话解释 3 件事：为何写入返回后数据可能仍需写回，为什么设备平均延迟不足以解释每次应用长尾，以及如何把路径、时间窗和故障假设写进方案。如果仍习惯从某个最显眼的数字直接归因，就先回到本课的分层图。后续网络课程会延续这套方法，逐步增加接口和性能知识，而不是先背完整协议栈。
放进方案里
在性能方案中增加“存储路径与持久性边界”。用目标进程、文件路径、挂载来源和块设备映射画出实际路径，注明普通缓冲访问还是其他方式。明确应用何时确认成功，以及这个确认是否要求掉电后仍保留数据。把可见、已写回、已完成同步分别描述，避免用“落盘”概括不同阶段。远端或虚拟设备还应注明可观测范围。
基线选择能够代表实际任务的时间窗，记录请求大小、读写比例、并发、同步频率和缓存条件。应用端保留耗时分布与错误，进程端采集活动，设备端记录等待和完成情况；必要时才增加短窗口块层跟踪。为每份结果附上时间、单位和设备关系，说明哪些数据属于平均值，哪些反映长尾。工具不可见的部分应列为待补充证据。
候选改动先写假设，再写预期变化。例如限制竞争备份的并发，预期目标同步延迟下降，同时备份完成时间延长。每次只改变可解释的条件，保留配置原值，按相同负载比较吞吐、延迟、错误与其他任务影响。若同步配置或写缓存发生变化，必须补充持久性审查和隔离环境中的恢复验证，不能仅以压测变快作为通过依据。
验收同时覆盖性能与数据保证：目标延迟满足预算，资源消耗可接受，接口错误得到处理，故障后的数据符合预先约定的确认规则。写出回滚触发条件、恢复步骤和负责人，并保留观察材料。最终结论限定在已验证的工作负载、配置与故障范围内；超出范围时，沿同样路径重新采证，而不是直接沿用参数。
10 小结：下一步高性能网络（S48）
存储性能需要沿进程、文件系统、缓存、块层和设备解释；持久性则需要从应用确认一直追到实际保障。iotop 帮助观察进程活动，blktrace 提供块层事件，它们都需要明确范围并对齐时间。调优之前先保留基线，涉及同步保障的改动还要检查故障后的结果。
自测：缓冲写很快而同步很慢，分别说明了什么？设备吞吐量不高却出现长等待，还需要哪些指标？应用确认成功后掉电丢数，应检查哪些保证边界？带着这些问题进入 S48，把相同的分层观察方法用于发送、接收、排队与网络性能。