I saw a fantastic presentation at the PASS Summit years ago from one of the vendors that worked extensively to perform hardware monitoring. They're not in business anymore, but their employee had a world of knowledge around hardware and specific recommendations at the time regarding the size of your RAID sets and types of disks you'd fill them with. This was before the time of cheap SANs, when almost every SQL Server I knew of used local disks.

I was reminded of that presentation this week when I saw Tony Rogerson's Short Stroking piece on disk performance, helping us understand a bit about performance and how our choices on disk usage can affect the way our databases impact users. It's a short piece, with some details about why you might not want to fill up those disks and why saving some space is a good thing.

What's not said is that a large SAN can overcome lots of this (as can SSDs), but if your data files are stored on arrays that place them on mostly full disks, you could see performance impacts. That's why I'd suggest that you think about the RAID layout and number of disks, not only ensuring free space inside your mdf/ndf/ldf files, but also on the underlying disk. I'd also suggest you review the physical layout of your LUNs with the SAN administrators and not count on the large number of platters to ensure you don't encounter performance problems.

I might make one more suggestion to make friends with the SAN people and buy them lunch at times. The performance of their systems directly affects yours.

For most of us this isn't likely a big problem, but if you are pushing the limits of your disk space and performance is not what you'd like, adding disk space, often a cheap endeavor, might be a quick way to make things run faster.