If you're tempted to put everything on one volume - Windows, data files, log files and tempdb files - DON'T!
"Everything on One Disk
Some subscribe to the theory that modern hardware can act like a shock absorber for whatever the worstworkload you can throw at it: just build a single LUN with disk in some type of RAID configuration and just put theentire database on it. This is just not the case. Thoughtful planning and testing is still mandatory. Mixing tempdb,transaction log and data together can and will cause performance problems. There are other considerations in this,too. For example, by putting log and data on the same physical volumes, you have created a single point of failure.Lose one RAID volume and you have lost log and data. What’s more, the performance penalty for calculating theparity bit on the log and/or tempdb can be a significant factor in disk latency (response) times. This can be seen inthe DMV’s and ::FN tables. (We’ll look at this in the monitoring section of the paper.) Effectively when we co-mingle workloads on the same physical disk (mixing log, tempdb, and data)—you are reading and writing to thesame disk at the same time which aggravates the situation. For example, you run a SELECT statement with anORDER BY that is not indexed well. You will be reading off the same disk that you will be writing to with thetempdb. The same can be said for backing up to the same volume that you have your database on: reading/writingto the same disk and a single point of failure (lose the data and lose the backup at the same time). Regrettably, thisis a common configuration we see often enough."
Poor Disk Performance, Time Outs, Database and the SQL Server Error Log