（计算机应用技术专业论文）minifs文件系统的设计与实现.pdf

摘要 随着互联网络的迅猛发展，人们对网络存储的需求越来越大。但是现有的文 件系统在存储小文件时，存在浪费空间、性能低下等缺陷。它们已经不能很好地 满足日益增长的集中而又分布的数据存储需求。因此，本文提出了m i n i f s 文件 系统。m i n i f s 文件系统针对小文件的读写进行特别优化。m i n i f s 改变了文件存 储结构，并为存储的文件建立b t r e e 索引，同时在客户端和服务器端设置缓存。 此外m i n i f s 利用其原子操作的特性，创建了增量日志系统。m i n i f s 在实现过程 中使用线程池技术，以满足高度并发访问的需求。 本文首先分析课题背景，提出海量数据存储的需求，接着对当前的文件系统 进行了细致的分析，从存储结构、索引方式等方面说明了它们的缺点。然后从改 进这些不足出发，阐述了m i n i f s 的设计考虑，并给出了m i n i f s 的系统架构。随 后，本文详细叙述了m i n i f s 的设计实现。在设计实现的描述中，从m i i l i f s 的业 务逻辑引出，描述了m i n i f s 的存储、索引、空间管理、缓存、日志系统等关键 模块的设计思想与实现方法，并就m i n i f s 实现中的几个难点进行了细致的描述。 本文还根据几大衡量指标，对m i n i f s 文件系统和现有的e x t 3 文件系统进行了性 能对比测试。测试结果表明，m i l l i f s 在多方面优于现有文件系统。最后，本文 指出了m i n i f s 存在的不足，概述了文件系统当前国内外的研究现状，并指出了 m i n i f s 今后的发展方向。 m i n i f s 是一个为存储海量( t b ) 小文件( i n o d e 的查询，而是直接通过 相对位移来定位i n o d e ，并利用i n o d e 找到这个小文件占用的数据块。这 会提升文件定位的速度。 尽可能保证了同一个数据文件保存在相邻的区域。也就是说，对于一个 文件的读取或写入，磁盘只需要顺序读取或写入，而不需要频繁地寻道、 旋转定位，这将极大提高读写效率。 2 1 3m i n i f s 的磁盘存储结构 图2 1m i n i f s 磁盘存储结构示意图 如图2 - 1 所示，在每一个b l o c k 中包含了以下信息： b l o c k l n d e x ：当前块的索引信息； 1 2 第二章m i n i f s 设计思路 c h e c k s u m ：当前块的校验和； a d d d a t e ：该数据文件添加的日期； f i l e d a t a b u f f e r ：数据文件对应的字节流。包含了文件名、文件长度、文 件数据等。 详情请参见4 2 节。 2 2 文件索引方式 为了提高文件的读取速率，m i n i f s 需要为所有文件建立一个索引。通常索引 的方式为：h a s h t a b l e 和b t r e e 。h a s h t a b l e 如果需要取得较好的性能o ( 1 ) ，就需 要较多b u c k e t ，从而加大空间的开销。而h a s h t a b l e 的特性要求其必须整个放置 在内存中，因此受限于内存空间。而b t r e e 有较好的空间利用率，但是其性能只 能达到o ( n l o g n ) 。 从时间和空间进行权衡，m i n i f s 采用了最普遍的b t r e e 索引。同时尽可能的 压缩每个索引节点占用的空间，也增大所能容纳的文件数。 此外，为了保证m i n i f s 在支持并发访问的同时保证数据的正确性，m i n i f s 需要对索引添加读写锁。参见4 5 2 节。 2 3 可用空间管理 m i n i f s 对资源的管理体现在其对可用块的管理。用户添加或者删除一个数据 文件，都涉及到可用块的修改。能否在并发情形下，快速可靠的分配可用块，对 m i n i f s 有着非常重要的意义。 为了实豌的简单，m i n i f s 对每种大小的可用块都建立相应的链表索引。 类似于文件索引，出于线程安全性考虑，m i n i f s 对可用块索引增加读写锁。 2 4 日志恢复系统 一个好的文件系统需要一个快速可靠的日志系统。日志系统的主要任务是维 持内存中保存的信息，与磁盘上实际文件的信息是一致的。一旦内存中的信息丢 失，日志系统能够通过某种方法，快速重建内存中的信息，以恢复一致性。 m i i l i f s 需要在内存中存储文件索引、文件描述信息、可用块索引。因此，如 果没有合适的日志系统，m i n i f s 将会变得十分脆弱。因为一旦系统突然崩溃， 第二章m i n i f s 设计思路 m i n i f s 就没有机会将这些内存中的信息保存到磁盘上。 这就导致在下一次m i n i f s 服务器端启动时，需要重新扫描全部的数据文件 以检查现有文件的一致性【1 2 1 。一旦m i n i f s 存储的数据文件容量达到t 级别时， 扫描所花费的时间将变得不可接受。因为，现有硬盘的顺序读的平均速率大致为： 3 0 6 0 m b s ，那么即使m i n i f s 什么都不做，完成一个2 g 文件的扫描需要 2 1 0 2 4 4 5 = 4 6 s 。那么当数据为t 级别时，花费的时间将达到4 6 * 5 1 2 3 6 0 0 = 8 h 。 更为致命的是，在这8 小时里，m i n i f s 不能对外提供任何服务。 如果简单的进行内存中信息的定时同步，由于这些信息的大小在g 级别，同 步时间的开销将会非常大( 2 0 s 左右) ，在同步期间，m i n i f s 的正常服务的性能会 受到较大的影响。 由于底层r a i d 硬件系统的支持，m i n i f s 只要考虑以下情形的处理。 硬盘上发生了实质变化，如：存储了一个数据文件、删除了一个数据文件或 者增加了一个大文件，但是相应的索引文件并没有记载其相关信息。 因此，m i n i f s 需要一个可靠、快速的日志恢复系统。为此，考虑使用增量方 式，来实现m i n i f s 的日志系统。 增量日志模式，对m i n i f s 提出了很高的要求。首先m i n i f s 执行的必须是原 子操作，同时m i n i f s 必须定时同步相关信息。 m i n i f s 定义了3 个原子操作，分别是：a d d 、d e l 和c r e a t e f i l e 。 a d d ，表示：m i n i f s 存储了一个文件到磁盘上： d e l ，表示：m i n i f s 从磁盘上删除了一个指定文件； c r e a t e f i l e ，表示：m i n i f s 添加了一个1 g b 的大数据文件。 、 m i n i f s 定时同步是指m i n i f s 定时地同步内存中的索引信息到磁盘文件。同 步时需要占用大量的磁盘i o 。这时，会影响m i n i f s 的正常服务。为此，需要让 m i n i f s 的内存索引信息尽可能的小，以减小同步的时问。 2 5 系统吞吐量优化 系统吞吐率的优化，在4 1 节提到了一部分，主要是通过优化文件的存储分 布，减少文件读取写入时磁头寻道、旋转的延迟，来提高读写的速率。 但是，仅仅依赖于4 1 节的考虑是不够的。m i n i f s 还需要考虑使用缓存和并 发访问的支持，来进一步提升m i n i f s 的吞吐率。 2 5 1m i n i f s 缓存的使用 在1 4 节提到，m i n i f s 文件系统分为客户端和服务器端。要想利用客户端的 1 4 第二章m i n i f s 设计思路 资源来降低服务器端的负荷和减少网络间不必要的数据传输，一个可行的方案就 是在客户端添加一个缓存。当然，为了减少服务器端不必要的读写操作，也需要 增加缓存。 客户端的缓存，主要是用来减少不必要的文件传输和服务器端不必要的磁盘 操作。客户端的缓存需要保存其在最近一段时问内g e t 的文件内容及相关信息。 当之后处理同一文件的g e t 请求时，客户端询问服务器端客户端缓存中的文件信 息是否有效，如果有效，则客户端将直接把其缓存中的文件信息返回给用户，反 之客户端等待服务器端发送回新的文件信息。 同时m i n i f s 在服务器端也需要放置缓存。服务器端的缓存一方面是为了减 少磁盘的读写操作，另外一方面，便于m i n i f s 采用批量读写文件的方式。批量 读写文件的方式是指多个同类磁盘操作一次完成，这将进一步提高m i n i f s 的文 件读写性能。 2 5 2m i n i f s 并发访问支持 m i n i f s 的服务器端需要和成百上千个m i n i f s 的客户端进行交互。如果 m i n i f s 采用单进程、单线程的线性处理方式来处理客户端的请求，其效率是可 想而知的。 对并发访问的支持，需要在两部分考虑。一部分是在网络模块，另外一部分 则是在逻辑处理模块。 网络模块的并发支持，主要是在a c c e p t 阶段。一般的做法就是不断地a c c e p 连接，然后处理该连接。但是，如果这个连接当时的网络状况不够理想，导致中 间有数据迟迟不能到达，那么就会影响别的客户端的请求。为此，需要采用高效 的轮询机制，同时结合线程池和生产消费队列来提高并发处理能力。 在逻辑处理模块提供并发支持，主要是基于以下统计：过去一个月的请求数 据的显示，m i n i f s 客户端的请求分布大致为：g e t ( 7 0 ) 、p u t ( 2 5 1 、d e l ( 5 ) 。 在正常的处理中，这三者的时间开销比例大致为：3 ：6 ：1 。因此，如果不提供 并发支持，那么对g e t 和d e l 的响应将会变得较慢。而且，p u t 是一个i o 密集型 的操作，当它进行时，c p u 是闲置的，此时如果能够充分利用c p u 完成一些计 算密集型的任务，比如查找索引，将大大提高m i n i f s 的总体响应速度。同样， m i n i f s 需要考虑使用线程池和生产消费队列的模型完成逻辑模块的并发支持。 由于m i n i f s 涉及到大量的并发操作，因此，如何同步各个线程，就显得十 分重要。如果同步不好，轻则多线程起不到明显的作用，甚至比单一线程还差； 重则影响m i n i f s 的正确性。比如：两个线程往同一个可用块中写入不同的文件， 这就会导致在系统不知情的状态下前一次写入文件丢失了。这就可能使得文件中 第二章m i n i f s 设计思路 存储的信息不正确。 线程的同步，主要是通过使用各类锁。因此，锁的数量和锁放置的位置，是 需要认真考虑的。如果添加的锁过多，m i n i f s 不能很好的支持并发访问，因为 频繁的开锁解锁，浪费了大量的资源；但是如果锁过少，且放置的地方不正确， 则可能破坏m i n i f s 的正确性。 m i n i f s 通过在文件索引和可用块索引，分别添加一个读写锁，很好的解决了 上述问题，在速率和正确性上取得最优。 2 6 哈希( h a s h ) 算法的选择 由于m i n i f s 的每一个操作都需要应用到h a s h m a p ，以提高查找效率。因此， 能否选择出一个合适的h a s h 算法，对整个系统的性能和可靠性有着至关重要的 意义。 衡量一个h a s h 算法是有合适，主要从以下几个方面考虑： 哈希生成的h a s h v a l u e 分布均衡程度。哈希值分布是否均与，直接关系 到文件索引b t r e e 能否以最小的代价来保证树的平衡属性。 哈希的速度。如果哈希的速度不够理想，由于其操作的频繁，并且这些 操作也往往是关键步骤，因此会给m i n i f s 的性能带来毁灭性的影响； 哈希的冲突概率。所谓“冲突，就是指两个不同的字符串经过哈希之后， 得到相同的哈希值。如果这个概率存在，意味着m i n i f s 系统中存储的文 件，都有可能不是用户希望的文件，哪怕这个概率很小。 哈希的一致性。所谓“一致性”，指的是：相同字符串经过哈希之后，永 远得到相同的哈希值。 2 7 数据正确性 作为一个文件服务器系统，最重要的是保证存储的文件的正确性。通俗地说， 就是需要确保文件系统存放的文件与用户提交的文件是一样的，同时保证用户再 次读取得到的也与其提交的一致。 m i n i f s 主要从两个方面来保证数据的正确性。 m i n i f s 不改变用户提交的文件信息。当m i n i f s 在读取用户提交的b u f f e r 后，直接将b u f f e r 中的信息复制到预分配好的空间中，然后再在该空间 的头部，添加其他元数据，如文件写入日期。 m i n i f s 对每一份文件在写入硬盘前，进行校验和计算。同时，在读取每 1 6 第二章m i n i f s 设计思路 一份文件后，进行校验和检验。如果校验和检验出错，则出错信息给用 户，同时在系统中删除该出错文件。 2 8 系统可靠性 m m i f s 需要考虑在某些意外情况下，系统的可靠性。 首先，m i n i f s 采用r a i d 阵列提高信息的冗余，保证信息的可靠性。 其次，m i n i f s 有监控模块，当m i n i f s 服务器不再发出心跳信号时，m i n i f s 监控模块将自动重启m i n i f s 服务器。 当然，在m i n i f s 的实现过程中，需要尽可能的处理异常情况，如某个大文 件无法打开、某个数据文件存储区域坏损等情形。 第三章m i n i f s 系统架构 第三章m i n i f s 系统架构 m i n i f s 整体分为客户端和服务器端两部分。其中，客户端提供接口给上层应 用( 以下简称用户) ，服务器端则负责处理客户端发来的文件处理请求。采用该c s 架构，不仅在目前阶段便于部署，给用户提供定义良好的接口，同时提供了极高 的灵活性和扩展性，而且为下一步将m i n i f s 扩展为分布式文件存储系统奠定了 良好的基础。 3 1m i n i f s 系统架构 本节从m i n i f s 总体架构，m i n i f s 客户端架构，m i n i f s 服务器端架构这三个 部分，详细地阐述了m i n i f s 的系统架构。 3 1 1m i n i f s 总体架构， e x t 3 文件系统e x t 3 文件系统 图3 1m i n i f