News for hackers. Stuff that matters.
Re:Don't trust default timeouts by mprovost on Saturday August 29, 2020 @10:17AM (#24316265)
One of the main complaints about NFS, one of the original distributed systems - is that client machines hang when the server is unavailable. The problem is that the (Unix) filesystem layer assumes that disks are reliable (spoiler alert: they're not), and NFS stretches disk access across a network.

The concept of a "soft mount" with a timeout was introduced to NFS but it's almost never recommended. This is because client programs have no idea how to handle a timeout from the filesystem. This article shows how every HTTP client has to be configured to handle failures. Imagine if every program that accesses a file, from /bin/cat all the way up, had to have error handling code to deal with timeouts and retries. A sane choice is to wait infinitely if there's nothing more intelligent that you can do.

Re:Don't trust default timeouts by tyingq on Saturday August 29, 2020 @10:51AM (#24316480)
"NFS server xyz not responding , still trying" is still in my head, despite not using nfs for probably a decade.
Re:Don't trust default timeouts by orisho on Saturday August 29, 2020 @10:48AM (#24316465)
Most software expect an error of some sort (e.g. file not found, permissions) and do nothing with it except print it. This would be sane behavior with a NFS timeout. Let the user retry rather than hanging forever.

Consider a startup script that hangs forever. Better it fail than hang. Or ls hanging forever when instead the filesystem could fail the operation after 30s.