I actually went further. Here's the originl setup:

1 Mirrorset - Transaction Logs (2 disks). Windows Drive I:

1 RAID10 - Data - MDF and NDF file (8 disks). Windows Drive J:

I was getting bad performance with Huge Average disk queue Lengths, so I split up the disks like this:

1 Mirrorset - Transaction Logs (2 disks). Windows Drive I:

1 Mirrorset - Data - One MDF and One NDF file  (2 disks). Windows Drive J:

1 Mirrorset - Data - One NDF file  (2 disks). Windows Drive K:

1 Mirrorset - Data - One NDF file  (2 disks). Windows Drive L:

1 Mirrorset - Data - One NDF file  (2 disks). Windows Drive M:

(All NDF files were in one filegroup, so all tables, indexes, etc. were 'striped' accross those four files). The other option is to place objects like tables on specific files (in their own filegroup) and their non-clustered indexes on other filegroups.

Windows performed much better, with Average disk queue lengths (for J, K, L, and M combined) around 20. This was oppossed to Avg. disk queue lengths up to 900 when the same physical disks were in a RAID 10 set (and one Windows drive letter, J).

BTW. stuff like the above is where it is good for DBAs to have a good understanding of SAN architecture, or to at least have a good storage/systems engineer to work with. My background was systems engineering before becomming a DBA, and I think it has served me well.