For a production solution it's better to put OS, data, log, and TempDb on different volumes, even if those volumes share a single disk, storage pool, or SAN array.

This limits the blast area of running out of space, and provides seperate visibility to the different IO types through the Windows Logical Disk performance counters.

However, it works fine, and is absolutly supported to put everything on C.

For a production solution it's better to put OS, data, log, and tempdb on different volumes, even if those volumes share a single disk, storage pool, or SAN array.

This limits the blast area of running out of space, and provides separate visibility to the different IO types through the Windows Logical Disk performance counters.

However, it works fine, and is absolutely supported to put everything on C.

For a production solution it's better to put OS, data, log, and TempDb on different volumes, even if those volumes share a single disk, storage pool, or SAN array.

This limits the blast area of running out of space, and provides seperate visibility to the different IO types.

However, it works fine, and is absolutly supported to put everything on C.

For a production solution it's better to put OS, data, log, and TempDb on different volumes, even if those volumes share a single disk, storage pool, or SAN array.

This limits the blast area of running out of space, and provides seperate visibility to the different IO types through the Windows Logical Disk performance counters.

However, it works fine, and is absolutly supported to put everything on C.