企业官网建设流程全解析

迁移完 30TB 数据，你敢直接下线源集群吗

【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs

刚跑完一轮跨集群迁移，最让人睡不着的不是带宽，而是那份没验证过的数据：源集群还能留几天？CubiFS 自带的cfs-fsck工具就是为这类CubiFS 数据一致性检查准备的，一条命令对比多个元数据副本，把孤立 inode 和悬空 dentry 挑出来，迁移验证从玄学变成清单。

工具能做什么，一张表说清

三种 check 的区别只有一句话：inode 校验文件元数据，dentry 校验目录项，both 两者都跑。工具会在当前目录生成_export_卷名文件夹，.obsolete后缀的文件就是检出的垃圾名单。

跟着做：从首次校验到清理

第一步｜连通性自检

./cfs-fsck get path --master "127.0.0.1:17010" --vol "myvol" --mport "17220" --inode 1

这条命令查根 inode 的路径，--master是 Master 的 HTTP 地址，--mport是元数据节点的 profiling 端口；能打印出路径，说明 Master 和元数据节点都连得通。

第二步｜执行全面校验

./cfs-fsck check both --master "127.0.0.1:17010" --vol "myvol" --mport "17220"

它会把卷下所有元数据分区（mp，元数据分片）的 inode 和 dentry 拉下来，从根 inode 出发沿目录树标记可达项，标不到的就是过时数据。输出里重点看三处：

• 终端的Obselete Total Count（过时 inode 数）和NLink Zero Total Count（硬链接数为 0、可安全清理的数量）
• _export_myvol/inode.dump.obsolete里是否有你认识的目录名，有的话先排查再往下走
• 控制台报 "No root inode" 或网络错误，说明参数或连通性有问题，回第一步

第三步｜确认无误后清理残留

⚠️ 执行前务必确认校验通过，且 obsolete 名单里没有任何业务路径。

./cfs-fsck clean inode --master "127.0.0.1:17010" --vol "myvol" --mport "17220"

清理有硬约束：只处理 NLink 为 0、修改时间超过 24 小时且类型为普通文件的 inode，其余会打印 can't be deleted 跳过。确实要强制清 NLink 非 0 的垃圾，才加--force，生产上能不加就不加。

两类高频场景，操作不一样

跨集群搬迁

搬迁的本质是新旧两个集群各跑一遍check both，比对 obsolete 名单是否收敛到 0：

• 大卷一次拉全量容易超时，用--inode-list、--dentry-list指定上次导出的名单，做分批增量校验
• 校验期间别停源集群业务，工具只读元数据，但清理只在验证完成后执行
• 网络不稳时把超时调大、跑慢一点，比中断后从头再来省时间

版本升级后回归

升级和搬迁的区别在于：数据没动，动的是元数据的格式兼容性和增量写入。

• 升级后先跑check both确认旧元数据读得回来，格式兼容不过关，后面一切免谈
• 只对升级窗口内新建、修改过的文件做增量校验：把新 inode 清单导出来用--inode-list指定，不必每次全量
• _export_卷名目录升级前留一份，升级后覆盖，出问题可以逐行 diff 定位

上手前 30 秒检查清单

• 工作机到 Master 和所有元数据节点网络可达
• Master 地址与元数据节点 profiling 端口（--mport）核对无误
• 卷名与集群当前卷名完全一致
• _export_卷名目录已备份或放在不会误删的盘上

清单打勾，就可以跑check both了，结果出来之前，源集群一个节点都别动 🚀

【免费下载链接】cubefscloud-native distributed storage项目地址: https://gitcode.com/gh_mirrors/cu/cubefs