后台扫描器用什么节奏发现位腐：30 天这个数字怎么读

一块盘写入时是好的，三个月后读出来才发现中间有几位变成了别的。这种损坏在写入路径上永远不会被发现，因为写进去的那个字节就是坏的那个。能发现它的只有一条路：在没人读写的时候，把数据重新读一遍、算一遍校验。RustFS 的后台扫描器干的就是这件事，而它的默认节奏是把这件事压到 30 天才做一次。

这个数字容易被读成「RustFS 一个月才检查一次数据」。env 参考页给出的措辞比这更具体，它描述的是周期长度，跟一次巡检跑多少没关系。也别把它读成承诺：2592000 是期望的触发间隔，实际一轮要多久，取决于后面讲的预算和节流，经常比这个值长得多。

一个周期里有浅扫和深扫两件事

扫描器的行为分两层。常规周期负责遍历对象、更新元数据缓存、顺手统计一些异常指标，这一层是廉价的，跑得很勤，默认周期由RUSTFS_SCANNER_CYCLE控制，文档举的例子是 3600 秒。深扫是另一层，它要逐块读数据并做位腐校验，代价高一个数量级，由RUSTFS_SCANNER_BITROT_CYCLE_SECS控制。

这两个变量是分开的，调一个不影响另一个。运维上真正重要的组合关系是：常规周期决定元数据多久刷新一次，深扫周期决定静默损坏最多能在盘上躺多久。前者快一点没有代价，后者快一点直接反映成磁盘读带宽的占用。

RUSTFS_SCANNER_BITROT_CYCLE_SECS的默认值是2592000，也就是 30 天。文档对几个特殊值有明确说明：0、true、on、yes都会让每一个周期都执行深扫，false、off、no、disabled会关掉。把RUSTFS_SCANNER_BITROT_CYCLE_SECS设成0的后果和按默认周期走完全不同：每一轮都会做全量位腐校验，磁盘上会出现一段持续的高读负载。

这一轮到底查到多少，还有两个变量在中间打折。RUSTFS_HEAL_OBJECT_SELECT_PROB默认1024，文档对它的定义是扫描器提交的修复检查按这个分母抽样，大约每 N 个对象挑一个做低优先级的检查；RUSTFS_SCANNER_DEEP_VERIFY_COOLDOWN_SECS默认60，意味着 60 秒之内被改过的对象在当前这一轮会跳过深校验。所以估覆盖率的时候，别按「一轮等于全量走一遍」算，40 GB 的集群和 4 PB 的集群差出来的不是时间，是真实的校验覆盖面。

一个周期跑多久有预算，超了就中断

真正让 30 天这个数字站得住的，是后面那几个预算变量。文档给RUSTFS_SCANNER_CYCLE_MAX_DURATION_SECS的默认值是1800，含义是单个周期最多跑 1800 秒，到点中断，剩下的留到下一轮。另有RUSTFS_SCANNER_CYCLE_MAX_OBJECTS和RUSTFS_SCANNER_CYCLE_MAX_DIRECTORIES两个上限，各自默认0，文档写明0表示不限制。

这组设计的意图很清楚：扫描器不能把磁盘读满。复制一个 PB 级集群的位腐校验，按时长算要几十天也不奇怪，如果允许一轮跑完，它会和线上读写抢带宽。设预算的意思是把工作量切成小块，长时间慢慢磨，宁可让周期往后推也不要在一次运行里把 IO 打满。

RUSTFS_SCANNER_BITROT_CYCLE_SECS=604800 RUSTFS_SCANNER_CYCLE_MAX_DURATION_SECS=2700

反过来，如果集群规模小、磁盘是 NVMe、业务有明确的低峰期，把预算放宽到 2 到 4 小时是合理的，能让深扫在一夜之间跑完。评估的时候按「总对象数除以单轮预算」算一下要几轮，比拍脑袋定时长可靠。

这个算式的结果如果大于一，就要当心另一件事：预算频繁触顶意味着扫描器长期停在「每轮只推进一点」的状态。一轮走不完整个命名空间，下一轮又从上次停下的地方接着走，几轮下来被反复覆盖的还是同一批目录，后面的目录一直排不上。于是坏得早的那批对象始终没被人碰过，而监控上一切正常，读写成功率也是绿的。位腐就是这么攒出来的。

判断这件事有没有发生，看状态接口比看配置值靠谱。/v3/scanner/status里有一组字段可以直接用来判断：

metrics.pacing_pressure里还有last_cycle_throttle_sleep_ratio、last_cycle_total_pause_ratio两个比值，都是相对上一轮时长的比例，看着涨说明扫描器自己压得厉害。这几个数连续几轮都不动，比把 30 天这个数字再调大有用得多。

空闲模式下它会自己减速

RUSTFS_SCANNER_IDLE_MODE默认是true，文档的说法是开启后扫描器会自己限流，设成false则全速跑。这只是一句概括，拆开是两件事，准确理解它才能判断自己该不该关：一是那套预设睡眠，二是一条前台读退避地板。后者才是真正的减速依据，它统计的是并发前台读的数量，每有一个并发的 GetObject 或流式读，扫描器就叠加一段退避，单次最多 250 毫秒。它数的是存储自己看到的并发读请求，不管这些请求来自哪个应用、走没走网关。

这么拆开看，有几个后果值得注意。业务流量全走一层代理或网关时，落到存储上的并发读可能比业务侧 QPS 低一个数量级，退避地板几乎不起作用，扫描器基本按预设速度跑；反过来，直接暴露给公网、请求量忽高忽低的部署，地板会在业务高峰被反复顶上去，扫描进度反而变慢。想判断自己属于哪一种，看/v3/scanner/status里metrics.pacing_pressure的active_scans与queued_scans：后者持续堆积，说明扫描队列已经跟不上，此时先降并发比延长预算有效。

背后另外三个变量在管具体数值：RUSTFS_SCANNER_SPEED的默认值是default，可选fastest、fast、default、slow、slowest，它一起控制睡眠系数、最大睡眠时间和周期间隔；RUSTFS_SCANNER_DELAY覆盖睡眠倍率，文档例子是30.0；RUSTFS_SCANNER_MAX_WAIT_SECS覆盖最大睡眠秒数；RUSTFS_SCANNER_CYCLE覆盖周期间隔。

调这几个之前先看懂一件事：它们互相覆盖。改了RUSTFS_SCANNER_SPEED之后再设RUSTFS_SCANNER_DELAY，前者里对应的值就被后者顶掉了，两个都写反而容易让人误判当前生效的是哪个。只改一个、把另一个留空，排查时少一层干扰。

另外两个并发阀门也值得记一下：RUSTFS_SCANNER_MAX_CONCURRENT_SET_SCANS和RUSTFS_SCANNER_MAX_CONCURRENT_DISK_SCANS默认都是4，文档写明设为0时各自回到按拓扑或盘数自动决定的并发度。真正吃紧的时候，先降并发比延长预算更有效，因为并发直接决定单块盘上的读队列深度。

扫描器会顺手报三样东西

深扫换来的回报是三个告警阈值，它们都是扫描器在遍历时顺手统计的，不需要额外任务：

这三个阈值指向的问题通常是同一个：写入侧没做生命周期管理。版本数超标说明删除策略没跟上，文件夹数超标说明上层应用在用「一个前缀当目录用」的方式造出海量子键。扫描器只是在路过时看到了，它不会替你清理。

还有一个容易被忽略的细节。RUSTFS_SCANNER_START_DELAY_SECS默认未设置，控制首次扫描前的等待；旧名字RUSTFS_DATA_SCANNER_START_DELAY_SECS仍然可用但会打警告，规范名字优先级更高，两个都写在配置里时生效的是后者。

rc admin scanner status rustfs

这个命令调的是/v3/scanner/status，需要带ServerInfoAdminAction权限的管理身份。它返回里每个生效值都标了来源，是env、config、scanner_compat_config还是default，一眼能看出哪几项是显式配置、哪几项还在按默认值跑。

修复那边有几个并发阀门

扫描器发现降级对象之后，接下来的活交给修复器。它自己有一组默认值：RUSTFS_HEAL_AUTO_HEAL_ENABLE为true，说明自动后台修复是开着的；RUSTFS_HEAL_QUEUE_SIZE是10000，候选队列容量；RUSTFS_HEAL_INTERVAL_SECS是10，修复调度器的运行间隔；RUSTFS_HEAL_TASK_TIMEOUT_SECS是300，单个修复任务的超时；RUSTFS_HEAL_MAX_CONCURRENT_HEALS是4；RUSTFS_HEAL_MAX_CONCURRENT_PER_SET是1。

最后两个的差别是关键。全局并发 4 允许同时修四个任务，但每纠删集并发 1 意味着同一个纠删集内的修复任务排队。这两条规则合在一起的含义是：一次坏两块盘时修复不会自我加速到相互抢资源，代价是修复时间按坏掉的集合数拉长。真正让人卡住的场景是同一个纠删集里多片同时损坏，每片都要单独排一次队，修完一片才轮到下一片，整体耗时会按集合里坏掉的数量成倍翻。盘坏得多的集群，值得评估的是放宽第二个还是先把坏盘换掉。

队列长度要盯着看。rc admin heal status rustfs加--json能拿到healQueueLength和healActiveTasks两个计数，队列一直有积压、活跃任务却不多，多半是 per-set 那条规则在串行，不是修不动。官方文档也提醒过一句：队列长度为零并不能证明离线盘已经更换、也不能证明每个对象都可恢复，要跟存储拓扑和就绪状态一起看。

任务超时 300 秒这条也要注意。修复一个超大对象可能超过 300 秒，超时的任务会被丢弃重新入队，表现是队列一直在跑但进度不前进。看日志里反复出现的同一个对象，第一反应应该是去核对它的实际大小。如果确认是对象的体积让单次修复稳定超过 300 秒，直接把RUSTFS_HEAL_TASK_TIMEOUT_SECS调大比反复观察更省事，代价只是修复期间多占一段时间；真正要警惕的是调大之后依然反复超时，那说明修复带宽本身不够，得看盘的读速而不是继续抬超时。

读路径本身也在修，别把希望全押在扫描器上

上面这一整套节奏说的是后台扫描器。处理读请求的那条路还另有一套：官方文档把集群修复的来源分成五类，autoHeal、scanner、readRepair、internal、admin。其中readRepair的说法是「读取修复路径可以提交在处理请求时发现的工作」，也就是说业务刚好读到一个对象、而这个对象的分片已经坏了，读请求本身就会把它记下来并提交修复，跟扫描器跑到没跑到这个对象无关。

这条路径的意义是它不守 30 天。一个刚坏的位腐对象，如果业务恰好要读它，修复提交可能发生在几分钟内；反过来，如果它写在一份写进去就没人再碰的数据里，可能真的要等扫描器走到。所以冷数据上出问题的风险并不对称：越是没人读的数据，越只能等后台扫描；越是频繁读的数据，越容易被读路径兜住。

监控上别把两条路混着看。修复队列里的条目是可以按来源区分的，healOperations状态用那几个来源名分开统计排队中、活跃和重试中的工作。如果队列里scanner来源积压明显而readRepair数量一直很低，说明当前能自动发现的损坏全押在后台扫描上，此时要么缩短深扫周期，要么把预算放宽，让扫描器至少能追上新增数据。

把一个月的沉默切成可解释的几段

把上面这些串起来看，30 天这个数字背后是一组默认值凑出来的结果：深扫每 30 天一轮，单轮最多 30 分钟，并发按 4 走，发现的问题进 10000 容量的队列慢慢修。这个组合对大多数部署是安全的，对数据量大、带宽紧张的部署则偏保守。它给的是节奏而不是完成保证，实际推进到哪一步，得靠状态接口去看。

判断自己需不需要动它，可以按这三个问题过一遍：集群的有效数据有多少、单轮 1800 秒能覆盖多少比例、剩下的需要几轮才能磨完。举例来说，一块 NVMe 盘在纯顺序读下的带宽远大于业务高峰期的预留量，30 分钟能扫完的量对一个中等集群来说可能已经超过全部数据；换成一堆 7200 转机械盘，同样 30 分钟只能覆盖一个很小的片段，这时把预算调到数小时反而更实际。

另一个角度是看数据本身的价值分布。真正需要位腐兜底的是那些写进去之后再也不碰、也没有第二份副本的数据。批处理产出但下游还有暂存的数据，坏了几位的代价可能低于多花一个月扫一遍的成本。把这两类分开，深扫周期就能按数据分层来定，而不是整个集群统一取一个值。

扫描器本身还有一件事要注意：它的默认值是按「不打扰业务」设计的，所以在多数生产部署里它是隐形的。正因为它隐形，一旦某次调整把RUSTFS_SCANNER_IDLE_MODE设成了false或者把周期预算放宽了而没人记录，业务侧会先感觉到延迟波动，反过来怀疑是不是硬件出了问题。这类变更写进变更单，比调参数本身更值得花力气。

要改的话，按影响面从小到大是这条顺序：先调单轮预算和并发，把扫描对业务带宽的影响压到可接受；再决定深扫周期要不要从 30 天缩短到每周；最后才动自动修复的并发。反过来做的话，一上来把深扫周期改成 0，等于给每台机器排了一段持续的高读负载，业务侧会先感觉到延迟上来。