Partition C Drive Windows 10

[Steven]

Inmy jobs almost two decades ago, IT experts would keep the size of Windows' main partition (C drive) extremely small compared to the other partitions. They would argued this runs PC at optimum speed without slowing down.

But the downside of it is, C: drive easily fills up if kept small, and soon you can't install new software as it runs out of space. Even if I install software in D: drive, part of it is always copied to C: which fills it up.

In my jobs almost two decades ago, IT experts would keep the size of Windows' main partition (C drive) extremely small compared to the other partitions. They would argued this runs PC at optimum speed without slowing down. [...] My question is this practice still good?

In older Windows versions, there were performance problems with large drives (more accurately: with large filesystems), mainly because the FAT filesystem used by Windows did not support large filesystems well. However, all modern Windows installations use NTFS instead, which solved these problems. See for example Does NTFS performance degrade significantly in volumes larger than five or six TB?, which explains that even terabyte-sized partitions are not usually a problem.

Nowadays, there is generally no reason not to use a single, large C: partition. Microsoft's own installer defaults to creating a single, large C: drive. If there were good reasons to create a separate data partition, the installer would offer it - why should Microsoft let you install Windows in a way that creates problems?

You should really back up all your data anyway, to splitting it across partitions does not really help. Also, if you really need to do it, all backup software I know lets you selectively back up a part of a partition.

While this is theoretically true, there is no guarantee damage will nicely limit itself to one partition (and it's even harder to check to make sure of this in case of problems), so this provides only limited guarantee. Plus, if you have good, redundant backups, the added safety is usually to small to be worth the bother. And if you don't have backups, you have much bigger problems...

While this may be true in theory, in practice many programs will write settings and other important data to drive C: (because they are unfortunately hardcoded to do that, or because you accidentally forgot to change their settings). Therefore IMHO it is very risky to rely on this. Plus, you need good backups anyway (see above), so after reinstallation you can restore the backups, which will give you the same result (just more safely). Modern Windows versions already keep user data in a separate directory (user profile directory), so selectively restoring is possible.

The historical reason for this practice is most likely rooted in the performance properties of rotating magnetic HDDs.The area on spinning disks with the highest sequential access speed are the outermost sectors (near the start of the drive).

If you use the whole drive for your operating system, sooner or later (through updates etc) your OS files would be spread out all over the disk surface. So, to make sure that the OS files physically stay in the fastest disk area, you would create a small system partition at the beginning of the drive, and spread the rest of the drive in as many data partitions as you like.

Windows has long been notoriously bad at staying stable over time, cleaning after itself, keeping the system partition healthy and providing convenient access to user data on it. So users preferred to reject the filesystem hierarchy that Windows provided and roll their own outside of it. The system partition also acted as a ghetto to deny Windows the means to wreak havoc outside of its confines.

Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, security identifiers, and file attributes like "read only", "compressed", "encrypted", etc.

This might introduce an advantage, though unnoticeable, thus this could be ignored, as it really doesn't make a difference. @WooShell's answer is more related to the performance issue, even though it still is neglectable.

Another thing to note, is that in case of having an SSD + HDD, it is way better to store your OS on the SSD and all your personal files/data on the HDD. You most likely wouldn't need the performance boost from having an SSD for most of your personal files and consumer-grade solid state drives usually do not have much space on them, so you'd rather not try to fill it up with personal files.

Described some of the reasons why it is done. And yes, it is still valid, though not a good practice anymore as it seems. The most notable downsides are that end-users will have to keep track on where applications suggest to install their files and change that location (possible during almost any software installation, especially if expert/advanced install is an option) so the bootable partition doesn't fill up, as the OS does need to update at times, and another downside is that when copying files from one partition to another, it actually needs to copy them, while if they were in the same partition, it just updates the MFT and the meta-data, does not need to write the whole files again.

I am also not saying that having multiple partitions with a small primary one is the best idea. It all depends on the purpose of the system, and although it introduce a better way to organize your files, it comes with its downsides, which on Windows systems in the current days, are more than the pros.

I'm a software developer, but also have spent time doing "regular" / back-office IT work. I typically keep the OS and applications on drive C:, and my personal files on drive D:. These don't necessarily need to be separate physical drives, but currently I am using a relatively small SSD as my "system" drive (C:) and a "traditional" disk drive (i.e. with rotating magnetic platters) as my "home" drive (D:).

I have found that fragmentation can significantly degrade system performance. For example, I've found that a full build of a large software project improved by over 50% after defragmenting my drive -- and the build in question took the better part of an hour, so this was not a trivial difference.

I should note that the development tools I use tend to generate a large number of temporary files, which seem to be a significant contributor to the fragmentation issue. So the severity of this issue will vary according to the software you use; you may not notice a difference, or as much of one. (But there are other activities -- for example video / audio composition and editing -- which are I/O intensive, and depending on the software used, may generate large numbers of temporary / intermediate files. My point being, don't write this off as something that only affects one class of users.)

Caveat: with newer versions of Windows (from 8 onward), this has become much more difficult, because user folders on a volume other than C: are no longer officially supported. I can tell you that I was unable to perform an in-place upgrade from Windows 7 to Windows 10, but YMMV (there are a number of different ways to [re]locate a user folder, I don't know which are affected).

One additional note: if you maintain two separate volumes on a traditional drive, you may want to set up a page file on the D: volume. For the reasons described in WooShell's answer, this will reduce seek time when writing to the page file.

As WooShell's answer says, the lower logical sectors on the drive (outside of platter) tend to be the fastest. My 1TB WDC Velociraptor drives start out at 215MB/s, but drops down to 125MB/s at the outer sectors, a 40% drop. And this is a 2.5" drive platter drive, so most 3.5" drives generally see an ever larger drop in performance, greater than 50%. This is the primary reason for keeping the main partition small, but it only applies where the partition is small relative to the size of the drive.

The other main reason to keep the partition small was if you were using FAT32 as the file system, which did not support partitions larger than 32GB. If you were using NTFS, partitions up to 2TB were supported prior to Windows 2000, then up to 256TB.

If your partition was too small relative to the amount of data that would be written, it is easier to get fragmented, and more difficult to defragment. Of you can just straight up run out of space like what happened to you. If you had too many files relative to the partition and cluster sizes, managing the file table could be problematic, and it could affect performance. If you are using dynamic volumes for redundancy, keeping the redundant volumes as small as necessary will save space on the other disks.

Today things are different, client storage is dominated by flash SSDs or flash accelerated magnetic drives. Storage is generally plentiful, and it is easy to add more to a workstation, whereas in the PATA days, you might have only had a single unused drive connection for additional storage devices.

So is this still a good idea, or does it have any benefit? That depends on the data you keep and how you manage it. My workstation C: is only 80GB, but the computer itself has well over 12TB of storage, spread across multiple drives. Each partition only contains a certain type of data, and the cluster size is matched to both the data type and the partition size, which keeps fragmentation near 0, and keeps the MFT from being unreasonably large.

The downsize is that there is unused space, but the performance increase more than compensates, and if I want more storage I add more drives. C: contains the operating system and frequently used applications. P: contains less commonly used applications, and is a 128GB SSD with a lower write durability rating than C:. T: is on a smaller SLC SSD, and contains user and operating system temporary files, including the browser cache. Video and audio files go on magnetic storage, as does virtual machine images, backups, and archived data, these generally have 16KB or larger cluster sizes, and read/writes are dominated by sequential access. I run defrag only once a year on partitions with high write volume, and it takes about 10 minutes to do the whole system.

3a8082e126