NFS is a bit of a pathological case. > but there's no way to generally broadcast this information to every process. Sure there is: pending I/O returns EIO. >

NFS is a bit of a pathological case. > but there's no way to generally broadcast this information to every process. Sure there is: pending I/O returns EIO. > What does `cat` do when it's informed that the file it's reading is temporarily unavailable? Let's test it. I inserted a USB disk, mounted it, started `cat`, and yanked the disk. `cat`'s read(2) call returns EIO, and cat dies with an error. I'd expect similar results from most processes: for applications, there is no sane, in-process way to recover from such a situation; either you can rely on the FS's capabilities, if any, or you need to build those into your files (e.g., how SQLite does). > And then you would have to build in error handling everywhere. Apps that presume I/O isn't fallible are broken. Disconnection is hardly the only possible error during I/O. NFS is, again, rather pathological: the FS driver there I think just keeps the mount alive, and pends the writes until a connection is re-established. I'd argue this is terrible behavior, too: the probability with which an SRE has to debug a hung, nigh unkillable process when NFS is involved in system design is 100%.