所以我遇到了这个问题。这个非常非常糟糕的问题。
我有一组 Linux NFS 服务器（在使用 CTDB 的 NFS/CIFS 群集中），它们仅在锁阻塞时才拒绝锁。如果是非阻塞调用，它工作正常。
请参阅下面的交通流向：
阻塞锁调用：
9.414674 10.10.1.40 -> 10.10.1.14 NLM 282 V4 LOCK Call FH:0xf6b3519c svid:5 pos:0-0 nlm.lock.caller_name == "centos-ad2012r2" nlm.exclusive == 1 nlm.block == 1
9.415002 10.10.1.14 -> 10.10.1.40 NLM 106 V4 LOCK Reply (Call In 39) NLM_BLOCKED nlm.stat == 3
18.613965 10.10.1.40 -> 10.10.1.14 NLM 274 V4 CANCEL Call FH:0xf6b3519c svid:5 pos:0-0 nlm.lock.caller_name == "centos-ad2012r2" nlm.exclusive == 1 nlm.block == 1
18.614003 10.10.1.40 -> 10.10.1.14 NLM 266 V4 UNLOCK Call FH:0xf6b3519c svid:5 pos:0-0 nlm.lock.caller_name == "centos-ad2012r2"
18.614675 10.10.1.14 -> 10.10.1.40 NLM 106 V4 CANCEL Reply (Call In 55) NLM_DENIED nlm.stat == 1
18.614889 10.10.1.14 -> 10.10.1.40 NLM 106 V4 UNLOCK Reply (Call In 56) nlm.stat == 0
非阻塞锁调用：
47.476050 10.10.1.40 -> 10.10.1.14 NLM 282 V4 LOCK Call FH:0xf6b3519c svid:6 pos:0-0 nlm.lock.caller_name == "centos-ad2012r2" nlm.exclusive == 1 nlm.block == 0
47.476647 10.10.1.14 -> 10.10.1.40 NLM 106 V4 LOCK Reply (Call In 102) nlm.stat == 0
51.908995 10.10.1.40 -> 10.10.1.14 NLM 266 V4 UNLOCK Call FH:0xf6b3519c svid:6 pos:0-0 nlm.lock.caller_name == "centos-ad2012r2"
51.909700 10.10.1.14 -> 10.10.1.40 NLM 106 V4 UNLOCK Reply (Call In 112) nlm.stat == 0
客户端是Centos 6.5
服务器是 Scientific Linux 6.2
底层文件系统是 Lustre。该问题可能与以下问题有相似/相同的原因另一个问题：
异步锁定接口在阻止锁方面做了一些稍微俗气的事情 - 它不是等待文件系统响应，而是立即发回一个拒绝（即使锁实际上可用），然后在发现锁可用时以授予的消息进行响应。