[PLUG] NFS 3 server going down.

[Russell Senior]

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
<tomas.kuchta.lists at 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.lists at 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" <ffilzlnx at 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" <kingbeowulf at 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 at pdxlinux.org
>>> > > http://lists.pdxlinux.org/mailman/listinfo/plug
>>> > >
>>> > >
>>> > _______________________________________________
>>> > PLUG mailing list
>>> > PLUG at 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 at pdxlinux.org
>>> http://lists.pdxlinux.org/mailman/listinfo/plug
>>>
>>
> _______________________________________________
> PLUG mailing list
> PLUG at pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug