'no such file' on NFS shares (DNFS)

[lxworks]

we encounter problems with NFS mounts from OpenVMS 7.3-2 (NFS-client) to a NetApp Filer (NFS-Server, FAS 940 cluster, DataOnTap 6.5.6P4)

From time to time some directories below the mount are showing 'no such file' entries, thats killing some applications...
after a tcpip unmount/mount of the NFS client mount everything is ok, all files are accessible again.

One characteristic is, that there can be up to 2500 directories in some levels, the complete share owns more than 8 Million files alltogether, but there are not more than approx. 200 files in one directory-level, maybe some contain 1500, but thats an exception.

The IP Version is

HP TCP/IP Services for OpenVMS Alpha Version V5.4 - ECO 6
on a AlphaServer DS25 running OpenVMS V7.3-2

And the mount looks as follows

tcpip show mount dnfs3:/full

myfileserver:/vol/dir1/dir2/dir3/dir4/dir5/data

Transport TCPIP-UDP Writing Enabled
Read/write size 8192/8192 Write conversion Enabled
RPC timeout 0 00:00:01.00 ADF usage USE,UPDATE,CREATE
RPC retry limit 4 Fileids Unique
Attribute time 0 00:00:15.00 Server type UNIX
Directory time 0 00:00:30.00 Advisory Locking Disabled
Cache Validation MODIFY TIME Default user [MYGROUP,MYUSER]
Superuser No Default UID,GID 1100,200


as a first try I switched off the ADF option hoping on improvement of the situation.

maybe someone got similar problems.

rgds
alex

[Hoff]

I'd not expect the ADF to be related to this. (ADF is a conversion operation.)

This looks to be a connectivity issue, or a bug in either the NFS client or in the NFS server, or an incompatibility between the two. I could also see the mount potentially blowing out the run-time context on the client environment; these volumes are mid to larger, in my experience.

The No Such File tends to imply access into the file header has been lost. There can be any number of triggers here.

You'll probably end up discussing this matter directly with HP, and probably enabling and then reviewing any available NFS logs when these files "drop out of sight". This looking for connectivity issues, error messages, etc.

[lxworks]

a call at HP has been opened - but actually they too cannot see a solution ...

[Hoff]

One of the usual ways this works -- should the HP NFS engineer(s) involved transition into the "stumped" state -- is that you can get to ship a pre-configured target box to HP, and HP then uses this box to sort it out. A NetApp box, in this case.

HP then performs the equivalent of a connect-a-thon pass using the box.

Now as to whether this is HP or NetApp software at fault, or whether HP should get themselves a NetApp box for testing, are other discussions.

And FWIW, it's certainly also possible for both the NFS client and the NFS server to be entirely correct and compliant. And to be mutually incompatible.