Under Solaris, are the filesystem drivers smart enough to control EWOULDBLOCK based on nfs read-ahead's?

Under Solaris, do the filesystem drivers even *return* EWOULDBLOCK/EAGAIN?

It's been ages since I've seen SunOS 5.x or even SunOS 4.x kernel code, but, as I remember, EWOULDBLOCK and EAGAIN were used only on "slow" devices, e.g. serial ports and pseudo-terminals, network connections, pipes, other sockets/STREAMS devices, and perhaps some specialized devices; it wasn't used on files.

I.e., it was used only for devices where the availability of input, and the availability of buffer space for output, was not completely under the control of the machine running the program - it depended on another machine on the network, or on a user.

EWOULDBLOCK antedated NFS, and heavy use of networked file systems; at that time, file data's availability was under the control of the machine reading or writing the file (it was dependent on the disks on which the data resided, but that's part of the machine).

With NFS or CIFS or other networked file systems, you could argue that even the availability of input from ordinary files is now under the control of machines other than the machine reading the file; for better or worse, however, non-blocking I/O and "select()"/"poll()" tend not, as far as I know, to be implemented by file system driver, so that "select()" and "poll()" assume that input is always available and output is always possible, and non-blocking I/O isn't different from blocking I/O.

I'm trying to decide if it'd be worth going to the trouble of implementing nonblocking io into the file reads of our httpd (whose docuement tree is all nfs-mounted)... Given the inherent latencies in NFS vs. local disk, I'm hoping that I could only issue reads to filehandles that already have read-ahead data.

I suspect that won't help. You might want to experiment with it - by, for example, writing a program that opens a file in non-blocking mode and, when you type a line to it, attempts to read from the file and reports whether it got -1 and EWOULDBLOCK/EAGAIN, and:

run the program, having it read from a file on some file server;

once it's waiting for you to type a line to it, temporarily unplug that file server from the network, type a line to the program, and see whether it hangs waiting for the read to finish (with the machine giving "NFS server XXX not responding") or gets -1 and EWOULDBLOCK/EAGAIN;

plug the file server back into the network when you're done.

If that fails, you'll have to try something else. I suspect, for example, that the asynchronous I/O operations - "aio_read()" and "aio_write()" - work on ordinary files, in which case you could use them to start a read on the file without blocking waiting for it to finish; you could later wait for the read, or arrange to have SIGIO, for example, delivered when the read completes.

That doesn't let you avoid doing the read altogether if the data isn't already available, but at least it keeps your program from blocking waiting for the read to finish.

Of course, it may be that the NFS latencies aren't worth worrying about - or aren't as bad as the latencies on your local disk - as Chris Lamb noted, so I'd be inclined to see whether there *is* a latency problem before trying to solve the problem.