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