Reprint to: http://beikeit.com/post-495.html simple translation: This Linux official information mainly describes the external fragments (external fragmentation), internal fragments (internal Fragmentation) concept and the related situation, it shows that the Linux file system in the case of 5% free disk space is not required to defragment. (Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% o F free space on a disk.). In actual use, the disk is still about 8% unused when there will be a warning, so defragmentation is not considered.
Defragmentation ideas are mainly in two categories of friends, one is affected by the windows thinking of friends, there is a kind of operating system principle has a certain degree of understanding of friends.
Let me briefly explain some of the problems here.
All the operating systems produce disk fragmentation, which is why some friends have doubts. This fragment is referred to as internal fragmentation in the official information above. It is generated, assuming that a disk has a space of 20k, its basic storage unit is a cluster, with two files, a 7k, a 1k. When the cluster size is 4k, the disk is divided into 5 clusters, two files Occupy 3 clusters, that is, the use of 12k, which wasted space is 4k, that is, the creation of internal fragments 4k. So we know that internal fragmentation is primarily a waste of disk space. Note that the fragmentation of Windows defragmentation is not the fragment, nor can it operate on the fragment, which is the fragment concept of external fragmentation.
Can the internal fragments be optimized for processing? The answer is yes. In the above example, if each cluster is divided into 2k, then 20k disk is divided into 10 clusters, 7k and 1k two files occupy 5 clusters, 10k space, wasted space, that is, internal fragments of 2k.
Thus, the smaller the cluster, the less space wasted. This is also an excellent place for NTFS than FAT32. In the case of the FAT32 file system of Win 2000, the size of the cluster is 4KB when the partition size is 2GB~8GB, the size of the cluster is 8KB when the partition size is 8GB~16GB, and the cluster size is 16KB when the partition size is 16GB~32GB. While the NTFS file system of Win 2000, when the size of the partition is below 2GB, the cluster size is smaller than the corresponding FAT32 cluster, and when the partition size is above 2GB (2GB~2TB), the cluster size is 4KB. By contrast, NTFS can manage disk space more efficiently than FAT32, minimizing wasted disk space.
Some friends will think further, then why the file system is not the cluster of very small? This leads to another problem, the file access lookup problem. The above example shows that when we are looking for a file to use, we need to access it through a page table. For example, where you live is like a cluster of files, but to find you, you have to access it through your address, and access the file through a file allocation table. If you live in more people, the address is also a lot of, then to find out the address you live spend a lot of time. Similarly, the smaller the cluster, the greater the address of the record cluster, and the more time it takes to find the cluster where the files are located. When the cluster is 4k, the address of the cluster is 5, and when the cluster is 2k, the address of the cluster is 10. Thus the size of the cluster is a result of a balance in space and time.
Here are some tips for another problem, some third-party partitioning software can customize the size of the cluster, it is recommended to use the default value, otherwise there will be some problems in some cases.
Some friends will ask further questions: so why under normal circumstances NTFS sub-cluster will be smaller than FAT32, and access speed will be similar? This also involves the file access mechanism and so on. Here I will no longer introduce, in fact, this problem I can not be completely clear, interested friends may find some operating system information to read, can solve this problem to a certain extent.
OK, let's start with the point: Linux doesn't need defragmenting!
The fragment under Windows concept, known as an external fragment in the Linux official information above, is the concept of fragmentation that affects performance. (This is called "external fragmentation" or simply "fragmentation" and are a common problem with MS-DOS file systems. Linux generally does not produce this kind of fragmentation. External disk fragmentation should be referred to as file fragmentation because files are scattered across different parts of the disk, rather than being kept in contiguous clusters of disks.
When the application requires insufficient physical memory, the general operating system generates temporary swap files on the hard disk and uses the hard disk space that the file occupies for virtual memory. The Virtual memory management program frequently reads and writes to the hard disk, producing a large amount of fragmentation, which is the main cause of disk fragmentation.
Other settings, such as temporary files or temporary file directories that are generated when browsing information from IE browsers, can create a large amount of fragmentation in the system. File fragmentation generally does not cause problems in the system, but too much file fragmentation can cause the system to look back and forth while reading files, causing system performance to degrade, and to shorten hard disk life. In addition, excessive disk fragmentation can lead to the loss of storage files.
This is how Windows generates external fragmentation, which is in fact related to the data structures used by the file system. For fat, a chain-style structure is used to record the clusters used by a file. The benefit of this approach is the need to contribute to the dynamic growth of documents. But with the problem of fragmentation, so that when reading and writing files, the head is frequently moved. For CD-ROM, because it is read-only, so there is no data growth problem, so a continuous method to record data, no fragmentation, and the Linux ext file format and CD-ROM is similar to the storage.
The following article is an easy-to-read explanation of why Linux does not require defragmentation and why Windows needs defragmenting:
Please note that the official information is that the Linux file system does not need to be defragmented in the case of 5% free space on the disk. (Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% o F free space on a disk.). In actual use, the disk is still about 8% unused when there will be a warning, so defragmentation is not considered.
And the following is about 20%.
Reference: Why Linux does not require disk defragmentation ONEANDONEIS2 translation: rainking
One question about Linux is often asked: Why doesn't Linux require disk defragmentation? Here I try to give a simple, non-technical answer to "why some file systems require disk defragmentation more than other file systems."
I'm going to try to use an ASCII matrix to explain all the principles, not the dull, obscure terminology that strikes everyone's motivation. Here is the matrix I will use to explain the principle:
- a b c d e f g h i j k l m n o p q r s t u v w x y z
-
- a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- b 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- c 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- f 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- g 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- h 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- i 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- j 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- l 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- m 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- n 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- p 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- t 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- u 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The above matrix can be simply used to represent a very small hard disk, the initial state is empty, all are 0 filled. A-Z at the top and left of the matrix is used to locate each data. The top left corner of the 0 is a AA, the top right corner of the 0 is za, the bottom left corner is AZ.
I will start with a file system that everyone is very very familiar with, a system-fat that often requires disk defragmentation. In fact, both Windows users and Linux users will use the FAT file system. Because USB flash drives generally use this file system. Fat is a very, very important file system, although it often requires disk defragmentation.
I'm now adding a file to the disk, so the disk looks like this:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
-
- A T o C h e l l o. T x t a E l e 0 0 0 0 0 0 0 0 0 0
- B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E H e l l O, _ w o R L D 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
(in order to look clearer, G-z's empty line is omitted)
As you can see, the first 4 rows are the TOC (table of Contents), the so-called Table of contents. The TOC stores the location of all files on the disk. In my example above, the TOC contains a file named "Hello.txt", and the content of this file is from AE to Le. Looking down at the content between AE and Le, we can see that the content of this file is "Hello,_world"
So far, everything's okay, right? OK, then let's add a file:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
-
- A T o C h e l l o. T x t A e l e b y e. T x t m e Z
- B E 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E H l l O, _ w o r l d G o o d b y E, _ w o R l D
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
As you can see, the second file is placed immediately after the first file. The advantage is that all of your files are tightly placed together, so reading them will be very quick and convenient. To know that the slowest on disk is the movement of the read-write head, the less it moves, the faster it reads.
However, when we need to modify the first file, the problem comes out. Now suppose we need to add two exclamation points at the end of the "hello.txt" file and we'll have a problem: no space! The file "Bye.txt" blocked the "Hello.txt" way. At this time we have two solutions, but none of them is perfect.
1 we delete the file "Hello.txt" and then add the modified "Hello.txt" after "Bye.txt". 2 We split the file "Hello.txt" into two-part storage so that there will be no empty disk space before "Bye.txt".
The first way to show it is this:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
-
- A T o C h e l l o. T x t a f n f b y e. T x t m e Z
- B E 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E 0 0 0 0 0 0 0 0 0 0 0 0 G o o d b y E, _ w o R l D
- F H e l l O, _ w o r l d!! 0 0 0 0 0 0 0 0 0 0 0 0
The second way to show it is this:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
-
- A T o C h e l l o. T x t A E l e a f b F b y e. T X
- b t m e z e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E H l l O, _ w o r l d G o o d b y E, _ w o R l D
- F!! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
This is why fat-formatted file systems often require disk defragmentation. All files are stored next to each other, so whenever a file needs to be enlarged, it will produce fragmentation. When any file is deleted, a blank area is left. So soon the disk will become a mess of random and Blank, the efficiency will become lower.
Linux is dealing with this problem in a different way. Windows's file system is good enough for a single user, but Linux is inherently a system designed for multiuser users, and it always assumes that at the same time multiple users are trying to manipulate different files. So the Linux relative FAT file system uses another method to design its own file system. The Linux file system looks like this:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
- A T o C h e l l o. T x t h N s n 0 0 0 0 0 0 0 0 0 0
- B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- J 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- K 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- L 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- N 0 0 0 0 0 0 0 H e l l O, _ w o R L D 0 0 0 0 0 0 0
- O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- R 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- S 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- U 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- V 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- W 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
When we add a file, it becomes like this
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
- A T o C h e l l o. T x t h n s n b y e. T x t d u q
- b U 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- J 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- K 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- L 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- N 0 0 0 0 0 0 0 H e l l O, _ w o R L D 0 0 0 0 0 0 0
- O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- R 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- S 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- U 0 0 0 G o o d b y E, _ w o R L D 0 0 0 0 0 0 0 0 0
- V 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- W 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The benefit of this file system is that the disk's head can always be in the middle, and all the files will be very close on average.
When we still add two exclamation points to "hello.txt", let's see how much trouble this can cause:
- A b c d e F g h i j k l m n o p q R S t u v w x y Z
- A T o C h e l l o. T x t h n u n b y E. T x t d u q
- b U 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- D 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 T O C
- E 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- J 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- K 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- L 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- N 0 0 0 0 0 0 0 H e l l O, _ w o r l d!! 0 0 0) 0 0
- O 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- R 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- S 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- U 0 0 0 G o o d b y E, _ w o R L D 0 0 0 0 0 0 0 0 0
- V 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- W 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- X 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
That's right! No trouble at all!
Windows always tries to store files as close to the start of the disk as possible, which often results in disk fragmentation when disk utilization becomes high.
Linux stores files on the entire disk, so there is always enough space when the size of the file needs to be changed.
Of course, when disk utilization is near saturation, Linux also needs to be collated. But as long as the disk has more than 20% of the free space, then this sort of finishing is basically not happening.
It is also important to understand that even when an operating system says that a disk has been completely defragmented, the fragmentation will still exist depending on the physical structure of a disk. Because disks are always made up of many platters and tracks.
Let's take a look at a disk with two platters, AA to ZM is the first, an to ZZ is the second one.
- a b c d e F g h i j k l m n o p q R S t u v w x y z
-
- a 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Li>e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- J 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- L 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- a b c d e F g h i j k l m n o p q R S t u v w x y z
-
- N 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Li>r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- u 0 0 0 0 0 0 0 0 0 0 0 0 0 0-0 0 0 0 0 0 0 0 0 0 0 0
- v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The file system is fragmented because the file spans rows m and N. And these two lines are not on a platter. To read this file, the disk's head must span from the very end of the disc 1 to the very beginning of Disc 2.
- a b c d e F g h i j k l m n o p q R S t u v w x y z
-
- a t o C h e l l o. T x t R m e n 0 0 0 0 0 0 0 0 0 0
- B 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- C 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- d 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Li>e 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- F 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- G 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- H 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- I 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- J 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- k 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- L 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- M 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 H e l l O, _ w o
- a b c d e F g h i j k l m n o p q R S t u v w x y z
-
- n R L d!! 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- o 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- P 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- q 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Li>r 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- s 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- T 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- u 0 0 0 0 0 0 0 0 0 0 0 0 0 0-0 0 0 0 0 0 0 0 0 0 0 0
- v 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- w 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- x 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- y 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
- Z 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Finally, I hope that the above explanation can let you understand why Linux does not need disk defragmentation, if you still do not understand, please make your doubts in spite of the place.
For a friend who is defragmenting windows, here's a little bit of a friendly tip.
1. When defragmenting the disk, to close all other applications, including screen savers, it is a good idea to set the virtual memory size to a fixed value. Do not read and write to the disk.
2, defragment the frequency of disk fragmentation to control the appropriate, too frequent collation will shorten the life of the disk. Generally read-write disk partitions are collated once a week.
Finally, I want to talk about the topic of thinking.
Have you considered two facts about friends who want to defragment their disks under Linux?
First, why Unix-like systems have been generated for decades, and no one does a defrag software? And even now, no friend in this forum mentioned the encounter with Linux virus, we can still find a lot of Unix-like antivirus software? I will be able to list at least 3 kinds of free antivirus software.
Second, many Unix-like operating systems are not shut down for years, such as banking, telecommunications, military, and so on, can you imagine them to stop the disk read and write, in a few hours to defragment the result of disk defragmentation? These machines have more disk reads and writes than home computers. The Linux ext2, ext3, and Ext4 file system--ubuntu and most of the latest Linux distributions used ext4--to use a smarter way to store files. Unlike putting multiple files on disk, the Linux file system disperses all the files across the disk, leaving a considerable amount of free space between each of the two files. When files are modified and the volume increases, they usually have enough space to expand. Once a fragment is generated, the file system will attempt to move the entire file to eliminate fragmentation, so you do not need a defragmentation tool.
Trivia-Why Linux does not require disk defragmentation