sp_BlitzFirst - File Stats Interpretation
Disclaimer: I'm one of the authors of sp_BlitzFirst and the First Responder Kit.

The wait stats section is on top for a reason: you need to focus on your top wait types. It doesn't really matter how fast or slow your drives are if SQL Server isn't waiting on them. Great example: say you've got a read-only database hosted on a server with enough memory to cache the entire database, and none of your queries happen to hit TempDB. Once the data's up in cache, does it matter how slow your drives are? Kinda - for maintenance tasks like backups and index rebuilds - but not for end user queries.

Now, look at your server's top 3 waits:


CXPACKET 1,530 hours - related to parallelism
OLEDB 502 hours (typically harmless, but I leave it in there because sometimes it isn't harmless in large quantities)
LATCH_EX 250 hours - usually goes hand in hand with CXPACKET
PAGEIOLATCH_SH 191 hours - reading data pages from a data file.


Yo, man - your top wait is coming up on TEN TIMES LARGER than your storage wait.

Forget the storage: you're barking up the wrong tree. Focus on your top wait type. To tune parallelism, go to https://BrentOzar.com/go/cxpacket. The short story:


Set Cost Threshold for Parallelism to 50 (some folks will say 40 or 75, and that's fine too)
Set MAXDOP to the number of cores in each processor
Find the queries reading large amounts of data, and tune them or the indexes they need. My favorite way is sp_BlitzCache @SortOrder = 'reads'
Ask SQL Server which indexes it wishes it would have had during query execution. My favorite way is sp_BlitzIndex @GetAllDatabases = 1.