The designers of NFS chose to make a distributed system emulate a highly consistent and available system (a hard drive), which was (and is) a reasonable tradeoff. It didn't require every existing tool, such as ls, to deal with things like the server rebooting while listing a directory. (The original NFS protocol is stateless, so clients can survive server reboots.) What does vi do when the server hosting the file you're editing stop responding? None of these tools have that kind of error handling.

I don't know how io_uring solves this - does it return an error if the underlying NFS call times out? How long do you wait for a response before giving up and returning an error?

> as can be seen by anyone who's tried to ctrl+c any app that's reading from a broken NFS folder

Theoretically "intr" mounts allowed signals to interrupt operations waiting on a hung remote server, but Linux removed the option long ago[1] (FreeBSD still supports it)[2]. "soft" might be the only workaround on Linux.

[1]: https://man7.org/linux/man-pages/man5/nfs.5.html

[2]: https://man.freebsd.org/cgi/man.cgi?query=mount_nfs&sektion=...

I run several machines at home with NFS $HOME and I usually don't notice. I'd say with a good network and as long as you're not stress-testing difficult cases like parallel writes to the same data from multiple machines, the average usability of NFS is actually very good.

I did have a hell of a difficult time once with intermittent failures from a poorly seated network cable.

Samba too