【ganesha】share reservation原理

share reservation原理

背景

在 NFS v4 协议中，每个 OPEN 操作除了指定读写权限外，还可以指定 share reservation（共享保留），告诉服务器：这个客户端打算 如何访问文件（读/写/读写)；以及它 希望其他客户端是否被允许访问。这样做的目的是：避免多个客户端同时操作同一文件时出现 冲突（conflict）；提供一种类似 Windows 文件共享模式（share modes） 的机制。

Share Reservation 的两个维度

1. Access（访问模式）

• READ → 需要读权限
• WRITE → 需要写权限
• BOTH → 需要读写权限

2. Deny（拒绝模式）

• DENY_NONE → 不拒绝别人访问（最宽松）
• DENY_READ → 拒绝别人读
• DENY_WRITE → 拒绝别人写
• DENY_BOTH → 拒绝别人读写（最严格）

所以，当客户端 OPEN 文件时，会带上 (access, deny) 组合，这就是 share reservation。

 

举个例子

• 客户端 A 执行 OPEN(file, access=WRITE, deny=WRITE) → A 想写文件，并且不允许其他客户端也写。
• 客户端 B 再执行 OPEN(file, access=WRITE, deny=NONE) → 冲突！因为 A 已经拒绝别人写。
• 客户端 C 执行 OPEN(file, access=READ, deny=NONE) → 允许，因为 A 只拒绝别人写，但没拒绝读。

 

普通 DENY_WRITE (advisory)
──────────────────────────
客户端A:  OPEN file, deny=WRITE
↓
Ganesha: 记录 share reservation
↓
客户端B:  通过 NFS 再次 OPEN file (写方式)
   └──> Ganesha 拒绝 (返回错误)
↓
客户端B: 直接通过底层FS (POSIX/CephFS) OPEN file (写方式)
   └──> 成功 (因为底层FS不感知NFS share deny)


强制 DENY_WRITE_MAND (mandatory)
───────────────────────────────
客户端A:  OPEN file, deny=WRITE_MAND
↓
Ganesha: 记录强制 share reservation
↓
客户端B: 通过 NFS 再次 OPEN file (写方式)
   └──> Ganesha 拒绝 (返回错误)
↓
客户端B: 直接通过底层FS (POSIX/CephFS) OPEN file (写方式)
   └──> 失败 (因为FS/协议层也强制阻止写入)