Does 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 - approx. translator
From the author: Looks like I accidentally wrote a whole book. Pour yourself a cup of coffee before reading.
')
Freeing up disk space does not speed up the computer, at least not by itself. This is a really common myth. This myth is so common because filling up your hard drive often happens concurrently with other processes that traditionally can slow down your computer. SSD performance may decline as it is filled , but this is a relatively new problem inherent in SSD, and, in fact, hardly noticeable to ordinary users. In general, the lack of free space is just a red rag for the bull ( distracts attention - comment of the translator ).
For example, such phenomena as:
What was written above illustrates another reason for the prevalence of this myth: although the exhaustion of free space is not directly a cause of slowing down, uninstalling various applications, deleting indexed and scanned content, etc. sometimes (but not always, such cases are outside the scope of this text) leads to an increase in productivity for reasons not related to the amount of free space. At the same time, disk space is naturally released. Consequently, a false connection between “more free space” and “fast computer” also appears here.
See : if your computer is slow because of the large number of installed programs, etc., and you clone your hard disk exactly onto a larger hard disk, then expand the partitions to get more free space, the computer does not will be on the wave of hands faster. The same programs are loaded, the same files are fragmented in the same way, the same indexing service works, nothing changes, despite the increase in free space.
No, not connected. There are two important points here:
No, this is not happening. At least in any of the file systems I know. Files are simply fragmented.
The process of “moving files back and forth to isolate a long continuous block” is called defragmentation . This does not happen when writing files. This happens when you run the disk defragmenter. at least on new Windows systems, this happens automatically on a schedule, but writing a file is never a reason to start this process.
Avoiding the need to move files in this way is key to the performance of file systems, and the reason why fragmentation occurs, and defragmentation is a separate step.
This is a more complicated question, and I have already written so much.
Basic rules to follow:
Personally, I usually buy a new larger disk, when I have about 20-25% of free space. This is not related to performance, it's just when I get to this point - this means that the place will end soon, which means it's time to buy a new disk.
More important than tracking the free space is to check that the planned defragmentation is enabled where it is necessary (not on the SSD), so that you will never come to a moment when it is large enough to have a noticeable impact.
There is one more thing to be mentioned. One of the other answers to this question mentions that half-duplex SATA mode does not allow reading and writing at the same time. While this is true, it is a strong oversimplification and for the most part is not related to the performance issues discussed here. In fact, this simply means that data cannot be transmitted across the wire simultaneously in two directions. However, the SATA specification includes tiny maximum block sizes (I think about 8kB per block during transmission over the wire), queues of read and write operations, etc., and nothing prevents you from writing data to the buffer while reading and similar intersecting operations are being performed.
Any blocking that may occur will be associated with competition for physical resources, which is usually compensated for by large amounts of cache. Duplex SATA has almost nothing to do with this case.
From the author: Looks like I accidentally wrote a whole book. Pour yourself a cup of coffee before reading.
')
Does disk space speed up your computer?
Freeing up disk space does not speed up the computer, at least not by itself. This is a really common myth. This myth is so common because filling up your hard drive often happens concurrently with other processes that traditionally can slow down your computer. SSD performance may decline as it is filled , but this is a relatively new problem inherent in SSD, and, in fact, hardly noticeable to ordinary users. In general, the lack of free space is just a red rag for the bull ( distracts attention - comment of the translator ).
Note author: * "Slowdown" - a term with a very broad interpretation. Here I use it for I / O related processes (i.e., if your computer is purely computing, the contents of the disk have no effect), or related to the processor and competing with processes that consume a lot of processor resources (i.e., antivirus scanning a large number of files)
For example, such phenomena as:
- File Fragmentation File fragmentation is a problem **, but the lack of free space, although one of many factors, is not the only cause of fragmentation. Highlights:
Note Authors: ** Fragmentation affects SSDs due to the fact that sequential read operations are usually much faster than random access, although the SSD does not have the same limitations as for mechanical devices (even in this case, the absence of fragmentation does not guarantee sequential access due to the distribution wear and tear and similar processes). However, in almost any typical use case, this is not a problem. Differences in SSD performance due to fragmentation are usually not noticeable for application launch processes, computer boot, 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 contiguous block of free space on the disk (that is, the “gaps” of free space), which is bounded above by the amount of free space. Another dependency is the method used by the file system when placing files (more on that later).
For example: If the disk is occupied 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, the normal file system fragment the files specifically - author's note ) (also the probability of fragmentation 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. - Please note that file fragmentation affects performance only when you access these files . For example: You have a good, defragmented disk with a lot of free “gaps” on it. Typical situation. Everything works well. However, at some point you come to a situation when there are no more large free blocks left. You download a big movie, and this file is highly fragmented. It will not slow down your computer . Files of your applications and others that were in perfect order will not become instantly fragmented. The movie can of course take longer to load (however, the typical movie bit rates are so much lower than the speed of reading hard drives that it will probably go unnoticed), it can also affect the I / O performance while the movie is loading, but nothing changes.
- Although fragmentation is a problem, often the problem is offset by caching and buffering from the operating system and hardware. Delayed write, read ahead, and so on, help solve problems caused by fragmentation. In general, you do not notice anything until the level of fragmentation becomes too high (I would even venture to say that as long as your page file is not fragmented, you will not notice anything)
- The probability of file fragmentation is not related to the amount of free disk space. It depends on the size of the largest contiguous block of free space on the disk (that is, the “gaps” of free space), which is bounded above by the amount of free space. Another dependency is the method used by the file system when placing files (more on that later).
- Another example is Search Engine Indexing. Suppose that you have enabled automatic indexing, and the operating system does not implement it very well. As you save more and more indexed files to your computer (documents and the like), the indexing starts to take more and more time and can begin to have a noticeable effect on the observed computer performance in the course of its work, eating at the same time I / O and processor 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 simultaneously with the preservation of a larger amount of content, so many people establish an incorrect relationship.
- Antivirus. Everything is very similar to the search index example. Let's say you have an antivirus that performs a background scan of your disk. You have more and more files to scan, the search begins to consume more and more I / O and processor resources, possibly interfering with the work. Again, the problem is with the amount of content being scanned. More content - less free space, but the lack of free space is the cause of the problem.
- Installed programs. Suppose you have installed many programs that run when the computer boots, which increases the boot time. This slowdown occurs because many programs are loaded. At the same time, installed programs take up disk space. Consequently, the amount of free space decreases simultaneously with deceleration, which can lead to wrong conclusions.
- Many other similar examples can be cited that give the illusion of a link between the exhaustion of disk space and a decrease in performance.
What was written above illustrates another reason for the prevalence of this myth: although the exhaustion of free space is not directly a cause of slowing down, uninstalling various applications, deleting indexed and scanned content, etc. sometimes (but not always, such cases are outside the scope of this text) leads to an increase in productivity for reasons not related to the amount of free space. At the same time, disk space is naturally released. Consequently, a false connection between “more free space” and “fast computer” also appears here.
See : if your computer is slow because of the large number of installed programs, etc., and you clone your hard disk exactly onto a larger hard disk, then expand the partitions to get more free space, the computer does not will be on the wave of hands faster. The same programs are loaded, the same files are fragmented in the same way, the same indexing service works, nothing changes, despite the increase in free space.
Is this somehow related to finding a place to put files?
No, not connected. There are two important points here:
- Your hard drive is not looking for a place to put files . The hard drive is stupid. He is nothing. This is a large block of addressable storage that blindly obeys the operating system in terms of placement. Modern disks are equipped with sophisticated caching and buffering mechanisms designed to predict operating system requests based on people's experience (some disks even know about file systems). But, in fact, the disk should be thought of as a big silly brick storing data, sometimes with performance enhancing features.
- Your operating system is also not looking for a place to put it. There is no "search . " Great efforts have been made to solve this problem, because it is critical to file system performance. The data is located on your disk as determined by the file system , for example, FAT32 (old computers with DOS and Windows), NTFS (new Windows systems), HFS + (Mac), ext4 (some Linux systems) and many others. Even the concept of a “file” or “directory” ( “folders” - translator's note ) is just the fruit of a typical file system: hard drives are not aware of such animals as “files”. Details are outside of this text. However, in fact, all common file systems contain a way to track free disk space and therefore, “searching” for free space, under normal circumstances (i.e., in the normal state of the file system), is not necessary. Examples:
- NTFS contains the master file table which includes special files (for example, $ Bitmap) and a lot of metadata describing the disk. In fact, it tracks subsequent free blocks, so that files can be written to disk without having to scan the disk each time.
- Another example, ext4 has an entity called a “bitmap allocator,” an improvement over ext2 and ext3, which helps directly determine the position of free blocks, instead of scanning the list of free blocks. Ext4 also supports “deferred allocation”, which is essentially the data buffering of the operating system into RAM before writing to disk, in order to make the best placement decision to reduce fragmentation.
- Many other examples.
Maybe it's about moving files back and forth to allocate a sufficiently long uninterrupted place while saving?
No, this is not happening. At least in any of the file systems I know. Files are simply fragmented.
The process of “moving files back and forth to isolate a long continuous block” is called defragmentation . This does not happen when writing files. This happens when you run the disk defragmenter. at least on new Windows systems, this happens automatically on a schedule, but writing a file is never a reason to start this process.
Avoiding the need to move files in this way is key to the performance of file systems, and the reason why fragmentation occurs, and defragmentation is a separate step.
How much free space should be left on the disk?
This is a more complicated question, and I have already written so much.
Basic rules to follow:
- For all types of disks:
- The most important thing is to leave enough space to use the computer effectively . If space runs out, you may need a larger disk.
- Many disk defragmentation utilities require a certain minimum of free space (it seems that delivered with Windows in the worst case requires 15% free space) for their work. They use this space to temporarily store fragmented files while moving other objects.
- Leave room for other operating system features. For example, if your computer does not have a large amount of physical RAM, and virtual memory is included 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 need enough free space to save the hibernation state file. Such are the things.
- Concerning SSD:
- For optimal reliability (and to a lesser degree of 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 permanent writing to the same place (which leads to resource depletion) . The concept of reserving free space is called over-provisionning . This is important, but in many SSDs, mandatory backup space is already allocated . That is, disks often have several tens of gigabytes more space than they demonstrate to the operating system. Cheaper drives often require you to leave some space unallocated. But when working with disks that have a forced backup, this is not required . It is important to note that additional space is often taken only from unallocated areas . Therefore, it will not always work option when your partition takes up the entire disk, and you leave some free space on it. Manual reinsertion requires that you make your partition smaller than the size of the disk. Check your SSD user manual. TRIM and garbage collection and similar things also have an impact, but they are beyond the scope of this text.
Personally, I usually buy a new larger disk, when I have about 20-25% of free space. This is not related to performance, it's just when I get to this point - this means that the place will end soon, which means it's time to buy a new disk.
More important than tracking the free space is to check that the planned defragmentation is enabled where it is necessary (not on the SSD), so that you will never come to a moment when it is large enough to have a noticeable impact.
Afterword
There is one more thing to be mentioned. One of the other answers to this question mentions that half-duplex SATA mode does not allow reading and writing at the same time. While this is true, it is a strong oversimplification and for the most part is not related to the performance issues discussed here. In fact, this simply means that data cannot be transmitted across the wire simultaneously in two directions. However, the SATA specification includes tiny maximum block sizes (I think about 8kB per block during transmission over the wire), queues of read and write operations, etc., and nothing prevents you from writing data to the buffer while reading and similar intersecting operations are being performed.
Any blocking that may occur will be associated with competition for physical resources, which is usually compensated for by large amounts of cache. Duplex SATA has almost nothing to do with this case.
Source: https://habr.com/ru/post/256231/
All Articles