While the locking mechanism is understandable, the side band way (NLM protocol) in v3 really is a bummer (very very bad performance for example) this surprises me:
"Their business makes it a requirement for the security"
There's really nothing w.r.t. "security" in v4.1 and up that is crucial or important that cannot, with the same effort (client side effort...), be implemented with v3. In practice. There's the sec=krb5{,i,p} stuff (old 7-mode syntax there I know). All is supported in all sensible Linux distros I'm aware of (and Oracle Solaris if anyone cares about that anymore I'm not sure). Other NFS client implementations, sure, YMMV. But it should be residual by now.
Another dimension of security is what Justin pointed out below about NVSv4 ACLs: ONTAP allows you to "nfsv4acls-nfsv3mounts".
Remains one more thing then (in addition to the first thing I wrote): the fact that NFSv4.x uses one port 2049. Everything. So it's easier to "open the Firewall". But seriously. How hard can it be with NFSv3 and those few side band protocols? It's just a few more ports, in total like 5 (TCP and UDP for the side band protocols: rpcbind, MOUNT, NLM, status. Who uses rquota these days...??) It's not rocket science. We have tons of FW openings for NFSv3 here in our complex network environments internally inside Ericsson's "Customer Zero" (our Engineering and Telco Test environments). It's rarely, if ever, a problem per se. The problem is that the storage traffic is very intense and tends to kill the Firewalls. There are so many sessions going on at the same time that if you put a FW in the middle of the (*one* Firewall mind you...) its CPUs will be at 100% sooner or later
Last but not least: yes there are fundamental performance issues (still) with v4.x. We have done investigations and it's not looking good vs NFSv3. Yes, it's possible to get v4.1 (and pNFS) to perform well if you can get your workload to parallelise very much -- scale out. Be prepared that the work to fiddle with everything and tune all the details to get it it to perform well for you in your particular environment is VERY cumbersome.
If not, if you have "vertical" workload threads that need to do *a lot* (incl metadata) on one (1) mount point, then high risk for a painful experience with ONTAP's v4.1 today. Bottlenecks which have to be removed first and it will take time
/M
-------- Original Message -------- Subject: RE: Re: Date: Fri, 2 Oct 2020 13:18:57 +0000 From: Parisi, Justin Justin.Parisi@netapp.com To: Sebastian P. Goetze spgoetze@gmail.com, Douglas Siggins siggins@gmail.com CC: Toasters Toasters@teaparty.net
We get lots of questions about NFSv4, especially for the security and locking aspects.
The main issues people see with it are performance (especially with high metadata workloads) and complexity in setup.
It's a stateful protocol, so it also sees disruption during failovers.
Mostly, people use it for the following reasons:
* Their business makes it a requirement for the security * They have an application that requires it for the locking * They want ACLs * They only want to open up a single port over a firewall
If you just want it for ACLs, ONTAP allows you to set v4 ACLs and still use NFSv3:
https://whyistheinternetbroken.wordpress.com/2017/08/11/nfsv4acls-nfsv3mount...
_________________________________________________ *From:* Toasters toasters-bounces@teaparty.net *On Behalf Of *Sebastian P. Goetze *Sent:* Friday, October 2, 2020 3:26 AM *To:* Douglas Siggins siggins@gmail.com *Cc:* Toasters Toasters@teaparty.net *Subject:* Re:
I teach NetApp and do have students once in a while using NFS v4, but usually only when necessary, e.g. routing through firewalls (which in my experience seems to be the #1 reason using v4). I did have people using pNFS in production, but that's rare.
Some are evaluating, though. Maybe when multipathing is supported (regular like VMware, not pNFS), there will be an uptick in adoption...
My 2c
Greetings from Northfriesland
Sebastian