We are having an issue on 2 linux servers that we think may be related to locking. Lock status shows many locks that are GWAITING, like so:
NLM[crater.pp.bcinfra.net,13260]: 94691143974912:18446649382565576704 1 GRANTED (0xffffff02c3600e00) NLM[carlsbad.pp.bcinfra.net,679]: 71133248356352:18446672940461195264 1 GWAITING (0xffffff02aa227428) NLM[carlsbad.pp.bcinfra.net,682]: 71107478552576:18446672966230999040 1 GWAITING (0xffffff0423515230) NLM[carlsbad.pp.bcinfra.net,684]: 71171903062016:18446672901806489600 1 GWAITING (0xffffff04cfccaa10) NLM[carlsbad.pp.bcinfra.net,685]: 71167608094720:18446672906101456896 1 GWAITING (0xffffff03bc421818) NLM[carlsbad.pp.bcinfra.net,687]: 71159018160128:18446672914691391488 1 GWAITING (0xffffff049a4a5e00) NLM[carlsbad.pp.bcinfra.net,689]: 71116068487168:18446672957641064448 1 GWAITING (0xffffff02a966d038) NLM[carlsbad.pp.bcinfra.net,693]: 71047349010432:18446673026360541184 1 GWAITING (0xffffff0332284620)
We are thinking we may be running into the same issue as this person:
http://comments.gmane.org/gmane.linux.nfs/42929
but we are already doing NFS over TCP.
I believe that the hex looking number from lock status (ie 0xffffff0332284620) is possibly an inode. Anyone know if that's true? If so, how can I take that and get an actual file name?
Thanks, Dan
According to “lock status” man page this is “lock address” without explanation what it actually means. But it seems output of “lock status -f”. In this case it should have been prefixed with file header “======== fsid:fileid”. Fileid is exactly inode number.
Could you show full command and its output?
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Dan Finn Sent: Friday, September 07, 2012 2:02 AM To: Mailing Lists Subject: Getting actual file paths from lock status
We are having an issue on 2 linux servers that we think may be related to locking. Lock status shows many locks that are GWAITING, like so:
NLM[crater.pp.bcinfra.net,13260]: 94691143974912:18446649382565576704 1 GRANTED (0xffffff02c3600e00) NLM[carlsbad.pp.bcinfra.net,679]: 71133248356352:18446672940461195264 1 GWAITING (0xffffff02aa227428) NLM[carlsbad.pp.bcinfra.net,682]: 71107478552576:18446672966230999040 1 GWAITING (0xffffff0423515230) NLM[carlsbad.pp.bcinfra.net,684]: 71171903062016:18446672901806489600 1 GWAITING (0xffffff04cfccaa10) NLM[carlsbad.pp.bcinfra.net,685]: 71167608094720:18446672906101456896 1 GWAITING (0xffffff03bc421818) NLM[carlsbad.pp.bcinfra.net,687]: 71159018160128:18446672914691391488 1 GWAITING (0xffffff049a4a5e00) NLM[carlsbad.pp.bcinfra.net,689]: 71116068487168:18446672957641064448 1 GWAITING (0xffffff02a966d038) NLM[carlsbad.pp.bcinfra.net,693]: 71047349010432:18446673026360541184 1 GWAITING (0xffffff0332284620)
We are thinking we may be running into the same issue as this person:
http://comments.gmane.org/gmane.linux.nfs/42929
but we are already doing NFS over TCP.
I believe that the hex looking number from lock status (ie 0xffffff0332284620) is possibly an inode. Anyone know if that's true? If so, how can I take that and get an actual file name?
Thanks, Dan
We are having an issue on 2 linux servers that we think may be related to locking. �Lock status shows many locks that are GWAITING, like so:
Hi Dan,
Just a thought... Is the filer allowed to connect to portmapper (rpcbind) on the NFS clients and also allowed to connect to the nlockmgr RPC service? Usually you don't expect to open network ports on a client, but for NFS, the server sometimes initiates connections to nlockmgr on the NFS client.
You usually see errors in /etc/messages on the filer when it cannot connect to pormapper on a NFS client.
We use a rule in iptables on our Linux NFS clients to allow all access from the filer's IP. We consider it too difficult to get more specific. Multiple ports must be opened for both TCP and UDP.
Steve Losen scl@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
-
Borzenkov, Andrey -
Dan Finn -
Steve Losen