4 ms·

The OS notices when disks or NFS servers ("NFS server not responding") go missing, but there's no way to generally broadcast this information to every process.

The OS notices when disks or NFS servers ("NFS server not responding") go missing, but there's no way to generally broadcast this information to every process. And then you would have to build in error handling everywhere. What does `cat` do when it's informed that the file it's reading is temporarily unavailable? You can either block the next read() call and hang the process until the disk comes back, or return a hard error that it's gone forever. Otherwise each application has to have its own wait/timeout code. (Which is what applications dealing with HTTP have to deal with but at least when you make an HTTP connection you're aware that something could go wrong.)

deathanatos 3y ago
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%.

deathanatos 3y ago

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%.