> 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
