Hacker News Reader

Comment by teddyh | Hacker News Reader

NFSv3? Wouldn’t NFSv4 be more appropriate?

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.

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.

Version 3 will be supported until the end of time. Version 4 was an evolutionary dead end that never took off or saw much adoption.

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/

True, but I define end of time as a 32-bit integer number of seconds from 1970.

The only sensible interpretation frfr

Version 4 has been implemented in and widely used in Linux, FreeBSD, Solaris, Microsoft Windows...

I'm not sure what value of "much adoption" you're using, but I think it's had great adoption.

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).

I use it all the time. It's a huge improvement over NFSv3 for many reasons (performance, network ports, locking, ACLs, ...).

All the operating systems I names have fully implemented and mature NFSv4 stacks. Definitely not a MVP to tick a box.

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.

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’.

http://linux-nfs.org/wiki/index.php/Server-side_silly_rename

NFS4 is a huge ugly bloated mess of a protocol, and they keep adding more stuff to it.

NFS3 is small (I wouldn't say "elegant" but by comparison...), works, and doesn't have anything wrong with it.

NFSv4 has sane, good locking out of the box. Implementing lockd on an NFSv3 server is a big world of hurt.

Is there some way to configure NFSv4 not to silently corrupt data or surface transient network errors to userspace?

(Correct NFSv3 implementations block forever, which is the best of three bad alternatives.)

https://access.redhat.com/solutions/1179643

NFSv4 should never do that, and I've never seen it happen.

Then again, if you're using file locking on a distributed filesystem at non-trivial scale you're in for a big world of hurt anyway. Source: I was a developer and maintainer of exactly such a beast for over a decade.

Reply on news.ycombinator.com