Make sure your link-MTU for the openvpn tunnel is set accurately so that you don't get fragmentation twice (one at the host from 8192 bytes to 1500 bytes and once at openvpn from 1500 bytes to 1400 bytes or whatever). openvpn handles setting the interface mtu very very poorly (actively hinders attempts to set the mtu correctly).
Check latency for different packet sizes going through and around the tunnel. Plot and look for problems.
Set up a test NFS outside the tunnel and do some performance measurements that way to isolate whether or not openvpn is the problem or not.
Try different versions of NFS, both TCP and UDP.
Try enabling aggressive caching and async I/O.
The following is a rant about the "active hindering" of openvpn WRT MTU (added by "request")
Yes. Setting tun-mtu causes openvpn to generate WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1413). I don't use --mssfix or --fragment.
Additionally, setting a static MTU in the configuration is stupid and errorprone, it needs to be dynamic. So, you use "mtu-disc yes", right? Well of course, except the value it passes into the startup script is off-by-14 (though I am using TAP for IPv6 support, which might mysteriously confuse it). So I need to /sbin/ifconfig $1 mtu $(($2-14)) up to get the proper value (proper meaning a value which will cause the tunnel packets to not be fragments or dropped because they are too big).
I have difficulty imagining a circumstance whereby setting the interface MTU to the correct value is not a good idea, at least if you don't have fragment set (and you should never have fragment set, least your network sins come to haunt you). It should also dynamically change the interface MTU if it later gets fragment needed errors due to network changes after initialization.
MSS is entirely the wrong network layer to do this work. If you have the interface MTU correctly configured, Path-MTU discovery, MSS, and everything simply works. If you don't, some things may kinda sort work, other things will not, and which things work depend on whether the real packet is sent from the openvpn host or some other host. Oh, and don't get me started on what can fail if the MTU is asymmetric (not entirely uncommon).
I think OpenVPN was written by people without lots of network and sysadmin experience and their poor choices got hardcoded in configuration and datastructures/API. They really didn't do a very good job with flexible and sane network configuration and integration (this is just one of a several examples). The sad thing is that it is hundreds of times better than the other solutions out there which makes me an OpenVPN supporter. The Cisco VPN is a blight, for example.
Best Answer
There are two limits that you may have hit.
inodes (unlikely)
You've consumed all of the available inodes for that volume. You can confirm this with the commands
df -iandmaxfiles.maxdirsize(more likely)ONTAP imposes a limit on size of directories. Size being a product of metadata/hardlinks, not file content. This limit defaults (assuming >6.5) to 1% of your system RAM. It does so to ensure that large directories don't impact system performance. Because linear directory scans require directory data structures to be loaded into memory. Quick overview:
ls -lkd.maxdirsizefor a volume is a bit of a one way operation.If it's neither of these issues then I'd recommend checking and posting your ONTAP logs.