GlusterFS卷创建失败主因是glusterd未运行或Brick路径不存在/权限不足；客户端卡顿需调优cache-size和ping-timeout；脑裂须人工干预；版本不兼容会导致peer断连；Brick状态异常需查port/pid确认是否启动。
GlusterFS 卷创建失败：volume create 报 Transport endpoint is not connected
这通常不是网络不通，而是本地 glusterd 服务没跑起来，或 Brick 路径不存在 / 权限不对。GlusterFS 启动 Brick 前会先尝试挂载一个伪文件系统（/var/lib/glusterd/vols/ 下的 volname 目录），如果该目录不可写、父目录不存在，或者 glusterd 没在运行，就会卡在这一步。
- 先确认
systemctl status glusterd是 active (running)，否则systemctl start glusterd - 检查每个 Brick 路径是否真实存在：
/data/brick1这类路径必须提前mkdir -p好，且属主为root:gluster（或至少gluster组可写） - 别用 NFS 或 CIFS 挂载点当 Brick —— GlusterFS 的 Brick 必须是本地 ext4/xfs 文件系统，且不能是其他挂载子目录
- 执行
gluster volume create前，确保所有节点时间同步（chronyd或ntpd），否则 peer probe 可能静默失败
客户端挂载后写入慢、ls 卡顿：默认配置下 performance.cache-size 和 network.ping-timeout 拉垮
GlusterFS 默认不开启读缓存，每次 ls 都要跨网络查所有 Brick 的目录项；同时，心跳超时设得过大（默认 42 秒），节点临时抖动就会让整个 I/O hang 住。
- 挂载时加选项：
mount -t glusterfs -o cache-size=256MB,transport.socket.keepalive-interval=2,transport.socket.keepalive-time=10 server1:/vol1 /mnt - 更稳妥的做法是在卷上设置：
gluster volume set vol1 performance.cache-size 256MBgluster volume set vol1 network.ping-timeout 5 - 注意
cache-size是 per-client 生效，不是全局内存占用；但设太大（如 >1GB）反而可能触发内核 page cache 压力，尤其小内存机器 - 如果用了
distribute-replicate类型卷，避免在客户端开read-ahead（默认开启），它对小文件随机读收益低，还加重网络负载
gluster volume heal 不自动修复，heal info 显示大量 Split-brain
Split-brain 不是“坏了”，而是 GlusterFS 明确拒绝自动仲裁 —— 它不知道哪边数据更新，也不敢随便丢数据。默认策略是停写、报错、等人工干预。
- 先查具体冲突文件：
gluster volume heal vol1 info split-brain，输出里带gfid:的就是真冲突 - 手动选一边恢复：
gluster volume heal vol1 split-brain bigger-file /path/to/file（选大文件）或source-brick（指定某节点为准） - 别碰
gluster volume set vol1 cluster.quorum-type改成none来绕过仲裁 —— 这等于关掉脑裂保护，后续写入可能永久丢失 - 预防比修复重要：确保复制卷（replica 3）至少 2 个 Brick 在线才允许写；用
quorum ratio 2（而非默认的auto）能避免偶发网络分区引发脑裂
升级 GlusterFS 后 gluster peer status 显示 Peer in Cluster 但状态为 Disconnected
这是版本不兼容的典型信号。GlusterFS 9.x 和 10.x 之间协议有变更，老节点无法解析新节点发来的 handshake 包，但又没彻底断连，就卡在“已加入集群但连不上”这种灰色状态。
- 先确认所有节点版本一致：
gluster --version，特别注意 CentOS Stream 8/9 自带的包可能混着 8.x/9.x - 升级顺序必须是：先停所有
glusterd，再统一 rpm/yum upgrade，最后逐台systemctl start glusterd - 升级后执行：
gluster volume reset all（清空旧配置缓存），再gluster peer probe重连（哪怕显示已连接也要重探） - 如果仍失败，检查
/var/log/glusterfs/etc-glusterfs-glusterd.vol.log里是否有protocol version mismatch，那就是版本硬冲突，没别的办法，只能全量降级或重装
GlusterFS 的“分布式”不是黑盒，每个 Brick 的磁盘健康、内核版本、甚至 SELinux 策略都可能成为单点故障源。最常被跳过的其实是 gluster volume status detail 里每个 Brick 的 Port 和 Pid —— 它们不显示，往往意味着 Brick 根本没起来，而不是网络问题。
