I have a 21TB array but only 16TB is visible from Windows

Unfortunately you might find such a dissertation difficult to find, and even if you did stumble across one while browsing relevant academic paper collections, sod's law says that the one circumstance not covered by the paper is the one closest to your expected I/O patterns.

It is actually a complex area - not complicated, as each part of the problem isn't rocket science, but complex because the different factors can interact with each other in fairly subtle ways - this is why you will find significant inconsistencies in some recommendations (the result of the tests that the recommendations are based upon depend greatly on the exact nature of the tests and the I/O pattern they are trying to simulate). Therefore finding a paper that covers your exact needs would be quite a stroke of luck unless your needs are very basic (in which case more generic recommendations like "the defaults will probably be fine" will actually suffice). Any paper that tried to cover everything (or even just most things) would take so long to produce as to be irrelevant long before it were completed.

The only true way to be sure is to give a few combinations a try. Try replicate a typical I/O load for your application on a couple of configurations and see how it benchmarks. I hope this doesn't come across as unhelpful, but I think it really is the only way to be sure. Having said that: if you provide a few more specific details of the environment you are considering RAID configuration for, someone might be able to point you to a paper or other resource that is more geared toward that sort of environment+kit+application+load combination than the sources you have already found.

As a nearly-on-topic example I did a few RAID tests on my netbook this last week (after deciding the internal SSD was writing far far far too slowly) and found some results that were far from what I expected when I started (though part of this is due to me not realising exactly how bad the internal SSD was by some metrics!). I'll not bore you with the exact details here as the I/O patterns I cared about in this circumstance will be entire worlds away from what it sounds like you are considering, but I'll reiterate that I think there really is no substitute for a few benchmarking runs based upon your knowledge of the system you are intending to build if you are wanting specific indicators/recommendations.

First use-case: Small File Server

You have so few demands on that system that optimizing the read-ahead settings won't get you much. Such workloads are significantly random I/O, but infrequent. Read-ahead will get some advantages, but the users aren't likely to notice.

Second use-case: Backup-to-Disk target

This type of system will be primarily write. Read-ahead in this instance is not used much since it's writing most of the time. The cache will be used to reorder writes. Which should go pretty well since this is primarily sequential writes happening (unless it's a deduplication system, at which point it'll be highly random) which makes things go a lot faster.

The caveat here is if backups are later staged to tape. The staging process will be primarily read, and if you're doing that kind of thing Read Ahead settings will absolutely net you gains so set them as high as you can (sequential writes mean sequential reads here! Unless it's a dedupe system, at which point it doesn't matter any more).

Third use-case: VM Host

This type of system is the most demanding on storage since it's a highly random mix of I/O types. Of the three types presented, it'll need the most tuning. Some read-ahead will be valuable, but not much due to the nature of the I/O demands.