NFS - who is connected

[TMcB]

Hello everyone

Would anyone know how I could get a list of current NFS drive mapping connections.

I have a list of nfs users (via mc authorize), and a separate list of nfs exports (with PC numbers), but is there a command which will
list who is connected?

Thanks for any advice

[Hoff]

AFAIK, there's no "who" here to look up.

You're asking the equivalent of an HSC or HSZ or EVA or other such storage controller about "users". The controller doesn't know about those pesky users. It tosses blocks around, and with whatever minimal host mapping is needed to do that.

NFS serves up disk blocks using a stateless protocol, and the UAF and UID/GID stuff simply maps remote the binary user ids in the individual datagrams into local user ids as part of tossing around the datagrams and the disk blocks.

Systems are connected.

User ids are transient.

(Yeah, I know, NFS is slightly higher up in the stack than an EVA, for instance. EVAs don't know from UIDs and GIDs.)

[Brian Reiter]

Try this thread

http://forums12.itrc.hp.com/service/forums/questionanswer.do?threadId=1043641

There would appear to be no commands to do what you want directly.

cheers

Brian

[TMcB]

thanks for your help with this.

[Richard W Hunt]

Maybe I missed something, but wouldn't you be able to do this with:

$ SHOW DEVICE xxxx /FILES /NOSYS

(at least for open files?)

Or does that not work in this case? (I have no direct experience with NFS.)

[Wim Van den Wyngaert]

NFS is stateless. The user has no direct access to the disk. And he is normally on other nodes (the clients). So, no go.

Wim

[Hoff]

Responding to the re-opening of an old topic per the earlier reply here.

The SHOW DEVICE /FILES command shows on-node connections from OpenVMS, so you'd be able to catch connections between the NFS server and the files when executed on the host where the NFS server is running.

But as the NFS server operates on behalf of remote users, and there's no mapping I'm aware of between the OpenVMS environment and the remote environment; you'd need something that back-tracked the connection through the local NFS server and its remote-to-local proxies and back to the remote user that was accessing the particular proxy. And that's not available.

NFS shares more with an HSC than with the OpenVMS cluster file system; this though most every NFS server goes out of its way to add some state to the connections, the protocol itself is block-oriented and stateless.

And it's within the protocol activity that you need to determine the mapping, per the question. And since there's no connection in the protocol, the best you could do is flag a host and a proxy mapping and a device access that has been seen within some unit time. (And I'm not at all sure that the NFS server has anything similar to that; a way to peek into the NFS implementation. You could probably look at the traffic using Wireshark, too.)

[Richard W Hunt]

OK, so NFS doesn't look at files. Would it be possible (granted, very UGLY - EXCEEDINGLY UGLY) to use something like, determine the name of the lock that grants access to the NFS volume and then use a script that runs ANALYZE/SYSTEM with three commands:

SET OUTPUT some-file-name
SHOW LOCKS/BRIEF /NAME="lockname"
EXIT

Probably a bit more than you want to do, and not something you would want to run very often,... but if you don't have any other way to know who is talking to the volume, it still has to have OpenVMS shared resource locks, right?

[Hoff]

Grossly oversimplifying NFS, NFS sends over a file name and a block address within same, and the NFS server then maps that request to the local operating system and to the local disk, reads the block, and ships it back.

To determine the remote access, you need context from within OpenVMS (and we have that, as you've pointed out in several of your approaches), and from within the NFS server and its cache and its proxies and within NFS itself, and there's the fundamental issue that the protocol is stateless and connectionless.

In a few lower-performing NFS servers, the server opens the file in response to the request, reads or writes the block, ships the response, and closes the file. In various other NFS servers, the NFS server uses a cache of open files, and ages and closes them over time and traffic.

NFS has simple locking as far back as the implementation found on OpenVMS, though newer NFS implementations can provide something more akin to a loosely-coupled cluster. But I digress.

No matter how carefully you look at the OpenVMS host and its locks and its file system, you don't see the view that's presented between the NFS server and the NFS client. And you don't see the NFS server network proxy mapping and caching. And you don't see the NFS server proxies. Not from OpenVMS. That's all in the server.

And regardless, there are no "connections" within NFS; it's rather more like http and the web and web servers in that regard. Stateless. (qv: cookies, et al.)