必须用 mount -t glusterfs 挂载原生协议，因其直连 GlusterFS Client、绕过 NFS 协议栈与网关转发，I/O 路径最短；NFS/CIFS 网关引入多跳网络和多次内存拷贝，小文件随机读延迟高 2–5 倍，顺序读吞吐低 30%–40%。
直接用 mount -t glusterfs 挂载原生协议，是 GlusterFS 客户端实现高性能读取的**唯一推荐路径**。NFS/CIFS 网关会引入额外协议转换和内核 NFS 层开销，吞吐和延迟明显劣于原生 FUSE 挂载。
为什么必须用 glusterfs 类型挂载，而不是 nfs
原生挂载绕过了 NFS 协议栈、NFS 服务器进程（rpcbind/nfsd）、以及网关节点的二次转发。FUSE 层直连 GlusterFS Client，I/O 路径最短；而 NFS 挂载需经网关节点解包、重封装、再发往后端 Brick，多跳网络 + 多次内存拷贝，实测小文件随机读延迟高 2–5 倍，顺序读吞吐低 30%–40%。
- 所有性能压测（如
fio测试 4K 随机读、1M 顺序读）都基于glusterfs类型挂载结果 - 网关模式仅用于兼容旧应用或 Windows 客户端，非性能场景
-
/etc/fstab中若写成nfs类型，即使挂载点指向 glusterd 管理的卷，也走的是网关路径，不是原生协议
mount -t glusterfs 的关键参数与避坑点
命令形式为：mount -t glusterfs server1:/volname /mnt/gluster，但实际部署中极易因参数缺失导致性能断崖式下降或挂载失败。
- 必须加
-o backup-volfile-servers：例如-o backup-volfile-servers=server2:server3，否则主管理节点宕机时客户端无法自动切换 volfile 获取源，会卡在Transport endpoint is not connected - 禁用
atime：-o noatime，避免每次读触发元数据更新，对小文件密集读场景影响显著 - 慎用
cache-size：默认 128MB，大文件流式读可调至 512MB；但 OLTP 类小文件场景建议保持默认或设为 64MB，过大反而增加 cache miss 开销 - 不要加
_netdev到/etc/fstab后——GlusterFS 客户端启动依赖网络就绪，但_netdev会让 systemd 在 network-online.target 之后才挂载，常导致服务启动卡住；应改用x-systemd.requires=network-online.target
挂载后验证是否真走原生协议
不能只看 mount | grep gluster，要确认底层通信未降级到网关模式。
- 检查挂载选项：
findmnt -T /mnt/gluster -o SOURCE,TARGET,FSTYPE,OPTIONS，输出中FSTYPE必须是glusterfs，且OPTIONS包含backup-volfile-servers和noatime - 抓包验证：
tcpdump -i any port 24007 or port 49152-49251 -c 20，应看到客户端直连各存储节点的 TCP 连接（目标端口在 49152–49251 范围），而非只连网关节点的 2049（NFS）端口 - 查日志：
grep -i "volfile.*download" /var/log/glusterfs/mnt-gluster.log，成功加载 volfile 表明客户端已获取集群拓扑，后续 I/O 由本地计算 brick 位置，不查中心元数据
真正难的不是挂上，而是让挂载持续稳定并始终走最优路径——volfile 更新延迟、brick 状态抖动、FUSE 缓存策略与业务 IO 模式错配，这三者才是线上性能波动的主因，比初始命令多敲几个参数重要得多。
