4 ms·
NFSv3? Wouldn’t NFSv4 be more appropriate?
by teddyh 3y ago
NFSv3? Wouldn’t NFSv4 be more appropriate?
- ylow 3y agoNFSv4 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.
- duped 3y agoYou 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.
- KirillPanov 3y agoYou 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.
- mprovost 3y agoVersion 3 will be supported until the end of time. Version 4 was an evolutionary dead end that never took off or saw much adoption.
- mac-chaffee 3y agoFunnily 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/ https://lwn.net/Articles/717076/
- chungy 3y agoVersion 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.
- mprovost 3y agoIt'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).
- chungy 3y agoI 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.
- FullyFunctional 3y agoThat’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.
- EdSchouten 3y agoAlso 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 http://linux-nfs.org/wiki/index.php/Server-side_silly_rename
- deleted 3y ago[deleted]
- LeoPanthera 3y agoNFS4 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.
- chungy 3y agoNFSv4 has sane, good locking out of the box. Implementing lockd on an NFSv3 server is a big world of hurt.
- hedora 3y agoIs 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 https://access.redhat.com/solutions/1179643
- chungy 3y agoNFSv4 should never do that, and I've never seen it happen.
- notacoward 3y agoThen 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.