小知识-为什么Linux不需要磁盘碎片整理

 

转载至：http://beikeit.com/post-495.html

简单译文:

这段linux官方资料主要介绍了外部碎片（external fragmentation）、内部碎片（internal fragmentation）的概念及相关情况，说明了linux文件系统在磁盘还有5%空闲空间的情况下是不需要碎片整理的。（Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% of free space on a disk.）。而在实际使用中，磁盘在还有8%左右未使用时就会有警告产生，所以碎片整理是不用考虑的。

产生碎片整理想法的主要在两类朋友中，一类是受windows思想影响的朋友，还有一类是对操作系统原理有一定程度了解的朋友。

我在这里先简单地说明一些问题。

所有地操作系统都会产生磁盘碎片，这正是某些朋友产生疑虑的原因。这个碎片在上面地官方资料中称为内部碎片。它是这样产生的，假设一个磁盘的空间有20k，它的基本存储单位为簇，设有两个文件，一个7k，一个1k。当簇的大小为4k时，磁盘分为了5个簇，两个文件共占用３个簇，即使用了12k，其中浪费地空间就是4k，也就是产生了内部碎片4k。因此我们就了解了：内部碎片主要是造成磁盘空间的浪费。请注意：windows的磁盘碎片整理功能所整理的碎片不是这个碎片，也无法对这个碎片进行操作，它所对应的碎片概念是外部碎片。

那么，可以对内部碎片进行优化处理吗？答案是肯定的。以上面的例子来说，如果把每一簇分成2k，那么20k的磁盘就分为了１０个簇，７k和１k两个文件共占用了５个簇，１０k的空间，浪费的空间，即内部碎片为２k。

由此可见，簇分的越小，所浪费的空间越少。这也是NTFS比FAT32优秀的一个地方。在Win 2000的FAT32文件系统的情况下,分区大小在2GB～8GB时簇的大小为4KB；分区大小在8GB～16GB时簇的大小为8KB；分区大小在 16GB～32GB时,簇的大小则达到了16KB。而Win 2000的NTFS文件系统，当分区的大小在2GB以下时,簇的大小都比相应的FAT32簇小;当分区的大小在2GB以上时(2GB～2TB),簇的大小 都为4KB。相比之下，NTFS可以比FAT32更有效地管理磁盘空间，最大限度地避免了磁盘空间的浪费。

有的朋友会进一步的思考，那么为什么文件系统不是把簇分的非常的小呢？这里就引出了另一个问题，文件访问查找的问题。还是以上面的例子说明，当我们要查找使用一个文件时，就需要通过页表来进行访问。打个比方，你住的地方就好比是文件所占用的簇，但是要找到你，就得通过你的住址来进行访问，而访问文件则是通过文件分配表。如果住的人多，地址也就很多，那么要查到你住的地址所花的时间也就很多。同样的道理，当簇分的越小，记录簇的地址也就越大，查找文件所在的簇所花的时间也就越多。当簇为4k时，簇的地址是５个，而簇为2k时，簇的地址是10个。因而簇的大小是在空间和时间上取得平衡的一个结果。

这里也对另一个问题作一些提示，有些第三方分区软件可以自定义簇的大小，建议采用默认值，否则会在某些情况下产生一些问题。

有的朋友会进一步提问：那么为什么在普通情况下NTFS分的簇会比FAT32的要小，而访问速度会差不多呢？这又牵涉到文件访问机制等等问题。这里我就不再介绍了，其实这个问题我也不能完全说清，有兴趣的朋友可以找一些操作系统方面的资料进行阅读，可以在一定程度上解决这个问题。

好，下面开始我们的重点：linux不需要碎片整理！

windows概念下的碎片，在上面linux官方资料中称为外部碎片，它就是影响性能的那个碎片概念。（This is called "external fragmentation" or simply "fragmentation" and is a common problem with MS-DOS file systems. ）而linux一般不会产生这种碎片。外部磁盘碎片应该称为文件碎片，是因为文件被分散保存到整个磁盘的不同地方，而不是连续地保存在磁盘连续的簇中形成的。

当应用程序所需的物理内存不足时，一般操作系统会在硬盘中产生临时交换文件，用该文件所占用的硬盘空间虚拟成内存。虚拟内存管理程序会对硬盘频繁读写，产生大量的碎片，这是产生硬盘碎片的主要原因。

其他如IE浏览器浏览信息时生成的临时文件或临时文件目录的设置也会造成系统中形成大量的碎片。文件碎片一般不会在系统中引起问题，但文件碎片 过多会使系统在读文件的时候来回寻找，引起系统性能下降，严重的还要缩短硬盘寿命。另外，过多的磁盘碎片还有可能导致存储文件的丢失。

上面所说的就是windows如何产生外部碎片的，其实这与文件系统所使用的数据结构有关。对于FAT来说，使用的是chain式的结构来记录一个文件所使用的簇。这种方式的好处就是有助于文件的动态增长的需要。但是却带了碎片的问题，使得读写文件的时候，磁头频繁移动。对于CD-ROM,由于是 read-only的，所以不存在数据增长的问题，所以，采用了连续的方法来记录数据，也不会产生碎片，而linux的ext等文件格式与CD-ROM的存储有相似之处。

下面这篇文章通俗易懂地解说了为什么linux不需要碎片整理以及windows为什么需要碎片整理：

请注意，官方资料所说的是linux文件系统在磁盘还有5%空闲空间的情况下是不需要碎片整理的。（Linux native file systems do not need defragmentation under normal use and this includes any condition with at least 5% of free space on a disk.）。而在实际使用中，磁盘在还有8%左右未使用时就会有警告产生，所以碎片整理是不用考虑的。

而下文中说的是20%。

引用:

为什么Linux不需要磁盘碎片整理

作者：OneAndOneIs2

翻译：rainking

有一个关于Linux的问题经常被问及：为什么Linux不需要磁盘碎片整理呢？在这里，我试图就“为什么有的文件系统比另一些文件系统更加需要磁盘碎片整理”给出一个简单的，非技术性的答案。

我将试图用一个ASCII矩阵来解释所有的原理，而不是用那些枯燥而晦涩的术语来打击大家的积极性。下面就是我将用来解释原理的矩阵：

1. 
   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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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 
16. 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 
17. 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 
18. 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 
19. 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 
20. 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 
21. 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 
22. 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 
23. 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 
24. 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 
25. 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 
26. 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 
27. 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 
28. 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

以上这个矩阵就可以简单的用来表示一个很小的硬盘，初始状态是空的，全部都被0填充。在矩阵顶部和左侧的a-z都是用来定位每一个数据的。最左上角的那个0就是aa，最右上角的那个0就是za，最左下角的就是az。

我将以一个大家都非常非常熟悉的文件系统开始，一个经常需要磁盘碎片整理的系统—FAT。其实无论Windows用户还是Linux用户都会用到FAT文件系统。因为USB闪盘一般都使用这个文件系统。FAT是一个非常非常重要的文件系统，虽然它经常需要磁盘碎片整理。

我现在在磁盘上加入一个文件，于是磁盘看起来会变成这个样子：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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-z的空行被省略了）

正如你所看到的，前4行是TOC（Table Of Contents），即所谓的内容表。TOC会存储磁盘上所有文件的位置。在我上面的例子中，TOC包含了一个名字叫做“hello.txt”的文件，并且这个文件的内容是从ae到le的。往下看ae到le之间的内容，我们能看到这个文件的内容是“Hello，_world”

到目前为止，一切都正常对吗？好，那我们再来添加一个文件：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. e H e l l o , _ w o r l d G o o d b y e , _ w o r l d 
8. 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

正如你所见，第二个文件被紧接着放置在第一个文件之后。这样的好处是你所有的文件都会紧密地放置在一起，这样读取它们将会非常的迅速和方便。要知道磁盘上最慢的就是读写头的移动了，它移动的越少，则读取的速度越快。

但是，当我们需要修改第一个文件的时候，问题就出来了。现在假设我们需要在“hello.txt”文件的尾部加入两个感叹号，我们就会遇到问题：没有空间！文件“bye.txt”挡住了“hello.txt”的去路。这时候我们有两个解决方法，但是没有一个是完美的。

1 我们把文件“hello.txt”删掉，然后再“bye.txt”后面加入修改过后的“hello.txt”。

2 我们把文件“hello.txt”拆成两部分存储，这样在“bye.txt”之前就不会有空的磁盘空间了。

第一种种方式表现出来就是这样：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. f H e l l o , _ w o r l d ! ! 0 0 0 0 0 0 0 0 0 0 0 0

第二种种方式表现出来就是这样：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. e H e l l o , _ w o r l d G o o d b y e , _ w o r l d 
8. 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

这就是为什么FAT格式的文件系统经常需要磁盘碎片整理的原因。所有的文件都紧挨着存放，所以任何时候，只要一个文件需要增大，就会产生碎片。而任何文件被删除了，就会留下一个空白区域。于是很快磁盘就会变成一堆乱糟糟的随便和空白，效率就会变低了。

而Linux 却用一种不同的方式来处理这种问题。对于单用户来说Windows的文件系统已经够好的了，但是Linux生来就是为多用户设计的系统，它总是假设在同一时间有多个用户试图去操作不同的文件。所以Linux相对FAT文件系统，使用了另一种方法来设计自己的文件系统。Linux文件系统看起来是这样的：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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 
16. 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 
17. 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 
18. 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 
19. 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 
20. 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 
21. 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 
22. 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 
23. 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 
24. 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 
25. 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 
26. 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 
27. 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 
28. 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

当我们添加了文件以后就变成这样了：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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 
16. 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 
17. 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 
18. 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 
19. 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 
20. 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 
21. 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 
22. 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 
23. 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 
24. 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 
25. 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 
26. 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 
27. 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 
28. 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 

这种文件系统的好处是磁盘的磁头可以一直位于中间位置，而所有的文件平均下来都会非常近。

当我们仍然给“hello.txt”加入两个感叹号时，我们来看看这会引起多大的麻烦：

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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 
16. n 0 0 0 0 0 0 0 H e l l o , _ w o r l d ! ! 0 0 0 0 0 
17. 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 
18. 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 
19. 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 
20. 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 
21. 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 
22. 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 
23. 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 
24. 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 
25. 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 
26. 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 
27. 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 
28. 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

对了！一点麻烦都没有！

Windows总是试图把文件存储在尽量靠近磁盘开始位置的地方，这导致当磁盘利用率变高的时候它经常会产生磁盘碎片。

Linux却在整个磁盘上存储文件，所以当文件的大小需要改变的时候，总是有足够的空间。

当然当磁盘利用率接近饱和的时候Linux也会需要文件整理。但是只要磁盘还有20%以上的可用空间，那么这种整理是基本不会发生的。

还有一点必须了解的是，即使当一个操作系统说某个磁盘已经完全碎片整理完毕了，但是根据一个磁盘的物理结构，碎片仍然会存在。因为磁盘总是由很多盘片和磁道组成的。

让我们来看看一个磁盘有两个盘片，aa到zm是第一个，an到zz是第二个。

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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

一下的文件系统是有碎片的，因为文件横跨了行m和n。而这两行不是在一个盘片上的。要读取这个文件，磁盘的磁头必须从盘片1的最末尾跨越到盘片2的最开始。

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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

1. 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 
3. 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 
4. 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 
5. 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 
6. 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 
7. 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 
8. 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 
9. 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 
10. 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 
11. 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 
12. 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 
13. 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 
14. 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 
15. 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

最后，希望我以上的解释能让你明白为什么Linux不需要磁盘碎片整理，如果你还是没有明白，请尽管提出让你疑惑的地方。

对windows进行磁盘碎片整理的朋友，这里也做一点小小的友情提示。

1、整理磁盘碎片的时候，要关闭其他所有的应用程序，包括屏幕保护程序，最好将虚拟内存的大小设置为固定值。不要对磁盘进行读写操作。

2、整理磁盘碎片的频率要控制合适，过于频繁的整理也会缩短磁盘的寿命。一般经常读写的磁盘分区一周整理一次。

最后想说说思考的话题。

那些想在linux下进行磁盘碎片整理的朋友，你们考虑过两个事实吗？

第一，为什么类unix系统产生几十年了，没有人做一个磁盘碎片整理软件？而即使是到现在，在这个论坛上也没有朋友提到过遇到linux病毒，我们仍然能找到许多类unix杀毒软件？我就至少能列出3种免费杀毒软件。

第二，很多类unix操作系统都是长年累月不关机的，诸如银行、电信、军工等系统，你能想象它们停止磁盘读写，在长达几小时内进行磁盘碎片整理所带来的后果吗？这些机器的磁盘读写量可是比家用机大多了。

 

 

Linux的ext2, ext3, 和 ext4 文件系统 ——Ubuntu和大多数最新的Linux发布版中使用的是ext4——采用了一种更聪明的方法来存放文件。与把多个文件并排放在磁盘上不同，Linux文件系统把所有文件都分散到了整个磁盘上，每两个文件之间都留有相当巨大的空闲空间。当文件被修改、体积增加时，它们通常有足够的空间来扩展。一旦有碎片产生时，文件系统会尝试移动整个文件来消除碎片，所以你不需要一个碎片整理工具。