The most current document says this: "The differences between Version 2 NFS, Version 3 NFS, and Version 4 NFS will be explained later on; for now, you might simply take the suggestion that you will need NFS Version 3 if you are installing a dedicated, high-volume, or production file server. NFS Version 2 or 4 should be fine for casual use." The fact that the document has not been edited in 10+ years, and is hosted on sourceforge, might easily be considered an embarrassment to all involved, but that's (afaict) the most up to date advice available.
http://linux-nfs.org/wiki/index.php/Main_Page which points at this: http://nfs.sourceforge.net/nfs-howto/ Russell On Thu, Nov 16, 2017 at 12:00 AM, Russell Senior <[email protected]> wrote: > For me, its the simplicity of it, and the legacy of it working for a > long time, and the utter lack of modern best practices documentation. > If you go looking for NFS howto's, you almost immediately notice that > they are all at least 10 years old, and there is pretty much nowhere > to ask questions. At least, that has been the case in the past when > I've tried to go looking. UDP in particular is stateless, which is a > nice feature. > > On Wed, Nov 15, 2017 at 11:10 PM, Tomas Kuchta > <[email protected]> wrote: >> We talked about my NFS v3 versus v4 reasons over a pint today, what better >> place! >> >> We talked about some enterprise filer issues not working correctly with >> RHEL. I guess this could be extended to any heterogenous x-nix environment. >> Maturity, is good enough reason - v3 is 1995 tech and v4 is 2000/2003 >> standards. >> >> Though that would not necessarily apply to RPi. So, the question remains - >> what else makes people prefer v3? >> >> I hope that my original wording didn't make the question sound like if I >> was trolling, which wasn't my intention. >> >> - Tomas >> >> On Nov 15, 2017 3:01 PM, "Tomas Kuchta" <[email protected]> >> wrote: >> >>> I am curious why using NFS v3, especially when having connection or >>> service reliability issues? V4 is more resilient and copes with >>> slow/unreliable connections better. >>> >>> Why not standard (these days) NFS v4? Are you avoiding it because of the >>> name spaces preventing you mounting the exports exactly the same way as in >>> v2 or v3? >>> >>> Just curious what motivates people to do the extra legwork to avoid clear >>> benefits of new and improved protocol like NFS. >>> >>> Tomas >>> >>> >>> >>> On Nov 15, 2017 10:13 AM, "Frank Filz" <[email protected]> wrote: >>> >>>> > Or maybe nfs3 with udp. >>>> >>>> You need to be careful of NFS with UDP on high speed networks (Gigabit or >>>> faster), the fragment lifetime is long enough for the 16 bit packet id to >>>> wrap, and the result is painfully slow data transfer with a significant >>>> possibility of data corruption (the checksum is also only 16 bits, so >>>> significant chance of assembling fragments from multiple packets with then >>>> over enough data transfer, an almost certainty of a miss-assembled packet >>>> having a valid checksum). This is not theoretical, I have observed it in >>>> test environments... >>>> >>>> Are you using fcntl locks? >>>> >>>> NFS should recover just fine. What mount options are you using on the >>>> client? What kinds of errors are you seeing? >>>> >>>> Frank >>>> >>>> > On Nov 13, 2017 5:17 PM, "King Beowulf" <[email protected]> wrote: >>>> > >>>> > > On 11/13/2017 02:03 PM, michael wrote: >>>> > > > I have an NFS 3 server on a Raspberry Pi 3 Model B. That server for >>>> > > > whatever reason seems to be going down, frequently. >>>> > > > >>>> > > > The clients, how do I trigger recovery when the server comes back >>>> up? >>>> > > > Of course, I need to figure out why the server is going down. >>>> > > > Recovery usually involves an umount followed by a mount of the NFS >>>> > > > share. >>>> > > >>>> > > You can try setting up autofs to dynamically mount on access, instead >>>> > > of via CLI or permanently in fstab. That might be a bit more >>>> resilient. >>>> > > >>>> > > -Ed >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > PLUG mailing list >>>> > > [email protected] >>>> > > http://lists.pdxlinux.org/mailman/listinfo/plug >>>> > > >>>> > > >>>> > _______________________________________________ >>>> > PLUG mailing list >>>> > [email protected] >>>> > http://lists.pdxlinux.org/mailman/listinfo/plug >>>> >>>> >>>> --- >>>> This email has been checked for viruses by Avast antivirus software. >>>> https://www.avast.com/antivirus >>>> >>>> _______________________________________________ >>>> PLUG mailing list >>>> [email protected] >>>> http://lists.pdxlinux.org/mailman/listinfo/plug >>>> >>> >> _______________________________________________ >> PLUG mailing list >> [email protected] >> http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list [email protected] http://lists.pdxlinux.org/mailman/listinfo/plug
