邮件过滤系统专用文件系统的设计与实现

分类号密级UDC学位论文邮件过滤系统专用文件系统的设计与实现（题名和副题名）注1注明《国际十进分类法UDC》的类号独创性声明本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。据我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表或撰写过的研究成果，也不包含为获得电子科技大学或其它教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并表示谢意。签名：日期：年月日关于论文使用授权的说明本学位论文作者完全了解电子科技大学有关保留、使用学位论文的规定，有权保留并向国家有关部门或机构送交论文的复印件和磁盘，允许论文被查阅和借阅。本人授权电子科技大学可以将学位论文的全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。（保密的学位论文在解密后应遵守此规定）签名：导师签名：日期：年月日摘要“邮件过滤系统专用文件系统”是信息产业部“电子发展基金”支持的“网络多功能服务器”项目下的一个子课题。在Internet迅猛发展的今天，电子邮件已经成为信息交换的重要载体，是目前Internet上最常用的功能。在本论文中，首先介绍了邮件服务器的基本理论、工作原理以及linux文件系统原理和特征，总结了各种文件系统在邮件系统应用中的优缺点。通过对垃圾邮件过滤中出现的问题进行分析和比较，最后提出了邮件过滤系统专用文件系统MFFS(MailFilteringFileSystem)的设计框架。在常规linux操作系统上，设计了一个用户级的基于linux原始输入输出的文件系统。本文件系统一方面采用高效的磁盘管理策略，用预先分配的连续磁盘空间作为磁盘队列，消除或减少文件创建、删除等文件管理开销，并减少磁盘碎片；采用延迟聚集写和预先连续读策略，通过一次磁盘搜索旋转定位，尽量读、写更多的有效数据，不仅减少了读、写次数，而且读、写连续的磁盘块也充分利用了磁盘带宽使邮件系统的磁盘性能有了显著提高；另一方面，采用了基于优先级的邮件队列设计方案，在一定程度上解决了常规邮件过滤方法准确率不高，误删邮件的缺点。并且使邮件服务器在垃圾邮件的高强度分布式拒绝服务攻击下具有很好的稳定性。通过对MFFS的功能和性能测试，表明这个文件系统达到了设计目标并具有较高的性能。关键词：电子邮件，文件系统，垃圾邮件过滤，邮件队列AbstractMailFilteringFileSystemisoneofthesub-subjectsofMultipleFunctionServer,anationalprojectsupportedbyElectricDevelopmentFundsofMII(MinistryofInformationIndustry).AstheInternetisgrowingexplosively,e-mailhasbecomeanimportantcarrierforinformationexchangeandoneofthemostfrequentlyusedfunctionsonInternet.Inthispaper,wefirstintroducedthebasictheoriesandworkingprocedureofamailserver,aswellastheprincipleandfeaturesofLinuxfilesystem.Thenwesummarizedtheadvantagesanddisadvantagesofvariousfilesystemsappliedonthemailserver.Throughanalyzingandcomparingproblemsencounteredinjunkmailfiltering,weputforwardsthedesignframeworkfortheMailFilteringFileSystem.BasedontheordinaryLinuxoperatingsystem,wedesignedauser-levelfilesystembuildingonLinux'srawinputandoutput.Thisfilesystemadoptedhighefficientdiskmanagementstrategies,whichutilizesadiskspacetoserveasdiskqueuetoreducefilemanageoverhead,inwhichadjacentmessagesarestoredinadjacentdiskblock.SeveralmessagesarewrittentodiskqueueinaonelargewritebyLazyGatheringWrite.SeveraladjacentmessagesarereadintobufferinaonereadbySequentialGroupingPrefetch.whichimprovedthediskperformanceforthemailserver.Ontheotherhand,italsoadoptedadesignformailqeueuesbasedondifferentpriorities,andtosomeextent,preventedtheincorrectdeletionsappearedinnormalmailserversandimprovedaccuracyformailfiltering.Besides,themailserverusingthisfilesystemshowedhigherstabilityunderstrongdistributedDOSattacks. Throughtests,ithasbeenprovedthatthisfilesystemhasachievedourdesigninggoalandprovideshighperformance.Keywords:ElectricMailSystem，FileSystem，SpamFiltering，MailQueue目录TOC\o"1-3"\h\z摘要 IIIAbstract IV目录 V第一章引言 11.1背景 11.2论文内容组织 2第二章理论基础及相关协议 42.1邮件服务器相关协议 42.1.1几个概念 52.1.2Internet邮件发送和接收协议--SMTP协议 52.1.3Internet邮件提取协议 72.2文件系统 102.2.1Linux文件系统简介 102.2.2虚拟文件系统VFS 112.2.3几种linux下常用文件系统研究 122.3小结 19第三章邮件队列的管理及其磁盘性能分析 203.1常用邮件队列管理方式分析 203.1.1邮件队列的物理磁盘管理方式分析 203.1.2邮件队列的逻辑管理方式分析 233.2磁盘性能分析 243.3邮件队列的优化 253.4小结 26第四章邮件过滤的插入点分析 274.1常规邮件系统过滤的插入点概述 274.1.1MTA过滤 274.1.2MDA过滤 284.1.3MUA过滤 284.2邮件过滤插入点效率分析 294.2.1邮件插入点效率概述 294.2.2基于优先级的策略中邮件过滤插入点分析 304.3小结 31第五章MFFS文件系统设计 325.1设计背景概述 325.2总体设计 345.2.1MFFS接口模块 365.2.2请求队列管理模块 385.2.3缓冲区管理模块 395.2.4邮件队列管理模块 475.2.5磁盘队列管理模块 485.3小结 56第六章MFFS文件系统的实现 576.1MFFS文件系统的模块划分 576.2邮件转发模块的实现 576.2.1主程序流程 586.2.2子线程流程 596.2.3Deliverd服务流程 596.2.4Deliverd主要函数实现分析 606.3邮件接收模块 636.3.1算法及流程 636.3.2函数说明 666.4MFFS接口模块 706.4.1总体结构设计 706.4.2写邮件的接口设计 706.4.3读邮件的接口设计 756.4.4读状态接口设计 766.4.5队列控制接口设计 786.5请求队列管理模块 796.5.1基本功能 796.5.2主要函数实现分析 796.6缓冲区管理模块 816.6.1基本功能 816.6.2主要函数实现分析 816.7邮件队列管理模块 836.7.1基本功能 836.7.2主要数据结构 846.7.3主要函数实现分析 846.8磁盘队列管理模块 846.8.1基本功能 846.8.2主要函数实现分析 856.9小结 87第七章测试及尚待解决的问题 887.1、测试项目 887.1.1、功能测试 887.1.2、性能测试 887.2、功能测试 897.2.1、SMTP服务器 897.3、性能测试 907.3.1、80％负载 917.3.2、100％负载 927.3.3、120％负载 927.3.4、120％负载下，%30垃圾邮件 937.3.5、120％负载下，%50垃圾邮件 947.4、小结 95第八章结论 97参考文献 98致谢 100个人简历 101引言背景随着因特网的不断普及，国内因特网的用户数呈指数级增长。其中电子邮件是Internet所有服务中最基本的服务，超过百分之八十的用户使用电子邮件服务。它为人们的工作、生活、娱乐提供了极大的便利。在充分享受电子邮件带来的便捷、实时和廉价的同时，网络时代的人们也饱尝垃圾邮件带来的烦恼。几乎每个人的信箱都充斥着大量来历不明的邮件，垃圾邮件像瘟疫一样蔓延，污染网络环境，影响网络的正常通信。而在我国，由于成百上千的开放邮件中继服务器被国外不法分子利用，国外许多邮件服务商曾一度封杀了中国邮件服务器的IP地址，致使中国用户蒙受不可估量的损失。垃圾邮件数量的增长速度如此之快的原因在于：第一，垃圾邮件一直被吹捧为是一种最有效却最廉价的广告形式。邮件地址列表很容易买到，也很容易从英特网搜集，特别是为了工作的需要，企业一般都在Web站点列出了员工的电子邮件地址。这使得编辑一个邮件地址数据库变得非常的廉价和容易。然后，再使用一个廉价的邮件软件按数据库中的邮件地址自动发送出去即可，非常简单。其次，传统的控制方法无法有效的过滤垃圾邮件，使得终端用户经常收到来自不同地方的商业广告。垃圾邮件制造者是通过邮件报头欺骗，对邮件主题和内容进行处理以及利用第三方服务器进行转发来达到目的。一个常见的垃圾邮件伪装方法是利用网络中的开放式SMTP服务器进行转发。如果网络中的一台SMTP服务器没有被配置为禁止转发电子邮件，那么它将可能成为被垃圾邮件制造者利用的对象。概括起来说，垃圾邮件是指一切通过非法手段和非正常手段发送的以破环邮件系统网络或者宣传反动，色情的电子邮件的总称。目前，从服务器本身的性能上来说，垃圾邮件的破坏方式有堵塞邮件服务器的出口，大量处理导致邮件服务器拒绝服务。或者利用后台内容过滤数据库的更新不及时、内容过滤的缺陷不断的更换关键字，如果过滤服务器本身的效率较低，就很容易受到破坏。而在垃圾邮件的处理中，普遍存在着过滤效率低的问题。其中一个最大的瓶颈就是文件系统的效率较低，通过专用文件系统的设计，将极大的提高系统的吞吐量，为过滤策略的实现，提供了良好的技术支持，从而更有效的遏制垃圾邮件的泛滥。目前，国内还没有厂商研制生产专用的邮件过滤服务器。国外有少量的厂商研制出了邮件过滤服务器，正处于市场推广阶段。这些产品价格昂贵，不适合国内市场。此外，邮件过滤系统是核心网络信息安全产品，对保证我国各行业的通信安全具有重要意义。因此，开发具有自主知识产权的邮件过滤系统将为中国的信息化进程提供坚实的保证，具有重大的社会意义和市场价值。论文内容组织本文从邮件协议，文件系统和物理磁盘读写的原理入手，概述了邮件协议及通用文件系统和物理磁盘的原理，分析常用邮件系统邮件队列的设计方式，以及通用文件系统应用于邮件过滤系统存在的问题。在以上研究的基础上，设计和实现了一个基于linux操作系统的用户级邮件过滤专用文件系统。后续章节的主要内容安排如下：第二章、理论基础及相关协议。主要讲述了邮件服务器的相关协议，常用linux文件系统原理，以及相关的技术。第三章、邮件队列的管理及其磁盘性能分析。主要分析了常用邮件系统的一些邮件队列管理机制，及其在磁盘性能上的优缺点。第四章、常用邮件过滤的插入点分析。主要分析了几种邮件过滤中过滤插入点的性能和效率，以及优缺点。第五章、邮件过滤专用文件系统的设计。主要讲述了邮件过滤专用文件系统设计中的关键技术，相关算法。第六章、邮件过滤专用文件系统的实现。着重讲述了邮件过滤专用文件系统实现中的关键技术、相关算法和主要流程。第七章、测试及尚待考虑的问题。从功能和性能两方面对文件系统进行测试，测试的结果表明系统实现了设计的功能并达到较高的性能。第八章、结论对MFFS文件系统设计的总结和结论。

理论基础及相关协议邮件服务器相关协议为了保证电子邮件系统的正常运行，TCP/IP定义了一组协议，SMTP（简单邮件传输协议）、POP3（邮局协议）和IMAP（Internet消息访问协议）是主要的几个协议。它们的关系如图2-1所示：POP3IMAPRead/WriteMTAMUAMUAMTASMTPPOP3IMAPRead/WriteMailboxMailboxMDAMDASMTPSMTPPOP3IMAPRead/WriteMTAMUAMUAMTASMTPPOP3IMAPRead/WriteMailboxMailboxMDAMDASMTPSMTP图2-1Internet邮件传送示意图电子邮件从发送到接收的过程如下：发送者利用MUA写一封新邮件，通过SMTP协议发送给MTA。如果该邮件是发送给本地用户的，MTA则将其交给MDA，MDA将该邮件投递到本地用户的邮箱中供用户通过MUA读取；如果该邮件是发送给远程用户的，MTA则通过SMTP协议将其发送给另一SMTP服务器的MTA，远程MTA判断该邮件接收者是本地或者远程，作上述同样的操作，直到该邮件存储到最终接收者的用户邮箱中。而接收者则利用MUA通过POP3/IMAP协议读取邮件。SMTP和POP3/IMAP服务器是服务器软件，它们运行在邮件服务器上。SMTP服务器功能包括MTA和MDA，也就是负责接收待发送的邮件，并发送至目标邮件服务器的SMTP服务器，由该SMTP服务器写入用户邮箱。实际上，由于SMTP服务器具有中转（Relay）功能，它并不区分邮件是来自用户机（如普通PC）还是其它SMTP服务器。如果用户想在普通客户机（没有SMTP服务器的普通主机）上接收邮件的话，它需要通过POP3协议或IMAP协议从邮件服务器上获取。不同的是，POP3服务器要求用户将邮件取回本地的普通客户机进行维护，而IMAP则可以在服务器上直接维护，例如建立不同的邮件夹等。几个概念1．MUA（MailUserAgent）称为邮件用户代理，用户利用MUA读取邮件，回复邮件以及写新邮件并发送。MUA种类繁多，有foxmail和微软的Outlook系列等客户端工具，还有专用的Webmail等。2．MTA（MailTransportAgent）称为邮件传输代理，MTA负责将电子邮件从一个SMTP服务器发送到另一个SMTP服务器。3．MDA（MailDeliveryAgent）称为邮件投递代理，MDA负责将电子邮件投递到最终目的地，实现上可以是MTA的一部分。4．Envelop称为信封，指明邮件的发送者和接收者的名字和地址，用于在MTA之间传输，分别是SMTP协议的MAILFROM命令和RCPTTO命令的参数。5．Header称为邮件信头，指明邮件的发送者和接收者的名字和地址，以及诸如主题、发送日期、关键词等邮件细节信息，还有该邮件所通过的MTA，加上邮件路由信息和Message-ID字段等。6．Body称为邮件正文，是发送给收件人的资料（包括文本或文件），一个空白行将正文同信头分开。邮件信头和正文构成了一封完整的邮件，其格式由RFC822规定。Internet邮件发送和接收协议--SMTP协议SMTP(SimpleMailTransferProtocol,RFC821/2821)是一个用7-bit基本ASCII字符传送简单信文的邮件协议。它是一个独立的用户级协议，它要求一个可靠的资料信道。在TCP/IP协议中，这个信道是8-bit的TCP数据流，因此SMTP的7-bit字节一律按照最高位为零的8-bit字节进行传输。如果要传送8-bit资料，需要用特殊的调制算法(例如MIME)将其转为7-bit资料，在接收端再用相反的算法将其复原。如图2-2，SMTP设计基于以下通信模型：针对用户的邮件请求，发送方SMTP建立与接收方SMTP之间是一个双向传送信道。接收方SMTP可以是最终接收者也可以是中间传送者。SMTP命令由发送方SMTP发出，由接收方SMTP接收，而应答则反方面传送。一旦传送信道建立，SMTP发送者发送MAIL命令指明邮件发送者。如果SMTP接收者可以接收邮件则返回OK应答。SMTP发送者再发出RCPT命令确认邮件接收者是否可以到达。如果SMTP接收者接收，则返回OK应答；如果不能接收到，则发出拒绝接收应答（但不中止整个邮件操作），双方将如此重复多次。当接收者收到全部邮件后会接收到特别的序列，如果接收者成功处理了邮件，则返回OK应答。SMTP提供传送邮件的机制，如果接收方与发送方连接在同一个传送服务下时，邮件可以直接由发送方主机传送到接收方主机；或者，当两者不在同一个传送服务下时，通过中继SMTP服务器传送。为了能够对SMTP服务器提供中继能力，它必须拥有最终目的主机地址和邮箱名称。MAIL命令参数是回复路径，它指定邮件从何处来；而RCPT命令的参数是转发路径的，它指定邮件向何处去。向前路径是源路径，而回复路径是返回路径（它用于发生错误时返回邮件）。当同一个消息要发往不同的接收者时，SMTP遇到了向不同接收者发送同一份资料的复制品的问题，邮件命令和应答有一个比较独特的语法，应答也有一个数字代码。命令与应答对大小写不敏感，也就是说，命令和应答可以是大写，小写或两者的混合，但这一点对用户邮件名称却不一定是对的，因为有的主机对用户名大小写是敏感的。这样SMTP实现中就将用户邮箱名称保留成初始时的样子，主机名称对大小写不敏感。命令与应答由ASCII字母表组成，当传送服务提供8位字节传送信道，每7位字符正确传送，而最高位被填充为0。当指定一般的命令或应答格式后，参数会由一些类似于语言的字符串表示出来，如"<string>"或"<reverse-path>"，这里尖括号表示这是一种类似于语言的变量。SMTP的一个重要特点是“中转”（Relay）。一般地，用户可以选择任意一台SMTP服务器（如A）来发送邮件(只要能与该服务器建立传输层连接)，若该服务器与目标SMTP服务器B可以建立直接连接，则邮件将被直接送至目标服务器B；若不能建立直接连接，该SMTP服务器将向其它所知的SMTP服务器询问路由，假如有一台SMTP服务器C可以与目标建立直接连接，或知道通向目标的路由，则邮件被转至服务器C，由服务器C向目标B转发。不管是从客户机到服务器的发送还是服务器间的中转，SMTP使用同一套指令来进行连接和数据的接收发送，从而使得整个过程清晰简捷。Internet邮件提取协议Internet文件RFC1733定义了分布式消息访问系统的三种操作模式或者称为消息访问机制：脱机方式（Offline）、联机方式（Online）和断开方式（Disconnected）。在脱机方式中，邮件客户程序，即邮件用户代理（MUA）从服务器将消息取回到本地机，并在服务器上将该消息删除，以后对消息的处理完全在本地机上进行。在联机方式中，邮件客户程序直接对服务器上的消息进行远程操作，不必将消息下载到本地。在断开方式中，邮件客户程序将服务器上的消息缓存到本地机后就与服务器断开连接，然后用户“脱机”得对已缓存到本地机的消息进行处理，若需要则可以重新连接到服务器并与服务器保持同步。但这个模型与纯粹的“脱机”方式是不同的，因为断开方式下原始消息是留在服务器上的，并且客户程序随后重新连接到服务器并对服务器和客户机消息缓存之间的消息状态进行同步。POP3协议是为脱机方式消息访问机制设计的；IMAP协议最初是为支持联机方式而设计的，同时也支持脱机和断开访问，并且IMAP4还为以后的功能扩展做好了准备。POP3协议POP3(PostOfficeProtocolversion3,RFC1939)定义了客户机从邮件服务器上获取邮件的一个简单的方法，它通过一组简单指令和应答实现与用户的交互操作。例如，用户通过user指令和pass指令实现身份认证，认证成功后可以通过retr指令收取邮件等。加州大学针对SMTP服务器Sendmail，开发了一个共享的POP3服务器软件popper，该软件具有与Sendmail相同的支持多平台和多种类型邮件的优点，并且在设计上采用结构清晰的状态机模型，其模型如下图2-3所示。user和user和pass匹配会话（TRANSACT会话（TRANSACT）状态身份认证（AUTH）状态接到quit命令user接到quit命令user和pass不匹配邮件更新（邮件更新（UPDATE）状态退出（HALT）状态图2-3POPPER状态机模型list、list、retr、dele…命令IMAP协议IMAP4(InternetMessageAccessProtocolversion4rev1,RFC2060)最初是为支持联机方式而设计的，同时也支持脱机和断开访问方式，并且IMAP4还为以后的功能扩展做好了准备。它具有很多POP3不支持的功能：支持多级活页夹，远程活页夹操作，支持共享文档夹，新到邮件通知，不用下载整个消息就可以确定消息的组成部分，有选择的取出邮件的MIME信体部分，支持基于服务器的搜索与选择以减少数据传输，设置标准的或用户定义的消息状态标记，联机性能优化等。基于IMAP的这些良好特性，使得IMAP4协议比POP3协议更适合现在的分布式计算环境。近来越来越多的电子邮件服务器软件已开始支持IMAP4，相应的邮件客户程序也将都会增加对IMAP4的支持。IMAP4提供了一种客户机/服务器模型，客户机通过向服务器发送一些命令来完成相应的操作。如图2-4客户机能够发送的命令与它所处的状态有关。IMAP定义了3种状态：未确认（Non-AuthenticatedState）、已确认状态（AuthenticatedState）和已选定状态（SelectedState）。在不同的状态下，客户机可以向服务器发送的命令是有区别的，某些命令还会导致状态的转换。如同POP3，IMAP客户机向服务器提出TCP连接请求，如果允许建立连接，服务器返回一个初始问候，表明连接已建立，然后服务器等待客户机向其发送请求。与POP3客户机发送完一个命令后必须等待服务器响应不同的是，IMAP允许客户机在不等待服务器响应的情况下发送多个命令请求。这就引起怎样来区分服务器返回的响应对应于哪个命令的问题。IMAP规定客户机发送命令的时候必须带上一个标识此命令的标签，即完整的IMAP命令应该是一个唯一的标签及命令本身和可能的参数。每个返回的响应也包含了一个标签，利用此标签就可以将该响应与相应的命令对应起来。对某些命令，服务器还会返回一类“无标签”响应，这类响应使用特殊的星号（*）作为标签。服务器返回的响应包含“OK”、“NO”、“BAD”、“BYE”、“PREAUTH”等用于表明状态的内容。与POP3相比，IMAP的命令要多得多，服务器返回的响应格式种类更多也更为复杂，因而实现起来更为困难。初始化连接和服务器问候初始化连接和服务器问候非预确认连接非预确认连接拒绝连接预确认连接未确认拒绝连接预确认连接未确认Login或AuthenticateLogin或Authenticate命令成功，LogoutLogout或服务器关闭或连接关闭Select或ExamineSelect或Examine命令失败，或Close命令已确认Logout或服务器关闭或连接关闭Select或Logout或服务器关闭或连接关闭Select或Examine命令成功已选定已选定Logout或服务器关闭或连接关闭Logout或服务器关闭或连接关闭注销并关闭连接注销并关闭连接图2-4IMAP状态机文件系统Linux文件系统简介LINUX操作系统包含许多实际的文件系统，如ext,ext2,minix,ums,ext3等，文件管理的最上层模块是文件系统。系统启动时，必须首先装入“根”文件系统，然后根据/etc/fstab中的指定，逐个建立文件系统。此外，用户也可以通过mount、umount操作，随时安装或卸载文件系统。当装入一个文件系统时，应首先向系统核心注册该系统及其类型。当卸载一个文件系统时，应向核心申请注销该系统及类型。文件系统的注册和注销反映在以vfsmntlist为链头,vfsmnttail为链尾，以vfsmount为节点的单向链表中。从链表的每一个vfsmount节点可找出一个已注册文件系统的信息。文件系统类型的注册和注销反映在以file_systems为链头，以file_system_type为节点的单向链表中。链表的每一个file_system_type节点描述一个已注册的文件系统类型。系统管理可从vfsmntlist开始，遍历整个文件系统链表，获得任何一个已安装文件系统的vfsmount。由vfsmount中的指针mnt_sb，获得该文件系统的super_block。再从super_block得到具体信息，如s_type指向文件系统类型链表，s_mounted指向第一个VFSinode，s_covered指向安装点目录项的VFSinode。虚拟文件系统VFSVFS是物理文件系统与服务之间的一个接口层，它对LINUX的每个文件系统的所有细节进行抽象，使得不同的文件系统在LINUX核心以及系统中运行的其他进程看来，都是相同的。严格说来，VFS并不是一种实际的文件系统。它只存在于内存中，不存在于任何外存空间。VFS在系统启动时建立，在系统关闭时消亡。VFS的功能包括：记录可用的文件系统的类型；将设备同对应的文件系统联系起来；处理一些面向文件的通用操作；涉及到针对文件系统的操作时，VFS把它们映射到与控制文件、目录、以及inode相关的物理文件系统。当某个进程发布了一个面向文件的系统调用时，核心将调用VFS中相应的函数，这个函数处理一些与物理结构无关的操作，并且把它重定向为真实文件系统中相应的函数调用，而这些函数调用则用来处理那些与物理结构相关的操作。VFS描述系统文件使用superblock和inode的方式。在系统初起时，所有被初始化的文件系统(file_system_type)都要向VFS(file_systems)登记。每种文件系统类型的读超级块子例程(read_super)必须识别该文件系统的结构并且将其信息映射到一个VFS的超级块数据结构上。为了文件系统的性能，设备上的超级块(或FAT表等索引信息)必须驻留内存空间。VFS的super_block数据结构即提供了这样的内存空间。其中，聚合类型成员super_block.u是实现的关键。例如，ext2类型的文件系统一旦安装，磁盘上的超级块信息即会复制到一个ext2_sb_info结构，super_block.u.ext2_sb将指向该结构。VFS超级块包含了一个指向文件系统中的第一个inode的指针s_mounted。对于根文件系统，它就是代表根目录的inode节点(inode结构将在下文描述)。VFS超级块也包含一个指向该文件系统安装点的inode(此inode属于另一文件系统)的指针s_covered。对于根文件系统，s_covered无效。利用VFS超级块的s_mounted和s_covered，以及inode，可以构造包容所有已安装文件系统的树型目录结构。文件系统由子目录和文件构成。每个子目录或文件只能由唯一的inode描述。inode是LINUX管理文件系统的最基本单位，也是文件系统连接任何子目录、任何文件的桥梁。VFS的inode同VFS的super_block一样，是物理设备上文件或目录在内存中的统一封装。其中，聚合类型成员inode.u是实现的关键。例如，对于ext2类型的文件系统，其磁盘上的inode信息ext2_inode复制到内存中就是一个ext2_inode_info结构，inode.u.ext2_i将指向该结构。几种linux下常用文件系统研究ext2文件系统ext2的设计者主要考虑的是文件系统的效率和性能方面的问题。ext2在写入文件内容的同时并没有同时写入文件的meta-data（和文件有关的信息，例如：权限、所有者以及创建和访问时间）。换句话说，Linux先写入文件的内容，然后等到有空的时候才写入文件的meta-data。如果在写入文件内容之后但在写入文件的meta-data之前，突然断电了，文件系统就会处于不一致的状态。在一个需要大量文件操作的系统中（例如，像Hotmail这样的免费的Webe-mail），出现这种情况会导致很严重的后果。日志文件系统可以帮助解决这个问题。假定你正在更新一个目录项（directoryentry）。你已经在这个巨大的目录项的第五个文件块（block）中改变了23个文件项（fileentry）。当正在写这个文件块的时候突然间断电了，这个文件块还没有写完，也就是被损坏了。重新启动的时候，Linux（就像其它的Unix）会运行一个叫做“fsck”（filesystemcheck）的程序，扫描整个文件系统，保证所有的文件块都被正确地分配或使用。它将找到这个被损坏的目录项并试图修复它，但是不能够保证fsck一定能够修复损坏。修复不了是经常的事。所以，当出现上面那种情况，目录项中所有的文件项可能会丢失，也就造成文件的丢失。如果文件系统很大，fsck扫描要费很长时间。在一个有数十亿个文件的计算机上，fsck可能要运行10个小时以上。在这段时间内，系统是不可用的，也就是导致了很长的当机时间。日志文件系统可以避免这种情况。对于邮件系统来说，用户能够忍受电子邮件的延迟到达，却不能忍受丢信。所以我们必须找一种更好的设计方式，以便保证邮件文件的安全，同时在灾难恢复的时候能够快速，方便。Resierfs文件系统Resierfs文件系统是一个linux下的日志文件系统，它设计的主要目标是在系统崩溃的时候能够快速恢复。而且在用于小文件和包含许多文件目录时，文件系统的效率也很高，这种特征和邮件文件大小分布相符合。Resierfs的一个重要概念是统一的名字空间。在理论上，HansReiser想创建一个由对象组成的文件系统，这些对象既是对象又是目录。Resierfs使文件边界与磁盘上的块对齐。这样做的原因是：使一个文件跨越的块数减到最少，在存储每一个没有完全填满的块时避免浪费磁盘和缓冲区空间。存在引用的局域性的时候，避免对没有完全填满的块的每一次访问浪费I/O带宽，减少在访问目录中的每一个文件时所需要的平均块获取数量，并且为它产生最简单的代码。Resierfs从一开始就以某种方式聚集小文件，避免磁盘空间的浪费。理解I/O效率和块大小之间的相互影响是非常复杂的，ReiserFS具有以下的结构缺点，这些缺点源于重新打包以节省空间和增加块大小的开销：当文件的尾部变得足够大，它自己就可以占用整个节点时，将从它所在的格式化节点中删除它，并将它转换为一个未格式化节点。小于一个节点的尾部可能跨越两个节点，如果引用的局域性很糟糕，那么这需要执行更多的I/O。将多个尾部聚集到一个节点中会使文件主体和尾部分离，这会降低读性能。对于大小接近节点的文件来说，这种效果会很明显。在向非格式化节点中的最后一个项目的文件或者尾部添加一个字节时，那么平均起来整个节点中会有一半在内存中移动。如果任何一个应用程序执行I/O并生成许多小型的未缓存写入，那么将让你为无法缓存I/O付出巨大的代价。使用最少的序列化和数据位移来确保可恢复的问题不可避免的会影响性能设计。Resierfs用perservelists的方案来确保可恢复性，这样在附近写入元数据，从而避免了覆盖原来的元数据。Reiserfs总的来说是非常出色的，这主要是由于科学和聪明的设计和编程方法，不过它最大的缺点是和linux内核组件（如NFS）的交互性很差。Log文件系统在过去的十多年，CPU的速度发生了戏剧性的变化，但是磁盘的的存取速度却提高很少，而且这一趋势在以后还有可能继续，越来越多的应用的瓶颈都集中在磁盘性能上，为了减少这个问题对应用程序的影响，设计出了一种新的磁盘存储方式，Log文件系统。它能够比常规的文件系统更好的利用磁盘带宽。Log文件系统比传统的文件系统安全，因为它用独立的日志文件跟踪磁盘内容的变化。就像关系型数据库（RDBMS），日志文件系统可以用事务处理的方式，提交或撤消文件系统的变化。文件系统通过为每个文件分配文件块的方式把数据存储在存储设备中。这样就需要维护每一个文件的文件块的分配信息，而分配信息本身也要保存在磁盘上。不同的文件系统用不同的方法分配和读取文件块。有两种常用的文件系统的分配策略：块分配（blockallocation）和扩展分配（extentallocation）。块分配当文件变大的时候每一次都为这个文件分配磁盘空间，而扩展分配则是当某个文件的磁盘空间不够的时候，一次性为它分配一连串连续的块。传统的Unix文件系统使用的块分配的机制提供了一个灵活而高效的文件块分配策略。磁盘上的文件块根据需要分配给文件，这样可以减少存储空间的浪费。当一个文件慢慢变大的时候，就会造成文件中文件块的不连续。这就导致了过多的磁盘寻道时间，当读取一个文件的时候有可能要随机而不是连续的读取文件块，这样的效率很低。可以通过优化文件块的分配策略（尽可能为文件分配连续的块）来避免文件块的随机分配。通过使用聪明的块分配策略，可以实现块的连续分配。这样就可以减少磁盘的寻道时间。但是，当整个文件系统的文件块的分配形成碎片的时候，就再也不可能连续分配了。每一次当文件扩展的时候，块分配的算法就要写入一些关于新分配的块所在位置的信息。如果每一次文件扩展的时候只增加一个块，那么就需要很多额外的磁盘I/O用来写入文件块的结构信息。文件块的结构信息也就是meta-data。meta-data总是一起同时地写入存储设备的，这就意味着改变文件大小的操作要等到所有的meta-data的操作都完成之后才能进行。因此，meta-data的操作会显著地降低整个文件系统的性能。扩展分配方式一次性为文件分配很多连续的块。当创建一个文件的时候，很多文件块同时被分配；当文件扩展的时候，也一次分配很多块。文件系统的meta-data在文件创建的时候被写入，当文件的大小没有超过所有已分配的文件块的大小，就不用写入meta-data。（直到需要再分配文件块的时候）这样可以优化磁盘寻道的方式，可以成组地分配块，有利于一次写一大批数据到存储设备中，这样就可以减少磁盘设备写数据的时间。基于扩展分配的文件系统在读取顺序文件的时候有很好的性能，因为文件块都是成组连续分配的。但是，如果I/O操作是随机的，基于扩展分配的文件系统的好处就非常有限了。例如，当我们要连续地读取一个基于扩展分配的文件的时候，我们只要读起始块号和文件长度就行了。然后，就可以连续地读取所有的文件块了，这样在顺序读取文件的时候，读meta-data的开销就很小。反之，如果随机地读取文件，我们就要先查找每一个所需块的块地址然后再读取块的内容，这样就和块分配方式很象了。在ext2文件系统中，对写性能的增强是通过尽量延迟写的时间，这样就能一次写一大批数据而不是每次写一小点。随之而来的就是系统效率的提高。同样，当读的时候，ext2也是一次读取一整组的块，也就是采用预读策略。这样就能提高ext2文件系统的读性能，大量减少每次读取少量数据的I/O操作。文件块的组或块簇（blockcluster）的大小是在编译的时候确定的。怎样设定簇的大小不是这里所要介绍的内容。但是，可以这么说，簇的大小对文件系统的性能确实有很大的影响，而且簇的大小也是文件系统设计的时候需要考虑的一个很重要的方面。像Veritas这样的扩展分配的文件系统和象ext2这样的“成簇写”（write-clustering）的文件系统，在默认情况下都使用512字节的块而不用1k字节的块。如果ext2用4k而不是1k字节的块，大概会有20%的性能提升。但是，为了减少被浪费的空间ext2文件系统的设计者建议使用1k字节的块。日志文件的设计思想是跟踪文件系统的变化而不是文件系统的内容。为了更好地解释这个问题，下面我用ext2文件系统和日志文件系统举一个例子：当我们改变文件“test.file”的内容的时候会出现什么情况？先假定“test.file”的inode有四个数据块。用来保存“test.file”文件的数据块的块号分别为3110、3111、3506和3507（因为在3111和3506之间的块已经分配给其它文件了，所以这些块不连续）。当硬盘要先找到3100，读两块，在跳到3500，再读两块，才能读取整个文件。假定你改变了第三块，文件系统会读取第三块，改变它，然后重新写入第三块，这一块还在3506这个位置。如果你往这个文件中添加了一些内容，就要从别的地方另外分配一些空余的块。如果在日志文件系统中，情况就有所不同。日志文件系统不会改变第3506块的内容，它会把“test.file”的inode的一个拷贝和新的第三块保存到磁盘上。在内存中的inode列表需要更新，让“test.file”使用新的inode。所有的变化、添加和改变需要被记录到一个文件系统中被称为“日志”的那部分中去。每隔一段时间，文件系统在“检查点”（checkpoint）回更新在磁盘上的inode，并且释放文件中用不到的那些旧块（例如：“test.file”文件最初的第三块）。在系统崩溃之后，日志文件系统很快就能恢复。它需要恢复的只是日志中记录下来的很少的几块。当断电之后，“fsck”只要用几秒钟的扫描时间。但是，文件系统为得到额外的安全也是要付出代价的，这就是系统开销。每一次更新和大多数的“日志”操作都需要写同步，这样就需要更多的磁盘I/O操作。系统管理员就面临这样一个问题：为了有一个更安全的文件系统值不值得牺牲一部分性能？大多数系统管理员会根据实际情况作出决定。没有必要把“/usr”目录放在日志文件系统上因为“/usr”目录大部分是只读的操作。但是，可以考虑把“/var”或包含e-mailspool文件的目录放在日志文件系统上。幸运的是在Linux系统中可以根据需要混合使用这些文件系统。日志文件系统还有一个问题就是更容易产生碎片。因为它的文件分配方式与众不同，很容易在文件系统中到处产生碎片。ext2文件系统也会产生碎片但是可能不会有这么严重。每个月定期把文件系统备份到磁带中然后重新恢复，不仅可以解决这问题，而且可以检查备份/恢复的过程是否正确。Webproxy文件系统。随着计算机网络尤其是Internet的快速发展，作为缓存服务器的WebProxy得到了普遍的应用。而随着网络速度的提高和磁盘速度的缓慢，WebProxy所在的文件系统的延迟在人们感觉到在WebProxy服务的响应时间中占了很大的比例。通常作为缓存的WebProxy运行在普通文件系统上，而普通的文件系统不是针对WebProxy应用服务来设计而优化的，所以这会造成服务的效率不高。商用的缓存服务器通常采用专用的操作系统、专用的文件系统甚至专用的硬件，加上专门的缓存服务程序，具有较高的性能，但是代价较为昂贵。Webproxy文件系统利用了WebProxy负载的一些特点，例如webpages一旦缓存大小就不会发生变化，存取权限也不会发生变化，webpages访问的邻接性等。这些特点可以让我们把一个文件的数据存储到连续的磁盘块之上。这种存储的连续性可以使对文件的读写最大限度的利用了磁盘的带宽，缩短了寻找的时间。WebProxy存储的文件是远方服务器的一个备份，这种冗余性可以使我们把所有的元信息放在内存当中来提高文件系统的效率。随着分布式计算越来越普遍，用户对服务器性能满意程度很大部分上取决于和远端服务器的交互的响应时间。为了性能和管理的原因，很多服务采用的是专用的硬件，专用的操作系统和专用的文件系统。然而，这些服务也经常跑在通用的操作系统和文件系统比如UNIX的UFS、FFS、LFS和Linux的EXT2之上，而这些操作系统和文件系统又是未对某一单独的应用程序优化过的，通常这会造成性能的下降。统计数据表明，对一个proxy的访问命中的文件90％来自于磁盘，而磁盘的延迟又对响应时间（用户感觉到的）的贡献是30％。由于网络速度的不断提高，而磁盘存取速度的没有什么提高，所以这个比重还会加大。通用文件系统在解决WebProxy系统性能上的局限性在于：命名策略：传统的UNIX文件系统采用的是层次化的树状目录命名策略来管理文件，而WebProxy不需要此层次结构，它需要的只是一个平坦的名字空间。比较深的层次化的树状目录结构会造成很长的遍历时间。而如果一个目录内有大量的文件也会减慢查询速度，因为在一个目录中查找文件很多系统的实现是线性查找.一致性：文件系统的元数据保存在inode里面，为了保持元数据的一致性，许多文件系统采用的同步写的技术，这样整个系统的性能就会下降。而WebProxy由于自身的特点，在一致性要求上较为宽松，不需要严格的一致性，从而换来一定的速度提升。数据缓冲的重复和不方便管理：例如一个典型的UNIX系统会把数据用DMA方式从设备放到设备驱动程序的缓冲区里面，然后再把数据拷贝到文件系统的缓冲区，最后再拷贝到应用程序的缓冲区。而后面两个拷贝应该避免。另外文件系统cache不方便管理。由于文件系统不能存取应用程序的信息，WebProxy一般在应用程序级维护自己的cache管理。但是应用程序级维护的cache很可能在文件系统级别也存在，特别是刚刚从磁盘存取过。这就是多重缓存的问题，这个问题降低了计算机内存的利用率、命中率以及造成响应时间的延长。访问的邻接性：磁盘的读写延迟主要是由于数据块的不连续