3 ms·

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 supp

by ylow 3y ago

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.

duped 3y ago
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.
- KirillPanov 3y ago
  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.
mprovost 3y ago
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.
- mac-chaffee 3y ago
  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/ https://lwn.net/Articles/717076/
  - mprovost 3y ago
    True, but I define end of time as a 32-bit integer number of seconds from 1970.
    - knewter 3y ago
      The only sensible interpretation frfr
- chungy 3y ago
  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.
  - mprovost 3y ago
    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).
    - chungy 3y ago
      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.
- FullyFunctional 3y ago
  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.
EdSchouten 3y ago
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 http://linux-nfs.org/wiki/index.php/Server-side_silly_rename

by ylow 3y ago

duped 3y ago

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.

KirillPanov 3y ago
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.

mprovost 3y ago

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.

mac-chaffee 3y ago
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/ https://lwn.net/Articles/717076/
- mprovost 3y ago
  True, but I define end of time as a 32-bit integer number of seconds from 1970.
  - knewter 3y ago
    The only sensible interpretation frfr
chungy 3y ago
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.
- mprovost 3y ago
  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).
  - chungy 3y ago
    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.
FullyFunctional 3y ago
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.

EdSchouten 3y ago

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 http://linux-nfs.org/wiki/index.php/Server-side_silly_rename