存储与运行
接管一块数据盘之前
从看见一块旧盘，到继续读写原数据，中间还要核对成员归属和旧写入者。以 FoundationDB 与 Yaostore 为例，说明接管前应保留哪些记录、何时可以重新开放写入。
失去联系留下了什么未知
控制器暂时无法联系节点时，已有数据库或对象存储进程可能继续工作。新节点上线、旧报告过期或操作调用超时，只改变管理侧能看到的事实，不能证明旧进程已退出，也不能证明它不再通过另一个设备别名写入。
接管前要独立取得三类依据：设备及成员归属与预期一致，旧写入者已经结束，当前执行者持续满足独占条件。三者都成立后，才允许以可写方式重开原数据；随后还要通过独立读回核对内容。一个管理状态不能同时证明这几件事。
FoundationDB：保留卷归属与数据库状态
FoundationDB 的每个卷携带集群、逻辑机器与卷三个归属字段。普通重启保留这些字段，也保留进程的数据和日志目录。节点先对确切设备进行只读归属检查，条件满足后再以可写方式重开已有的 XFS 文件系统。
集群连接文件也是长期保存的状态，由 FoundationDB 在运行中维护。控制器提供给新客户端首次连接的种子不会覆盖已有文件。若标记或连接文件损坏，普通启动会被阻止，需另行修复；数据目录看似为空不能成为重新初始化的依据。
Yaostore：用独立记录识别原成员盘
Yaostore 接管 RustFS 对象存储引擎的已有成员盘时，要求操作者独立保留完整预期：物理设备、磁盘与分区的唯一标识（UUID）、文件系统 UUID，以及池、部署、成员盘标识、分组和组内位置。Agent 节点代理核对后才把磁盘纳入管理，接管不格式化。
这与按已有归属记录普通重启不同。转由全新控制器管理时，还需保留原凭据与有序池布局，等旧管理方和写入者结束后明确接管、恢复。恢复先把完整配置送达各节点并保持停止，再单独授权启动；认出磁盘不等于集群已恢复服务。
| 问题 | FoundationDB | Yaostore |
|---|---|---|
| 卷属于谁 | 集群／逻辑机器／卷标记 | 设备、分区、文件系统及存储成员预期 |
| 保留什么 | 进程目录与数据库连接文件 | 原盘标识、成员布局与对象内容 |
| 控制器记录说明什么 | 当前声明及节点报告 | 登记、归属关系与配置应用 |
| 谁确认没有其他写入者 | 卷所有者与实际主机管理方 | 节点所有者与实际主机管理方 |
一次更换控制器，至少经过三次独立判断
以 Yaostore 的明确接管为例，先保留独立的成员预期和已知对象，再让旧管理方与实际写入者结束。新控制器识别磁盘时只完成归属核对，不借此格式化；恢复拓扑先形成停止状态下的完整配置，启动服务另行授权。
这条顺序区分了“认出原盘”“配置已应用”和“原对象可读”。任一环节缺少观察，就在对应位置保留未知。新进程已经出现、S3 接口返回某个成功状态，或后台显示配置已保存，都不能替代对预先保留对象字节的比较。
认出原成员
把当前设备与独立保存的标识、分组、位置和原凭据核对。
应用完整配置
在旧写入者已结束的前提下恢复原有布局，先保留停止意图。
启动并读回
明确启动后，通过对象接口读取已知版本并逐字节比较。
正确读回支持数据保持结论
独立保存的对象版本与字节，为接管后的读取提供预期。
管理记录不等于写入排他
配置、心跳和报告都不能单独证明原写入者已经结束。
初始化是一项不同的授权
两份设计都把初始化与复用分开。FoundationDB 对停用节点上的确切卷执行显式格式化，控制卷先建立连接文件，最后持久化归属标记。Yaostore 则对授权整盘固定新标识，再完成分区、格式化和结果观察。
一次调用超时不撤销可能已经发生的效果。FoundationDB 初始化结果丢失后不会自动重发；Yaostore 对相同动作编号保留原工作和结果。未结束的工具进程、输入输出与挂载仍由原执行者负责；新的破坏性操作必须等待冲突工作结束。
把数据保持落实到独立观察
对 FoundationDB，设计中的验证重点是用已知数据重开同一批已归属卷，确认数据库更新过的连接文件与进程目录未被重置；再用错误标记或不足以识别归属的只读观察，检查可写挂载不会提前发生。
对 Yaostore，保留一个已知对象版本和完整成员预期，在停启、控制器重开与明确接管后，通过 S3 对象接口读回原字节。延迟旧写入者结束或提供错误预期，分别检验等待与拒绝。配置已保存、进程已启动和数据正确读回，需要三份独立证据。