poor NFS performance when retrieving directories WITH attributes

[lxworks]

hi, all.

this is the environment:
NFS Server is a NetApp FAS940 running DataOnTap 6.5.x. the NFS Client is an OpenVMS Alpha DS25 running OpenVMS 7.3-2, Patches not too old, TCPIP Version V5.4 - ECO 6 in a cluster with four other nodes, that may mount the same DNFS devices, but must not (I don´t know if NFS caching is clusterwide)

the DNFS is mounted as follows:

$ tcpip mount dnfs80: /host="mynetapp.mydomain.com" -
/path="/vol/vol2/vol3/vol4"/server_type=UNIX /CONVERT/ADF=CREATE -
/system /user=user /owner=[xxx,y] /uid=xxxx /gid=yyy

the share may contain up to 3000 directory entries in root level.

now the problem:
when issuing a "directory dnfs80:[000000]" without any qualifiers, the listing of these 3000 entries is very fast. (fresh mounted, I assume, there is no data in cache, but I´m not shure!?)

when adding some qualifiers as a directory /date/size/owner/prot, the same listing needs up to 20 Minutes (twenty!)

Any ideas or is this standard?

thanks&rgds
alex

[Wim Van den Wyngaert]

Is it also slow when you repeat the 2nd command again after it has completed ?

Wim

[lxworks]

the second run is faster sometimes until the point I reached with the first run, but the results are very different. In most cases a second complete listing is as slow as the first.

[Hoff]

This looks broken.

Confirm the NetApp FAS is current on its firmware, turn on whatever logging or sniffing might be available on either end in your network connection or via a protocol sniffer, confirm local client username process quotas are somewhere between adequate and generous, and then call HP support.

I'd also try the same sequence with something other than the NetApp FAS NFS server, to see if this is specific to the NetApp device or a connection with same, or if this is a generic problem with the NFS client.

If you have a testing environment, you could also see if one of the Process software IP stacks has a faster NFS.

[lxworks]

i tried it with a complete new FAS3020 running OnTap 7.2.2. was the same. we created a TCPDUMP and sent it to NetApp. I´m actually installing the recent V5.6 ECO 1 on an IA64 OpenVMS 8.3 and hope I can gather more information and will finally open a call at HP. for a sniffer session I unfortunately have not the time and the resources actually.

[Wim Van den Wyngaert]

Can you setup the nfs device from a non-vms node and check if performance is bad too ?

Wim

[lxworks]

we have solaris and hpux and linux and all this stuff and the "ls -lisa" from these nodes is as fast as the "ls". 1 second for the complete listing including all the owner,size and time information.

[Hoff]

"...FAS3020 running OnTap 7.2.2..." versus the "...NetApp FAS940 running DataOnTap 6.5..."

It's quite typical and entirely common that a particular product vendor will use consistent code -- possibly with differences among available corrections and enhancements -- across its product line. The vendor builds or OEM-licenses the application code once, and re-uses it.

For purposes of bug isolation, testing with entirely different vendors is better. In this case, with whatever replaced Windows SFU, or with Linux, HP-UX, or Mac OS X Server, or...

And to keep debugging interesting, even entirely different vendors can sometimes use the same code base. In the case of NFS on OpenVMS and HP-UX, these do use different code bases, as the products themselves originated from DIGITAL and from HP; from different corporations.

[Bojan Nemec]

Alex,

Welcome to the VMS forum!

Because of how VMS directory works, I think that a comparable command on an UNIX node will be:

ls -lisa /vol/vol2/vol3/vol4
cp /vol/vol2/vol3/vol4/.\$ADS\$* /dev/null

Bojan

[Wim Van den Wyngaert]

Just did some playing and found that NFS is slow when working set is too small.
Check ucx help mount /acp to increase the settings (if you can, investigate what the process quotas are). If you have avail check and increase with this product.

Wim