Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Is it bad to fill up my Windows installed Drive i.e. C:\ . If yes then Why , How much space should I fill , will adding more and more files in the C drive affect my hardware performance. How much space should I leave unfilled for better performance. What could be the consequences by filling the whole drive.

share|improve this question
Just a comment : one day, my HDD was so full that even the CSS files from websites were not loaded. So yes, you have to keep some free space :) – Baztoune Aug 31 '10 at 14:57
up vote 7 down vote accepted

Well, what instantly jumps to mind is that having a "completely full" drive may cause some of the following problems:

  • May cause problems for any program that need to generate temporary files or use the disk to cache (for example installers (even to other drives), downloading, compression, etc).
  • Your pagefile will be unable to expand if it ever needs to (assuming it is kept on C).
  • May prevent hibernation if there is insufficent space to save RAM to disk. [Edit: as Martin points out in his answer, hibernation doesn't need additional space when you hibernate, but instead uses up space when hibernation is first switched on.]
  • Will make defragmentation very slow or impossible.

Assuming that you keep the drive defragmented, a "full" drive should perform as well as an "empty" one, so I don't think there is much of a performance issues. [Edit2: Joel's answer wonderfully explains how full drives have more seeking to do in spread out or full drives, which will obviously have a negative effect on performance.]

I think that 85-90% usage is the maximum recommended, but I cannot remember where I've got that figure from at the moment.

share|improve this answer
I would say the usage figure should be less than that as the access speed for something on the "outer rim" rather than the centre of the disk can be up to two times as slow. Disk reads and writes become slower as you move out from the centre of the disk. Unfortunately I can't find the specific article stating this. – Richard Aug 31 '10 at 9:45
@Richard Are you sure? The edge performs the same number of RPM as the centre, and IIRC there's the same number of sectors per track - so it's just a head repositioning delay (which, by it's nature, is quite random based on the head's inital position), isn't it? – DMA57361 Aug 31 '10 at 10:01
@DMA57361 The outer area of the disk spins at the same number of rotations per second as an inner point, but due to angular velocity the actual speed of a point at the outside of the disk is much higher than a point on the inner area of the disk and so the data can be read much faster. I suspect they do not have a fixed number of sectors per track anymore as to my mind that would limit the amount of data on an outer track to the same an an inner track which would mean a massive amount of wasted space on a modern drive with huge data densities... – Mokubai Aug 31 '10 at 10:22
@Mokubai Matching sector counts could well be old assumption of mine, it's been quite a while since I've had to do much at that level. So, if read/write speed is potentially higher on the outer rim, what about seek time as per @Richard's comments? – DMA57361 Aug 31 '10 at 10:35
My understanding of what happens here is that you move out from the center of the disk, individual bits are staggered so you have a constant bit rate pass under the read/write head. – Joel Coehoorn Aug 31 '10 at 16:50

To understand this answer, I first need to relate a couple paragraphs worth of background information:

The hard drive is typically the slowest part and biggest performance bottleneck on your system. Having a fast hard drive is more important for many facets of system performance than memory or a fast cpu. This slowness is because it depends on actual moving parts for operation. These moving parts impact performance in three ways: rotational throughput, rotational latency, and seek time. Rotational throughput is how many bytes pass under the read/write head in a given time span, depending on how fast the platter is moving. Rotational latency is the time it takes for the first byte in a request to rotate to reach the read/write head. Seek time is the amount of time it takes for the seek head to reach the correct position on the platter.

It's that last item I want to talk about. To help reduce seek time, disk controllers will try to keep data grouped near the beginning of the drive. This is why if you watch an XP machine defragment files you will see it spend a lot of time compacting files. It's also why you want to defragment at all, as every time you have a new fragment in a file you need to do another (slow!) seek operation.

Okay, enough background. Let's move on to a real-world scenario that directly addresses your question. Let's say you buy a new drive that advertises an 8-9millisecond average seek time. 8-9 milliseconds may not seem like much, but to your computer — which thinks in nanoseconds — even one full millisecond is an eternity. Now let's say you only use 25% of that drive's capacity and keep it well defragged. What's your average seek time? The correct answer is something much less than 8-9 milliseconds, because the read/write head will never have to seek to the outer 75% of the drive. It's always starting out much closer to it's destination.

Now let's imaging you fill that drive up. You're back up to 8-9 milliseconds on average per seek. Hopefully I've helped you understand here that as you fill up the drive, your seek times will start to suffer, and this brings down performance of the entire system. You can reduce this impact by adding ram or other optimization techniques like readyboost, but you can't eliminate it entirely.

share|improve this answer

Generally speaking filling up the hard drive on Windows has worse effects than on a Linux box.

I agree with all what the previous poster said, except for the remark on hibernation (not stand-by). Since the space necessary is allocated on the disk as soon as hibernation is turned "on". It creates a hidden file C:\hiberfil.sys. Its size is almost the same as the amount of RAM you have in your computer (2GB RAM --> 2GB hiberfile.sys). Having a full disk could "prevent" switching hibernation on. If you switch hibernation off you'll free as much disk space as you have RAM.

The maximum recommended usage of 85% -> This number appears when you install Windows XP. More precisly: It tells you to keep at least 15% of your disk free.

You may perform the following two experiments to get a rough understanding of what is going on inside your computer/on your disk regarding writing/reading files and defragmentation.

Experiment 1:

  1. Open the defragmentation tool in windows
  2. Defragment the disk (probably twice), until nothing red (fragmented space) appears anymore
  3. Download a large file (e.g. an Ubuntu iso-image ~750MB).
  4. Switch to the defrag tool and just check the disk
  5. You see a lot of red marks now

The reason is that the data was written "step-by-step". It got somewhat "distributed" across the whole disk. Your browser didn't tell your computer/Windows to create a file with a size of e.g. 750MB, but created a file and appended data byte-by-byte. Windows didn't know how big this file will become in advance.

If you never defragment your disk and it's quite full, "your computer" has too look/seek for free space on your disk and suddenly MUST distribute your (in this example) newly downloaded file in a way that fills the remaining gaps of free space. This makes writing slower.

If a file is distributed across the whole disk and you want to read it (e.g. burn the above mentioned ISO file) the read/write head inside the disk must move back-and-forth very often to grab all the pieces. This makes reading slower.

Experiment 2:

  1. Mark the newly downloaded ISO and copy it to another disk. (USB stick, external hard drive, etc)
  2. Delete the original file ("Windows" drive), just keep the copy on the other media
  3. Copy the file back from the external disk or whatever onto your "Windows" harddisk
  4. Run "check" in the defrag tool again
  5. You'll see almost no red marks now.

The file was written in one sequence. This is because Windows knew the file size in advance and therefore was able to reserve all the necessary space on the disk in one go.

share|improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .