随着文件系统的扩容，碎片整理愈发显得重要。不久之前，我们工作的环境还是很小的2GB文件系统，或者是容量更小的文件。当厂家能够提供的文件系统超过2TB时，文件的大小仍然局限于2GB。
随着我们即将进入21世纪第一个10年的中期，大文件系统常常达到50-100TB的容量，在今后几年内，一些场合需要达到500TB到数PB的容量。当然，这要等技术变革之后方可实现，其中一个革新就是用基于对象的存储设备(OSD) 代替SCSI标准。但要等到终端到终端的OSD产品成为主流，尚须时日。
关于文件系统的碎片，以及文件系统的不断扩容，我的看法如下：
随着文件系统容量的增大，文件系统的碎片也在增长，假如文件系统的容量持续增长，终端用户即便尚未认识到这一问题的存在，也会感觉到系统的性能有所下降。
要解决这个问题，需要了解下面若干知识：
什么文件系统碎片？
我的文件系统会出现这个现象吗？
如果问题能够解决，怎么进行？
什么是文件系统碎片？
简单地说，文件系统碎片是指在存储设备中，对任何数据的任何访问按计划应该是顺序进行的，但是实际并不是顺序访问的。这只是个粗略的定义，它涉及到文件系统内的数据存取方面的若干问题。
背景
在我们目前所处的光纤通道/SCSI世界中，硬盘或者RAID LUN(Logical Unit Number 逻辑单元号)是简单的块设备，这就意味着LUN的第一个块号为0，最后一个块号的数值小于 4,294,967,296，即以每块512字节，共计2TB。注意 2TB是目前所能创建的最大的SCSI LUN的极限了，该格式化硬盘扇区为512字节。
几乎所有文件系统在用于轮询分配的LUN或者LUN组中，都采用首次适配算法来分配数据空间，首次适配意味着一旦找到文件系统中的第一个符合要求的空闲区，就把该数据放到其中。
记住，文件系统同存储设备通信，在存储设备中，所有的分配单位都是512字节，即便寻址小于512字节或者不是521字节的整数倍的时侯，文件系统的寻址仍以512字节为单位。
文件系统元数据是另外一个概念，关于元数据有三个部分需要强调：
文件系统索引节点(inode)
当文件大小超过索引节点指定的那一个存储单元容量时，分配的其它单元的位置.
内在的文件系统，常称之为超级数据块(superblock)。在一些文件系统中，如果文件系统容量增大到一定限度，超级数据块也可以被分割成文件碎片。
提示一：关于索引结点(inode).unix/linux系统为每个文件提供一个称为索引节点的号码inode,用于唯一的标志一个文件.可以将inode简单理解成一个指针，它永远指向本文件的具体存储位置。系统是通过索引节点(而不是文件名)来定位每一个文件的物理存储头区域.
提示二：关于超级数据块（Superblock）个文件系统总是由它的superblock来定义的，所以创建文件系统的同时superblock也被创建。它包含了文件系统的一些基本参数，例如文件系统中的数据块(data blocks)数和最大文件数等等。因为superblock包含了一些临界数据，以便于进行灾难性的恢复。所以缺省的superblock总是固定地位于文件系统所在磁盘分区的开始处。Superblock还有一个备份叫做冗余superblock，就像DOS中的文件分配表的副本。冗余superblock和缺省的superblock不一样，它被分散地保存在磁盘分区上。
对于文件碎片来说，元数据是个重要而且通常被忽视的领域，对于支持HSM（层次化存储管理）的文件系统来说，这一个问题的确存在，因为这些文件系统中通常拥有数千万甚至数亿个文件。
我的文件系统出现这个问题吗？
你的文件系统是否有碎片？确实有，但这问题不大。真正需要提出的不是是否有，而是是否造成后果？如果应用程序需要I／O带宽有限，那么你的文件系统即便有碎片，你仍有足够的带宽来满足你的I/O需求。这一般指的是在架构或者工程中的峰值。
此时，如果你的峰值性能基于一个完全碎片化的文件系统，并不会出现问题。经常发生的却是人们为了往往购买了过多的带宽来运行应用程序。其中的一个原因我认为就是对付文件碎片。
如果在现在的15K RPM转速的硬盘上顺序分配数据，并且回读时，在整个设备上进行读的平均速度是每秒 50 MB，但是，如果数据并不是顺序读出来的，这个速度是多少？例如，考虑一个完全随机读8KB的应用程序，设备的平均寻道时间加上平均旋转时间延迟为0.007秒。
1/ (8192/ (1024 * 1024 * 50) + 0.007))
块大小
每秒50 MB传输率
平均寻道加延迟时间
此时，每秒读出数据仅为140个8 KB，即 1.09 MB/sec的传输率，仅仅是顺序I/O平均值的1/45，当然，这是我们在系统中采用了多个200 MB/sec 的通道以及大量硬盘的原因。几乎所有的应用程序都无法满负荷地用足多个200 MB/sec 通道来读／写数据，但是这的确需要，因为要对付不少应用程序所产生的小容量的随机的I/O操作。
数据碎片
随着文件系统的数据的容量增大，随着文件的创建和删除，信息的搜索越来越耗时，对于小文件来说，这不成问题，因为小文件通常在一个文件分配块中也装得下。而大文件就成了大问题。
什么是大文件，这取决于文件系统中的空间分配的大小，如果文件系统中最小的分配单位是25MB，而你的文件的平均大小为100 MB，那么我认为这是个小文件，而不是大文件，因为你需要调用分配空间子程序至多4 次。
另外一方面，如果分配单位是 4 KB，这样调用分配空间子程序的次数就多了，那么同样的100 M文件就是一个大文件了。每当你返回调用分配子程序，来查找空闲空间时，还会同其他进程竞争空间的分配。
记住，空间分配通常采用的是首次适配算法，所以所获得的空间取决于已经分配了空间的文件，以及其他请求空闲空间的进程。这就回到了我最初的断言：多数应用程序并不是满负荷地用到完全的文件系统的带宽，同时多数架构配有足够的硬盘和通道传输速度（IOPS）以便满足多数应用程序的需要。
元数据碎片
只是到最近，元数据的碎片方成为一个大问题。随着文件系统的增大，文件系统的元数据所需要的空间也随着加大，进而引发性能问题。为了元数据的性能，在架构上所做的大改进可以追溯到上个世纪八十年代克雷计算机公司的研究人员所做的工作，那就是把数据设备同元数据设备分开。
从那时起，在大型环境中所使用的大多数文件系统能够分隔（或者具有分隔这一选项）数据和元数据，而且多数能够记录操作的文件系统也能够把日志存放到一个单独的设备中。
对于我所了解的多数文件系统，同对数据的分配一样，对于元数据的分配也是顺序进行的。如果你创建了一个文件，之后又创建了一个，你会使用顺序存储的文件索引节点。如果你删除一个文件，该文件所对应的索引节点所对应的空间就可再次被分配出去，仍然采用首次适配算法。在不少的目录中进行文件添加和删除操作，如果这个工作反复进行，最终对元数据的分配就成为随机的了。
运行诸如 ls -l这样的命令之后，即需要按照字母顺序读出文件的元数据，可能包含一个小容量的读操作（通常为512字节），有一个平均寻道和平均延迟事件，以及另外一个读操作。基本上，我们仅能每秒进行142次读。这同以前我们进行的8KB的 I／O操作毫无二致。当然，这意味着寻道和延迟时间远比数据的传输时间要高。所以，这种场合中，性能将会很糟。
当然，这纯粹是从纯理论角度分析的，因为还存在不少其他因素。例如RAID缓存，RAID 提前读，inode提前读，inode分配空间的大小，inode缓存等。另外一方面，存在其他影响性能的因素，例如到终端的延迟和竞争。据我所知的一个站点，其ls -l命令在客户获得元数据前就花费了大约400秒。这主要是为每个文件和每个目录逐一重写索引节点，在重写完毕之后， ls -l命令仅仅花费了 25秒。
结论
诸如NTFS这样的有碎片整理程序的文件系统，能够对数据空间进行整理，有时也包括元数据空间的碎片的整理。注意我没有提到元数据，而仅仅提到元数据空间。因碎片而造成的性能下降一般不是立即发生的，而是随着时间逐渐显露出来的，这就给诊断带来了难度。通常，当文件系统的碎片情况很严重时，文件系统的性能已经处于很差的状态。
通常一些支持层次化存储管理（HSM）的文件系统，支持传输和恢复文件系统元数据，当恢复元数据时，一般是以更为优化的方式进行的，但这却很耗时。元数据碎片是一个新问题，仅仅在最近才浮出水面。要等文件系统开发商彻底解决该问题，尚需时日。
文件系统在最近几年来的增速惊人。不久之前（1996），5TB的文件系统已经很大了，如今使用的是70 TB的文件系统。这已经远超出摩尔定律的曲线。重要的是要认识到数据和元数据均存在碎片问题，需要依靠工具和厂商来解决这些问题。
