True for small QD's that your stripe size size has a larger (by percentage) effect, however this is minimal in real world practice. Read ahead disablement is good where your workload request size is small enough and random enough so that the next block from the subsystem would not be otherwise requested. With most raid (hardware) type cards you have options of 'drive read ahead' and 'volume read ahead' or similar. Those terms, the 'drive read ahead' is to have the drive read as many blocks as needed to match to the stripe size of your array. the volume read ahead is to read multiple stripes in anticipation of larger requests. Add on top of that file system read ahead (and/or logical volume or OS buffers). All of this needs to be tested, the defaults are just best guesses for general use which will probably never match a particular case. As for disabling caching (assuming you mean write cache) this is /always/ a good idea for any cache that is not battery backed (I'm not talking UPS here, I'm talking BBU). Some file systems support write barriers which allow some minimal caching to be enabled (the fs writes through to the drive and waits for a safe store response). This generally doesn't work w/ raid setups however (raid's fake the response).

cluster or block sizes of a file system only really have an effect on writes, there is no read effect (as, barring the above read a-heads, only the blocks that the application requests will be read regardless if it's a full cluster or not with the limit being that any device can't read less than the physical sector size of the media (i.e. 512byte generally). Higher performance file systems have concepts of allocation groups (think of the file system being comprised of many file systems each controlling their own clusters/blocks so things can be done in parallel), NTFS is not one of these however, though NTFS does use some features like btrees for indexing.

As for multiple I/O operations at the same time on different file systems, this is what I was alluding to before that you want different drives. Each file system (NTFS) can only do one task at a time due to the need to maintain a lock on the metadata. The problem here is that this is not really the OS doing this, it's just the nature of having multiple file systems so your application is the one that needs to be written to understand some parallelism or give you the opportunity to move structures to different file systems.

RAID-3 is a full stripe raid, it works well for video (large files) and some COW (copy on write) and log based file systems. It does not do well with general user data at all as there is no means to write a partial stripe so if you do that you will take a hit. RAID-4 (and variants) is nothing more than a raid 0 + separate parity disk (or disks). This can have problems with bottlenecking with parity updates and was one reason why raid-5 (distributed parity) became more popular so as to not have the same spindle(s) be a bottleneck. It works (or can be made to work with some abstraction layers) but you need to know your workload well to make sure you pick the right tool for the job. All raids have all spindles working all the time so I don't understand that comment really unless you're referring to IBM's distributed sparing idea (RAID 1E, 5E, et al) where even the spare disk is part of the raid set. This is nice but by doing this you no longer have a global spare (it's part of the raid set) but since you're always using it you have less of a chance to get surprised when a drive dies and the hot spare is found that it doesn't work. Also you get the additional drive's iops added to the raid set.

For SSD's, yet they have some (what you can call striping) of the cells or low level raiding which is important for alignment purposes but this is really no different than say SAN or environments using logical volume groupings (i.e. multiple layers of storage that have to be considered for alignment purposes). The biggest problem here is the lack of vendor information to explicitly indicate the underlaying mechanisms of the drive so it makes it very hard / lot of leg work to reverse engineer what is going on and then build up. I think it should be standard information on the spec sheet just like the drives block size.