容量转速都一样的两块盘为什么差一截价：CMR 与 SMR 的写入模型差在哪

两块容量和转速都一样的机械盘，报价能差出一截。差的这个东西，叫记录方式。

第一次遇到这事的人，多半以为是渠道、保修年限或者"企业级/监控级"的定位差异，转头去跟供应商砍价。砍几轮会发现砍不动——因为这两块盘确实不是同一种东西。它们在盘片上摆放磁道的方式不一样，而这件事直接决定了写入的时候盘内部会发生什么。前者叫 CMR，磁道一条挨一条并排摆；后者叫 SMR，磁道像屋顶瓦片一样一层压着一层。后者靠"叠起来"换来了更高的单盘容量和更低的单位容量成本，代价是写入模型被整个改掉了。

本篇只回答一个问题：同样容量、同样转速的机械盘为什么会差出一截价，这种盘用在什么场景会出事。读完你只需要记住一句——SMR 不是次品，它是一套"为归档设计的写入模型"，把它放到数据库、日志和阵列成员盘上，才是真的会出事。

• 价差来自记录方式，不是缩水：SMR 让磁道部分重叠，换来更高的单盘容量与更低的单位容量成本，代价是原地覆写被禁止。
• 随机写会被放大成整带重写：改一个位置的数据，得先把整条带读出来、改完再顺序写回去，这就是"读-改-写"，写放大和延迟长尾由此产生。
• 盘里那块高速缓存区把问题盖住了：短时间、小数据量的拷贝测试基本测不出异常，持续写入越过这块缓存区之后才会进入明显的降速阶段。
• 真正危险的场景是阵列重建：重建本身就是一次覆盖全盘的连续写入，会长时间落在降速区间，重建耗时从小时级被拖到天级。
• 采购清单上必须把"记录方式"写死：只写容量和转速，等于把选择权交给了供应商的库存。

报价差出来的那一截，差的既不是容量也不是转速

先说采购现场最常见的情形。需求方给供应商一张清单，上面写着容量、转速、接口、数量，最多再加一句"要企业级"。供应商回两份报价，容量一样、转速一样、接口一样，价格差出一截。这时候大部分人会默认贵的那个是"企业级"、便宜的那个是"监控级"或者"渠道货"，然后按预算挑一个。

这个判断方式在几年前还能用，现在经常失灵。因为单价的差距里，真正占大头的一项往往不是定位，而是记录方式。同样是面向桌面或小型办公场景的大容量盘，采用传统磁记录和采用叠瓦式磁记录的两种方案，单位容量成本天然就有差距——后者在同样的盘片面积上能塞下更多磁道，单盘容量更容易往上顶，摊到每 TB 上的成本自然更低。这不是偷工减料，这是两套不同的物理设计，各自有各自合适的用处。

问题出在：记录方式这件事，在很多渠道报价单上是不写的。它不像容量、转速那样有明确的数字可以对照，也不像接口那样插不上就发现得了。它藏在一个"装上去能用、跑起来也不报错"的灰色地带里，直到某天业务负载发生变化，或者某块盘坏了需要重建，才突然以非常难看的方式暴露出来。

所以那句"为什么差一截价"的正确答案是这样的：贵的那块保留了传统磁记录的写入模型，允许你在任意位置原地覆写；便宜的那块用磁道重叠换容量，写入模型被改成了"只能顺序追加、改写要整段搬"。你省下的那部分钱，本质上是把一部分写入性能和一个确定性的延迟承诺，换成了容量。这笔交换在归档场景里非常划算，在数据库场景里就是一场事故。

CMR 与 SMR 的物理差别：磁道是并排排还是叠着排

机械盘的盘片上，数据是一圈一圈的同心圆，每一圈叫一条磁道。传统磁记录（CMR， Conventional Magnetic Recording）的做法是让这些磁道并排摆放，磁道与磁道之间留出足够宽的隔离带。留出隔离带是有原因的：写磁头本身的宽度要大于一条磁道的宽度，如果磁道之间不留余量，写一条磁道的时候就会把旁边那条已经写好的数据顺带抹掉。

有了这个余量，写头在写某一条磁道时，即使它的磁场覆盖范围比磁道更宽，超出部分也落在隔离带上，不会伤到邻居。这就带来一个非常关键的性质：任意一条磁道都可以被单独、就地地重写，而不影响任何其他磁道。这也是几十年来整个存储软件栈——文件系统、数据库、阵列控制器——默认的前提假设。所有的"随机写"之所以叫随机写，就是因为大家默认"我可以在任何位置改一个块"。

叠瓦式磁记录（SMR，Shingled Magnetic Recording）把这个前提拿掉了。它的做法就像铺屋顶瓦片：后铺的那片瓦压住前一片的一部分。放到盘片上，就是后写入的磁道部分覆盖在前一条磁道之上，把前一条磁道的有效宽度"削窄"了。这样一来，磁道之间不再需要那么宽的隔离带，同样的盘片面积能排下更多磁道，单盘容量就上去了。容量和成本上的收益，全部来自这一步。

代价同样直接：既然后写的磁道压着先写的磁道，那么"就地重写"就变成了不可能——你想改中间某条磁道上的数据，写头一旦落下去，就会顺带破坏紧邻的那条（在叠瓦顺序上后写的）磁道上的有效数据。于是 SMR 盘给自己加了一条硬性约束：叠瓦区只能顺序写。盘片上的叠瓦部分被组织成一个个"带"，带内必须从起始位置开始、顺着磁道的叠瓦顺序一条一条往下写，不能回头插队。

"读-改-写"是怎么被逼出来的：随机写在 SMR 上为什么会放大

把上面那条约束和主机发下来的写入请求对上，就能看懂 SMR 上最要命的那件事了。

假设主机要改某一个逻辑块，而这个块恰好落在某条带的中间位置。盘固件不能直接写——直接写会毁掉后面磁道上的数据。它能做的只有一件事：先把这条带上、目标位置之前和之后所有还有效的数据读出来，在盘内缓存里跟新数据合并，然后从这条带的起始位置开始，把整条带顺序重写一遍。这就是"读-改-写"（Read-Modify-Write）。一次主机看来极小的写入，在盘内部变成了一次读 + 一次大幅度的重写，写入量被放大了不止一个量级。

更麻烦的是这个放大是不可预测的。改一个块要整带重写；改一万个块，如果它们恰好落在同一条带里，也只需要一次整带重写；但如果它们分散在不同带上，就是一万次整带重写。也就是说，SMR 盘的写入表现不取决于"你写了多少"，而取决于"你写在哪"。同样是改一批数据，落点连续和落点分散，内部工作量可以差出好几个量级，而主机这边看到的只是延迟忽高忽低、长尾拉得很长。

反过来，纯粹的顺序写是 SMR 最舒服的状态。因为顺序写本来就沿着带的顺序往前走，跟磁道的叠瓦方向一致，不需要任何读-改-写，也不产生写放大。这也是为什么很多用过 SMR 盘的人会说"我这盘挺快的啊"——他们干的事基本就是拷大文件、做备份，全是大块顺序写，正好踩在 SMR 的舒适区里。真正会翻车的是另一类负载：小块的、随机分布的、持续不断的写。数据库的事务提交、日志的滚动追加、虚拟机的写时复制、邮件服务器的索引更新，全是这一类。

这里还有一层容易被忽略的连锁反应：如果一条带的容量已经被写满，而这次改写需要的数据量比原来更大（比如文件系统把一段连续区间扩写了），那么这条带放不下，就会波及下一条带，形成级联搬移。固件在后台处理这些搬移是要占资源的，而此时主机还在继续下命令。于是你会看到一个典型的症状：写入还在进行，但延迟的抖动幅度越来越大，偶尔出现几秒级的"卡顿"，而监控上看 IOPS 似乎没降多少。

盘里那块高速缓存区：为什么短时间测试看不出问题

如果 SMR 的写入模型这么别扭，为什么很多人拿到盘、装上、拷几个文件，完全感觉不到异常？答案在盘内那块相对高速的缓存区上。

绝大多数 SMR 盘都会在内部划出一块按普通磁记录方式管理的区域，行业里常叫介质缓存或者持久缓存。这块区域不叠瓦，可以接受随机写、可以就地覆写，行为跟传统盘几乎一样。固件的工作方式是：主机写进来的数据，先落在这块高速区域里；等盘空闲下来，或者后台整理的条件满足了，再把这些数据在空闲时段顺序搬迁到叠瓦区里去。这个过程对主机是透明的，主机只看到"写完了"。

这套设计在工程上是合理的——绝大多数负载都有忙闲交替，闲的时候把活干完，主机全程感受不到叠瓦的存在。但它有一个非常明确的边界条件：主机写入的速度和总量，必须在这块缓存区的承接能力和后台搬迁速度之内。一旦持续写入的量越过了这块区域，或者后台搬迁的速度追不上主机写下来的速度，盘就没有退路了，只能把写入直接落到叠瓦区上，读-改-写开始大规模出现，速率随之阶段式地掉下去，并在相当长一段时间里维持在这个低位。

这就解释了那个最经典也最坑人的测试方法为什么是假阴性：拿一个几十 GB 的文件往盘上拷，或者跑一个几分钟的写入测试，写入量根本不足以越过那块缓存区，后台搬迁也完全来得及，测出来的曲线跟传统盘没区别。要真正看到 SMR 的写入模型，测试必须同时满足三个条件——写入总量要明显大于盘内那块缓存区、写入要持续不断不给后台留整理窗口、负载里要包含一定比例的随机小块写。三条缺一条，测出来的结论都不可信。

顺带说一句，这也解释了为什么"降速"这件事很难在短时间复现、却几乎必然在长时间任务里出现。备份、重建、全盘初始化、数据迁移，这些任务的特征恰好都是"不间断地写一大片"，正好是全条件命中。具体的降速幅度与持续时间因厂商实现、盘内缓存区大小与实际负载而异，需以厂商规格与实际负载为准，但"越过某个点之后会出现一段明显变慢的时期"这件事，是这类盘的共性行为。

最危险的场景不是日常读写，是阵列重建

现在把镜头切到 RAID 上，这才是本篇真正想让你警惕的地方。

带冗余的阵列里坏了一块盘，换上新盘之后要做的那件事叫重建。控制器会按条带把其余成员盘上的数据读出来，通过校验算出丢失的那部分，再一块一块写到新盘上。从新盘的角度看，这是一次几乎覆盖全盘的、大体连续的、中间不停顿的写入。

把这句话和上一节对照一下，问题就清楚了：持续、不间断、总量覆盖全盘——三条全中。日常业务负载虽然也可能很重，但它有忙有闲，闲的时候盘可以做后台整理，把缓存区腾空；重建不给这个窗口，它是从头写到尾的一条直线。所以重建过程几乎必然会越过盘内的高速缓存区，然后长时间落在那个降速区间里跑完全程。

而降速带来的后果，在重建这个场景里是会被二次放大的。因为重建期间阵列处于降级状态，业务并没有停，主机还在继续下读写命令；同时控制器还要从其他成员盘上读数据算校验。写入、读取、校验三件事挤在同一组盘上，而此时写入方的速率已经掉了一大截。结果就是重建耗时被显著拉长——从小时级被拖到天级，这是行业里对这类盘在阵列中最常报告的现象，具体数值以实际盘型、容量与负载为准。

还有一层容易被人忽略的压力：重建是一次全盘高强度读，所有成员盘会同时长时间处在满负荷状态。同一批采购、同一批上电、老化程度接近的盘，在这种集中压测式的负载下，本来就是最容易暴露潜在问题的时候。也就是说，重建这个动作本身就是阵列生命周期里风险最集中的一段时间，而 SMR 把这段时间拉长了数倍。

被拉长的重建窗口里，真正要命的是第二块盘

为什么"重建时间变长"这件事值得单独拿出来说？因为它不是单纯的"慢"，它是把一段风险窗口按比例拉长了。

单冗余阵列（比如 RAID5）在重建期间是没有冗余余量的：任何一块成员盘再出问题，整个阵列直接失效。双冗余阵列（比如 RAID6）在重建期间只剩一份余量，第二块盘出问题还能撑住，第三块就不行了。换句话说，重建窗口的长度，几乎等价于"系统暴露在不可承受故障之下的时长"。这个窗口每拉长一倍，撞上第二次故障的概率就往上走一截。

而第二次故障一旦发生，代价的形态就完全变了。不再是"重建慢一点"，而是：阵列崩溃、业务中断、数据需要从备份里整体恢复。恢复意味着从备份介质上把全量数据拉回来，这个过程本身又要花很长时间，中间业务要么停着要么跑在严重降级的状态。这时候你回头看当初采购时省下的那点盘钱，会发现它跟这次中断的损失根本不在一个量级上。

所以关于 SMR 能不能进阵列，我的立场很明确：不建议，尤其是在单冗余阵列里，尤其当这个阵列承载的是核心业务数据时。这里要区分两个问题——"能不能跑起来"和"出事时会不会崩"。SMR 盘进 RAID 组，跑起来完全没问题，日常读写也不见得慢，看上去一切正常。但阵列的价值恰恰体现在出事的那一刻，而出事的那一刻，它需要的正是"长时间、不间断、全盘顺序写"这种负载，正好是 SMR 最不擅长的那一种。你花钱买冗余是为了扛故障，结果冗余生效的那一次，被盘自己的写入模型拖住了。

说白了，SMR 在阵列里的代价不是性能数字，是风险窗口的长度。性能慢你还能忍，窗口长你忍不了——因为你不知道第二块盘什么时候掉。

怎么判断手上的盘属于哪一种：厂商标注、型号核对、写入行为反推

道理说完了，落到操作上：一批盘摆在你面前，怎么知道它们是哪种记录方式？有三条路，建议三条一起用，不要只信其中一条。

第一条：看厂商标注，但要知道标注不一定在你手上

正规厂商的产品页和规格文档里，通常会给出记录方式这一项，写法可能是缩写，也可能是"传统磁记录/叠瓦式磁记录"这样的中文表述。采购时最直接的办法，就是让供应商提供该型号对应的官方规格文档，把这一项圈出来。要注意的是，很多渠道商的销售页面为了省事，只保留容量、转速、接口、缓存这几个字段，记录方式根本不出现——不出现不等于不存在，也不等于就是传统磁记录。

第二条：按具体型号核对，不能按系列一概而论

这是最容易踩的坑。同一个系列、同一个品牌下，不同容量段完全可能采用不同的记录方式——厂商为了把容量顶上去，往往是在系列里的高容量型号上引入叠瓦，而低容量型号保持传统磁记录。所以"这个系列我查过，是传统磁记录"这种结论是无效的，必须核到具体型号，甚至核到具体尾缀与固件版本。

更麻烦的是同一型号在不同批次、不同渠道也可能存在差异。所以真正稳妥的做法，是在合同或者配置确认单上把这一项写成交付要求，而不是靠口头承诺或者一份历史文档。下单前多问一句，比事后对簿公堂便宜得多。

第三条：用写入行为反推，把它当辅助证据

如果前两条都走不通（比如盘已经在跑了，文档找不到了），可以用行为来反推。方法的核心是制造一个"必然越过盘内高速缓存区"的写入场景：找一个空闲时段，对这块盘做一次持续时间足够长、总量足够大的连续写入，同时把速率曲线记录下来。如果曲线在中后段出现一个明显的台阶式下降，并且之后长时间维持在这个低位不再回升，这是叠瓦式写入模型的典型指纹。

再补一个随机写为主的负载，观察延迟分布：如果平均延迟看起来还行，但长尾特别长、偶尔出现明显卡顿，同样是这类盘的特征。需要提醒的是，这条路径只能作为辅助判断，不能单独定性——后台有其他任务、盘上有坏块重映射、控制器缓存策略变化，都可能造成类似的曲线。而且这类测试必须在非生产盘上做，别在跑着业务的盘上跑全盘写入。

还有一个很好用的旁证维度：面向企业级阵列设计的盘，通常会在固件行为上做一整套约束（比如错误处理时限、对阵列控制器的兼容性），厂商也会维护一份阵列兼容性列表。如果一块盘的产品定位明确写着面向企业级阵列、并且出现在主流阵列厂商的兼容列表里，它的记录方式通常不会是那种只适合归档的方案。反过来，定位里出现"归档""备份""冷存储""一次性写入"这类词，就要多留一个心眼。

SMR 真正该待的地方：归档、备份、冷数据，以及采购清单上该怎么写

讲了这么多风险，得把话说回来：SMR 不是坏东西，它只是被放错了地方。

适合它的场景有一个共同的画像——写一次，读多次，几乎不改。冷数据归档、备份落地、监控录像的流式追加、对象存储的冷层、历史影像资料的沉淀池，全都是这个画像。这些场景的写入特征是长时间的大块顺序追加，正好踩在 SMR 的舒适区里；而"几乎不改"意味着读-改-写基本不会被触发。用更低的单位容量成本去装更多几乎不访问的冷数据，这笔账怎么算都划算。

要特别提醒的是"备份"这个场景需要再细分一层。备份的写入动作本身（全量落地）是顺序的、友好的；但如果你用的是带有去重、合成全备、或者增量合并机制的备份软件，它会在备份介质上做大量的读取与改写操作，写入特征就从"顺序追加"变成了"随机改写"。这种情况下 SMR 盘的表现会明显不同。判断标准很简单：看这套备份方案落地之后，是否还会回过头去修改已经写进去的数据块。

不适合的场景同样清楚：数据库与交易型业务、虚拟机镜像与容器运行时、日志与指标采集、邮件服务器、版本库与 CI 产物、搜索引擎索引，以及任何以随机小块写为主的业务。还有一条要单独拎出来——阵列成员盘，尤其是那些承载核心业务的阵列。这一条不接受"但是我们的负载很轻"这种辩解，因为决定风险的是重建那天发生什么，而不是今天有多闲。

采购清单该怎么写？把字段从"容量 / 转速 / 接口"扩成五项：容量 / 转速 / 接口 / 记录方式 / 适用场景。记录方式这一栏直接写"CMR（传统磁记录，非叠瓦式）"，不要写"等效容量""同容量替代""同系列更高容量"这种模糊表述——这些措辞存在的唯一作用，就是给交付时换盘留空间。适用场景这一栏写清楚是给数据库、阵列还是归档用，让供应商在报价阶段就知道你要的是什么。验收环节再加一道：要求提供实际交付的型号清单，以及对应型号的厂商规格文档。

租用或者定制存储型机型也是同一个道理。与其等机器交付之后再逐块盘去反推，不如在下配置单的时候就把记录方式这一项写进去。像一万网络这样深耕 IDC 19 年（成立于 2007 年）、承接存储型机型配置的商家，配置确认阶段是可以把这一项明确下来的；具体机型与价格需实时询价，以签约时最新报价与合同为准。

这张表怎么看？别只看最后一列的"建议"，要看第三、四列之间的差值。差值越大的场景（数据库、日志、阵列重建），越不能碰 SMR；差值越小甚至反过来有优势的场景（归档、流式追加），才是它该待的地方。具体表现以厂商规格与实际负载为准。

买盘时最容易踩的四个坑

坑一：只按容量和转速下单

为什么坑：这是本篇讲的那个问题的源头。容量和转速相同的两块盘，记录方式可能完全不同，写入模型也完全不同。你的清单上不写这一项，供应商按什么发货都不算违约——你连追责的依据都没有。而对供应商来说，在没被约束的情况下按库存和成本最优发货，是再正常不过的商业行为。

怎么判断自己有没有踩：翻出你最近一次的存储采购清单或者服务器配置确认单，看看上面有没有"记录方式"这一栏。如果只有容量、转速、接口、数量，那就是踩了。补救办法也很简单：在合同或配置单的交付要求里补上"CMR（传统磁记录，非叠瓦式）"，并加一句"以厂商官方规格文档为准"。

坑二：用短时间拷贝测试判断一块盘

为什么坑：盘内那块高速缓存区专门就是为了让短时间、小总量的写入看起来跟传统盘一样。你拷几分钟文件测出来的曲线，测的是缓存区，不是叠瓦区。这个测试的结论是假阴性——它告诉你"没问题"，但它根本没有触及真正会出问题的那部分。

怎么判断自己有没有踩：回想一下你的验收流程：写入测试跑了多久、总量多大？如果总写入量只有几十 GB、或者只跑了几分钟，那基本可以判定结论不可信。有效的测试必须让写入总量明显超过盘内缓存区、持续时间足够长且不给后台整理留窗口，同时负载里要有随机小块写。另外别忘了，这种测试要在非生产盘上做。

坑三：把 SMR 盘放进 RAID 组

为什么坑：因为重建那一天会发生什么是确定的。重建是一次覆盖全盘的、不间断的连续写入，它一定会越过盘内缓存区，一定会在降速区间里跑完全程。你买的冗余在真正生效的那一次被拖慢了数倍，而这段时间里阵列处于降级状态、没有余量。这不是"可能慢"，这是"必然慢，且慢在有风险的那段时间里"。

怎么判断自己有没有踩：对已经在跑的阵列，把成员盘的型号逐个核出来，再按型号去查厂商规格文档里的记录方式。核不出来就用行为反推：找维护窗口，在备份盘上做一次足够长的连续写入看曲线。如果确认组里混了叠瓦式盘，优先规划替换——先把热数据阵列换掉，冷数据阵列可以排到后面。还有一点要留意：同一阵列里成员盘的型号最好保持一致，混合不同记录方式会让重建行为更难预测。

坑四：拿 SMR 盘当数据库盘或日志盘

为什么坑：这两类负载的写入特征恰好是叠瓦式写入模型最怕的那一类：小块的、随机分布的、持续不断的、还经常就地更新。数据库的事务提交和索引维护会持续触发读-改-写；日志看起来是追加，但滚动清理和索引更新会把随机写带进来。结果是写放大持续存在、延迟长尾被拉长，业务侧的表现就是"时快时慢，说不清为什么"。

怎么判断自己有没有踩：看延迟分布，不要只看平均值。如果一块盘的写入平均延迟看着还行，但延迟的尾部很长、偶尔出现明显卡顿，而且这种现象在写入持续时间变长之后越来越频繁，那就要警惕了。再结合型号核对去确认。这类问题最讨厌的地方在于它不会报错——盘是健康的，SMART 也正常，只是慢得莫名其妙。

买大容量机械盘时被问得最多的几件事

Q1：SMR 盘能不能当系统盘用？

不建议，理由跟数据库盘是一样的。操作系统盘看着读写量不大，但它的写入特征其实相当糟糕：系统日志、临时文件、页面交换、包管理器的更新、各种守护进程的状态文件，这些全是小块的随机写，而且是从开机到关机从不间断。更要命的是系统盘的写入没法"择时"，你没法让它等到空闲再去整理。所以即便只是装个系统，也建议用传统磁记录的盘，或者干脆用固态盘——系统盘对容量要求通常不高，没必要为了容量去承受那个写入模型。

Q2：已经在跑的盘，怎么判断它属于哪一种记录方式？

三条一起用。第一条查型号：把盘的实际型号（含尾缀）抄下来，去查厂商的官方规格文档，记录方式这一项通常会明确给出。第二条查定位：看这款盘的产品定位是面向企业级阵列、面向监控、还是明确写着归档/备份/冷存储，后两类要多留心。第三条用行为反推：找维护窗口，在非生产盘上做一次持续时间足够长、总量明显超过盘内缓存区的连续写入，同时记录速率曲线，看中后段有没有出现台阶式下降并且长期不回升；再补一轮随机写负载看延迟长尾。三条里如果有两条指向同一结论，基本就可以定下来了。别在跑着业务的盘上做这种测试。

Q3：SMR 盘能不能组阵列？

技术上能跑起来，但我明确不建议，尤其是单冗余阵列。理由不是日常性能，是重建：重建是一次覆盖全盘的、不间断的连续写入，必然越过盘内高速缓存区并在降速区间里跑完全程，重建耗时从小时级被拖到天级。而这整段时间里阵列处于降级状态、没有冗余余量，第二块盘在这期间出问题就是阵列崩溃。如果你现在已经有这样的组合在跑，优先规划替换，先替换承载核心业务和热数据的阵列，冷数据阵列可以往后排；替换时最好整组一起换，让成员盘保持一致。

Q4：备份和归档用 SMR 合适吗，要注意什么？

归档和冷数据池是它最合适的地方，甚至可以说这类盘就是为这个场景设计的：写入是一次性的大块顺序写，之后几乎不改写，读-改-写基本不会触发，容量和成本优势能充分发挥。备份场景需要多分一层：如果你的备份方案是"全量落地、之后只读"，那没问题；但如果方案里带去重、合成全备、增量合并这类机制，备份软件会回过头去修改已经写进去的数据块，写入特征就从顺序追加变成了随机改写，这时候表现会明显不同。判断方法很直接——看这套方案落地之后还会不会改写已写的数据块。另外备份盘还有一个常被忽略的点：恢复速度。演练一次完整恢复，记下耗时，别等真出事那天才知道要多久。

Q5：采购清单上这一项到底该怎么写才不会买错？

把字段从三项扩成五项：容量、转速、接口、记录方式、适用场景。记录方式这一栏直接写"CMR（传统磁记录，非叠瓦式）"，不要用"等效容量""同容量替代""同系列更高容量"这类模糊措辞——这些说法存在的意义就是给交付时换盘留余地。适用场景那一栏写清楚是给数据库、阵列还是归档用，让供应商在报价阶段就明白你的真实需求。验收环节再加一道：要求提供实际交付的型号清单，以及这些型号对应的厂商规格文档，把记录方式那一项圈出来存档。租用或定制存储型机型同理，在下配置单的时候就把这一项写进去，比交付之后逐块盘反推省事得多。

这篇的立场：一句话说完

回到开头那个问题：容量和转速都一样的两块盘为什么差一截价。答案是——SMR 用"让磁道部分重叠"换来了更高的单盘容量和更低的价格，代价是写入模型被改掉了：随机写会触发整带的读-改-写，产生写放大和不可预测的延迟；持续写入越过盘内那块高速缓存区之后，会进入一段明显的降速期。而真正危险的地方不是日常使用，是阵列重建——重建本身就是一次覆盖全盘的顺序重写，一旦撞进降速期，重建时间从小时级被拖到天级，在这个被拉长的窗口里再来一块盘出问题，才是真正的代价。

所以结论就一句话：SMR 只适合"写一次、读多次"的归档与备份，不适合数据库、日志、阵列成员盘，以及任何持续随机写的场景。采购的时候，把"记录方式"这一项在清单上写死，别只写容量和转速。这一栏多写六个字，省掉的是后面一整段说不清的排查和一个说不准什么时候会来的重建窗口。

这篇内容依据的是什么

本文关于 CMR 与 SMR 记录方式差异的部分依据公开的存储技术原理与行业通行运维经验整理，具体以硬盘厂商标称规格与实际负载为准；涉及一万网络的机型与价格需实时询价，以签约时最新报价与合同为准。

文中未引用任何一方的实测数据、跑分结果或具体客户案例，所有关于降速、写放大与重建耗时的描述均为相对表述，不构成对任何具体盘型的性能承诺。如需核对某一型号的记录方式与适用范围，建议以该型号厂商官方规格文档与阵列厂商兼容性列表为准，相关页面可参见 官网 的存储型机型配置说明，或直接向配置承接方索取书面规格确认。