Doing so adds lots of visual clutter.

Allowing the kernel to send multiple reads for the same file handle
concurrently interferes with sequential read detection like that in
GoogleCloudPlatform/gcsfuse#103.

One of them caused the writeMessage error observed on OS X in
GoogleCloudPlatform/gcsfuse#101.

It's not expecting them.

This reproduces the writeMessage errors from
GoogleCloudPlatform/gcsfuse#101.

For GoogleCloudPlatform/gcsfuse#99.

On Linux this significantly increases gcsfuse sequential read throughput.

As best I can tell, this instructs the kernel not to synchronize on the
completion of a read request before sending further requests. This
definitely means further read requests, but I believe it means any sort
of request as well. It appears to make a big difference to gcsfuse read
support.