Então eu tenho esse problema. Esse horrível e terrível problema.
Eu tenho um conjunto de servidores Linux NFS (em um cluster NFS / CIFS usando CTDB) que recusam bloqueios… somente quando o bloqueio está bloqueando. Se é uma chamada sem bloqueio, funciona muito bem.
Veja o fluxo de tráfego abaixo:
Bloqueio da chamada de bloqueio:
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
Chamada de bloqueio sem bloqueio:
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
O cliente é o Centos 6.5
O servidor é o Scientific Linux 6.2
O sistema de arquivos subjacente é o Lustre. O problema pode ter uma causa semelhante / igual ao outro problema :
The asynchronous locking interface does something slightly cheesy for blocking locks--instead of waiting for the filesystem to respond, it just sends back a deny immediately (even if the lock might actually be available), then responds later with a granted message when it discovers it's available.