百图向导带你入门
Linux不需要磁盘碎片整理。
以下引自linux官方网站对碎片的解说：来源于
http://www.linux.org/docs/ldp/howto/Partition/appendix.html#fragmentation
希望有能力、有闲暇地朋友能对上面的官方材料进行翻译，我的能力有所不及，这里仅仅做一些阐述。
这段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为什么需要碎片整理：
来自http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
请注意，官方资料所说的是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%。
对windows进行磁盘碎片整理的朋友，这里也做一点小小的友情提示。
1、整理磁盘碎片的时候，要关闭其他所有的应用程序，包括屏幕保护程序，最好将虚拟内存的大小设置为固定值。不要对磁盘进行读写操作。
2、整理磁盘碎片的频率要控制合适，过于频繁的整理也会缩短磁盘的寿命。一般经常读写的磁盘分区一周整理一次。
最后想说说思考的话题。
那些想在linux下进行磁盘碎片整理的朋友，你们考虑过两个事实吗？
第一，为什么类unix系统产生几十年了，没有人做一个磁盘碎片整理软件？而即使是到现在，在这个论坛上也没有朋友提到过遇到linux病毒，我们仍然能找到许多类unix杀毒软件？我就至少能列出3种免费杀毒软件。
第二，很多类unix操作系统都是长年累月不关机的，诸如银行、电信、军工等系统，你能想象它们停止磁盘读写，在长达几小时内进行磁盘碎片整理所带来的后果吗？这些机器的磁盘读写量可是比家用机大多了。
#由于我水平有限，错误疏漏之处难免，欢迎各位批评指证。
#26楼的朋友提出
linux没有官方网站
我再次查证后，还是认为引用材料是权威性的。理由如下：
第一，www.linux.org自身描述为The Linux Home Page at Linux Online。
第二，org顶级域名是orgonization的缩写，也就是说非营利性组织会使用这种域名。例如：
GNU官方站点为http://www.gnu.org/
Debian官方站点为http://www.debian.org/
而域名申请有如下规定：不得使用公众知晓的其他国家或者地区名称、外国地名、国际组织名称。
作为linux，我认为这是一个公众知晓的国际组织，因此www.linux.org我认为是官方网站。由linus组织的黑客组织在进行内核发布时，一定是有一个发布渠道的，而网站就是其中一个比较方便的渠道。
同时，我的材料来自HowTo文档，这也是权威的，下面的引用说HOWTOs是官方的。引自http://www.linux.org/docs/
对这方面有所了解的朋友，请不吝赐教，大家共同进步。
#11月10日第一次修改，把《为什么Linux不需要磁盘碎片整理》替换为中译版本。
＃11月22日第二次修改，对文章内容扩充，主要增加了有关外部碎片的说明。[/quote]
最后由 我思故我在 编辑于 2006-12-07 14:23，总共编辑了 4 次
以下引自linux官方网站对碎片的解说：来源于
http://www.linux.org/docs/ldp/howto/Partition/appendix.html#fragmentation
引用:
10.4. Some facts about file systems and fragmentation
Disk space is administered by the operating system in units of blocks and fragments of blocks. In ext2, fragments and blocks have to be of the same size, so we can limit our discussion to blocks.
Files come in any size. They don't end on block boundaries. So with every file a part of the last block of every file is wasted. Assuming that file sizes are random, there is approximately a half block of waste for each file on your disk. Tanenbaum calls this "internal fragmentation" in his book "Operating Systems".
You can guess the number of files on your disk by the number of allocated inodes on a disk. On my disk
# df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda3 64256 12234 52022 19% /
/dev/hda5 96000 43058 52942 45% /var
there are about 12000 files on / and about 44000 files on /var. At a block size of 1 KB, about 6+22 = 28 MB of disk space are lost in the tail blocks of files. Had I chosen a block size of 4 KB, I had lost 4 times this space.
Data transfer is faster for large contiguous chunks of data, though. That's why ext2 tries to preallocate space in units of 8 contigous blocks for growing files. Unused preallocation is released when the file is closed, so no space is wasted.
Noncontiguous placement of blocks in a file is bad for performance, since files are often accessed in a sequential manner. It forces the operating system to split a disk access and the disk to move the head. This is called "external fragmentation" or simply "fragmentation" and is a common problem with MS-DOS file systems. In conjunction with the abysmal buffer cache used by MS-DOS, the effects of file fragmentation on performance are very noticeable. DOS users are accustomed to defragging their disks every few weeks and some have even developed some ritualistic beliefs regarding defragmentation.
None of these habits should be carried over to Linux and ext2. 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. There is a defragmentation tool for ext2 called defrag, but users are cautioned against casual use. A power outage during such an operation can trash your file system. Since you need to back up your data anyway, simply writing back from your copy will do the job.
The MS-DOS file system is also known to lose large amounts of disk space due to internal fragmentation. For partitions larger than 256 MB, DOS block sizes grow so large that they are no longer useful (This has been corrected to some extent with FAT32). Ext2 does not force you to choose large blocks for large file systems, except for very large file systems in the 0.5 TB range (that's terabytes with 1 TB equaling 1024 GB) and above, where small block sizes become inefficient. So unlike DOS there is no need to split up large disks into multiple partitions to keep block size down.
Use a 1Kb block size if you have many small files. For large partitions, 4Kb blocks are fine.
Disk space is administered by the operating system in units of blocks and fragments of blocks. In ext2, fragments and blocks have to be of the same size, so we can limit our discussion to blocks.
Files come in any size. They don't end on block boundaries. So with every file a part of the last block of every file is wasted. Assuming that file sizes are random, there is approximately a half block of waste for each file on your disk. Tanenbaum calls this "internal fragmentation" in his book "Operating Systems".
You can guess the number of files on your disk by the number of allocated inodes on a disk. On my disk
# df -i
Filesystem Inodes IUsed IFree %IUsed Mounted on
/dev/hda3 64256 12234 52022 19% /
/dev/hda5 96000 43058 52942 45% /var
there are about 12000 files on / and about 44000 files on /var. At a block size of 1 KB, about 6+22 = 28 MB of disk space are lost in the tail blocks of files. Had I chosen a block size of 4 KB, I had lost 4 times this space.
Data transfer is faster for large contiguous chunks of data, though. That's why ext2 tries to preallocate space in units of 8 contigous blocks for growing files. Unused preallocation is released when the file is closed, so no space is wasted.
Noncontiguous placement of blocks in a file is bad for performance, since files are often accessed in a sequential manner. It forces the operating system to split a disk access and the disk to move the head. This is called "external fragmentation" or simply "fragmentation" and is a common problem with MS-DOS file systems. In conjunction with the abysmal buffer cache used by MS-DOS, the effects of file fragmentation on performance are very noticeable. DOS users are accustomed to defragging their disks every few weeks and some have even developed some ritualistic beliefs regarding defragmentation.
None of these habits should be carried over to Linux and ext2. 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. There is a defragmentation tool for ext2 called defrag, but users are cautioned against casual use. A power outage during such an operation can trash your file system. Since you need to back up your data anyway, simply writing back from your copy will do the job.
The MS-DOS file system is also known to lose large amounts of disk space due to internal fragmentation. For partitions larger than 256 MB, DOS block sizes grow so large that they are no longer useful (This has been corrected to some extent with FAT32). Ext2 does not force you to choose large blocks for large file systems, except for very large file systems in the 0.5 TB range (that's terabytes with 1 TB equaling 1024 GB) and above, where small block sizes become inefficient. So unlike DOS there is no need to split up large disks into multiple partitions to keep block size down.
Use a 1Kb block size if you have many small files. For large partitions, 4Kb blocks are fine.
希望有能力、有闲暇地朋友能对上面的官方材料进行翻译，我的能力有所不及，这里仅仅做一些阐述。
这段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为什么需要碎片整理：
来自http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting
请注意，官方资料所说的是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矩阵来解释所有的原理，而不是用那些枯燥而晦涩的术语来打击大家的积极性。下面就是我将用来解释原理的矩阵：
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
以上这个矩阵就可以简单的用来表示一个很小的硬盘，初始状态是空的，全部都被0填充。在矩阵顶部和左侧的a-z都是用来定位每一个数据的。最左上角的那个0就是aa，最右上角的那个0就是za，最左下角的就是az。
我将以一个大家都非常非常熟悉的文件系统开始，一个经常需要磁盘碎片整理的系统—FAT。其实无论Windows用户还是Linux用户都会用到FAT文件系统。因为USB闪盘一般都使用这个文件系统。FAT是一个非常非常重要的文件系统，虽然它经常需要磁盘碎片整理。
我现在在磁盘上加入一个文件，于是磁盘看起来会变成这个样子：
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
（为了看起来更加清楚，g-z的空行被省略了）
正如你所看到的，前4行是TOC（Table Of Contents），即所谓的内容表。TOC会存储磁盘上所有文件的位置。在我上面的例子中，TOC包含了一个名字叫做“hello.txt”的文件，并且这个文件的内容是从ae到le的。往下看ae到le之间的内容，我们能看到这个文件的内容是“Hello，_world”
到目前为止，一切都正常对吗？好，那我们再来添加一个文件：
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 e 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
正如你所见，第二个文件被紧接着放置在第一个文件之后。这样的好处是你所有的文件都会紧密地放置在一起，这样读取它们将会非常的迅速和方便。要知道磁盘上最慢的就是读写头的移动了，它移动的越少，则读取的速度越快。
但是，当我们需要修改第一个文件的时候，问题就出来了。现在假设我们需要在“hello.txt”文件的尾部加入两个感叹号，我们就会遇到问题：没有空间！文件“bye.txt”挡住了“hello.txt”的去路。这时候我们有两个解决方法，但是没有一个是完美的。
1 我们把文件“hello.txt”删掉，然后再“bye.txt”后面加入修改过后的“hello.txt”。
2 我们把文件“hello.txt”拆成两部分存储，这样在“bye.txt”之前就不会有空的磁盘空间了。
第一种种方式表现出来就是这样：
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
第二种种方式表现出来就是这样：
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 e 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
这就是为什么FAT格式的文件系统经常需要磁盘碎片整理的原因。所有的文件都紧挨着存放，所以任何时候，只要一个文件需要增大，就会产生碎片。而任何文件被删除了，就会留下一个空白区域。于是很快磁盘就会变成一堆乱糟糟的随便和空白，效率就会变低了。
而Linux 却用一种不同的方式来处理这种问题。对于单用户来说Windows的文件系统已经够好的了，但是Linux生来就是为多用户设计的系统，它总是假设在同一时间有多个用户试图去操作不同的文件。所以Linux相对FAT文件系统，使用了另一种方法来设计自己的文件系统。Linux文件系统看起来是这样的：
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
当我们添加了文件以后就变成这样了：
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
这种文件系统的好处是磁盘的磁头可以一直位于中间位置，而所有的文件平均下来都会非常近。
当我们仍然给“hello.txt”加入两个感叹号时，我们来看看这会引起多大的麻烦：
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
对了！一点麻烦都没有！
Windows总是试图把文件存储在尽量靠近磁盘开始位置的地方，这导致当磁盘利用率变高的时候它经常会产生磁盘碎片。
Linux却在整个磁盘上存储文件，所以当文件的大小需要改变的时候，总是有足够的空间。
当然当磁盘利用率接近饱和的时候Linux也会需要文件整理。但是只要磁盘还有20%以上的可用空间，那么这种整理是基本不会发生的。
还有一点必须了解的是，即使当一个操作系统说某个磁盘已经完全碎片整理完毕了，但是根据一个磁盘的物理结构，碎片仍然会存在。因为磁盘总是由很多盘片和磁道组成的。
让我们来看看一个磁盘有两个盘片，aa到zm是第一个，an到zz是第二个。
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
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
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
一下的文件系统是有碎片的，因为文件横跨了行m和n。而这两行不是在一个盘片上的。要读取这个文件，磁盘的磁头必须从盘片1的最末尾跨越到盘片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
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
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
最后，希望我以上的解释能让你明白为什么Linux不需要磁盘碎片整理，如果你还是没有明白，请尽管提出让你疑惑的地方。
作者：OneAndOneIs2
翻译：rainking
有一个关于Linux的问题经常被问及：为什么Linux不需要磁盘碎片整理呢？在这里，我试图就“为什么有的文件系统比另一些文件系统更加需要磁盘碎片整理”给出一个简单的，非技术性的答案。
我将试图用一个ASCII矩阵来解释所有的原理，而不是用那些枯燥而晦涩的术语来打击大家的积极性。下面就是我将用来解释原理的矩阵：
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
以上这个矩阵就可以简单的用来表示一个很小的硬盘，初始状态是空的，全部都被0填充。在矩阵顶部和左侧的a-z都是用来定位每一个数据的。最左上角的那个0就是aa，最右上角的那个0就是za，最左下角的就是az。
我将以一个大家都非常非常熟悉的文件系统开始，一个经常需要磁盘碎片整理的系统—FAT。其实无论Windows用户还是Linux用户都会用到FAT文件系统。因为USB闪盘一般都使用这个文件系统。FAT是一个非常非常重要的文件系统，虽然它经常需要磁盘碎片整理。
我现在在磁盘上加入一个文件，于是磁盘看起来会变成这个样子：
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
（为了看起来更加清楚，g-z的空行被省略了）
正如你所看到的，前4行是TOC（Table Of Contents），即所谓的内容表。TOC会存储磁盘上所有文件的位置。在我上面的例子中，TOC包含了一个名字叫做“hello.txt”的文件，并且这个文件的内容是从ae到le的。往下看ae到le之间的内容，我们能看到这个文件的内容是“Hello，_world”
到目前为止，一切都正常对吗？好，那我们再来添加一个文件：
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 e 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
正如你所见，第二个文件被紧接着放置在第一个文件之后。这样的好处是你所有的文件都会紧密地放置在一起，这样读取它们将会非常的迅速和方便。要知道磁盘上最慢的就是读写头的移动了，它移动的越少，则读取的速度越快。
但是，当我们需要修改第一个文件的时候，问题就出来了。现在假设我们需要在“hello.txt”文件的尾部加入两个感叹号，我们就会遇到问题：没有空间！文件“bye.txt”挡住了“hello.txt”的去路。这时候我们有两个解决方法，但是没有一个是完美的。
1 我们把文件“hello.txt”删掉，然后再“bye.txt”后面加入修改过后的“hello.txt”。
2 我们把文件“hello.txt”拆成两部分存储，这样在“bye.txt”之前就不会有空的磁盘空间了。
第一种种方式表现出来就是这样：
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
第二种种方式表现出来就是这样：
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 e 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
这就是为什么FAT格式的文件系统经常需要磁盘碎片整理的原因。所有的文件都紧挨着存放，所以任何时候，只要一个文件需要增大，就会产生碎片。而任何文件被删除了，就会留下一个空白区域。于是很快磁盘就会变成一堆乱糟糟的随便和空白，效率就会变低了。
而Linux 却用一种不同的方式来处理这种问题。对于单用户来说Windows的文件系统已经够好的了，但是Linux生来就是为多用户设计的系统，它总是假设在同一时间有多个用户试图去操作不同的文件。所以Linux相对FAT文件系统，使用了另一种方法来设计自己的文件系统。Linux文件系统看起来是这样的：
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
当我们添加了文件以后就变成这样了：
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
这种文件系统的好处是磁盘的磁头可以一直位于中间位置，而所有的文件平均下来都会非常近。
当我们仍然给“hello.txt”加入两个感叹号时，我们来看看这会引起多大的麻烦：
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
对了！一点麻烦都没有！
Windows总是试图把文件存储在尽量靠近磁盘开始位置的地方，这导致当磁盘利用率变高的时候它经常会产生磁盘碎片。
Linux却在整个磁盘上存储文件，所以当文件的大小需要改变的时候，总是有足够的空间。
当然当磁盘利用率接近饱和的时候Linux也会需要文件整理。但是只要磁盘还有20%以上的可用空间，那么这种整理是基本不会发生的。
还有一点必须了解的是，即使当一个操作系统说某个磁盘已经完全碎片整理完毕了，但是根据一个磁盘的物理结构，碎片仍然会存在。因为磁盘总是由很多盘片和磁道组成的。
让我们来看看一个磁盘有两个盘片，aa到zm是第一个，an到zz是第二个。
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
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
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
一下的文件系统是有碎片的，因为文件横跨了行m和n。而这两行不是在一个盘片上的。要读取这个文件，磁盘的磁头必须从盘片1的最末尾跨越到盘片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
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
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
最后，希望我以上的解释能让你明白为什么Linux不需要磁盘碎片整理，如果你还是没有明白，请尽管提出让你疑惑的地方。
对windows进行磁盘碎片整理的朋友，这里也做一点小小的友情提示。
1、整理磁盘碎片的时候，要关闭其他所有的应用程序，包括屏幕保护程序，最好将虚拟内存的大小设置为固定值。不要对磁盘进行读写操作。
2、整理磁盘碎片的频率要控制合适，过于频繁的整理也会缩短磁盘的寿命。一般经常读写的磁盘分区一周整理一次。
最后想说说思考的话题。
那些想在linux下进行磁盘碎片整理的朋友，你们考虑过两个事实吗？
第一，为什么类unix系统产生几十年了，没有人做一个磁盘碎片整理软件？而即使是到现在，在这个论坛上也没有朋友提到过遇到linux病毒，我们仍然能找到许多类unix杀毒软件？我就至少能列出3种免费杀毒软件。
第二，很多类unix操作系统都是长年累月不关机的，诸如银行、电信、军工等系统，你能想象它们停止磁盘读写，在长达几小时内进行磁盘碎片整理所带来的后果吗？这些机器的磁盘读写量可是比家用机大多了。
#由于我水平有限，错误疏漏之处难免，欢迎各位批评指证。
#26楼的朋友提出
davix 写道:
linux没有官方网站
我再次查证后，还是认为引用材料是权威性的。理由如下：
第一，www.linux.org自身描述为The Linux Home Page at Linux Online。
第二，org顶级域名是orgonization的缩写，也就是说非营利性组织会使用这种域名。例如：
GNU官方站点为http://www.gnu.org/
Debian官方站点为http://www.debian.org/
而域名申请有如下规定：不得使用公众知晓的其他国家或者地区名称、外国地名、国际组织名称。
作为linux，我认为这是一个公众知晓的国际组织，因此www.linux.org我认为是官方网站。由linus组织的黑客组织在进行内核发布时，一定是有一个发布渠道的，而网站就是其中一个比较方便的渠道。
同时，我的材料来自HowTo文档，这也是权威的，下面的引用说HOWTOs是官方的。引自http://www.linux.org/docs/
引用:
Linux information and technical support is available from a wide variety of locations. There are the "official" routes such as the Linux Software Map, Linux Documentation Project, HOWTOs, and FAQs (Frequently Asked Questions).
对这方面有所了解的朋友，请不吝赐教，大家共同进步。
#11月10日第一次修改，把《为什么Linux不需要磁盘碎片整理》替换为中译版本。
＃11月22日第二次修改，对文章内容扩充，主要增加了有关外部碎片的说明。[/quote]
最后由 我思故我在 编辑于 2006-12-07 14:23，总共编辑了 4 次
作者: 我思故我在 发布时间: 2006-10-16
好文章，建议大家都来看看，知其然还要知其所以然。
作者: Eyoka 发布时间: 2006-10-16
这样的专业技术贴一定要顶！
作者: goldfox_79 发布时间: 2006-10-16
顶一下，感觉论坛上应该增加一些这样的好文章。呵呵
作者: fyfwn 发布时间: 2006-10-24
通俗易懂，好文章
作者: nobrain 发布时间: 2006-10-24
mark
作者: zhuqin_83 发布时间: 2006-10-25
Nice!
作者: again 发布时间: 2006-11-10
支持，建议加精
作者: bzimage 发布时间: 2006-11-10
好文章，加精，收藏。
作者: qwneo 发布时间: 2006-11-10
这个帖子应该加精华并置顶啊，呼唤版主！
作者: 茶叶棍儿 发布时间: 2006-11-10
呵呵 OneAndOneIs2 师兄的文被翻译成中文了。
强烈建议OneAndOneIs2 以后就不要这么折磨大家了，直接中文就是了....
强烈建议OneAndOneIs2 以后就不要这么折磨大家了，直接中文就是了....
作者: xiaosilent 发布时间: 2006-11-12
sogood~！通俗易懂。有机会能不能介绍一下什么叫做日志式文件系统啊？
作者: milkboy_x 发布时间: 2006-11-12
milkboy_x 写道:
sogood~！通俗易懂。有机会能不能介绍一下什么叫做日志式文件系统啊？
简单的说，就是带有日志记录的文件系统，这样的文件系统，会记录在其上进行的操作，所以有助于故障恢复。
作者: patrickhe 发布时间: 2006-11-13
又增加了 知识
作者: wsk170 发布时间: 2006-11-15
哈哈，我们学校关于linux的杂志上也曾引了这篇，确实是精华
作者: TheThirdGhost 发布时间: 2006-11-15
精華。。。
好像這個論壇越來越像faq list了求助區了。一些技術貼也要有啊！！
好像這個論壇越來越像faq list了求助區了。一些技術貼也要有啊！！
作者: choukuangjay 发布时间: 2006-11-17
引用:
所有类unix系统从来没听说过有碎片整理软件，从这一点就可以轻易分析出一个结论：类unix不存在碎片影响性能的情况！否则，类unix系统都产生几十年了，难道还会没人做个软件来解决碎片问题。
不存在碎片整理工具->不存在碎片影响性能情况->不存在碎片,这种三段式推理让我联想到"我们不存在以权谋私情况"
一方面Ext2和ReiserFS的资料都提到为了减少碎片化而不断作改进
一方面有资料提到Linux下面没有碎片,而且越用碎片越少
一方面有资料说本来就没有碎片,放一起居然还有人信,我怕也就国内信的人多了
引用:
早期的文件系统,采取尾部留空,那时候还不成问题,当前磁盘存储的飙升,在这种情况下,如果当前末尾没有足够的空间,铁定是会不连续的记录了.相对于将尾部置换出连续空间所一定付出的性能代价,大于了当前文件碎片化所可能得到的受益
作者: 曾半仙 发布时间: 2006-11-17
不错，看后受益菲浅
作者: deerlux 发布时间: 2006-11-18
看了17楼的话，我在这里先做个简短的回复：
你没有仔细看帖。
这句话是正确的。另外，对于小文件系统，ReiserFS性能优于EXt3。
这句话严格的说是错误的，但是也可以说是对的，因为linux下确实不会产生windows概念下的碎片。我原帖中有
但是你忽略了我原帖中的后话
这句话是linux官方的说法，英文引用地址我也给出来了。
事实上内部碎片所造成的损失是在空间的浪费上，我为了解说方便，所以说的是不影响性能。对于那个推论，我也认为不够严谨，但是类unix不需要碎片整理这个结论是正确的，能够有我的那个推论的思考，也就不会莫明其妙的去思考如何做碎片整理。
我会进一步在原帖中补充有关这方面的内容，先向你解释到这里。
你没有仔细看帖。
引用:
一方面Ext2和ReiserFS的资料都提到为了减少碎片化而不断作改进
这句话是正确的。另外，对于小文件系统，ReiserFS性能优于EXt3。
引用:
一方面有资料提到Linux下面没有碎片,而且越用碎片越少 ，一方面有资料说本来就没有碎片
这句话严格的说是错误的，但是也可以说是对的，因为linux下确实不会产生windows概念下的碎片。我原帖中有
引用:
所有操作系统都会产生碎片，这个碎片称为内部碎片（internal fragmentation）
但是你忽略了我原帖中的后话
引用:
另一个碎片概念，称为外部碎片，这个碎片对访问性能才有影响，这也是windows概念下的碎片，（This is called "external fragmentation" or simply "fragmentation" and is a common problem with MS-DOS file systems. ）
这句话是linux官方的说法，英文引用地址我也给出来了。
事实上内部碎片所造成的损失是在空间的浪费上，我为了解说方便，所以说的是不影响性能。对于那个推论，我也认为不够严谨，但是类unix不需要碎片整理这个结论是正确的，能够有我的那个推论的思考，也就不会莫明其妙的去思考如何做碎片整理。
我会进一步在原帖中补充有关这方面的内容，先向你解释到这里。
作者: 我思故我在 发布时间: 2006-11-18
看不懂原理，但知道结果已经很不错了。优良的系统～！
作者: bchan 发布时间: 2006-11-22
太精彩了，学到很多东西，谢谢楼主。
作者: wilfuler 发布时间: 2006-11-22
受教了，非常感谢！
作者: linuxoser 发布时间: 2006-11-23
受教了，非常感谢！
作者: linuxoser 发布时间: 2006-11-23
确实是不错的文章
作者: qwfyxwxl 发布时间: 2006-11-25
这就是我选择Linux的原因之一
作者: tiego 发布时间: 2006-11-30
文章很好
但提示一下，linux没有官方网站
但提示一下，linux没有官方网站
作者: davix 发布时间: 2006-11-30
学到很多知识，谢谢~~~
作者: jellyfish 发布时间: 2006-12-01
不错，不错。
windows性能方面还是难以与linux相比。
windows性能方面还是难以与linux相比。
作者: xjj 发布时间: 2006-12-03
学习.学习,再学习.
作者: wllbao 发布时间: 2006-12-04
很精彩啊。深受了解。
作者: hyden 发布时间: 2006-12-05
茅塞顿开啊！
作者: Jimmy.Zhou 发布时间: 2006-12-09
好文章！我终于明白了Linux是真的不需要磁盘整理的。
作者: TualatriX 发布时间: 2006-12-09
我看过了，很不错哦。加深了印象
作者: Cyclonecj 发布时间: 2006-12-27
我问一个问题如果文件系统用到一定的程度后（如下，其中1为文件1，2为文件。。。），要再添加一个比较大的文件（如加入50个f），那个文件不是也会有外部碎片吗？
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 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
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 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
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 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
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 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
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 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
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 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
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 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
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 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
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 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
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 a a a a a a a a a a a a a a a a a a a a a a a a a 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 b b b b b b b b b b b b b b b b b b b b b b b b b b
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 c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c
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 d d d d d d d d d d d d d d d d d d d d d d d d d d
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
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 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
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 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
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 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
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 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4
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 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5 5
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 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6 6
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 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7 7
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 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8 8
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 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9 9
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 a a a a a a a a a a a a a a a a a a a a a a a a a 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 b b b b b b b b b b b b b b b b b b b b b b b b b b
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 c c c c c c c c c c c c c c c c c c c c c c c c c c c c c c
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 d d d d d d d d d d d d d d d d d d d d d d d d d d
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
作者: xyz042 发布时间: 2006-12-27
文章的标题有点奇怪，其内容上也有不少值得商榷之处：
1：
从数学上来说，只要你给定一个整数k，那么，一定存在一个整数k+1。
所以，根据以上数学定理，无论Linux为两个文件之间保留了多少预留空间，我总能把它填满并溢出……
使用预留空间的做法，只能说降低了发生溢出的几率，而不可能从根本上杜绝这个情况的发生。
至于文中一再强调的“20%”，只能合理的理解为：当磁盘剩余可用空间小于20%的时候，这种溢出的发生几率会大大增加，以至于到了不可忽视的地步。
事实上，MS的NTFS系统用的也是类似的方法，所以不要再抱着FAT/FAT32的老皇历来沾沾自喜了。
2：
事实上，第二点正是出现第一点的原因。
为什么没有人在*nix中使用磁盘碎片整理软件？那是因为没有人愿意承受由此带来的后果。
为什么没人开发在*nix下的磁盘碎片整理软件？那是因为没有人愿意使用它。
道理是很浅显的，再举个例子吧：
先在美国在伊拉克弄的满头烟，那么它要是把在伊拉克的什叶派和逊尼派都统统三光了，伊拉克不就清静了？
它有这么多原子弹，有这么多的毒气、生化武器，能力绝对不是问题。
但是这么做而带来的后果显然是美国所不能承受，或者说不想承受的，所以它也就没这么做。
所以，当人们没有做一件事情的时候，往往是不愿意承担其风险，或者承受其代价，故而没有需求，也就没有动力。
而不是没有能力，或者真的不需要。
3：
文中一再强调：“内部碎片主要是造成磁盘空间的浪费”
而在它解释Linux为什么不会产生文件碎片的时候，却说Linux文件的存放机制是文件A、B是不会紧密相连的，中间会有一个“预留空间”。那么请问这个“预留空间”的存在会不会造成“磁盘空间的浪费”呢？
事实上Linux在这个问题上仅仅是投机取巧了一点而已：它没有了“簇”的概念，但是不等于它就真的没有了“内碎片”，只不过由FAT的“簇内剩余空间”的“浪费”变成了文件A、B之间的“预留空间”而已。不客气的说一句：那是换汤不换药。
另外，再说一下，FAT的磁盘空间碎片也不是一定有的，只要一个文件的大小增长还是在一个“簇”之内，其实还是不会产生文件碎片的，这个原理和所谓的“Linux不会产生文件碎片”的原理也是完全一样的。
4：
有没有真正没有文件碎片的磁盘文件格式呢？
有，当然有。所有（至少是大部分）一次性写入的格式都是这样的，例如说磁带机的顺序写入、CD/DVD上的文件格式（可能不包括DVD-RAM，因为那个是完全可随机读写的）、还有一些一次性写入的ROM之类的。
从逻辑上来说，只要支持随机文件读写删除的文件系统，就不可避免的产生文件碎片和空间浪费。
而且，从工程上说，“磁盘空间浪费”是为了尽可能减少“文件碎片”所采取的措施的副作用。从目前所有的主流磁盘文件格式来看，它们为了减少“文件碎片”而采取的方法和手段基本上都是类似的，无非就是利用预留磁盘空间，来减少因为文件大小增加所需要的重新分配。所以，在这个问题上，谁也无法独善其身，特别需要强调的是：所有的*nix所用的ext?系统，同样如此。
至于可怜的FAT/FAT32，只不过是它们出现的时间比较早，而且当时计算机的性能也不高，所以就采用了比较机械的“簇”的方式来实现这个功能，因而也被大家老拿来说事。不得不感叹：可怜的老前辈啊～
1：
引用:
Linux却在整个磁盘上存储文件，所以当文件的大小需要改变的时候，总是有足够的空间。
从数学上来说，只要你给定一个整数k，那么，一定存在一个整数k+1。
所以，根据以上数学定理，无论Linux为两个文件之间保留了多少预留空间，我总能把它填满并溢出……
使用预留空间的做法，只能说降低了发生溢出的几率，而不可能从根本上杜绝这个情况的发生。
至于文中一再强调的“20%”，只能合理的理解为：当磁盘剩余可用空间小于20%的时候，这种溢出的发生几率会大大增加，以至于到了不可忽视的地步。
事实上，MS的NTFS系统用的也是类似的方法，所以不要再抱着FAT/FAT32的老皇历来沾沾自喜了。
2：
引用:
第一，为什么类unix系统产生几十年了，没有人做一个磁盘碎片整理软件？而即使是到现在，在这个论坛上也没有朋友提到过遇到linux病毒，我们仍然能找到许多类unix杀毒软件？我就至少能列出3种免费杀毒软件。
第二，很多类unix操作系统都是长年累月不关机的，诸如银行、电信、军工等系统，你能想象它们停止磁盘读写，在长达几小时内进行磁盘碎片整理所带来的后果吗？这些机器的磁盘读写量可是比家用机大多了。
第二，很多类unix操作系统都是长年累月不关机的，诸如银行、电信、军工等系统，你能想象它们停止磁盘读写，在长达几小时内进行磁盘碎片整理所带来的后果吗？这些机器的磁盘读写量可是比家用机大多了。
事实上，第二点正是出现第一点的原因。
为什么没有人在*nix中使用磁盘碎片整理软件？那是因为没有人愿意承受由此带来的后果。
为什么没人开发在*nix下的磁盘碎片整理软件？那是因为没有人愿意使用它。
道理是很浅显的，再举个例子吧：
先在美国在伊拉克弄的满头烟，那么它要是把在伊拉克的什叶派和逊尼派都统统三光了，伊拉克不就清静了？
它有这么多原子弹，有这么多的毒气、生化武器，能力绝对不是问题。
但是这么做而带来的后果显然是美国所不能承受，或者说不想承受的，所以它也就没这么做。
所以，当人们没有做一件事情的时候，往往是不愿意承担其风险，或者承受其代价，故而没有需求，也就没有动力。
而不是没有能力，或者真的不需要。
3：
文中一再强调：“内部碎片主要是造成磁盘空间的浪费”
而在它解释Linux为什么不会产生文件碎片的时候，却说Linux文件的存放机制是文件A、B是不会紧密相连的，中间会有一个“预留空间”。那么请问这个“预留空间”的存在会不会造成“磁盘空间的浪费”呢？
事实上Linux在这个问题上仅仅是投机取巧了一点而已：它没有了“簇”的概念，但是不等于它就真的没有了“内碎片”，只不过由FAT的“簇内剩余空间”的“浪费”变成了文件A、B之间的“预留空间”而已。不客气的说一句：那是换汤不换药。
另外，再说一下，FAT的磁盘空间碎片也不是一定有的，只要一个文件的大小增长还是在一个“簇”之内，其实还是不会产生文件碎片的，这个原理和所谓的“Linux不会产生文件碎片”的原理也是完全一样的。
4：
有没有真正没有文件碎片的磁盘文件格式呢？
有，当然有。所有（至少是大部分）一次性写入的格式都是这样的，例如说磁带机的顺序写入、CD/DVD上的文件格式（可能不包括DVD-RAM，因为那个是完全可随机读写的）、还有一些一次性写入的ROM之类的。
从逻辑上来说，只要支持随机文件读写删除的文件系统，就不可避免的产生文件碎片和空间浪费。
而且，从工程上说，“磁盘空间浪费”是为了尽可能减少“文件碎片”所采取的措施的副作用。从目前所有的主流磁盘文件格式来看，它们为了减少“文件碎片”而采取的方法和手段基本上都是类似的，无非就是利用预留磁盘空间，来减少因为文件大小增加所需要的重新分配。所以，在这个问题上，谁也无法独善其身，特别需要强调的是：所有的*nix所用的ext?系统，同样如此。
至于可怜的FAT/FAT32，只不过是它们出现的时间比较早，而且当时计算机的性能也不高，所以就采用了比较机械的“簇”的方式来实现这个功能，因而也被大家老拿来说事。不得不感叹：可怜的老前辈啊～
作者: yhz 发布时间: 2007-01-20
严重同意楼上的讲法！！其实大家对linux不产生碎片似乎很感兴趣，但事实上无论任何系统都会产生或多或少的文件不连续情况，照所谓官方的文章来看，我认为linux换了一个概念，一、文件如何分配比较合理？如果像文章举例的那样，那么我想问一句，究竟文件与文件之间该留多少空间来避免碎片的产生？二、无可否认EXT的存储机制（仅存储）比较先进，但是没有碎片产生？那么你的linux分区所需要的空间相当大，我是按文章所说的所推导出来的，而ntfs所倡导的是读取速度优先！这种以速度换取质量的情形其实不奇怪，最主要是针对的客户群不同！！
UNIX/Linux的系统一般为大型服务器使用，因为这些服务器上面存放的数据很重要，有些是很敏感的，因此数据安全性比读取速度远远要重要得多，采取linux的存储机制可以有效地防止数据的丢失或者读写错误，而NT系统一般为交换服务器或者为局域网所采用，因为这些服务器需要及时的反应！试想下如果你要访问硬盘上某个文件的话，是连续访问容易还是跳着访问容易？时效性这就出来了（这是根据硬盘的物理结构所提出的，不知道硬盘结构的请想像一下以前旧式的黑胶唱片的运作，硬盘的运作基本上就和这差不多）
因此，在硬盘上没有不产生碎片的存储格式，只是产生的环境不同，应用的环境不同，所以大家要注意保护下自己的硬盘，过分的读写还是会使硬盘坏的哦
UNIX/Linux的系统一般为大型服务器使用，因为这些服务器上面存放的数据很重要，有些是很敏感的，因此数据安全性比读取速度远远要重要得多，采取linux的存储机制可以有效地防止数据的丢失或者读写错误，而NT系统一般为交换服务器或者为局域网所采用，因为这些服务器需要及时的反应！试想下如果你要访问硬盘上某个文件的话，是连续访问容易还是跳着访问容易？时效性这就出来了（这是根据硬盘的物理结构所提出的，不知道硬盘结构的请想像一下以前旧式的黑胶唱片的运作，硬盘的运作基本上就和这差不多）
因此，在硬盘上没有不产生碎片的存储格式，只是产生的环境不同，应用的环境不同，所以大家要注意保护下自己的硬盘，过分的读写还是会使硬盘坏的哦
作者: gman3025 发布时间: 2007-01-20
长见识了：） 谢谢！
作者: tt2nn 发布时间: 2007-01-21
学习了。好文章 ，谢谢！
作者: yuwensheng 发布时间: 2007-01-29
谢谢35楼的yhz朋友，对我的文章提出了诸多看法。
我的文章主题是说明linux不需要磁盘碎片整理，这里已经把讨论范围扩大化了，下面我也扩展的说说类unix。
首先，从现状来看，类unix的服务器的磁盘读写速度比windows个人机快。
从技术上讲，先说重点：文件系统。类unix显然追求着更快的速度。
如类unix下的linux，它有一种文件系统是ReiserFS，是使用了特殊的优化b*平衡树（每个文件系统一个）来组织所有的文件系统数据。和ext2不同，ReiserFS并不固定地以1k或者4k的块分配存储空间，而是分配所需要的精确尺寸。而且ReiserFS也包括了以尾文件为中心的特殊优化―尾文件是指那些比文件系统块小的文件及文件结尾部分。为了提高性能，ReiserFS能够在b*树的叶子节点存储文件，而不是把数据存储在磁盘的其它地方再指向它。ReiserFS基于快速平衡树(balanced tree)搜索，ReiserFS搜索大量文件时，搜索速度要比ext2快得多。实际上，当处理小于1k的文件时，ReiserFS大概要比ext2快8到15倍！
又例如基于类unix下的系统Irix的XFS，它使用高的表结构(B+树)，保证了文件系统可以快速搜索与快速空间分配。能够持续提供高速操作，文件系统的性能不受目录中目录及文件数量的限制。 XFS能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中，其吞吐量最高可达7GB每秒，对单个文件的读写操作，其吞吐量可达4GB每秒。上面的ReiserFS在小文件系统中表现出优异的性能，而XFS则正是在大文件处理上有着更大的优势。
除了在文件系统上追求更快的读写速度。类unix服务器也常采取raid策略加快存取，windows用raid的则比较少。
在硬件上，服务器常用SCSI硬盘，个人则常用IDE。而SCSI是比IDE更快的。服务器多用类unix，个人则是windows。
从用户需求来说：以windows XP为例，它默认同时只能一个用户操作。而类unix诞生时即是为多用户同时处理设计。多用户同时对磁盘读写与单用户磁盘读写谁需要更快的速度也是显而易见的。
下面是一台linux的磁盘速度：
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 3212 MB in 2.00 seconds = 1606.24 MB/sec
Timing buffered disk reads: 380 MB in 3.01 seconds = 126.35 MB/sec
下面是14块15k的SCSI盘，做的raid0+1。
#hdparm tT /dev/cciss/c0d0p4
/dev/cciss/c0d0p4:
Timing cached reads: 3840 MB in 2.00 seconds = 1919.33 MB/sec
Timing buffered disk reads: 916 MB in 3.00 seconds = 304.97 MB/sec
这两个都是网友机器的实测值，你敢说它们慢？
说NTFS采取了更优化的文件系统，这个我承认。然而我常常看到别人NTFS上的磁盘磁片超过10%。下面是我的FreeBSD的磁盘碎片量：
/dev/ad0s2a: clean, 222837 free (261 frags, 27822 blocks, 0.1% fragmentation)
/dev/ad0s2e: clean, 253793 free (33 frags, 31720 blocks, 0.0% fragmentation)
/dev/ad0s2f: clean, 2255668 free (53364 frags, 275288 blocks, 0.9% fragmentation)
/dev/ad0s2d: clean, 429129 free (1313 frags, 53477 blocks, 0.3% fragmentation)
因为最近几个月主要用它，就贴它了。其中/dev/ad0s2f我三次在容量使用上超过了它的警界线，而我在查看磁盘碎片量时，从来没看到磁盘碎片超过2%。所以，我个人是相信类unix几乎不产生磁盘碎片，类unix不需要磁盘碎片整理这一说法的。
下面另外讲讲，类unix产生磁盘碎片少的原因，这些则只是我的个人思考，不一定正确。
windows容易产生碎片的一个方面是内存交换文件swap或pagefile，类unix与之对应的是swap。由于类unix是尽量多的用物理内存，所以用swap很少，以我的个人机器来说，1G的物理内存，用类unix时一般swap使用是0，而在windows XP下则常在300~400M，这时windows会产生碎片，而类unix不会。其次，类unix一般默认会单独分区swap，windows的pagefile在和启动区混在一起。
类unix的文件系统很科学，临时文件一般都会产生在/tmp下，而windows则不是。临时文件的回收上，类unix也比windows好。此外，有些管理员会单独分区/boot、/usr等，并将/boot标为只读，而/usr在最早机器装好软件后，几乎不会再进行写操作。所以这两个区的碎片也是极低的。windows则没有这种策略。我也曾把windows下的一些$TEMP一起移到一个区，然而某些程序报错了，我最后只能打消这个念头。
最后，有一点我同意你的说法。类unix确实在空间上有损耗。以我的为例：
$df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s2a 496M 61M 396M 13% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s2e 496M 54K 456M 0% /tmp
/dev/ad0s2f 11G 7.1G 3.4G 68% /usr
/dev/ad0s2d 989M 151M 759M 17% /var
/dev/ad0s8 36G 21G 16G 57% /media/ad0s8
如/usr，它是UFS文件系统，我分区时给了约12G，它显示的是11G空间，Used+Avail却只有10.5G，另外0.5G它就不准备让用户使用。
而/media/ad0s8是FAT32，它的Used+Avail甚至比显示大小36G还大了1G。
实际上各种文件系统也必然有着各自的考量，不同的应用、不同的需求采用的文件系统是不同的。没有一种文件系统会在安全性、速度、兼容等方面都最强。
我的文章主题是说明linux不需要磁盘碎片整理，这里已经把讨论范围扩大化了，下面我也扩展的说说类unix。
首先，从现状来看，类unix的服务器的磁盘读写速度比windows个人机快。
从技术上讲，先说重点：文件系统。类unix显然追求着更快的速度。
如类unix下的linux，它有一种文件系统是ReiserFS，是使用了特殊的优化b*平衡树（每个文件系统一个）来组织所有的文件系统数据。和ext2不同，ReiserFS并不固定地以1k或者4k的块分配存储空间，而是分配所需要的精确尺寸。而且ReiserFS也包括了以尾文件为中心的特殊优化―尾文件是指那些比文件系统块小的文件及文件结尾部分。为了提高性能，ReiserFS能够在b*树的叶子节点存储文件，而不是把数据存储在磁盘的其它地方再指向它。ReiserFS基于快速平衡树(balanced tree)搜索，ReiserFS搜索大量文件时，搜索速度要比ext2快得多。实际上，当处理小于1k的文件时，ReiserFS大概要比ext2快8到15倍！
又例如基于类unix下的系统Irix的XFS，它使用高的表结构(B+树)，保证了文件系统可以快速搜索与快速空间分配。能够持续提供高速操作，文件系统的性能不受目录中目录及文件数量的限制。 XFS能以接近裸设备I/O的性能存储数据。在单个文件系统的测试中，其吞吐量最高可达7GB每秒，对单个文件的读写操作，其吞吐量可达4GB每秒。上面的ReiserFS在小文件系统中表现出优异的性能，而XFS则正是在大文件处理上有着更大的优势。
除了在文件系统上追求更快的读写速度。类unix服务器也常采取raid策略加快存取，windows用raid的则比较少。
在硬件上，服务器常用SCSI硬盘，个人则常用IDE。而SCSI是比IDE更快的。服务器多用类unix，个人则是windows。
从用户需求来说：以windows XP为例，它默认同时只能一个用户操作。而类unix诞生时即是为多用户同时处理设计。多用户同时对磁盘读写与单用户磁盘读写谁需要更快的速度也是显而易见的。
下面是一台linux的磁盘速度：
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 3212 MB in 2.00 seconds = 1606.24 MB/sec
Timing buffered disk reads: 380 MB in 3.01 seconds = 126.35 MB/sec
下面是14块15k的SCSI盘，做的raid0+1。
#hdparm tT /dev/cciss/c0d0p4
/dev/cciss/c0d0p4:
Timing cached reads: 3840 MB in 2.00 seconds = 1919.33 MB/sec
Timing buffered disk reads: 916 MB in 3.00 seconds = 304.97 MB/sec
这两个都是网友机器的实测值，你敢说它们慢？
说NTFS采取了更优化的文件系统，这个我承认。然而我常常看到别人NTFS上的磁盘磁片超过10%。下面是我的FreeBSD的磁盘碎片量：
/dev/ad0s2a: clean, 222837 free (261 frags, 27822 blocks, 0.1% fragmentation)
/dev/ad0s2e: clean, 253793 free (33 frags, 31720 blocks, 0.0% fragmentation)
/dev/ad0s2f: clean, 2255668 free (53364 frags, 275288 blocks, 0.9% fragmentation)
/dev/ad0s2d: clean, 429129 free (1313 frags, 53477 blocks, 0.3% fragmentation)
因为最近几个月主要用它，就贴它了。其中/dev/ad0s2f我三次在容量使用上超过了它的警界线，而我在查看磁盘碎片量时，从来没看到磁盘碎片超过2%。所以，我个人是相信类unix几乎不产生磁盘碎片，类unix不需要磁盘碎片整理这一说法的。
下面另外讲讲，类unix产生磁盘碎片少的原因，这些则只是我的个人思考，不一定正确。
windows容易产生碎片的一个方面是内存交换文件swap或pagefile，类unix与之对应的是swap。由于类unix是尽量多的用物理内存，所以用swap很少，以我的个人机器来说，1G的物理内存，用类unix时一般swap使用是0，而在windows XP下则常在300~400M，这时windows会产生碎片，而类unix不会。其次，类unix一般默认会单独分区swap，windows的pagefile在和启动区混在一起。
类unix的文件系统很科学，临时文件一般都会产生在/tmp下，而windows则不是。临时文件的回收上，类unix也比windows好。此外，有些管理员会单独分区/boot、/usr等，并将/boot标为只读，而/usr在最早机器装好软件后，几乎不会再进行写操作。所以这两个区的碎片也是极低的。windows则没有这种策略。我也曾把windows下的一些$TEMP一起移到一个区，然而某些程序报错了，我最后只能打消这个念头。
最后，有一点我同意你的说法。类unix确实在空间上有损耗。以我的为例：
$df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/ad0s2a 496M 61M 396M 13% /
devfs 1.0K 1.0K 0B 100% /dev
/dev/ad0s2e 496M 54K 456M 0% /tmp
/dev/ad0s2f 11G 7.1G 3.4G 68% /usr
/dev/ad0s2d 989M 151M 759M 17% /var
/dev/ad0s8 36G 21G 16G 57% /media/ad0s8
如/usr，它是UFS文件系统，我分区时给了约12G，它显示的是11G空间，Used+Avail却只有10.5G，另外0.5G它就不准备让用户使用。
而/media/ad0s8是FAT32，它的Used+Avail甚至比显示大小36G还大了1G。
实际上各种文件系统也必然有着各自的考量，不同的应用、不同的需求采用的文件系统是不同的。没有一种文件系统会在安全性、速度、兼容等方面都最强。
作者: 我思故我在 发布时间: 2007-02-05
好贴
作者: linbingqing 发布时间: 2007-02-08
yhz 写道:
文章的标题有点奇怪，其内容上也有不少值得商榷之处：
事实上，MS的NTFS系统用的也是类似的方法，所以不要再抱着FAT/FAT32的老皇历来沾沾自喜了。
事实上，MS的NTFS系统用的也是类似的方法，所以不要再抱着FAT/FAT32的老皇历来沾沾自喜了。
根据。根据，有理有据。你这句话在我看来是一面之辞。请拿出根据。
我用ext3，ntfs也用，fat也用，reiserfs也用。
我的ntfs盘，同样经常需要整理碎片，而且碎片能够达到10%-20%，相同条件下，ext3的碎片少得多。——没有人说ext3无碎片，可是对于大多数的典型应用来说，ext3都能够做到比ntfs少得多的碎片。这是个不争的事实。
不可否认NTFS速度确实做了优化，可是NTFS的速度与reiserfs还是有相当大的差距，证据？网上有测试数据，一大把。比较著名的，可以找NTFS-3G的作者作的评测，NTFS3G不是个简单的东西，写这个的作者做事情必然也是个很细腻的人。作者自己非常坦率的表明：虽然NTFS3G的驱动比Windows的NTFS驱动快了许多倍，但是仍然与reiserfs有差距。
至于说NTFS速度优化的问题，如果是指的windows自身的驱动，我表示怀疑，因为我被NTFS3G的性能所折服，原来在linux下访问NTFS可以比windows下快这么多。——但是在windows下，我做过测试NTFS绝对不比FAT快。——NTFS的好处只是安全，因为FAT遇到掉电几乎是100%出问题，NTFS目前还没有遇到过掉电造成数据损坏的情况。
其实我是个windows和linux的两面派，所以我无意维护任何一个操作系统，因为他们都有对方做不了的事情。——但是就文件系统来说。NTFS的确也”没什么好得意的“。虽然NTFS的速度可以快过ext3，但是Linux并不是只能用ext3。。。而且ext3的碎片仍然比NTFS少得多。
作者: poet 发布时间: 2007-02-09
好贴
linux下的目录结构文件结构是比较先进的
linux下的目录结构文件结构是比较先进的
作者: kingwxj 发布时间: 2007-02-09
看完。明白了。帮顶！！
作者: YinzCN 发布时间: 2007-02-14
To 我思故我在 和 poet 朋友：
既然两位都拿出了数据，那么我也就顺着两位的要求拿出点数据来看看，NTFS究竟是不是比EXT3慢吧：
“我思故我在”朋友贴出了一堆网友提供的数据，看到我如临大敌啊。熟悉硬盘的都知道，最快的15K盘应该不外乎ST的15K.4、fujitsu的MAU、Maxtor的Atlas 15K II等几个型号，其单盘外圈的连续读取速度也不过是9xMB/s。而且目前为止我还没听说哪块硬盘单盘外圈能超过100MB/s的了，更不用说平均速度，大约都在7xMB/s左右（Maxtor的平均速度可以超过80MB/s，但那是因为内圈速度快，可能是其惯用的屏蔽内圈磁道的效果）。后面还跟了一个0+1的raid系统数据，看得我是直流口水啊，只可惜兜里没米～
不过“我思故我在”朋友的数据却漏了一个很重要的环节：对比数据。
众所周知，由于硬件平台环境千差万别，没有同一平台下的对比数据，是什么也说明不了的。那么我就给出一下在我现在用的系统上的对比数据吧：
我的硬盘是fujitsu的MAP3147NC+29160，它是纯数据盘，操作系统包括虚拟内存或者swap都不在这个硬盘上。
在Win2003上用SiSoftware Sandra测试NTFS格式的F盘（即sda1）的数据如下：
（SiSoftware Sandra给出的数据和结果相当的多，我只截取了关键的一段）
Benchmark Breakdown
Buffered Read : 112 MB/s
Sequential Read : 65 MB/s
Random Read : 46 MB/s
Buffered Write : 19 MB/s
Sequential Write : 62 MB/s
Random Write : 46 MB/s
Average Access Time : 6 ms (estimated)
在Ubuntu上用“hdparm -tT /dev/sda”测试EXT3格式的sda2的数据（三次）如下：
/dev/sda:
Timing cached reads: 3892 MB in 2.00 seconds = 1946.66 MB/sec
Timing buffered disk reads: 204 MB in 3.02 seconds = 67.53 MB/sec
/dev/sda:
Timing cached reads: 3980 MB in 2.00 seconds = 1990.99 MB/sec
Timing buffered disk reads: 204 MB in 3.02 seconds = 67.54 MB/sec
/dev/sda:
Timing cached reads: 3852 MB in 2.00 seconds = 1926.65 MB/sec
Timing buffered disk reads: 204 MB in 3.03 seconds = 67.40 MB/sec
三次的数据非常接近，而且在第二、第三次测试之间我还重启了一次系统。但是和“我思故我在”朋友贴出的第一组数据：
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 3212 MB in 2.00 seconds = 1606.24 MB/sec
Timing buffered disk reads: 380 MB in 3.01 seconds = 126.35 MB/sec
中“Timing cached reads”项相差不大，还略高于它，但是“Timing buffered disk reads”却远远不及。其中的原因不太清楚，希望“我思故我在”能补充一下测试的软硬件环境？
由于我同时测试WD3000JB（这个硬盘才是测试时的系统盘）的数据如下：
/dev/hda:
Timing cached reads: 3852 MB in 2.00 seconds = 1927.44 MB/sec
Timing buffered disk reads: 176 MB in 3.03 seconds = 58.09 MB/sec
从网上大量的数据都可以反映出来，这两款硬盘的实际读取速度是相近的（毕竟MAP是三四年前的产品了），所以我暂且认为我的数据是没有问题的。
虽然在EXT3下的测试数据和“我思故我在”朋友贴出的数据有点不同，但是作为对比测试数据，同时也基于上面我给出的解释，所以我还是应该采信我自己系统上的数据：EXT3上的“buffered disk reads”才67.53 MB/sec，而NTFS分区的“Buffered Read”是112 MB/s。另外，需要指出的是，那个测试用的NTFS分区在测试完之后，用自带的磁盘碎片检测工具进行分析，结果是“推荐进行磁盘碎片整理”的。当然，我从很多年前，就对这个建议嗤之以鼻的了。
还有，我相当怀疑那个“1946.66 MB/sec”能否作为一项比较的数据，我的SCSI卡才160M的总线带宽，而且还接在32bit的PCI插槽上，理论带宽只有133MB/s，可能有 1946.66 MB/sec的测试结果吗？而且在man中看到hdparm的测试选项太少，而且非常的不专业。不过Linux上我还不知道有类似Windows下SiSoftware Sandra和HD tach那样专业的磁盘速度测试软件，所以只能暂时用这个替代一下，如果有谁有更好的软件，我倒是愿意继续做测试一下，毕竟在我实际工作中，感觉EXT3分区的性能不至于差这么多。
我的机上目前还没有reiserfs分区，也没有装NTFS3G，所以暂时无法做类似的测试。
至于两位一再强调的NTFS文件碎片多，或者碎片多了之后影响性能之类的，我在上面的文章已经说过了：那是因为对“碎片”的定义不同而导致的。事实上MS对“碎片”的定义依然沿用老式的FAT时代的标准，所以会发现磁盘碎片非常容易产生。但是我自己做过的测试表明：一个连续做了FTP一个月，磁盘碎片分析完全是红色的分区进行读取测试，比碎片整理后同一分区的读取测试仅仅慢了不到2％（具体数字忘了，记得是刚过1%），这个测试结果让我最终抛弃了磁盘碎片整理这个无聊的举动。事实上在公司的局域网里，有几台Win的文件服务器，照样用的是NTFS分区，从来就没人整理过什么磁盘碎片。
“我思故我在” 朋友说到的Windows下虚拟内存文件会干扰系统盘的运行，这当然是正确的。但是，正如Linux可以单独分一个swap分区，单独为/tmp或者/home分一个分区一样，Windows也可以单独为虚拟内存文件指定一个非系统分区，临时目录或者桌面路径等也可以通过修改注册表来转移。在WinXP下的PowerToys甚至可以不用通过注册表，就可以搞定这些操作，只是可惜在Win2003下需要自己动手改注册表。
另外，说多几句：我一直认为，人们通常以为Windows服务器性能不佳或者安全性不够，不是因为Windows服务器版不行，而是人们太过于自以为是，把Windows桌面版的习惯统统“移植”到了服务器版上才导致问题的出现。事实上，一个经过细心的良好的配置管理的Windows服务器的性能和安全性，绝对比默认设置下Linux服务器版要高。人们愿意花大量的精力去学习Linux的系统操作和管理，为什么就不愿意花同样的精力去学习Windows服务器版的操作和管理呢？
对于“poet”朋友说的：“作者自己非常坦率的表明：虽然NTFS3G的驱动比Windows的NTFS驱动快了许多倍，但是仍然与reiserfs有差距”。
我相当怀疑这个说法：如果MS自家推出的NTFS格式，自家系统的读写效率还不如别人破解出来的NTFS-3G高的话，那么盖茨大叔应该去跳楼了。呵呵。
所以，我个人认为，如果不是这个作者以偏概全的话，那么就只能说明他在读写NTFS分区时，要么有bug，要么忽略了一些操作，例如（可能是，没有具体研究过）安全性检查，完整性校验等等。不过这种也只是我个人的怀疑，毕竟谁也没办法看到Windows自家读写NTFS分区的代码，信不信就自己琢磨吧。
至于说到NTFS分区速度优化的问题，老实说，从最简单的原理都可以知道：越简单的系统，其性能越高。所以，NTFS怎么又优化速度，也比不上FAT的速度是理所当然的。正如我所说的：一切都在于权衡和取舍。无论是性能上还是安全上，无论是效率上还是消耗上，都是如此。
既然两位都拿出了数据，那么我也就顺着两位的要求拿出点数据来看看，NTFS究竟是不是比EXT3慢吧：
“我思故我在”朋友贴出了一堆网友提供的数据，看到我如临大敌啊。熟悉硬盘的都知道，最快的15K盘应该不外乎ST的15K.4、fujitsu的MAU、Maxtor的Atlas 15K II等几个型号，其单盘外圈的连续读取速度也不过是9xMB/s。而且目前为止我还没听说哪块硬盘单盘外圈能超过100MB/s的了，更不用说平均速度，大约都在7xMB/s左右（Maxtor的平均速度可以超过80MB/s，但那是因为内圈速度快，可能是其惯用的屏蔽内圈磁道的效果）。后面还跟了一个0+1的raid系统数据，看得我是直流口水啊，只可惜兜里没米～
不过“我思故我在”朋友的数据却漏了一个很重要的环节：对比数据。
众所周知，由于硬件平台环境千差万别，没有同一平台下的对比数据，是什么也说明不了的。那么我就给出一下在我现在用的系统上的对比数据吧：
我的硬盘是fujitsu的MAP3147NC+29160，它是纯数据盘，操作系统包括虚拟内存或者swap都不在这个硬盘上。
在Win2003上用SiSoftware Sandra测试NTFS格式的F盘（即sda1）的数据如下：
（SiSoftware Sandra给出的数据和结果相当的多，我只截取了关键的一段）
Benchmark Breakdown
Buffered Read : 112 MB/s
Sequential Read : 65 MB/s
Random Read : 46 MB/s
Buffered Write : 19 MB/s
Sequential Write : 62 MB/s
Random Write : 46 MB/s
Average Access Time : 6 ms (estimated)
在Ubuntu上用“hdparm -tT /dev/sda”测试EXT3格式的sda2的数据（三次）如下：
/dev/sda:
Timing cached reads: 3892 MB in 2.00 seconds = 1946.66 MB/sec
Timing buffered disk reads: 204 MB in 3.02 seconds = 67.53 MB/sec
/dev/sda:
Timing cached reads: 3980 MB in 2.00 seconds = 1990.99 MB/sec
Timing buffered disk reads: 204 MB in 3.02 seconds = 67.54 MB/sec
/dev/sda:
Timing cached reads: 3852 MB in 2.00 seconds = 1926.65 MB/sec
Timing buffered disk reads: 204 MB in 3.03 seconds = 67.40 MB/sec
三次的数据非常接近，而且在第二、第三次测试之间我还重启了一次系统。但是和“我思故我在”朋友贴出的第一组数据：
# hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 3212 MB in 2.00 seconds = 1606.24 MB/sec
Timing buffered disk reads: 380 MB in 3.01 seconds = 126.35 MB/sec
中“Timing cached reads”项相差不大，还略高于它，但是“Timing buffered disk reads”却远远不及。其中的原因不太清楚，希望“我思故我在”能补充一下测试的软硬件环境？
由于我同时测试WD3000JB（这个硬盘才是测试时的系统盘）的数据如下：
/dev/hda:
Timing cached reads: 3852 MB in 2.00 seconds = 1927.44 MB/sec
Timing buffered disk reads: 176 MB in 3.03 seconds = 58.09 MB/sec
从网上大量的数据都可以反映出来，这两款硬盘的实际读取速度是相近的（毕竟MAP是三四年前的产品了），所以我暂且认为我的数据是没有问题的。
虽然在EXT3下的测试数据和“我思故我在”朋友贴出的数据有点不同，但是作为对比测试数据，同时也基于上面我给出的解释，所以我还是应该采信我自己系统上的数据：EXT3上的“buffered disk reads”才67.53 MB/sec，而NTFS分区的“Buffered Read”是112 MB/s。另外，需要指出的是，那个测试用的NTFS分区在测试完之后，用自带的磁盘碎片检测工具进行分析，结果是“推荐进行磁盘碎片整理”的。当然，我从很多年前，就对这个建议嗤之以鼻的了。
还有，我相当怀疑那个“1946.66 MB/sec”能否作为一项比较的数据，我的SCSI卡才160M的总线带宽，而且还接在32bit的PCI插槽上，理论带宽只有133MB/s，可能有 1946.66 MB/sec的测试结果吗？而且在man中看到hdparm的测试选项太少，而且非常的不专业。不过Linux上我还不知道有类似Windows下SiSoftware Sandra和HD tach那样专业的磁盘速度测试软件，所以只能暂时用这个替代一下，如果有谁有更好的软件，我倒是愿意继续做测试一下，毕竟在我实际工作中，感觉EXT3分区的性能不至于差这么多。
我的机上目前还没有reiserfs分区，也没有装NTFS3G，所以暂时无法做类似的测试。
至于两位一再强调的NTFS文件碎片多，或者碎片多了之后影响性能之类的，我在上面的文章已经说过了：那是因为对“碎片”的定义不同而导致的。事实上MS对“碎片”的定义依然沿用老式的FAT时代的标准，所以会发现磁盘碎片非常容易产生。但是我自己做过的测试表明：一个连续做了FTP一个月，磁盘碎片分析完全是红色的分区进行读取测试，比碎片整理后同一分区的读取测试仅仅慢了不到2％（具体数字忘了，记得是刚过1%），这个测试结果让我最终抛弃了磁盘碎片整理这个无聊的举动。事实上在公司的局域网里，有几台Win的文件服务器，照样用的是NTFS分区，从来就没人整理过什么磁盘碎片。
“我思故我在” 朋友说到的Windows下虚拟内存文件会干扰系统盘的运行，这当然是正确的。但是，正如Linux可以单独分一个swap分区，单独为/tmp或者/home分一个分区一样，Windows也可以单独为虚拟内存文件指定一个非系统分区，临时目录或者桌面路径等也可以通过修改注册表来转移。在WinXP下的PowerToys甚至可以不用通过注册表，就可以搞定这些操作，只是可惜在Win2003下需要自己动手改注册表。
另外，说多几句：我一直认为，人们通常以为Windows服务器性能不佳或者安全性不够，不是因为Windows服务器版不行，而是人们太过于自以为是，把Windows桌面版的习惯统统“移植”到了服务器版上才导致问题的出现。事实上，一个经过细心的良好的配置管理的Windows服务器的性能和安全性，绝对比默认设置下Linux服务器版要高。人们愿意花大量的精力去学习Linux的系统操作和管理，为什么就不愿意花同样的精力去学习Windows服务器版的操作和管理呢？
对于“poet”朋友说的：“作者自己非常坦率的表明：虽然NTFS3G的驱动比Windows的NTFS驱动快了许多倍，但是仍然与reiserfs有差距”。
我相当怀疑这个说法：如果MS自家推出的NTFS格式，自家系统的读写效率还不如别人破解出来的NTFS-3G高的话，那么盖茨大叔应该去跳楼了。呵呵。
所以，我个人认为，如果不是这个作者以偏概全的话，那么就只能说明他在读写NTFS分区时，要么有bug，要么忽略了一些操作，例如（可能是，没有具体研究过）安全性检查，完整性校验等等。不过这种也只是我个人的怀疑，毕竟谁也没办法看到Windows自家读写NTFS分区的代码，信不信就自己琢磨吧。
至于说到NTFS分区速度优化的问题，老实说，从最简单的原理都可以知道：越简单的系统，其性能越高。所以，NTFS怎么又优化速度，也比不上FAT的速度是理所当然的。正如我所说的：一切都在于权衡和取舍。无论是性能上还是安全上，无论是效率上还是消耗上，都是如此。
作者: yhz 发布时间: 2007-02-25
虽然不是完全明白，支持一下，感谢lz
作者: csdh79483 发布时间: 2007-02-26