I was tracking down some lock issues with a 8.0 (7 mode) box, and it appears the output of 'lock status -f' is different than described in the man page.
Man page example:
========b1000060:0007a88d simcity1775 state=GONE mode=Writ-denyA
My machine:
========002c613d:00760cb9 NLM[10.44.128.20,41648]: 0:0 1 GRANTED (0xffffff08d3686428)
Looks like more information to me. Question is... What is that field after the host name/IP (the 41648 above)? I thought at first it might be a port on the client, but I don't see anything on the client associated with ports there. So if that's true, it's not a persistent connection.
Is there some other meaning that would help me track down on the client the owner (or past owner) of the lock?
Thanks!
On 09/03/2010 02:26 PM, A Darren Dunham wrote:
I was tracking down some lock issues with a 8.0 (7 mode) box, and it appears the output of 'lock status -f' is different than described in the man page.
Man page example:
========b1000060:0007a88d simcity1775 state=GONE mode=Writ-denyA
My machine:
========002c613d:00760cb9 NLM[10.44.128.20,41648]: 0:0 1 GRANTED (0xffffff08d3686428)
Looks like more information to me. Question is... What is that field after the host name/IP (the 41648 above)? I thought at first it might be a port on the client, but I don't see anything on the client associated with ports there. So if that's true, it's not a persistent connection.
Is there some other meaning that would help me track down on the client the owner (or past owner) of the lock?
Should be the PID of the process running on 10.44.128.20.
--rdp
On Fri, Sep 03, 2010 at 02:54:08PM -0400, Payne, Rich wrote:
Is there some other meaning that would help me track down on the client the owner (or past owner) of the lock?
Should be the PID of the process running on 10.44.128.20.
Doesn't seem to fit. This is a linux machine, and PID 3 is almost always [migration]. I can't think of why that would be involved in a lock.
Here's the full list I have for this client:
lock status -h ======== NLM host 10.44.128.20 3 0x002c613d:0x00bbfd88 0:0 1 GRANTED (0xffffff08d37bfe00) 13 0x002c613d:0x00bbfd8a 0:0 1 GRANTED (0xffffff08d2a04e00) 46 0x002c613d:0x00bbfd8a 0:0 1 GRANTED (0xffffff0725f07038) 98 0x002c613d:0x00bbfd8a 0:0 1 GRANTED (0xffffff08d2bcac08) 8 0x002c613d:0x018ced8e 0:0 1 GRANTED (0xffffff0813d10230) 48697 0x002c613d:0x00000067 0:0 1 GWAITING (0xffffff08d2a04230) 48696 0x002c613d:0x00000067 0:0 1 GRANTED (0xffffff08372f1620) 42038 0x002c613d:0x00760cb9 0:0 1 GWAITING (0xffffff08d29dda10) 42037 0x002c613d:0x00760cb9 0:0 1 GWAITING (0xffffff08d29ddc08) 41650 0x002c613d:0x00760cb9 0:0 1 GWAITING (0xffffff0583a73c08) 41648 0x002c613d:0x00760cb9 0:0 1 GRANTED (0xffffff08d3686428) 41594 0x002c613d:0x018ced82 0:0 1 GWAITING (0xffffff08d36c5c08) 41593 0x002c613d:0x018ced82 0:0 1 GWAITING (0xffffff08d37baa10) 41592 0x002c613d:0x018ced82 0:0 1 GWAITING (0xffffff08d3636818) 41590 0x002c613d:0x018ced82 0:0 1 GRANTED (0xffffff08d2aecc08) 35517 0x002c613d:0x018ced82 0:0 1 GRANTED (0xffffff08d2ae2428) 29148 0x002c613d:0x018ced82 0:0 1 GRANTED (0xffffff08d36c5818) 21727 0x002c613d:0x000af324 0:0 1 GRANTED (0xffffff08d2a04038)
When I turn the hex inodes into file paths, they're exactly the paths I expect to be locked. But the numbers on the left mean nothing to me. I don't have any processes on this machine in 40K range. In fact my current max PID is 20442, and I don't think it's wrapped over.
Looking through 'netstat', the client only has one line with reference to the filer, and that's the established (TCP) NFSv3 connection.
Although I didn't think it was client port, I'm starting to think that it is, but that the port isn't persistent so there's nothing to find after the fact.
On 09/03/2010 03:17 PM, A Darren Dunham wrote:
On Fri, Sep 03, 2010 at 02:54:08PM -0400, Payne, Rich wrote:
Is there some other meaning that would help me track down on the client the owner (or past owner) of the lock?
Should be the PID of the process running on 10.44.128.20.
Doesn't seem to fit. This is a linux machine, and PID 3 is almost always [migration]. I can't think of why that would be involved in a lock.
No, sorry, wasn't clear about the part I was responding to.
You had:
"My machine:
========002c613d:00760cb9 NLM[10.44.128.20,41648]: 0:0 1 GRANTED (0xffffff08d3686428)
"
Which would mean that process 41648 from host 10.44.128.20 has a lock on the file. Now, that doesn't mean process 41648 still exists on the client. We had a couple of cases last week where this occurred, however these were 7.3.X Ontap filers machines.
--rdp
On Fri, Sep 03, 2010 at 03:59:04PM -0400, Payne, Rich wrote:
No, sorry, wasn't clear about the part I was responding to.
You had:
"My machine:
========002c613d:00760cb9 NLM[10.44.128.20,41648]: 0:0 1 GRANTED (0xffffff08d3686428)
Which would mean that process 41648 from host 10.44.128.20 has a lock on the file.
Yup. I understood you. But because I had another lock where instead of "41648", I had a "3", I couldn't belive that it was the PID.
So maybe it's supposed to be the PID, but it's not. And I was thinking, how would the filer ever know what the PID is anyway. Well, maybe the client is supposed to hand it over, but Linux doesn't.
Sure enough, breaking out wireshark I see that the NLM v4 LOCK packet hands over a filehandle and a "svid" that matches the number I see.
NLM V4 LOCK Call FH:0x38c878f6 svid:34846 pos:0-0
========a400b02a:005d6abd NLM[jumpy,34846]: 0:0 1 GRANTED (0x796f8ef8)
So the answer is that the number I see isn't magical, and I need to find something on the Linux client side that might tell me how it maps to a process. :-(
Thanks for the help!
-
A Darren Dunham -
Payne, Rich