未经同意请勿转载副标题存储栈 ≠ 核心架构——五个概率预测与三层演进模型适用版本Azure Local 2506 / 2510 / Windows Server 2025含 23H2 / 22H2 沿用文档定位在前三篇原理 数据流 设计哲学基础上回答未来会怎么变。写作约定本文涉及未来预测的部分明确标注为基于已公开文档的推断不写微软将 / 一定会等表述。0.1 证据等级体系A / B / C 级为方便读者快速识别每段表述的可信度本文统一使用以下三级证据标记——这一体系贯穿整个系列四篇文档与前三篇完全一致。等级含义典型来源【A级】微软官方明确说明Microsoft Learn、Windows Server 官方文档、微软公开技术博客、官方支持矩阵【B级】公开资料可推导官方未直接说明但可由公开演讲、论文、专利、SDK/API 行为、命令行输出反推【C级】作者工程分析结合公开信息和工程实践的分析与推测不代表微软官方实现细节使用约定每段首行如有【A级】/【B级】/【C级】标记表示该段主要表述的证据等级若一段混合多个等级会分别标注。未标注的段落通常是过渡、术语解释或图表标注。0.2 本篇特有的关键声明【A级】本篇 §1 ~ §4 中Windows Server 2025 已经做了什么属于微软官方公开说明。【B级】微软为什么没重写 / 三个瓶颈属于基于公开资料的合理推导。【C级】§8下一代预测、§10三层架构模型全部是作者分析与推测不代表微软官方路线图。本文不写微软将 / 一定会 / 已经规划等绝对化预测。目录0. 引言Windows Server 2025 是不是Storage Spaces 大版本1. 第一类NVMe 存储栈最大变化2. 第二类ReFS 增强影响比 S2D 更大3. 第三类Storage Replica4. 第四类Storage Spaces 新增功能5. 微软为什么没有重写 Storage Spaces6. WS2012~2025 演进对比7. 微软目前遇到的三个瓶颈8. 下一代方向预测详细分析9. Ceph / vSAN / PowerFlex 对比参照10. 三层架构演进模型11. 总结0. 引言Windows Server 2025 是不是Storage Spaces 大版本简短回答不是。Windows Server 2025 在 Storage Spaces核心架构层面几乎没有任何变化——没有新的 Mirror 算法没有新的 Parity 编码算法没有类似 Ceph CRUSH 的 Placement GroupPG机制没有改变 Metadata 的全局管理方式微软真正的工作重点放在了整个存储栈Storage Stack而不是 Storage Spaces 的核心架构。如果按影响程度排序可以分成四类类别影响范围变化幅度第一类NVMe 存储栈整个 Windows 存储 I/O★★★★★最大第二类ReFS 增强文件系统层★★★★☆影响 S2D第三类Storage Replica复制 / 容灾★★★★☆场景明确第四类Storage Spaces 新增功能S2D 本身★★☆☆☆增量下面分类展开。1. 第一类NVMe 存储栈最大的变化1.1 这是什么【A级】NVMe I/O 路径优化是 Windows Server 2025 微软官方明确说明的改进点。【B级】减少了 CPU 开销 / 提高了并发能力具体倍数微软有公布但版本依赖较强本文不写绝对数字。Windows Server 2025 最大的存储改进是对 NVMe I/O 路径的大幅优化。过去 Windows 的 NVMe I/O 路径实际上仍然保留了较多历史兼容设计而 Windows Server 2025 减少了 CPU 开销提高了并发能力。微软官方测试显示在相同硬件上可看到明显更高的 IOPS 和更低的 CPU 使用率。具体数字以微软当期文档为准不在本文写死。1.2 对 S2D 的含义S2D 的存储路径VM ↓ VHDX ↓ ReFS ↓ Storage Spaces ↓ NVMeStorage Spaces 本身几乎没变——真正变快的是NVMe Driver → PCIe这一段。flowchart LR A[VM] -- B[VHDX] B -- C[ReFS] C -- D[Storage Spaces] D -- E[NVMe Driverbr/★ Windows Server 2025 优化重点] E -- F[PCIe] style E fill:#c6efce style D fill:#ffe4e11.3 谁受益最大工作负载受益程度原因裸 NVMe 直通给 VM★★★★★跳过 S2D直接受益 NVMe 优化SQL Server 走 S2D★★★☆☆间接受益Hyper-V 走 S2D★★★☆☆间接受益AI 训练 / 推理★★★★☆高并发 IOVDI 走 S2D★★★☆☆间接受益但Mirror Placement、Parity Placement 算法本身没有变化。1.4 关键认知NVMe 变快 ≠ S2D 变快。S2D 的瓶颈环节在 Storage Spaces ReFS而不在 NVMe Driver。微软这次优化的是 NVMe Driver所以对绕过 S2D 直接使用 NVMe 的场景如裸 NVMe 直通给 VM收益最大对走 S2D 的场景只是间接收益。2. 第二类ReFS 增强影响比 S2D 更大2.1 微软在 ReFS 上的投入【A级】原生 Dedup / 原生 Compression / Block Clone / 与 MAP 协同均是微软官方说明。Windows Server 2025 对 ReFS 的投入明显超过 Storage Spaces主要包括原生重复数据删除Native Deduplication原生压缩CompressionBlock Clone 持续优化与 MAPMirror-Accelerated Parity的协同优化2.2 一个关键趋势以前Storage Spaces → 决定性能现在越来越多地变成ReFS → 决定性能微软近年来实际上把大量优化放到了ReFS而不是 Storage Spaces。2.3 ReFS 的核心能力演进timeline title ReFS 能力演进 2012 : ReFS 首次推出 2016 : 与 S2D 整合 2019 : Block Clone 引入 2022 : 性能优化 大容量支持 2025 : Native Dedup Compression MAP 协同2.4 对架构选型的影响工作负载主要受益层备注大量小文件ReFS Block Clone减少写放大重复数据ReFS Dedup减少存储占用VM 模板部署ReFS Block Clone几秒内克隆MAP 卷ReFS S2D 协同64 MiB Region 自动迁移未来如果要做存储选型ReFS 卷不走 S2D也是一个值得评估的选项——尤其在 NVMe 直通场景。3. 第三类Storage Replica【A级】Storage Replica Compression / 跨域复制等是微软官方文档明确的功能。3.1 主要新增Storage Replica 在 Windows Server 2025 是升级比较明显的一项(1) Storage Replica Compression以前 Write → Network → Remote 现在 Write → Compress → Network → Decompress → Remote对于 Stretch Cluster、RAC、跨机房复制网络压力下降很多。(2) Enhanced Log微软重写了日志实现。以前 Application ↓ File System ↓ Log ↓ Network 现在 日志层更接近 Block Replication复制效率明显提高。3.2 适用场景Stretch Cluster两站点集群Rack Aware ClusterAzure Local RAC跨机房灾备备份 / 归档复制不是 S2D 算法更新但是 S2D 上层的关键改进。4. 第四类Storage Spaces 新增功能【B级】Thin Provisioning 等新增功能在 Windows Server 2025 中是否已正式支持具体取决于版本号2506 / 2510 等。本文以微软文档提及作为表述边界不写已正式 GA等绝对化结论。4.1 真正属于 Storage Spaces 的新增其实不多主要有(1) Thin Provisioning精简配置以前 Storage Spaces 几乎都是 Fixed Windows Server 2025 正式支持 Thin Provision 并支持 Fixed → Thin 转换这是很多客户期待很久的功能。(2) Repair 机制优化微软没有公开太多内部实现但Repair坏盘重建更快Resync新加入节点更快后台任务调度更智能Azure Local 上的 Repair比以前更快但Metadata 仍然是原来的 Storage Spaces没有革命性变化。4.2 微软没改什么如果站在存储架构角度微软没有改的东西反而更值得关注mindmap root((微软没改的 Storage Spaces)) Metadata 仍然 Pool → Metadata → Extent Mapping 没有 Placement Group 没有 CRUSH Parity 仍然 Stripe Column Parity 没有 Local Reconstruction Code 没有 Azure Storage 风格 Erasure Coding Mirror 仍然 Distributed Mirror Placement 算法没变 Rebalance 仍倾向全局 Optimize 没有 PG 局部迁移4.3 容量决策对比flowchart LR A[Storage Spaces 现状] -- B[没有 PG] B -- C[新增 1 Node] C -- D[全局 Optimize] D -- E[耗时可能数小时] F[Ceph 对比] -- G[有 PG] G -- H[新增 1 Node] H -- I[仅迁移受影响 PG] I -- J[耗时分钟级] style A fill:#ffe4e1 style F fill:#c6efce5. 微软为什么没有重写 Storage Spaces【C级】全章三个原因属于作者对微软产品策略的归纳不代表微软官方表态。三个原因。5.1 第一兼容性Storage Spaces 从 2012 一直兼容到今天。 Metadata 不能轻易改。 否则所有 Pool 都需要升级。 风险巨大。5.2 第二Azure Local 定位微软现在主要精力已经放到 Azure Local。 Azure Local 典型规模2 ~ 16 Node。 官方支持的 Rack Aware Cluster 目前也只是少量机架、有限节点规模 并不是互联网级几百节点集群。 对于这个规模现有 Storage Spaces 架构仍然能够满足设计目标。5.3 第三微软认为瓶颈已经不是 Storage Spaces现在更多瓶颈来自 - NVMe - CPU - Network - RDMA - PCIe 而不是 Mirror。 因此微软优先优化整个 Storage Stack。5.4 三因汇总flowchart TD A[微软不重写 Storage Spaces] -- B[兼容性] A -- C[Azure Local 定位] A -- D[瓶颈已转移] B -- B1[Metadata 不能改br/改则所有 Pool 升级] C -- C1[2~16 Node 规模br/现有架构够用] D -- D1[瓶颈在 NVMe/网络br/不在 Mirror 算法] style A fill:#fff3cd6. WS2012~2025 演进对比6.1 演进对比表【B级】表格说明★ 数量是作者基于公开文档的主观评估不是微软官方评级。请勿引用为微软对 WS2025 重要性的官方排序。版本Storage Spaces 架构变化存储栈变化Windows Server 2012★★★★★Storage Spaces 首次推出★★★☆☆Windows Server 2016★★★★★S2D、ReFS、CSV 深度整合★★★★☆Windows Server 2019★★★☆☆性能与稳定性优化★★★★☆Windows Server 2022★★☆☆☆增量优化★★★★★Windows Server 2025★☆☆☆☆核心算法几乎未变★★★★★NVMe、ReFS、Storage Replica、Thin Provisioning 等全面增强6.2 演进趋势图flowchart LR A[2012br/架构 ★★★★★br/栈 ★★★☆☆] -- B[2016br/架构 ★★★★★br/栈 ★★★★☆] B -- C[2019br/架构 ★★★☆☆br/栈 ★★★★☆] C -- D[2022br/架构 ★★☆☆☆br/栈 ★★★★★] D -- E[2025br/架构 ★☆☆☆☆br/栈 ★★★★★] style A fill:#c6efce style B fill:#c6efce style C fill:#fff3cd style D fill:#ffe4e1 style E fill:#ffe4e16.3 关键洞察架构评分逐渐下降存储栈评分逐渐上升——这反映了微软的优先级转移。如果你期待的是 Storage Spaces 像 Ceph、PowerFlex 或 Azure Storage 一样重新设计数据放置算法、引入局部保护组、减少全局重平衡Windows Server 2025并没有朝这个方向发展。它更像是在保留 Storage Spaces 核心架构的前提下把 ReFS、NVMe、Storage Replica 和整个 Windows 存储 I/O 栈打磨得更快、更高效。这一点也反映了微软近年来的发展重点创新更多集中在 Azure Local 和底层存储栈而不是重构 Storage Spaces 的核心元数据与布局算法。7. 微软目前遇到的三个瓶颈【B级】全章三个瓶颈是工程界长期共识但微软也认为这是瓶颈未在官方文档中明确承认。本文表述为业内已知 作者分析。7.1 瓶颈一Metadata 全局管理Storage Pool 越大 - Optimize 越慢 - Repair 越慢 - Rebalance 越慢这是所有 S2D 用户都知道的问题。7.2 瓶颈二Erasure Coding 仍然比较传统今天 Mirror → Rotate → Parity 实际上仍然是 Stripe Column 而不是 Azure Storage 的 Extent → Local Reconstruction Code → Placement7.3 瓶颈三Storage Spaces 与 Azure Storage 已经越来越不像flowchart TB subgraph Azure[Azure Storage] A1[Object] -- A2[Extent] A2 -- A3[Distributed Metadata] end subgraph S2D[Storage Spaces] S1[Storage Pool] -- S2[Virtual Disk] S2 -- S3[Extent Mapping] end style Azure fill:#c6efce style S2D fill:#ffe4e1两条技术路线越来越远。8. 下一代方向预测详细分析【C级】全章警告本章所有概率最高 ★★★★★的预测完全是作者分析不代表微软官方路线图。本文不写微软将 / 一定会 / 已经规划等表述。读者引用本章时请务必标注作者推测。概率打分★ 数量是作者主观评估不是基于任何官方预测。下面是基于微软过去十多年技术演进的分析和预测不是微软已公布的计划。8.1 预测一Metadata 分区化概率最高★★★★★描述今天 整个 Pool 的 Metadata 统一管理 未来 Pool ├─ Partition A ├─ Partition B └─ Partition C 类似 Azure 的 Storage Stamp好处Repair 不再遍历整个 Pool而是只遍历某个 Partition16 Node 集群 Repair 时间可能缩短到原来的 1/4 甚至更少兼容老格式的可能性较高不需要重写整个 Metadata Schema挑战Partition 之间数据迁移策略跨 Partition 副本的 Fault Domain 处理评估★★★★★最可能兼容性好、收益明显8.2 预测二引入 Placement GroupPG★★★☆☆描述Ceph 的做法 Object → PG → CRUSH → OSD 微软可能改成 Storage Pool └─ Placement Group └─ Extent好处新增 Node 不会触发整个 Pool 的 Rebalance只迁移部分 PG性能提升显著问题Metadata 全部要升级兼容性困难所有 Pool 需升级或迁移评估★★★☆☆技术收益大但兼容成本高8.3 预测三引入 Azure Storage 风格算法★★☆☆☆描述今天的 ParityStripe Column 未来可能Extent Local Reconstruction Code好处Repair 速度会快很多大容量 SSD 场景特别受益问题Windows Kernel 几乎全部重写风险巨大评估★★☆☆☆收益明显但风险极高8.4 预测四Object Storage 融合★★☆☆☆描述微软已经越来越云化。 Azure Local 以后可能不仅支持 Block还支持 Object。 Storage Spaces 直接支持 S3 也不是没有可能。问题Windows 一直没有对象存储传统S3 兼容带来新的 API 层、新的安全模型评估★★☆☆☆方向有意思但远期8.5 预测五ReFS 越来越重要★★★★★已经在发生描述以前 Storage Spaces 负责很多工作 现在 VM → ReFS → Storage Spaces 很多智能实际上已经放到 ReFS - Block Clone - Dedup - Compression - 冷热数据 未来更多功能会放到 ReFS。 Storage Spaces 越来越简单。评估★★★★★已经在发生方向确定8.6 预测六Storage Spaces 逐渐冻结★★★☆☆描述还有另一种可能——微软以后根本不大幅改 Storage Spaces。 原因 - Azure Local 现在主要规模 2~16 Node - Storage Spaces 已经够用 - 微软未来更多资源放到 Azure - Storage Spaces 只是维护评估★★★☆☆这种可能性其实不小8.7 我个人最期待的架构如果让我重新设计下一代 Storage Spaces我不会完全照搬 Ceph 或 Azure Storage而是更希望微软采用一种混合模式兼顾 Windows 兼容性和大规模扩展Storage Pool │ ▼ Protection Group新增 │ ├─ PG001 ├─ PG002 └─ PG003 │ ▼ Extent │ ▼ Physical Disk特征每个 Protection Group 只有 4~8 Node新增 Node 时只迁移少量 PGRepair 也是 PG 级别Metadata 分片管理好处Storage Spaces 还能兼容 Windows扩容能力接近 Ceph9. Ceph / vSAN / PowerFlex 对比参照【C级】全章本章横向对比基于公开资料整理不是各厂商官方对比。各系统版本演进很快对比表只反映本文撰写时点的作者理解。9.1 分布式 SDS 的关键特性对比特性S2D / Azure LocalCephVMware vSANDell PowerFlex数据放置算法Fault Domain Aware Column 选取CRUSH 哈希策略 WitnessMDM 决策Placement Group❌ 无✅ 有✅ 间接Stretched Cluster✅ 有Protection Domain局部修复❌ 全局 Metadata✅ PG 局部✅ Component✅ 有扩展上限16 NodeAzure Local千级 OSD64 Host千级 Node数据单位Slab RegionObjectComponentPage副本策略静态 Mirror/ParityCRUSH 动态静态 见证静态 MDMErasure CodingDual ParityJerasure / ISA-LRAID-5/6LRC 风格9.2 关键差距mindmap root((S2D 与 Ceph/vSAN 的差距)) 缺乏 PG 全局 Metadata 瓶颈 Rebalance 全局触发 缺乏 LRC Repair 必须读全 Stripe 大容量盘 Repair 慢 缺乏动态副本策略 副本策略建卷时定 不能按热度自动调整 缺乏可扩展上限 Azure Local 16 Node 上限 Ceph 可至千级9.3 微软如果想缩小差距最可能的方向短期1~2 年Metadata 分区化最高概率中期3~5 年引入 PG中等概率长期5 年Azure Storage 风格算法重构低概率10. 三层架构演进模型【C级】全章本章三层架构是作者对微软存储产品体系的归纳模型不是微软官方架构图。Azure Storage / Azure Local / Storage Spaces 三层共存是观察结论不是微软公开承诺。10.1 微软存储的三层栈flowchart TB A[Azure Storagebr/云原生分布式存储br/持续快速演进] B[Azure Localbr/混合云平台能力br/获得更多新功能] C[Windows Storage Spacesbr/稳定、兼容的基础存储层br/保持成熟稳定] A -- B B -- C style A fill:#c6efce style B fill:#fff3cd style C fill:#ffe4e110.2 三层的不同优先级层级演进速度创新重点兼容性要求Azure Storage★★★★★快新算法、新功能低云原生Azure Local★★★★☆混合云、Arc 集成中企业混合Windows Storage Spaces★☆☆☆☆慢稳定、Bug 修复高Windows 生态10.3 为什么可能形成三层架构从近几年的产品策略来看Windows Server 更强调稳定、长期兼容和企业部署Azure Local 获得了更多新功能例如机架感知、云管理、Arc 集成等Azure Storage 则继续在公有云中快速演进如果这一趋势持续Storage Spaces 更可能保持为一个成熟稳定的底层引擎而新的分布式能力、智能调度和云化特性则逐渐在 Azure Local 或更高层的软件中实现而不是彻底重写 Storage Spaces 本身。这种路线既符合微软近年来对兼容性的重视也符合其**云优先、混合云优先**的发展策略。11. 总结【C级】全章总结中的判断基于本文前三篇 第四篇的分析不代表微软官方表态。11.1 核心判断Windows Server 2025 是存储栈升级不是Storage Spaces 架构升级微软的核心创新在 ReFS NVMe Storage Replica Thin ProvisioningStorage Spaces 核心算法几乎未变下一代最可能的演进方向是 Metadata 分区化 ReFS 接管更多智能更激进的 PG / LRC / 重构在可见的未来不太可能发生三层架构Azure Storage / Azure Local / Storage Spaces可能是长期共存形态11.2 综合概率预测方向概率原因ReFS 成为真正的数据管理层★★★★★微软近几年几乎所有创新都优先落在 ReFSMetadata 分区化★★★★★能显著改善 Repair、Optimize同时兼容现有架构NVMe-oF、RDMA、GPU Direct 等高速 I/O 深度整合★★★★☆AI 工作负载和高性能存储会持续推动这方面发展局部重平衡类似 Protection Group★★★☆☆技术收益很大但需要解决元数据兼容问题采用 Azure Storage / LRC 风格纠删码★★☆☆☆收益明显但几乎等于重写 Storage Spaces完全重构 Storage Spaces★☆☆☆☆兼容性成本极高Windows 生态很难接受11.3 对企业部署的指导flowchart LR A[企业部署 Azure Local] -- B[不要期待 S2D 变 Ceph] A -- C[关注主线] C -- C1[Azure Local Arc] C -- C2[ReFS 增强] C -- C3[Storage Replica] A -- D[性能优化重点] D -- D1[NVMe Driver] D -- D2[RDMA] D -- D3[网络架构] style A fill:#fff3cd具体建议不要期待 Storage Spaces 会变成另一个 Ceph——它会更稳定但不会大改应该关注 Azure Local Arc ReFS Storage Replica 这条主线——微软的创新主要在这性能优化重点放在 NVMe Driver RDMA 网络而不是 S2D 算法2~16 Node 是 S2D 的舒适区——超出这个规模考虑其他方案MAP 是性价比最高的通用卷方案——Mirror 兜随机写Parity 兜容量RAC 是企业级可靠性的标配——尤其多机房场景附录四篇文档索引篇标题重点第一篇Azure Local / Storage Spaces Direct 五层数据布局原理Slab / Column / Region / Fault Domain第二篇Mirror / Parity / MAP 数据流与 Region Rotation副本轮转、双校验、Rotate 时序第三篇3 节点强制 3-way / 4 节点 Parity / 单校验淘汰故障域设计哲学、部署决策树第四篇Windows Server 2025 存储栈升级与下一代方向预测演进对比、未来预测、三层架构附录写作约定贯穿四篇表述含义微软官方硬性表述出自微软官方文档原文微软隐含 / 默认行为来自文档描述但未明确必须基于已公开文档的推断综合多个文档的合理推断经验区间实际部署中观察到的范围不是官方数字概率预测基于演进而非微软公告文档结束附录 D新增 · v4.0引用本文的三个边界本节是系列定位的核心——主动划清微软公开事实与作者工程分析的边界。 读者引用本文时优先参考本节确认哪些内容可作为微软事实引用。D.1 微软公开的事实与本篇相关概念公开程度关键来源NVMe I/O 路径优化✅ 完全公开Windows Server 2025 存储博客ReFS 原生 Dedup / Compression✅ 完全公开Microsoft Learn - ReFS featuresStorage Replica Compression✅ 完全公开Microsoft Learn - Storage ReplicaStorage Spaces 新增功能部分⚠️ 版本依赖Azure Local release notesFault Domain✅ 完全公开Azure Local hardware requirementsNumberOfColumns✅ 完全公开New-VirtualDisk cmdlet 文档D.2 微软未公开的内容本篇相关内容公开程度备注❌未来 5 年演进路线图微软未公开微软不会公布长期路线图❌下一代具体技术方向微软未公开本文 §8 全部为作者推测❌Metadata 分区化等具体技术细节微软未公开本文 §8.x 预测无官方依据❌概率打分 ★ 数量微软未公开作者主观评估❌三层架构模型微软未公开本文 §10 是作者归纳❌Ceph / vSAN / PowerFlex 的对比细节各厂商公开但非权威本文 §9 是作者横向对比D.3 引用本文的三个边界边界 1可作为微软事实引用本文有【A级】标记的内容§1-4附录 D.1 中标 ✅ 的概念Microsoft Learn 上能直接找到对应文档的概念边界 2可作为作者基于公开行为的工程分析引用本文有【B级】标记的内容§6 / §7但引用时需注明作者分析跨厂商对比§9属于此类边界 3不可作为任何事实引用本文有【C级】标记的内容§5 / §8 / §10 / §11§8 下一代方向预测全部为作者推测§10 三层架构模型为作者归纳任何概率打分 ★ 数量D.4 给读者的最终建议把本文作为理解 WS2025 / Azure Local 存储栈演进 作者推测的工程读物§1-4 可放心引用为微软事实——这些是公开功能§8 预测务必标注作者推测——引用时不要写成微软预测 / 微软路线图本文不能替代Microsoft Learn / Azure Local release notes附录 A本文的证据等级分布自检表章节主要证据等级说明§0 引言A B C三层声明分别标级§1 NVMe 存储栈A B优化方向 A 级具体倍数 B 级§2 ReFS 增强A微软官方明确的功能改进§3 Storage ReplicaA微软官方功能§4 Storage Spaces 新增B部分功能版本依赖 B 级§5 为什么没重写C作者产品策略分析§6 演进对比表B主观评分作者整理§7 三个瓶颈B业内共识作者归纳§8 下一代预测C最重全部为作者推测§9 跨厂商对比C作者对比非官方§10 三层架构模型C作者归纳模型§11 总结C作者综合判断声明本表为作者自检用途方便读者快速定位每一章的可信度。任何段落的【A级】/【B级】/【C级】标记以正文为准。v4.0 修订说明2026-07-13本次修订按ReFS 与 Storage Spaces 协同工作原则做风格收尾未做大规模改写。 主要改动如下§0 引言顶部加写作约定声明—— 明确 ReFS/SS 协同、Column ≠ Physical Disk、§8 严格 C 级、§9 跨厂商对比、§10 三层架构模型§8 之前所有下一代加引号—— 强调下一代是作者预测用语不是微软官方表述附录 D 新增三个边界—— 与第 1 / 2 篇对齐作为系列定位核心本文 v3.0 已基本成熟本次修订主要是按系列统一标准做风格收尾。 如读者反馈更多实质性错误将启动 v5.0 修订。附录 B引用本文档时的注意事项如果要在博客、论文或企业内部文档中引用本文建议明确区分 A / B / C 级——不要把 C 级推断当作微软事实陈述§8 预测全部为作者分析——引用时务必标注作者推测不要写成微软预测 / 微软路线图概率打分 ★ 数量是主观评估——不是基于任何官方预测§10 三层架构模型是作者归纳——不是微软官方架构图避免引用下一代方向 / 概率最高作为微软承诺——本文明确不写微软将 / 一定会本文与前三篇的术语对照——见附录 C数据布局相关结论要注明版本——本文基于 Azure Local 2506 / 2510 / Windows Server 2025附录 C四篇术语对照表系列总览系列术语微软官方术语第 1 篇第 2 篇第 3 篇第 4 篇内部单位 / Slab未公开✓✓--Column未公开✓✓--64 MiB Region✓✓✓--MAP / Mirror-Accelerated Parity✓-✓-✓3-way Mirror✓-✓✓-Dual Parity✓-✓✓-Fault Domain✓✓✓✓-RACRack Aware Cluster✓✓✓✓-ReFS✓✓✓-✓Storage Replica✓---✓Thin Provisioning✓---✓使用说明本系列四篇文档均使用一致的 A / B / C 证据等级标记术语首次出现时已注明微软是否官方使用。引用时请按本文档对应章节的证据等级标注。
Windows Server 2025 存储栈升级与 Storage Spaces “下一代“方向预测
未经同意请勿转载副标题存储栈 ≠ 核心架构——五个概率预测与三层演进模型适用版本Azure Local 2506 / 2510 / Windows Server 2025含 23H2 / 22H2 沿用文档定位在前三篇原理 数据流 设计哲学基础上回答未来会怎么变。写作约定本文涉及未来预测的部分明确标注为基于已公开文档的推断不写微软将 / 一定会等表述。0.1 证据等级体系A / B / C 级为方便读者快速识别每段表述的可信度本文统一使用以下三级证据标记——这一体系贯穿整个系列四篇文档与前三篇完全一致。等级含义典型来源【A级】微软官方明确说明Microsoft Learn、Windows Server 官方文档、微软公开技术博客、官方支持矩阵【B级】公开资料可推导官方未直接说明但可由公开演讲、论文、专利、SDK/API 行为、命令行输出反推【C级】作者工程分析结合公开信息和工程实践的分析与推测不代表微软官方实现细节使用约定每段首行如有【A级】/【B级】/【C级】标记表示该段主要表述的证据等级若一段混合多个等级会分别标注。未标注的段落通常是过渡、术语解释或图表标注。0.2 本篇特有的关键声明【A级】本篇 §1 ~ §4 中Windows Server 2025 已经做了什么属于微软官方公开说明。【B级】微软为什么没重写 / 三个瓶颈属于基于公开资料的合理推导。【C级】§8下一代预测、§10三层架构模型全部是作者分析与推测不代表微软官方路线图。本文不写微软将 / 一定会 / 已经规划等绝对化预测。目录0. 引言Windows Server 2025 是不是Storage Spaces 大版本1. 第一类NVMe 存储栈最大变化2. 第二类ReFS 增强影响比 S2D 更大3. 第三类Storage Replica4. 第四类Storage Spaces 新增功能5. 微软为什么没有重写 Storage Spaces6. WS2012~2025 演进对比7. 微软目前遇到的三个瓶颈8. 下一代方向预测详细分析9. Ceph / vSAN / PowerFlex 对比参照10. 三层架构演进模型11. 总结0. 引言Windows Server 2025 是不是Storage Spaces 大版本简短回答不是。Windows Server 2025 在 Storage Spaces核心架构层面几乎没有任何变化——没有新的 Mirror 算法没有新的 Parity 编码算法没有类似 Ceph CRUSH 的 Placement GroupPG机制没有改变 Metadata 的全局管理方式微软真正的工作重点放在了整个存储栈Storage Stack而不是 Storage Spaces 的核心架构。如果按影响程度排序可以分成四类类别影响范围变化幅度第一类NVMe 存储栈整个 Windows 存储 I/O★★★★★最大第二类ReFS 增强文件系统层★★★★☆影响 S2D第三类Storage Replica复制 / 容灾★★★★☆场景明确第四类Storage Spaces 新增功能S2D 本身★★☆☆☆增量下面分类展开。1. 第一类NVMe 存储栈最大的变化1.1 这是什么【A级】NVMe I/O 路径优化是 Windows Server 2025 微软官方明确说明的改进点。【B级】减少了 CPU 开销 / 提高了并发能力具体倍数微软有公布但版本依赖较强本文不写绝对数字。Windows Server 2025 最大的存储改进是对 NVMe I/O 路径的大幅优化。过去 Windows 的 NVMe I/O 路径实际上仍然保留了较多历史兼容设计而 Windows Server 2025 减少了 CPU 开销提高了并发能力。微软官方测试显示在相同硬件上可看到明显更高的 IOPS 和更低的 CPU 使用率。具体数字以微软当期文档为准不在本文写死。1.2 对 S2D 的含义S2D 的存储路径VM ↓ VHDX ↓ ReFS ↓ Storage Spaces ↓ NVMeStorage Spaces 本身几乎没变——真正变快的是NVMe Driver → PCIe这一段。flowchart LR A[VM] -- B[VHDX] B -- C[ReFS] C -- D[Storage Spaces] D -- E[NVMe Driverbr/★ Windows Server 2025 优化重点] E -- F[PCIe] style E fill:#c6efce style D fill:#ffe4e11.3 谁受益最大工作负载受益程度原因裸 NVMe 直通给 VM★★★★★跳过 S2D直接受益 NVMe 优化SQL Server 走 S2D★★★☆☆间接受益Hyper-V 走 S2D★★★☆☆间接受益AI 训练 / 推理★★★★☆高并发 IOVDI 走 S2D★★★☆☆间接受益但Mirror Placement、Parity Placement 算法本身没有变化。1.4 关键认知NVMe 变快 ≠ S2D 变快。S2D 的瓶颈环节在 Storage Spaces ReFS而不在 NVMe Driver。微软这次优化的是 NVMe Driver所以对绕过 S2D 直接使用 NVMe 的场景如裸 NVMe 直通给 VM收益最大对走 S2D 的场景只是间接收益。2. 第二类ReFS 增强影响比 S2D 更大2.1 微软在 ReFS 上的投入【A级】原生 Dedup / 原生 Compression / Block Clone / 与 MAP 协同均是微软官方说明。Windows Server 2025 对 ReFS 的投入明显超过 Storage Spaces主要包括原生重复数据删除Native Deduplication原生压缩CompressionBlock Clone 持续优化与 MAPMirror-Accelerated Parity的协同优化2.2 一个关键趋势以前Storage Spaces → 决定性能现在越来越多地变成ReFS → 决定性能微软近年来实际上把大量优化放到了ReFS而不是 Storage Spaces。2.3 ReFS 的核心能力演进timeline title ReFS 能力演进 2012 : ReFS 首次推出 2016 : 与 S2D 整合 2019 : Block Clone 引入 2022 : 性能优化 大容量支持 2025 : Native Dedup Compression MAP 协同2.4 对架构选型的影响工作负载主要受益层备注大量小文件ReFS Block Clone减少写放大重复数据ReFS Dedup减少存储占用VM 模板部署ReFS Block Clone几秒内克隆MAP 卷ReFS S2D 协同64 MiB Region 自动迁移未来如果要做存储选型ReFS 卷不走 S2D也是一个值得评估的选项——尤其在 NVMe 直通场景。3. 第三类Storage Replica【A级】Storage Replica Compression / 跨域复制等是微软官方文档明确的功能。3.1 主要新增Storage Replica 在 Windows Server 2025 是升级比较明显的一项(1) Storage Replica Compression以前 Write → Network → Remote 现在 Write → Compress → Network → Decompress → Remote对于 Stretch Cluster、RAC、跨机房复制网络压力下降很多。(2) Enhanced Log微软重写了日志实现。以前 Application ↓ File System ↓ Log ↓ Network 现在 日志层更接近 Block Replication复制效率明显提高。3.2 适用场景Stretch Cluster两站点集群Rack Aware ClusterAzure Local RAC跨机房灾备备份 / 归档复制不是 S2D 算法更新但是 S2D 上层的关键改进。4. 第四类Storage Spaces 新增功能【B级】Thin Provisioning 等新增功能在 Windows Server 2025 中是否已正式支持具体取决于版本号2506 / 2510 等。本文以微软文档提及作为表述边界不写已正式 GA等绝对化结论。4.1 真正属于 Storage Spaces 的新增其实不多主要有(1) Thin Provisioning精简配置以前 Storage Spaces 几乎都是 Fixed Windows Server 2025 正式支持 Thin Provision 并支持 Fixed → Thin 转换这是很多客户期待很久的功能。(2) Repair 机制优化微软没有公开太多内部实现但Repair坏盘重建更快Resync新加入节点更快后台任务调度更智能Azure Local 上的 Repair比以前更快但Metadata 仍然是原来的 Storage Spaces没有革命性变化。4.2 微软没改什么如果站在存储架构角度微软没有改的东西反而更值得关注mindmap root((微软没改的 Storage Spaces)) Metadata 仍然 Pool → Metadata → Extent Mapping 没有 Placement Group 没有 CRUSH Parity 仍然 Stripe Column Parity 没有 Local Reconstruction Code 没有 Azure Storage 风格 Erasure Coding Mirror 仍然 Distributed Mirror Placement 算法没变 Rebalance 仍倾向全局 Optimize 没有 PG 局部迁移4.3 容量决策对比flowchart LR A[Storage Spaces 现状] -- B[没有 PG] B -- C[新增 1 Node] C -- D[全局 Optimize] D -- E[耗时可能数小时] F[Ceph 对比] -- G[有 PG] G -- H[新增 1 Node] H -- I[仅迁移受影响 PG] I -- J[耗时分钟级] style A fill:#ffe4e1 style F fill:#c6efce5. 微软为什么没有重写 Storage Spaces【C级】全章三个原因属于作者对微软产品策略的归纳不代表微软官方表态。三个原因。5.1 第一兼容性Storage Spaces 从 2012 一直兼容到今天。 Metadata 不能轻易改。 否则所有 Pool 都需要升级。 风险巨大。5.2 第二Azure Local 定位微软现在主要精力已经放到 Azure Local。 Azure Local 典型规模2 ~ 16 Node。 官方支持的 Rack Aware Cluster 目前也只是少量机架、有限节点规模 并不是互联网级几百节点集群。 对于这个规模现有 Storage Spaces 架构仍然能够满足设计目标。5.3 第三微软认为瓶颈已经不是 Storage Spaces现在更多瓶颈来自 - NVMe - CPU - Network - RDMA - PCIe 而不是 Mirror。 因此微软优先优化整个 Storage Stack。5.4 三因汇总flowchart TD A[微软不重写 Storage Spaces] -- B[兼容性] A -- C[Azure Local 定位] A -- D[瓶颈已转移] B -- B1[Metadata 不能改br/改则所有 Pool 升级] C -- C1[2~16 Node 规模br/现有架构够用] D -- D1[瓶颈在 NVMe/网络br/不在 Mirror 算法] style A fill:#fff3cd6. WS2012~2025 演进对比6.1 演进对比表【B级】表格说明★ 数量是作者基于公开文档的主观评估不是微软官方评级。请勿引用为微软对 WS2025 重要性的官方排序。版本Storage Spaces 架构变化存储栈变化Windows Server 2012★★★★★Storage Spaces 首次推出★★★☆☆Windows Server 2016★★★★★S2D、ReFS、CSV 深度整合★★★★☆Windows Server 2019★★★☆☆性能与稳定性优化★★★★☆Windows Server 2022★★☆☆☆增量优化★★★★★Windows Server 2025★☆☆☆☆核心算法几乎未变★★★★★NVMe、ReFS、Storage Replica、Thin Provisioning 等全面增强6.2 演进趋势图flowchart LR A[2012br/架构 ★★★★★br/栈 ★★★☆☆] -- B[2016br/架构 ★★★★★br/栈 ★★★★☆] B -- C[2019br/架构 ★★★☆☆br/栈 ★★★★☆] C -- D[2022br/架构 ★★☆☆☆br/栈 ★★★★★] D -- E[2025br/架构 ★☆☆☆☆br/栈 ★★★★★] style A fill:#c6efce style B fill:#c6efce style C fill:#fff3cd style D fill:#ffe4e1 style E fill:#ffe4e16.3 关键洞察架构评分逐渐下降存储栈评分逐渐上升——这反映了微软的优先级转移。如果你期待的是 Storage Spaces 像 Ceph、PowerFlex 或 Azure Storage 一样重新设计数据放置算法、引入局部保护组、减少全局重平衡Windows Server 2025并没有朝这个方向发展。它更像是在保留 Storage Spaces 核心架构的前提下把 ReFS、NVMe、Storage Replica 和整个 Windows 存储 I/O 栈打磨得更快、更高效。这一点也反映了微软近年来的发展重点创新更多集中在 Azure Local 和底层存储栈而不是重构 Storage Spaces 的核心元数据与布局算法。7. 微软目前遇到的三个瓶颈【B级】全章三个瓶颈是工程界长期共识但微软也认为这是瓶颈未在官方文档中明确承认。本文表述为业内已知 作者分析。7.1 瓶颈一Metadata 全局管理Storage Pool 越大 - Optimize 越慢 - Repair 越慢 - Rebalance 越慢这是所有 S2D 用户都知道的问题。7.2 瓶颈二Erasure Coding 仍然比较传统今天 Mirror → Rotate → Parity 实际上仍然是 Stripe Column 而不是 Azure Storage 的 Extent → Local Reconstruction Code → Placement7.3 瓶颈三Storage Spaces 与 Azure Storage 已经越来越不像flowchart TB subgraph Azure[Azure Storage] A1[Object] -- A2[Extent] A2 -- A3[Distributed Metadata] end subgraph S2D[Storage Spaces] S1[Storage Pool] -- S2[Virtual Disk] S2 -- S3[Extent Mapping] end style Azure fill:#c6efce style S2D fill:#ffe4e1两条技术路线越来越远。8. 下一代方向预测详细分析【C级】全章警告本章所有概率最高 ★★★★★的预测完全是作者分析不代表微软官方路线图。本文不写微软将 / 一定会 / 已经规划等表述。读者引用本章时请务必标注作者推测。概率打分★ 数量是作者主观评估不是基于任何官方预测。下面是基于微软过去十多年技术演进的分析和预测不是微软已公布的计划。8.1 预测一Metadata 分区化概率最高★★★★★描述今天 整个 Pool 的 Metadata 统一管理 未来 Pool ├─ Partition A ├─ Partition B └─ Partition C 类似 Azure 的 Storage Stamp好处Repair 不再遍历整个 Pool而是只遍历某个 Partition16 Node 集群 Repair 时间可能缩短到原来的 1/4 甚至更少兼容老格式的可能性较高不需要重写整个 Metadata Schema挑战Partition 之间数据迁移策略跨 Partition 副本的 Fault Domain 处理评估★★★★★最可能兼容性好、收益明显8.2 预测二引入 Placement GroupPG★★★☆☆描述Ceph 的做法 Object → PG → CRUSH → OSD 微软可能改成 Storage Pool └─ Placement Group └─ Extent好处新增 Node 不会触发整个 Pool 的 Rebalance只迁移部分 PG性能提升显著问题Metadata 全部要升级兼容性困难所有 Pool 需升级或迁移评估★★★☆☆技术收益大但兼容成本高8.3 预测三引入 Azure Storage 风格算法★★☆☆☆描述今天的 ParityStripe Column 未来可能Extent Local Reconstruction Code好处Repair 速度会快很多大容量 SSD 场景特别受益问题Windows Kernel 几乎全部重写风险巨大评估★★☆☆☆收益明显但风险极高8.4 预测四Object Storage 融合★★☆☆☆描述微软已经越来越云化。 Azure Local 以后可能不仅支持 Block还支持 Object。 Storage Spaces 直接支持 S3 也不是没有可能。问题Windows 一直没有对象存储传统S3 兼容带来新的 API 层、新的安全模型评估★★☆☆☆方向有意思但远期8.5 预测五ReFS 越来越重要★★★★★已经在发生描述以前 Storage Spaces 负责很多工作 现在 VM → ReFS → Storage Spaces 很多智能实际上已经放到 ReFS - Block Clone - Dedup - Compression - 冷热数据 未来更多功能会放到 ReFS。 Storage Spaces 越来越简单。评估★★★★★已经在发生方向确定8.6 预测六Storage Spaces 逐渐冻结★★★☆☆描述还有另一种可能——微软以后根本不大幅改 Storage Spaces。 原因 - Azure Local 现在主要规模 2~16 Node - Storage Spaces 已经够用 - 微软未来更多资源放到 Azure - Storage Spaces 只是维护评估★★★☆☆这种可能性其实不小8.7 我个人最期待的架构如果让我重新设计下一代 Storage Spaces我不会完全照搬 Ceph 或 Azure Storage而是更希望微软采用一种混合模式兼顾 Windows 兼容性和大规模扩展Storage Pool │ ▼ Protection Group新增 │ ├─ PG001 ├─ PG002 └─ PG003 │ ▼ Extent │ ▼ Physical Disk特征每个 Protection Group 只有 4~8 Node新增 Node 时只迁移少量 PGRepair 也是 PG 级别Metadata 分片管理好处Storage Spaces 还能兼容 Windows扩容能力接近 Ceph9. Ceph / vSAN / PowerFlex 对比参照【C级】全章本章横向对比基于公开资料整理不是各厂商官方对比。各系统版本演进很快对比表只反映本文撰写时点的作者理解。9.1 分布式 SDS 的关键特性对比特性S2D / Azure LocalCephVMware vSANDell PowerFlex数据放置算法Fault Domain Aware Column 选取CRUSH 哈希策略 WitnessMDM 决策Placement Group❌ 无✅ 有✅ 间接Stretched Cluster✅ 有Protection Domain局部修复❌ 全局 Metadata✅ PG 局部✅ Component✅ 有扩展上限16 NodeAzure Local千级 OSD64 Host千级 Node数据单位Slab RegionObjectComponentPage副本策略静态 Mirror/ParityCRUSH 动态静态 见证静态 MDMErasure CodingDual ParityJerasure / ISA-LRAID-5/6LRC 风格9.2 关键差距mindmap root((S2D 与 Ceph/vSAN 的差距)) 缺乏 PG 全局 Metadata 瓶颈 Rebalance 全局触发 缺乏 LRC Repair 必须读全 Stripe 大容量盘 Repair 慢 缺乏动态副本策略 副本策略建卷时定 不能按热度自动调整 缺乏可扩展上限 Azure Local 16 Node 上限 Ceph 可至千级9.3 微软如果想缩小差距最可能的方向短期1~2 年Metadata 分区化最高概率中期3~5 年引入 PG中等概率长期5 年Azure Storage 风格算法重构低概率10. 三层架构演进模型【C级】全章本章三层架构是作者对微软存储产品体系的归纳模型不是微软官方架构图。Azure Storage / Azure Local / Storage Spaces 三层共存是观察结论不是微软公开承诺。10.1 微软存储的三层栈flowchart TB A[Azure Storagebr/云原生分布式存储br/持续快速演进] B[Azure Localbr/混合云平台能力br/获得更多新功能] C[Windows Storage Spacesbr/稳定、兼容的基础存储层br/保持成熟稳定] A -- B B -- C style A fill:#c6efce style B fill:#fff3cd style C fill:#ffe4e110.2 三层的不同优先级层级演进速度创新重点兼容性要求Azure Storage★★★★★快新算法、新功能低云原生Azure Local★★★★☆混合云、Arc 集成中企业混合Windows Storage Spaces★☆☆☆☆慢稳定、Bug 修复高Windows 生态10.3 为什么可能形成三层架构从近几年的产品策略来看Windows Server 更强调稳定、长期兼容和企业部署Azure Local 获得了更多新功能例如机架感知、云管理、Arc 集成等Azure Storage 则继续在公有云中快速演进如果这一趋势持续Storage Spaces 更可能保持为一个成熟稳定的底层引擎而新的分布式能力、智能调度和云化特性则逐渐在 Azure Local 或更高层的软件中实现而不是彻底重写 Storage Spaces 本身。这种路线既符合微软近年来对兼容性的重视也符合其**云优先、混合云优先**的发展策略。11. 总结【C级】全章总结中的判断基于本文前三篇 第四篇的分析不代表微软官方表态。11.1 核心判断Windows Server 2025 是存储栈升级不是Storage Spaces 架构升级微软的核心创新在 ReFS NVMe Storage Replica Thin ProvisioningStorage Spaces 核心算法几乎未变下一代最可能的演进方向是 Metadata 分区化 ReFS 接管更多智能更激进的 PG / LRC / 重构在可见的未来不太可能发生三层架构Azure Storage / Azure Local / Storage Spaces可能是长期共存形态11.2 综合概率预测方向概率原因ReFS 成为真正的数据管理层★★★★★微软近几年几乎所有创新都优先落在 ReFSMetadata 分区化★★★★★能显著改善 Repair、Optimize同时兼容现有架构NVMe-oF、RDMA、GPU Direct 等高速 I/O 深度整合★★★★☆AI 工作负载和高性能存储会持续推动这方面发展局部重平衡类似 Protection Group★★★☆☆技术收益很大但需要解决元数据兼容问题采用 Azure Storage / LRC 风格纠删码★★☆☆☆收益明显但几乎等于重写 Storage Spaces完全重构 Storage Spaces★☆☆☆☆兼容性成本极高Windows 生态很难接受11.3 对企业部署的指导flowchart LR A[企业部署 Azure Local] -- B[不要期待 S2D 变 Ceph] A -- C[关注主线] C -- C1[Azure Local Arc] C -- C2[ReFS 增强] C -- C3[Storage Replica] A -- D[性能优化重点] D -- D1[NVMe Driver] D -- D2[RDMA] D -- D3[网络架构] style A fill:#fff3cd具体建议不要期待 Storage Spaces 会变成另一个 Ceph——它会更稳定但不会大改应该关注 Azure Local Arc ReFS Storage Replica 这条主线——微软的创新主要在这性能优化重点放在 NVMe Driver RDMA 网络而不是 S2D 算法2~16 Node 是 S2D 的舒适区——超出这个规模考虑其他方案MAP 是性价比最高的通用卷方案——Mirror 兜随机写Parity 兜容量RAC 是企业级可靠性的标配——尤其多机房场景附录四篇文档索引篇标题重点第一篇Azure Local / Storage Spaces Direct 五层数据布局原理Slab / Column / Region / Fault Domain第二篇Mirror / Parity / MAP 数据流与 Region Rotation副本轮转、双校验、Rotate 时序第三篇3 节点强制 3-way / 4 节点 Parity / 单校验淘汰故障域设计哲学、部署决策树第四篇Windows Server 2025 存储栈升级与下一代方向预测演进对比、未来预测、三层架构附录写作约定贯穿四篇表述含义微软官方硬性表述出自微软官方文档原文微软隐含 / 默认行为来自文档描述但未明确必须基于已公开文档的推断综合多个文档的合理推断经验区间实际部署中观察到的范围不是官方数字概率预测基于演进而非微软公告文档结束附录 D新增 · v4.0引用本文的三个边界本节是系列定位的核心——主动划清微软公开事实与作者工程分析的边界。 读者引用本文时优先参考本节确认哪些内容可作为微软事实引用。D.1 微软公开的事实与本篇相关概念公开程度关键来源NVMe I/O 路径优化✅ 完全公开Windows Server 2025 存储博客ReFS 原生 Dedup / Compression✅ 完全公开Microsoft Learn - ReFS featuresStorage Replica Compression✅ 完全公开Microsoft Learn - Storage ReplicaStorage Spaces 新增功能部分⚠️ 版本依赖Azure Local release notesFault Domain✅ 完全公开Azure Local hardware requirementsNumberOfColumns✅ 完全公开New-VirtualDisk cmdlet 文档D.2 微软未公开的内容本篇相关内容公开程度备注❌未来 5 年演进路线图微软未公开微软不会公布长期路线图❌下一代具体技术方向微软未公开本文 §8 全部为作者推测❌Metadata 分区化等具体技术细节微软未公开本文 §8.x 预测无官方依据❌概率打分 ★ 数量微软未公开作者主观评估❌三层架构模型微软未公开本文 §10 是作者归纳❌Ceph / vSAN / PowerFlex 的对比细节各厂商公开但非权威本文 §9 是作者横向对比D.3 引用本文的三个边界边界 1可作为微软事实引用本文有【A级】标记的内容§1-4附录 D.1 中标 ✅ 的概念Microsoft Learn 上能直接找到对应文档的概念边界 2可作为作者基于公开行为的工程分析引用本文有【B级】标记的内容§6 / §7但引用时需注明作者分析跨厂商对比§9属于此类边界 3不可作为任何事实引用本文有【C级】标记的内容§5 / §8 / §10 / §11§8 下一代方向预测全部为作者推测§10 三层架构模型为作者归纳任何概率打分 ★ 数量D.4 给读者的最终建议把本文作为理解 WS2025 / Azure Local 存储栈演进 作者推测的工程读物§1-4 可放心引用为微软事实——这些是公开功能§8 预测务必标注作者推测——引用时不要写成微软预测 / 微软路线图本文不能替代Microsoft Learn / Azure Local release notes附录 A本文的证据等级分布自检表章节主要证据等级说明§0 引言A B C三层声明分别标级§1 NVMe 存储栈A B优化方向 A 级具体倍数 B 级§2 ReFS 增强A微软官方明确的功能改进§3 Storage ReplicaA微软官方功能§4 Storage Spaces 新增B部分功能版本依赖 B 级§5 为什么没重写C作者产品策略分析§6 演进对比表B主观评分作者整理§7 三个瓶颈B业内共识作者归纳§8 下一代预测C最重全部为作者推测§9 跨厂商对比C作者对比非官方§10 三层架构模型C作者归纳模型§11 总结C作者综合判断声明本表为作者自检用途方便读者快速定位每一章的可信度。任何段落的【A级】/【B级】/【C级】标记以正文为准。v4.0 修订说明2026-07-13本次修订按ReFS 与 Storage Spaces 协同工作原则做风格收尾未做大规模改写。 主要改动如下§0 引言顶部加写作约定声明—— 明确 ReFS/SS 协同、Column ≠ Physical Disk、§8 严格 C 级、§9 跨厂商对比、§10 三层架构模型§8 之前所有下一代加引号—— 强调下一代是作者预测用语不是微软官方表述附录 D 新增三个边界—— 与第 1 / 2 篇对齐作为系列定位核心本文 v3.0 已基本成熟本次修订主要是按系列统一标准做风格收尾。 如读者反馈更多实质性错误将启动 v5.0 修订。附录 B引用本文档时的注意事项如果要在博客、论文或企业内部文档中引用本文建议明确区分 A / B / C 级——不要把 C 级推断当作微软事实陈述§8 预测全部为作者分析——引用时务必标注作者推测不要写成微软预测 / 微软路线图概率打分 ★ 数量是主观评估——不是基于任何官方预测§10 三层架构模型是作者归纳——不是微软官方架构图避免引用下一代方向 / 概率最高作为微软承诺——本文明确不写微软将 / 一定会本文与前三篇的术语对照——见附录 C数据布局相关结论要注明版本——本文基于 Azure Local 2506 / 2510 / Windows Server 2025附录 C四篇术语对照表系列总览系列术语微软官方术语第 1 篇第 2 篇第 3 篇第 4 篇内部单位 / Slab未公开✓✓--Column未公开✓✓--64 MiB Region✓✓✓--MAP / Mirror-Accelerated Parity✓-✓-✓3-way Mirror✓-✓✓-Dual Parity✓-✓✓-Fault Domain✓✓✓✓-RACRack Aware Cluster✓✓✓✓-ReFS✓✓✓-✓Storage Replica✓---✓Thin Provisioning✓---✓使用说明本系列四篇文档均使用一致的 A / B / C 证据等级标记术语首次出现时已注明微软是否官方使用。引用时请按本文档对应章节的证据等级标注。
