yes, partition alignment and RAID are separate topics, but this is one issue,
partitions not aligned to 32K or 64K boundaries on single disks, or in theory, RAID 1, is not an issue, because an IO request for any given block goes only to 1 disk
partition alignment is only an issue in RAID stripes, including RAID 5, 10, even 0, because an IO that should have only gone to 1 disk, ends up going to 2
I had to cut a lot of details and supporting data out of this post to keep it reasonably short, to be more clear, a read cache is ineffective.
First, consider a data buffer in system memory larger than the storage controller cache. In theory, there should be nothing in the storage cache that is not in the database cache, with exceptions for differences in caching algorithms. but mostly, the storage cache duplicates whats already in system memory. this was the double buffering subject from long ago.
Next, if storage cache is larger than database cache, yes, IO does get handled by the cache. But is this a good idea? the cpu cost (on the database server) of going out to storage is much higher than if it were in-process, ie, the sqlserver instance. second, some memory is wasted because of double buffering,
third, caching is not free from the impact sense. that is, if you built a storage system with and without cache, the overhead of caching will degrade the performance of IO that actually go to disk.
Look at the few TPC-C publications that use a SAN for storage. Read the full disclosure carefully. Note that cache is disabled on the data partitions.
All that having been said, I will say an Oracle guy who does alot of EMC work says that a very tiny 2MB read cache per LUN is recommended because this enables read-ahead to work, use the rest for write cache (on transaction apps only)
I think EMC Clarion defaults to read-ahead disabled, because everywhere I have been, sequential performance really stinks, 10-12MB/sec per disk, which is what one would expect if read-ahead is disabled