C:\ is for OS, D:\ is for Data?

"Back in the day" we always segregated our OS drives (in Windows) from our Data drives. In the Linux world, although I am much less familiar with it, I am aware that the wisdom dictates even more volumes defined and used in a best-practice configuration.

Now that server storage is just as likely to be on a SAN (where the disk resources are shared by many individual operating systems and applications), does it really matter any more that the OS and Data partitions be segregated at the volume level?

What are your thoughts?

There are three main drivers for keeping OS and Data separated storage-wise.

1. Space. As ErikA points out, you really REALLY don't want your OS volume running out of space. All kinds of bad things can happen. Separating these two growth methods
2. I/O Access Requirements. The type of I/O used on your OS volume is generally a lot different than the kind used by your Data volumes. Keeping your I/O types separate is a very good idea on many levels.
3. Storage Portability. When it come time to upgrade your server OS, you can nuke the OS volume and keep all the data. Or in SAN or VM environments you can just move the Data volume to a new, freshly installed server and save time on upgrades.

Also, some operating systems (Windows is among them) don't take too kindly to resizing the OS volume, which means you generally need to give as much of it as it will need in its lifetime when you format the server. Contrast this to Data volumes which can and frequently are resized many times over the lifetime of a server. Even in fully virtualized environments where the OS and Datavvolumes themselves are being housed in the same actual storage, not being able to resize your OS volume can be a major handicap. Windows 2008+ is now recommending 30GB for the C:\ drive these days, a far cry from the 10GB we were using on Server 2003; this is something that will nail many Windows admins as they make the conversion from 2003 to 2008.

Yes, most certainly separate OS from data. I've seen it time and time again where, with a shared partition, the partition ends up filling up and making it impossible to patch the OS, impossible to extend the partition (due to various reasons), etc.

IMO, the overhead of managing two partitions is a small price to pay for the isolation provided.

With regards to the SAN-backed systems you referred to, that still won't protect you from data filling up your OS partition. With fully-virtualized storage, you don't need to worry as much about ensuring that OS and data live on separate spindles.

I would say it depends on what you are doing with the system. If you may need to reinstall the os you might save yourself some hassle by putting all of your data on a separate partition. Otherwise I don't see the necessity any more. My two cents.

In general principle, I think segregating the default OS space (such as C:) from the Data (D:) is a good idea, but I would also recommend creating a smaller partition for Log files (L:) to keep them a little more secure and prevent some types of Denial-of-Service attacks.

Linux is very nice in that the file system remains hierarchically under one root directory no matter how many physical disks or virtual partitions you use. I would definitely partition the disk, but not necessarily for data vs. OS separation (since very often the two get mixed up anyway).

I would look at:

1. Which subdirectories are likely to fill their disk and cause space problems for other directories (i.e. partition off /home and /var/log for example).
2. Whether different parts of your directory structure need different file systems for performance reasons (i.e. XFS for stability, Ext3 for all-around use, etc.)
3. Which directories might need to be expanded in the future -- these are good candidates for partitioning because you can simply rename the directory, partition and mount a new set of disk space to the directory location, and copy the data from the old to the new location.