I'm not seeing any problems, at least none of the users are realistically complaining. The monitors say the disk IO is good and latency is under 15ms or so. Occasionally higher but nothing sustained.
What brought up the question is this. This server is running under Hyper-V and there is a push to cluster the VM host machines. When the sys admin checked the configuration with MS, the response was to move all of the files to a single drive letter. The rational was it was simpler and more reliable to only have to mount one drive and keep it connected than several drives.
That sort of made sense, simpler is generally always better. But really flies in the face of everything that I've been told about how to configure SQL Server.
What made me stop and think was how this SAN is constructed. Basically there is only 2 controllers and I have no influence on how the drives are created. The SAN is shared with file storage, RDS desktops, client VM's, server VM's, you name it in a small to medium company. In other words, I cannot specify the data files are on one controller and the log files are on the other. So if the data and logs are on different drive letters but the drive letters all point back to the same controller and disks, how is that going to help protect from a disk failure or make IO faster?
The servers are, in my opinion, lightly loaded in spite of one having 75 databases installed. Some have data updated all the time, others are basically updated nightly and used for reporting, some are for SharePoint, etc. Total disk space is less than a TB, so not really all that big.
I know, the only answer is "It Depends". But looking for some reason to make the change or insist on keeping things the same.