Isilon - NFS Open files

Hello macyero,

There is not a command to run like you can for SMB to see open files.  Here is a link to the CLI guide just in case you don’t already have it. https://dell.to/3K8Doed

I was hoping a workaround using perl and installing the Linux::Fuser module. I cannot seem to get it to install using cpan

There are three NAS protocols on current Isilon systems: NFSv3, NFSv4(.[1-2]) and SMBv[2-3], of which only the latter two are stateful. NFSv3 is mostly stateless if you look at the protocol from the server's (i.e., Isilon's) point of view. There is some necessary server state in the Duplicate Request Cache, but in general, all state about which files are opened and still in use on an NFSv3 mount lives on the client. After mounting a share and performing directory lookups, the NFSv3 client gets a list of filehandles. The client doesn't "open" a file, it sends direct read/write RPC requests to the server using a filehandle it got from a previous directory lookup. The client also never closes a file to tell the server it is done with it. It simply ceases to use that filehandle in RPC requests. A NFSv3 server also has no idea which clients are still connected: if no TCP-keepalives are used, then a client can survive a week-long network partition, as long as it never needs any access to the NFS server, and neither the client nor the server would be any the wiser that a partition occurred.

This is in contrast to NFSv4 and SMB, where the server does know which clients are connected at all times and have which files open, because the NFSv4/SMB clients use so called sessions and are required to open a specific file first before performing operations (read/write) on it. That's part of the much increased state that's maintained between server and client, but that brings with it its own set of tradeoffs in greater complexity to synchronize that state between client and server and a resultant intricate protocol and state machine.

So, with NFSv3 mounts, it's impossible in general to know from the server side which clients still have a file open, because that information is simply not available to any NFSv3 server. There is, however, a side-band protocol, NLM, to perform locking on files. But that's merely advisory (i.e.: clients are not required to use it), and I for one haven't seen much use of NFSv3 locking over the years. But if your NFSv3 clients are of a rare breed and do use NLM consistently for all file access, then you can get an idea about the files in use with isi nfs nlm locks list.

For NFSv4, you can get information about the state (including which files are in use), from the command isi_nfs4mgt. You have to run this command on each node individually.

I have no idea whether the following one-liner will render correctly in this forum software. The exact use of sigils and quotes is important, so if the command gets mangled in any way, it will not work. But it will give you an idea how to tackle the problem to print open file information from each NFSv4.x client:

isilon-a-1# isi_for_array isi_nfs4mgmt --list | perl -naE 'next unless $F[8] > 0; $node = $F[0] =~ s/(.+):$/$1/r; $session = $F[1]; system "isi_for_array -n$node -Q isi_nfs4mgmt --dump=$session"' | perl -nE '$fn = $1 if m/File Name: (.+)/; $host = $2 if (m/Remote: ((.+?)\.\d+)\s+Local/); if ($host && $fn) { $hosts{$host} = [] if not exists $hosts{$host}; push $hosts{$host}->@*, $fn unless grep $fn, $hosts{$host}->@* }; END { map { say $_, "\t", join ", ", $hosts{$_}->@* } sort keys %hosts }'
10.      /ifs/
192.168.   /ifs/
isilon-a-1#