仅靠gluster volume heal <volume> info split-brain有输出不能确认真脑裂，必须用getfattr -n replica.split-brain-status <filepath>查到data或metadata-split-brain:yes才算实锤；否则需结合getfattr -d -e hex -m .比对GFID、stat比对类型/大小等进一步验证。
直接看 gluster volume heal <volume> info split-brain，有输出就说明真裂了，不是误报。
怎么确认文件是不是真的裂脑了
仅靠 heal info split-brain 列出的路径还不够——它只告诉你“AFR 没法自动选主”，但没说具体是哪类不一致。得进挂载点或 brick 本地查扩展属性：
-
getfattr -n replica.split-brain-status <filepath>：输出里含data-split-brain:yes或metadata-split-brain:yes才算实锤；如果全是no，那可能是 GFID 不一致或类型错配（比如一边是文件、一边是目录），这个命令不显示 - 更底层验证：用
getfattr -d -e hex -m . <brick_path/file>对比多个 brick 下同名文件的trusted.gfid值，十六进制不一致 = GFID 裂脑 - 别漏掉
stat <filepath>：在不同 brick 上跑，看Modify时间、Size、File type是否一致；大小不同大概率是 data 裂脑，类型不同（file vs dir）就是 type-mismatch，CLI 无法自动修复
为什么 gluster volume heal <volume> full 没反应
执行后 heal info 还是一堆条目？常见原因不是命令没跑，而是 AFR 卡在“不敢动”：
- 卷没开自愈：检查
gluster volume get <volume> cluster.self-heal-daemon，返回off就得先gluster volume set <volume> cluster.self-heal-daemon on - 仲裁节点异常：如果是
replica 2 arbiter 1卷，arbiter brick 不在线或挂载异常，AFR 直接拒绝决策，gluster peer status和gluster volume status必须全 green - 扩展属性脏标记残留：某些异常中断后
trusted.afr.*xattr 没清干净，导致 AFR 认为“还在事务中”，此时需人工清理（风险高，慎用）
手动选源修复时 filepath 怎么写才对
gluster volume heal <volume> split-brain bigger-file <filepath> 的 <filepath> 不是绝对路径，也不是 brick 内路径，而是“挂载点下的相对路径”：
- 假设挂载点是
/mnt/gluster，heal info split-brain输出/mnt/gluster/app/config.json，那<filepath>应填/app/config.json（开头带斜杠，但去掉挂载点前缀） - 填错会报
File not found或静默失败——它不会去 brick 目录下搜，只在校验挂载点视图下的路径是否存在 - 修复前务必确认该路径在挂载点下可访问且内容可信；如果挂载点本身已不可读，得先切到对应 brick 的物理路径上操作
真正麻烦的永远是目录裂脑和 type-mismatch：前者可能嵌套多层子项不一致，后者 CLI 完全无能为力，必须停服务、逐 brick 对比 GFID 和 inode 类型、手动 mv/cp/ln，稍错一步就丢数据。
