SQLWebpedia

The PSS Team blog (Bob Dorr wrote article) has a great discussion on a couple of common myths for SQL Server performance:

• SQL Server Uses One Thread Per Data File
• A Disk Queue Length greater than 2 indicates an I/O bottleneck

 http://blogs.msdn.com/psssql/archive/2007/02/21/sql-server-urban-legends-discussed.aspx
Summary notes from article:
Adding more files and properly aligning them with storage can increase the I/O performance for a variety of reasons but achieving new I/O threads per file is NOT one of them. SQL Server I/O is all about I/O response time...SQL Server uses asynchronous I/O allowing any worker to issue an I/O requests regardless of the number and size of the database files or what scheduler is involved
...[on tempdb argument ]This is again a misinterpretation of the legend as tempdb tuning is all about the allocation activity, not a number of threads per file (no such thing). 
 SQL Server 2005 reduces contention with the ‘cached temp table’ feature and allocation contention skip ahead actions...When multiple workers are attempting to create or drop objects in tempdb you can decrease the bottleneck by having

• As many files in tempdb as schedulers
• All files sizes are equal
• Uniform allocations enabled (-T1118)

On the Disk Queue Length >2 issue: SQL Server is designed to push disk queue lengths above 2 when it is appropriate. The next time someone looks at the disk counters on the system and states the disk queue length is above 2 and this is a problem take a minute to look at other data points.   The key for SQL Server is the I/O response times. Start by looking at the Average Disk Seconds Per Transfer for the same I/O path. Then look at the SQL Server sysprocesses and waitstats for buffer based I/O wait information.   You want to see evidence from SQL Server that the disk queue length is related to an I/O bottleneck.