Does freeing up disk space speed up your computer?

This is a translation of the answer to the question about the effect of free disk space on performance from the site superuser.com.

From the author:I think I accidentally wrote a whole book. Pour yourself a cup of coffee before reading.

Does freeing up disk space speed up your computer? Freeing up disk space does not speed up a computer, at least not by itself. This is a really common myth. This myth is so common because filling your hard drive often happens at the same time as other processes that can traditionally slow down your computer. The performance of an SSD may decrease as it is filled, but this is a relatively new problem inherent in an SSD, and, in fact, invisible to ordinary users. In general, the lack of free space is just a red rag for the bull.

The author’s note: “Slowdown” is a term with a very broad interpretation. I use it here in relation to I/O processes (i.e., if your computer is purely computational, the contents of the disk have no influence) or processor-related and competing processes that consume a lot of CPU resources (i.e. antivirus scanning a lot of files).
For example, phenomena such as:

• File fragmentation. File fragmentation is a problem, but lack of space, while one of many factors, is not the only cause of fragmentation. Highlights:
  ** Fragmentation affects SSDs because sequential reading operations are usually much faster than random access, although SSDs do not have the same limitations as mechanical devices (even so, the absence of fragmentation does not guarantee consistent access due to wear distribution and similar processes). However, in almost any typical use case, this is not a problem. Differences in SSD performance associated with fragmentation are usually not noticeable for the processes of launching applications, booting a computer, and others.
  • The probability of file fragmentation is not related to the amount of free disk space. It depends on the size of the largest continuous block of free space on the disk (i.e. “gaps” of free space), which is limited from above by the volume of free space. Another dependency is the method used by the file system when placing files (more on this later).
    For example: If the disk occupies 95% of the space and everything that is freely represented by one continuous block, then the new file will be fragmented with a probability of 0% (unless, of course, a normal file system fragments the files specifically – approx. author) (also the probability of fragmentation of the expandable file does not depend on the amount of free space). On the other hand, a disk filled with 5% of data evenly distributed over it has a very high probability of fragmentation.
  • Note that file fragmentation affects performance only when these files are accessed. For example: You have a good, defragmented disk with a lot of free “gaps” on it. Typical situation. It's working well. However, at some point you come to a situation where there are no more large free blocks left. You download a big movie, and the file is very fragmented. It won't slow down your computer. Your application files and others that were perfectly fine will not become instantly fragmented. A movie can certainly take longer to load (however, typical movie bitrates are so much lower than hard drive reading speeds that it’s likely to go unnoticed), and it can affect I/O performance while the movie is loading, but nothing else will change.
  • Although fragmentation is a problem, often the problem is offset by caching and buffering by the operating system and hardware. Postponed writing, pre-emptive reading, etc. help solve the problems caused by fragmentation. In general, you don’t notice anything until the fragmentation level is too high (I even venture to say that as long as your paging file isn’t fragmented, you won’t notice anything).
• Another example is Search Engine Indexing. Let’s say you have automatic indexing enabled and the operating system doesn’t implement it very well. As you save more and more indexable files to your computer (documents, etc.), indexing takes more and more time and can begin to have a noticeable effect on the observed performance of the computer in the course of its work, eating both I/O and CPU time. This is not related to free space, but is related to the amount of data being indexed. However, the exhaustion of disk space occurs at the same time as saving more content, so many establish the wrong relationship.
• Antiviruses. This is very similar to the search index example. Say you have an antivirus that performs background scans of your drive. You have more and more files to scan, and the search starts consuming more and more I/O and processor resources, possibly interfering with your work. Again, the problem is the amount of content being scanned. More content means less space, but the lack of free space is the cause of the problem.
• Established programmes. Let’s say you have a lot of programs running when your computer boots up, which increases boot time. This slowdown happens because a lot of programs are loaded. At the same time, installed programs take up space on the disk. Therefore, the volume of free space decreases simultaneously with the slowdown, which can lead to incorrect conclusions.
• There are many other similar examples that give the illusion of linking the exhaustion of disk space and reduced performance.

The above illustrates another reason for the prevalence of this myth: although the exhaustion of free space is not directly the cause of the slowdown, the uninstallation of various applications, the removal of indexed and scanned content, etc. sometimes (but not always, such cases are outside the scope of this text) leads to increased productivity for reasons not related to the amount of free space. The disk space is released naturally. There is a false connection between “more free space” and “fast computer.”

Look.: If your computer is slow because of the large number of programs installed, etc., and you clone exactly your hard drive to a larger hard drive, and then expand the partitions to get more free space, the computer will not get faster by hand. The same programs are downloaded, the same files are fragmented in the same way, the same indexing service works, nothing changes despite the increase in free space.

Does this have anything to do with finding a place to place files?
No, it's not. There are two important points here:

1. Your hard drive is not looking for a place to place files.. The hard drive is stupid. He's nothing. This is a large block of addressable storage that blindly obeys the operating system in terms of placement. Modern drives are equipped with sophisticated caching and buffering mechanisms designed to predict operating system queries based on human experience (some drives even know about file systems). But essentially, the drive should be thought of as a big stupid data-storing brick, sometimes with performance-enhancing features.
2. Your operating system is also not looking for a location. There's no "search.". A great deal of effort has been made to address this issue, as it is critical to file system performance. Data resides on your drive as defined by the file system, such as FAT32 (old DOS and Windows computers), NTFS (new Windows systems), HFS+ (Mac), ext4 (some Linux systems), and many others. Even the concept of “file” or “directories” is just the fruit of a typical file system: hard drives don’t know about beasts like “files.” The details are beyond this text. Essentially, however, all common file systems contain a way to track free space on the disk, so it is not necessary to search for free space under normal circumstances (i.e., in the normal state of the file system). Examples:
   
   
   • NTFS contains a master file table that includes special files (for example, $Bitmap) and a lot of metadata that describes the disk. Essentially, it tracks subsequent free blocks so that files can be written to the drive without having to scan the drive each time.
   • Another example, ext4 has an entity called “bitmap allocator,” an improvement over ext2 and ext3 that helps directly determine the position of free blocks, instead of scanning the list of free blocks. Ext4 also supports “delayed distribution,” essentially buffering data by the operating system into RAM before writing to disk, in order to make the best placement decision to reduce fragmentation.
   • Lots of other examples.

Maybe it's about moving files back and forth to allocate long enough uninterrupted space while saving?
No, that's not happening. At least not in any file system I know. The files are just fragmented.

The process of moving files back and forth to allocate a long continuous block is called defragmentation. This does not happen when writing files. This happens when you run a disk defragmentation program. at least in newer Windows systems, this happens automatically on a schedule, but writing a file is never a reason to start this process.

The ability to avoid having to move files this way is key to file system performance, and the reason why fragmentation occurs and defragmentation is a standalone step.

How much free space should be left on the disk?
This is a more difficult question, and I have already written so much.

The basic rules that can be followed:

• For all disc types:
  
  • The most important thing is to leave enough space to use your computer effectively. If you run out of space, you may need a larger disk.
  • Many disk defragmentation utilities require a minimum of free space (it seems that it comes with Windows in the worst case requires 15% free space) for their work. They use this space to temporarily store fragmented files while other objects are moved.
  • Leave room for other operating system functions. For example, if your computer does not have a large amount of physical RAM, and virtual memory is enabled with a dynamic volume paging file, you should leave enough free space to accommodate the maximum size paging file. If you have a laptop that you send to hibernation, you will need enough free space to save the hibernation state file. These are things.
• Regarding the SSD:
  
  • For optimal reliability (and to a lesser extent performance), there should be some free space on the SSD, which, without going into detail, is used to evenly distribute data across the disk to avoid constant writing to the same place (which leads to resource depletion). The concept of reserved space is called over-provisioning. This is important, but many SSDs already have mandatory backup space. That is, disks often have several tens of gigabytes more space than they show the operating system. Cheaper drives often require you to leave part of the space unmarked. But when working with disks that have forced redundancy, this is not required. It is important to note that Additional space is often taken only from unmarked areas.. Therefore, it will not always work when your partition occupies the entire disk, and you leave some free space on it. Manual relay requires you to make your partition smaller than the disk size. Check the user manual of your SSD. TRIM and garbage collection and things like that also have an impact, but they are beyond the scope of this text.

Personally, I usually buy a new, larger disc when I have about 20 to 25 percent free space. It’s not about performance, it’s just that when I get to that point – it means the place is going to run out soon, which means it’s time to buy a new disc.

More important than spot tracking is to make sure that the planned defragmentation is on where it should be (not on an SSD), so you never get to the point where it is large enough to have a noticeable impact.

Afterword
There is one more thing to mention. One of the other answers to this question mentions that the half-duplex SATA mode makes it impossible to read and write at the same time. While this is true, it’s a strong oversimplification and it’s largely unrelated to the performance issues discussed here. In reality, this simply means that data cannot be transmitted over a wire in two directions at the same time. However, the SATA specification includes tiny maximum block sizes (I think about 8kB per block when transmitted over the wire), queues of read and write operations, and so on, and nothing prevents writing data into a buffer while reading and similar overlapping operations are carried out.

Any blockage that may occur will involve competition for physical resources, which is usually offset by large cache volumes. The duplex SATA mode has almost nothing to do with this case.

Source: habrahabr.ru/post/256231/