Mediocre NFS read performance

[no_connection]

When reading sequential we already queue up enough to know what comes next until the read is done (unless you request data at a slower rate than discs can read).
Might not be thinking of the same thing with "read ahead". What you described sounds more like regular intelligent queue than predictivly read stuff the user might request in the future which in this case would come at the expense of reading what the user wants now. Like adding pit stops at the way picking stuff up that might get used.

 

[jgreco]

The question here is about how to get faster read speeds of sequential data.

Your statement, "at the expense of reading what the user wants now" is a nonissue, because you already have that in cache, so there is no "expense" or risk there, and the fact that the user was reading the file at high velocity led to that being cached, and the only real risk is that the user MIGHT screech to a grinding halt at the current block, which makes speculative read-ahead a slight risk in that it could be forcing other useful data out of the ARC. But if you're reading a 50GB file, and you've gotten 10GB into it, sequentially and at high speed, there probably isn't a huge amount of risk in reading at least the next 1GB speculatively.

In practice, ZFS doesn't seem to do as much speculation as it could, which is what is causing the OP's question. From a "naive" perspective, the average person might kinda expect that if you have 12 disks in a RAID5, with a tight interleave like 64K, that you would get read-ahead behavior that is at least 50% of the I/O capacity of the underlying disks, because this is how it actually does work with hardware RAID controllers. This is devastating to concurrent performance, of course, but great for benchmarks. ZFS optimizes more for concurrent performance and avoids swamping the pool with a single client's requests. Both methods have their ups and downs.