> 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.
It's a bit surprising there isn't much NFS how to online, but most of the NFS developer community is involved with enterprise servers and probably the how to stuff is in product installation guides and such... If you don't really require fcntl locks, then NFS v3 is certainly a simple protocol for transferring data, though as I mentioned before, using UDP is now strongly discouraged due to the fragment reassembly issues causing both severe performance issues and data integrity issues. NFS v4 doesn't always perform as well as NFS v3, but if you are doing fcntl locking, it's far superior for resiliency across server and client crashes. I can try and answer questions here... I know a thing or two about NFS (having worked with both the Linux kernel NFS implementation and the nfs-ganesha user space server)... Frank > On Wed, Nov 15, 2017 at 11:10 PM, Tomas Kuchta > <tomas.kuchta.li...@gmail.com> 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" <tomas.kuchta.li...@gmail.com> > > 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" <ffilz...@mindspring.com> 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" <kingbeow...@gmail.com> > 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 > >>> > > PLUG@pdxlinux.org > >>> > > http://lists.pdxlinux.org/mailman/listinfo/plug > >>> > > > >>> > > > >>> > _______________________________________________ > >>> > PLUG mailing list > >>> > PLUG@pdxlinux.org > >>> > 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 > >>> PLUG@pdxlinux.org > >>> http://lists.pdxlinux.org/mailman/listinfo/plug > >>> > >> > > _______________________________________________ > > PLUG mailing list > > PLUG@pdxlinux.org > > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
