NFSv4 is quite a bit more complicated and is also stateful which makes it a bit more challenging to implement. NFSv3 is a good starting point, and is still supported on all the major platforms. Certainly, extending with a v4 implementation would be great future work.
Also keep in mind that NFSv4 is mostly adds necessary complexity. Not accidental complexity.
For example, NFSv4 supports accessing files that have been unlinked, but still have one or more open file descriptors. NFSv3 does not. It needs to resort to a technique named ‘silly renames’.
You will have to throw away almost all of your code for NFSv4, it's a completely different protocol. One of the advantages of 4.x is that you don't need the portmapper or mount protocols, you just need to know the hostname/port of the server.
You can run NFSv3 without the portmapper, and for most servers (like unfs3) the mount protocol is served by the same process as the filesystem, so it isn't two daemons -- just one.
Funnily enough, "the end of time" for NFSv3 is in about 15-83 years, depending on whether the implementation uses signed or unsigned 32-bit integers for timestamps: https://lwn.net/Articles/717076/
It's widely implemented but not adopted. Most vendors implemented v4 to tick a box for some RFQ. I don't think any of the commercial fileserver vendors publish numbers but I used to work in that space and internally customer adoption of v4 was always a single digit percent. When I was on the customer side in HPC none of the supercomputer clusters were using v4 (I'm sure there are exceptions that I wasn't aware of).
That’s completely incorrect. NFSv4 was a quantum leap in performance; greatly reducing network traffic via COMPOUND and dramatically improving write performance via delegation.
All my file access is over NFSv4 (in a mix of 10 GbE and 100 GbE).
Having GP’s crate expand to support NFSv4 would be welcome but a nontrivial bit of work.
