




版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领
文档简介
FRONT互联网文件存储与共享系统刘斌刘忠义网络实验室夏冰数据库实验室朱彬软工实验室摘要本文受Freenet项目的启发,设计并实现了一个具备存储和共享功能的互联网分布式文件系统——FilesReiableONinTernet(FRONT)。FRONT在操作系统的文件系统之上提供了一层新的虚拟文件系统,上传到FRONT系统的文件被适当地切分并分配到网络中某些节点上。通过文件分块表或文件块复制和缓存,用户得以利用FRONT实现可用高效的文件访问。FRONT系统使用磁盘配额和固定共享空间比例的技术来配合这个虚拟文件系统,来解决P2P应用中的Freerider问题。Front使用RandomWalk算法进行文件定位,并且在网路规模变化时保持系统中文件的高可用性和高性能。实验表明本文实现FRONT系统运行正确,性能有待进一步实验。关键词分布式系统、P2P、网络存储、文件共享介绍工作动机今天互联网上已经有许多成熟的P2P文件共享系统,例如BT、迅雷、Maze等,它们的存在极大地丰富了普通网民可以访问的互联网资源。这些系统着重于将互联网上的文件以P2P的方式共享给更多用户。几乎在这些P2P共享协议在开始被研究和应用的同时(2001年),学术界也曾热烈地讨论过在互联网络上提供开放的存储服务的分布式文件系统,一些著名的系统包括CFS、Gnutella、FreeNet等。今天仍有一些个人和组织在这些协议的基础上开发扩展和应用。但是由于版权、用户激励、网络封禁等等原因,这些系统一直停留在研究阶段或者很小规模的应用。随着网络的普及和计算服务的无所不在,普通用户开始在一个以上的计算机上进行文件存取;并且越来越多的群体或组织的成员参与到互联网上的协作和共享。这样的需求可以使用分布式的文件存储和共享技术来满足。本文是几位研究生在学习分布式系统课程之后的一次尝试,希望开发一个具有一定可扩展性的分布式文件系统FRONT(FilesReliableONinTernet),用户可以使用这个系统实现高效的文件存储与访问。本文内容FRONT文件系统最主要受到FreeNet[6]项目的启发。FRONT系统无须依托任何基础设施,当文件存储或者共享的需求产生时,它即可从一台主机的规模开始扩展,在网络规模和共享空间逐渐扩大的同时,它可以持续提供高可用、高性能的文件存储与共享服务。FRONT采用用户磁盘配额的方式,让每一台主机向整个系统提供存储空间,并通过控制共享空间与用户需求空间的比例来避免freerider问题。FRONT系统对用户上传的文件进行适当地切分,使之映射为操作系统的文件系统之上的虚拟文件系统FrontVFS中的文件。文件分块的设计让用户可以上传更大的文件,并且流行的文件块将被分配到更多的机器上,带来更高的访问性能。新的一层虚拟文件系统还造成了用户对磁盘空间使用的不透明性,又一次保证了客户端在使用系统的同时提供必要的服务。在文件分块后,系统中需要存储的数据包括文件的分块表和文件块两种类型。文件分块表使用“发布者用户空间”上的路径来定位,文件块使用对数据内容的哈希来定位。为了提供高可用性和高性能,FRONT在文件块的级别在系统中实现了复制和缓存。FRONT对于局域网构成的网络还做了特别的优化处理,让处在同一个以太网络内的本地用户高效地利用网络,并降低对整体网络的负担。另外,FRONT系统中节点的通讯组织方式提供了高效的文件查找功能。这些都将在下面的章节中系统介绍。下文的主要内容:第II部分描述了Front文件系统对于应用场景的假设,并分析在假设情况下的文件系需要解决的问题。第III部分是对Front文件系统的结构设计。第IV部分是本文的主要部分,介绍了开发Front文件系统的细节。第V部分讲述了Front文件系统的运行情况,分析对比了与其他文件系统的区别和特点。最后第VI部分是对本文工作的总结和展望。假设和问题我们基于互联网上的存储和共享需求设计并实现了Front网络文件系统,为互联网用户提供了高效可靠的文件服务。它适用于在下文定义的一些假设情况,我们认为这些假设有较强的普遍性和适应性,满足了很多应用需求。这些假设包括以下几点:互联网中存在多个节点,无论它们是否邻近。它们愿意共同组织一个文件存储和共享平台。这个平台可以选择由预先定义的用户组成,与Internet上可能存在的其他front网络没有交互。每个参与的节点提供存储空间和一定的网络带宽。每个节点的空间组合起来构成全局大容量的存储共享空间。节点在自己的文件需要的容量之外还能够提供一定比例的“服务空间”,用于存储全局的其他文件,为别人提供服务。文件系统的文件发布和下载对于用户来说好像本地的一样。节点上的用户不用关心文件传输的事情,包括文件内容从哪里获得、发往哪里。分布式系统数据复制和协议通讯对用户都是不可见的。一些节点组成的分布式网络中。发布和下载的需求并不一定是对称的。例如在一个极端情况下,一个网络中总是由一个节点在发布(上传)文件,其他节点都是不同需要的下载者。文件系统提供的语义是只读的。文件发布后即可由他人获得,但不可修改。向Front网络上发布的文件可能很大,甚至大于本地节点提供的共享空间容量。但只要front网络平台上还有空间,它就应该上传成功。本文需要设计一个网络文件系统,满足以上假设的应用场景,并且保证这个分布式文件系统的高可用和高性能。需要解决的问题有下面3个方面:本地文件系统首先,为了在本地保证用户提供的“共享空间”比例,Front在本地磁盘上的存取应该对用户有一定的不透明性。也即用户看不到是什么数据(在操作系统里看就是文件)占用了本地磁盘。一种可行的方案是,用户在操作系统里看到的存储文件不是发布到Front系统的文件的直接形式。发布的文件可以经过某种转化后存在磁盘上,用户不知道那个什么文件是自己需要的还是提供给他人的,因此不太愿意去冒险删掉其中的一部分。从这个角度上可以部分解决P2P系统的FreeRider问题。一种简单的磁盘存储不透明性可以用文件分块来实现。通过把文件切分成一定大小的文件块,可以自然的把系统上的众多文件数据“混淆”在一起。把文件分成块,还可以简化一个节点上传大于本地空间大小的文件的设计。另外,在分布式文件系统中,我们希望资源(包括复本)可以均匀的分布在更多的节点上,这样可以带来更高的可用性和性能。显然,当文件分成较小的块时,系统中的大文件也更加容易实现在网络中的这种分布。文件分块的一个额外开销是需要在这个网络中维护文件分块信息,并且对文件的请求被分为多个不走。另一个需要在本地处理的问题是,当资源请求超过了本地磁盘配额,如何权衡用户的需要得到满足和节点同时为网络提供存储服务的矛盾,Front系统本地需要一个安全有效的数据替换算法。网络互联和文件查询网络上需要协作的Front节点需要一种办法来知道彼此的存在。节点加入和离开对网络的影响不能太大。因此当网络规模较大时,节点之间不可能两两可知的。相互可知的节点互为邻居,并且可以彼此交换信息,以增强网络连通性或者传递查询请求等。一个理想的网络连接情况是:临近(IP或者地理位置)的节点尽可能互为邻居,形成连通性较强的局部网络;距离较远的节点之间保持一定的连通,这样才能让远处的查询得到本地的信息,让整个网络的信息通畅。为了避免网络中的节点孤岛,需要一种方法显式地加入已经存在的网络。文件的查询涉及命名和查询路由。文件在系统的命名最好可阅读的,并且具有一定的区分性。后者让不同用户发布文件较难产生命名冲突。对于系统内部,对文件(可能被切分成文件块)的识别应该是唯一的,可以跟可阅读的文件名一一对应。另外,不同的用户可能发布完全一样的文件,应该被识别并且利用起来。当网络中的节点向路由器一样连接起来后,每个节点根据本地邻居信息,以一定的方式将请求和应答在分布式系统中传播,最终使请求发起者获得文件的信息。数据复制和传输系统中的文件数据需要被合理地分配在分布式节点上。这一点保证系统中的文件以尽可能大的概率存在于网络中并且可达。同时对于文件的传输请求也可以向传统P2P网络中那样从多个目标节点同时开始。当文件被分块后,文件的结构信息也应该被广泛地分布于整个网络中,以使得被更多的节点可知。数据复制的触发可以放在发布时,当节点有可能探测到文件的复本可能在网络中下降时,或者很受欢迎被很多人请求时,也应该出发复制(在后一种情况中被称为缓存)。系统结构设计为了解决第II部分提出来的几点问题,设计Front网络文件系统需要考虑的几个模块的交互。Front系统及节点的本地结构如图表一所示。图表SEQ图表\*CHINESENUM3一Front系统节点的本地结构系统中所共有的Front结构信息在commonstructures里定义。FrontVirtualFileSystem是本地与操作系统的文件系统交互的唯一模块,它通过将文件分块,并维持本地文件结构表和本地分块表,来向上层提供一层虚拟的文件系统。Networkingcomponent模块负责与其他节点的通讯和数据传输。在FrontVFS和Networkingcomponet之上的一层是Front文件系统的对外接口FSClientNode。FSClientNode就好像一层中间件,可以向上层提供可以实现网络存储和共享的文件系统。在我们的实现中,我们设计了用户界面来调用FSClientNode,即实现了一个完整的客户端。关于每个模块的实现将在第IV部分介绍。实现FRONT互联网文件存储与共享系统的实现,分成以下5个部分来介绍。命名Front文件系统的命名问题属于第V部分介绍的Frontcommonstructures部分。上文已经提到,每个文件应该拥有一个可阅读(humanreadable)的文件路径。这个路径在用户发布是制定。有namespace域和systempath域组成。文件系统内部使用的定位符(identifier)统一使用128位数据来表示。针对文件的定位符,根据可阅读的文件路径经过MD5计算得到。因此,请求文件的用户只要知道这个可阅读的文件路径即可发出请求。针对文件块的定位符,根据文件块数据内容经过MD5计算得到。这样当一个固定的文件被分块时,如果能够保证分块结构总是一致,那每一块计算得到的定位符也是相等的。这个特性有利于Front系统对发布相同文件的识别和利用。下文将会提到,FrontVFS对于相同的文件,分块的结果是一致的。本地文件系统FRONTVFSFRONTVFS是建立在操作系统文件系统之上的一层文件系统,用户与在整个系统中与FRONTVFS进行交互。对系统中存在的文件我们选择了对其进行分块。分块的好处首先在于一个节点存放不下的文件可以分开存储在多个节点上。第二,如果用户修改某个文件的一部分,重新发布时很可能有的块并没有变化,此时只需发布更改过的块即可。第三个好处在于可以均衡负载,用户可以同时从几个网络节点上下载不同的块来达到加速传输的目的。考虑下面一种情况:网络中有三个节点存储三个300M的文件,每个节点指定的共享空间为300M。那么,如果我们将三个文件都分成三个块,分布在三个节点。这样用户下载每一个文件时都可以从三个节点同时下载三个块,比文件不分块时必须从单个节点下载的情况效率要高。但是,分块同时带来了资源存在的不确定性。如果存放一个文件的某个块的节点关机,系统中又没有该块的备份,那么这个文件就无法被完整获得。分块越多分布越广越容易出现这样的问题。除了采取一定的复制策略外,我们的分块算法也保证一个文件不要分成太多的块。根据文件大小所在的不同区间,我们对文件采取不同的分块策略。分块算法如下:intintchunkSize;inttimes=1;intmaxChunkNum=chunkNumStart;while(true){if(minChunkSize*times>maxChunkSize){ chunkSize=maxChunkSize; break;}if(fileLength<=minChunkSize*times*maxChunkNum){ chunkSize=minChunkSize*times; break;}maxChunkNum+=chunkNumInterval;times*=chunkSizeGrowthRate;}我们定义了几个可调的参数:minChunkSize是最小分块大小,小于此大小的文件将不被分块;分块大小也是从minChunkSize开始增长的。maxChunkSize是最大分块大小,一个典型的赋值为用户共享空间的最低大小300M。chunkNumStart是初始分多少块后开始上调分块的大小,如minChunkSize设为25M,chunkNumStart设为3,则当文件大于25M*3即75M时将调高分块的大小。chunkNumInterval是下次上调分块大小的块数间隔,按之前的数据,若chunkNumInterval设为1,则下次文件需要被分为3+1即4块以上时才再次上调分块大小,以此类推。chunkSizeGrowthRate是每次上调分块大小的增长率。一组典型赋值为://25M//25MprivatestaticfinalintminChunkSize=1024*1024*25;//300MprivatestaticfinalintmaxChunkSize=1024*1024*300;privatestaticfinalintchunkNumInterval=1;privatestaticfinalintchunkNumStart=3;privatestaticfinalintchunkSizeGrowthRate=2;一些根据文件大小分块情况的例子如下:文件大小分块大小块数20M25M175M25M3100M50M2200M50M4250M100M3500M100M5600M200M31200M200M61300M300M5文件和块唯一的标识信息是它们的key。文件的key是通过namespace和systempath域算出来的,块的key是根据其内容,用md5的方式算出。本地维护两个表——文件信息表和块信息表。文件信息表里记录文件的相关信息,包括文件在FRONT系统中的路径、文件大小、对应的块列表等;块信息表里记录块的信息,包括块的key、大小和最后使用时间等。我们在存储时利用块的key作为其文件名,这样可以无需记录块的存储路径。文件信息表和块信息表会定期写到磁盘上,下次系统启动时从磁盘上读入。当本地共享空间不够时,除了用户增大共享空间外,我们也加入了对块进行替换的机制。经过研究,我们的块替换机制采用了LRU(最近最少使用)这一策略:对每一个块,在块信息表中会记录该块最后被使用的时间,替换时会按此时间排序,优先替换最近最少使用的块。但为防止用户下载文件时多个块还没有拼接成文件就被替换以及刚接受其他用户上传过来的块就将此块替换的情况,我们设定了一个时间控制,在该时间间隔以内更新的块将无法被替换。在磁盘上的块不能被替换以腾出空间时,我们会选择向网络中的节点传送块以保证文件的发布。为解决freerider的问题,我们定义了一个配额比值,一个典型的取值为50%。用户指定的共享空间必须有50%的空间用来替别人存放内容,剩下的50%用来放自己的内容。当存放自己内容的百分比达到配额时,用户将不被允许从网络中下载文件,直至其增大共享空间删除自己内容保证不再超过配额比为止。网络管理和邻居管理一个网络相当于一个俱乐部,由一些具有相同兴趣的节点组成。与网络相关的操作包括加入网络、创建网络、退出网络等,相关元语定义如下:加入网络。加入网络有两种方式,其一是只指定网络名称,系统负责探测该网络是否存在,然后再决定加入还是创建;其二是指定网络名称和该网络中某个指定节点的IP地址来加入,系统通过与指定IP的节点进行交互判断该网络是否存在并执行加入或创建操作。收到HELLO更新时间戳收到HELLO更新时间戳添加邻居并记录时间戳发送节点和当前节点在同一个LAN中?发送节点存在于neighborList?发送节点存在于remoteNeighborList?YNYYNNProcedureJoinNetwork(networkName)BEGINSendNETPROBEbroadcastmessageWaitfortsecondsforNETREPLYIFreceiveNETREPLYTHENBEGINSetcurrentnetworktonetworkNameSetneighborlistviaHELLOmessagesENDENDPProcedureJoinNetwork(networkName,knownIP)BEGINSendNETPROBEunicastmessagetoknownIPWaitfortsecondsforNETREPLYIFreceiveNETREPLYTHENBEGINSetcurrentnetworktonetworkNameIFknownIPnotinsameLANwithcurrentnodeTHEN AddknownIPtoremoteNeighborListELSE AddknownIPtoneighborListSetneighborlistviaHELLOmessagesENDEND创建网络。创建网络的操作比较简单,只需要把自己的当前网络设为给定的网络名,然后在HELLO包中使用该网络名即可。PProcedureCreateNetwork(networkName)BEGINSetcurrentnetworktonetworkNameUsenetworkNameinHELLOmessagesEND退出网络。只需要停止发送HELLO消息。邻居管理方面,通过周期性地发送HELLO广播包来进行邻居维护。如果一个节点在指定的时间段内未收到某个邻居节点的HELLO消息,则将该邻居从邻居列表中删除。需要指出的是,neighborList和remoteNeighborList的维护方式是不同的,neigborList中的节点与当前节点处于同一个LAN中,因此可以通过广播HELLO来维护;remoteNeighborList中的节点与当前节点不在同一个LAN中,通过单播的HELLO包来维护。图表SEQ图表\*ARABIC2收到HELLO消息的处理通过这个机制,既可以支持不在同一个LAN中的邻居的高效管理,又可支持远程邻居的列表的维护。然而,该邻居管理方案并不完美,尤其是在广域网中。其问题在于,一个LAN中只有固定的节点来维护与远程节点的邻居关系,这个节点相当于一个SuperNode,可是一旦这个SuperNode失效,则有可能失去与远程邻居的联系。一个改进的方法是定一个LAN中SuperNode的管理机制,当一个SuperNode失效后,选举别的有效节点行使其职能。文件查询通过K-RandomWalk的方式来定位一个文件。发出文件定位请求的节点启动K个RandomWalk,即每次随即选择一个邻居,向该邻居发送FILEQUERY消息。FILEQUERY中包含一个TTL,用于指定搜寻的范围。收到FILEQUERY的节点检查本地文件表,看有没有要找的文件,如果有则进行应答并丢弃FILEQUERY;如果没有则把FILEQUERY中的TTL减1,如果TTL>0,则任选一个邻居把FILEQUERY发送出去。FILEQUERY的发起节点在启动RandomWalk之后,启动一个计时器,在这个时段内系统收集所有的应答(FILEREPLY)。每个应答中包含了文件的Chunk列表和本地保存的Chunk的列表。在计时器到期时,如果所有的chunk的信息都已经可用,则把结果显示到UI;否则再依次搜索每个未知未知的chunk。搜索chunk的方式也是K-RandomWalk。收到FILEQUERY收到FILEQUERY丢弃FILEQUERY任选邻居转发FILEQUERY本地保存有请求的文件信息?FILEQUERY.TTL>0?YNYN发送应答FILEQUERY.TTL--图表SEQ图表\*ARABIC3FILEQUERY的路由PProcedureQueryFile(fileKey)BEGINFORiin[0,min{K,neighborCount}]DOBEGIN Neighbor=getRandomNeighbor(); SendFILEQUERYtoneighborENDStart_timer(T_Query,collectQueryResult)//waitsT_QuerysecodsandthencollecttheresultENDPProcedurerecvFileQueryReply(reply)BEGINMergereply.availiableChunkstoreceivedAvailiableChunks;RecordchunklocationsinreceivedAvailiableChunks;ENDProcedurecollectQueryResult()BEGIN IFhasfullresultTHEN DisplayresulttoUI ELSE BEGIN Queryremainingchunkslikefilequery startTimer(T_chunk_Query,collectQueryResult) ENDEND根据引文[10]的结论,在K=16~64的情况下,K-RandomWalk能够得到很好的查询效率。然而,简单的K-RandomWalk可能导致一定的低效率,原因包括:K次选择随即邻居有可能重复选择;有可能造成环状搜索,即节点A选择了邻居B,B又选择了A(或者A选择了B,B选择了C,C又选择了A,等等);不同的Walker可能遍历相同的节点。其中,第一个问题很容易解决。然而,后面两个问题则不那么简单。事实上,一个有意思的研究问题是,如何使得K-RandomWalk的效率最高(遍历的节点最多)?如何避免重复经过某些节点?一个简单的解决环状搜索(第二个问题)的方法是在Query消息中添加途经的节点列表,然后每个转发节点尽量选择不在途经节点列表中的邻居进行转发。然而,更进一步,如何使得不同的Walk之间的重叠尽可能的小?我们提出的解决方案是:为每个FILEQUERY添加一个序列号属性,每个FILEQUERY由<发起者IP,序列号>唯一确定;添加主动HELLO消息,每当有FILEQUERY经过本节点时就广播主动HELLO,主动HELLO中包含近期所途经的M个Query消息的<发起者IP,序列号>,主动HELLO的信息也添加到邻居表中;节点在进行转发决策时,就可以选择邻居列表中不曾收到过待转发请求的节点进行转发。文件块的复制和传输当用户发布文件时,就需要发起文件复制。文件复制包括了复制触发点、块传输和文件的复制策略三方面。在设计这一部分时需要考虑到实现的灵活性和可扩展性。首先是复制触发点的设置。当用户发布文件时,显然需要触发文件复制。然后客户端需要主动地定时探测当前网络该文件的复制情况,当复本数长期小于额定值时,也是需要触发文件复制的。当出现替换文件块时,就需要主动地发起复制,最简单的情况就是将该块复制到某个其它的节点,但这样的复制没有全局的考虑。如果考虑了整个文件当前的复制情况的话,就可以收到更好的效果,例如可以请求发布文件的节点重新发起复制。其次,在考虑块传输时,有两种实现的方法:一种是使用多线程同步Socket的方法,一种是使用异步Socket的方法。使用异步Socket的方法虽然在效率上和多线程相近,但在代码的简洁性上显然不如多线程的方法。因此为了提高块传输的效率,以及追求代码的简洁,我们使用了多线程。每个块的传输都有一个线程对应,这样很好的减少了代码量和代码的复杂性。文件复制时存在很多的线程同时在传输,这时就需要有一个统一的线程来管理这些块传输的线程。每个文件复制的过程由一个线程控制,而每个文件块的传输也都由一个线程负责,这样的实现可以保证在用户发布文件时,不用长时间等待文件复制的完成,就可以进行下一步的操作。在实现之初,文件复制需要文件的本地分块完成之后才开始,这样就要求用户的本地空间足够大,显然这个要求过于苛刻。为了解决这个问题,我们需要在用户本地空间不够放下整个文件时,只要用户本地空间能都放下最大的文件块,用户仍然可以发布文件。在分块过程中,如果发现本地空间不足时,就需要等待当前文件块复制完成,再使用相应的替换算法替换不必要的文件块。这样的实现既提高了文件复制的效率,又无需用户长时间的等待,还能满足用户发布大文件的需求。再次,可以将文件的复制策略从文件复制中剥离出来,通过定义一个复制策略的基类,如果需要新的复制策略时,只需要继承这个基类,实现其中的方法。这样就可以在只改变少量代码的情况下就能实现扩展,定义新的文件复制策略。在实现具体的复制策略时,需要确定复制中候选节点的范围、复制节点的选择、文件块在这些节点的分配策略以及复制份数。这些方面并非各自独立的,某一方面的决策可能会影响另一方面的策略。候选节点的范围可以是在邻居节点或者整个网络。如果是邻居节点则较易实现,如果是在整个网络则需要通过邻居节点来试探整个网络,以得到潜在的候选节点,这些节点需要能够均匀的分布在网络中。在选择候选节点时,节点之间的距离(即两个节点间的最短跳数)是一个重要的参考,不同距离的节点就是有代表性的候选节点。在一个合理的网络中,各种不同距离的节点可以认为是均匀分布的,同时也考虑了网络的连通性,远端节点也覆盖到了。另外节点的IP地址也是很好的参考,通过IP地址和子网掩码可以了解节点之间的关系,相同网段的节点可以认为具有较近的地理位置,不同网段的节点也是有代表性的候选节点。复制节点选择的复杂性同候选节点的范围有关,当候选节点的范围较小时,复杂性相对会低一点。选择复制节点需要考虑节点的网络带宽、存储余额等,网络带宽较大或者存储余额较大的节点较易被选中,同时还需要考虑节点数,一种策略是一个文件复本应尽量在少量的节点上,以确保文件的可用性。除此之外,选择有代表性的节点也是很重要的,能够考虑整个网络的全局信息,选择最佳的复制节点也是需要考虑的因素。文件块的分配策略需要考虑到均衡性,尽量保证文件块均匀的放置在这些节点中,同时还需保证相同的文件块复本不应放在同一个节点上。这样的策略不仅是为了公平而均匀的使用用户共享的空间,同时也是基于多线程的考虑,均匀的分配有利于充分利用网络带宽,在尽可能短的时间内完成复制。考虑到候选节点的选择策略,距离较接近的节点和相同网段的节点倾向于拥有一个复本,当然两个复本所占用节点的交集应当尽量小,这些节点往往连通性较好,地理位置较近,这样即使网络出现了问题,在网络的某个局部仍然可以保证文件的可用性。至于复制份数,可以根据当前网络的大小和网络存储空间的大小来确定,网络的大小可以通过探测节点之间的距离和网络中的节点数来获得,网络的大小同节点之间的距离和网络中的节点数成正比,当然其中节点数的比重应该更大。节点数多、节点间距离大,那么复制份数就可以多一点。网络存储空间的大小可以通过试探各个节点的存储余额来估算。在获得相当数量的存储余额后,通过简单的求平均来得到当前网络中节点的平均存储余额,余额越多,那么复制份数就可以越多。性能与相关工作由于Front文件系统和其它类似系统在应用场景的区别,难以构造同样的环境对比。并且由于时间和网络环境的限制,我们只在3个节点的网络规模上进行了测试。实验中文件发布、复制和下载功能均得到正确的结果。在本文之前的大多数P2P文件系统,例如迅雷、Bt等,都提供的是文件共享的服务。本文试图使用文件分块的技术提供具有一定扩展性的网络文件存储和共享系统。不同于使用DHT结构的一些系统,例如Chord等,Front系统的设计目标是尽可能地提供高可靠、高性能的文件服务,同时降低对网络负载的影响。Front文件系统使用文件分块实现了一层操作系统文件系统之上的文件层。磁盘上文件的不透明性一定程度上促使用户向网络提供一定比例的空间服务。Front系统使用RandomWalk算法进行文件定位,一定程度上降低了网络开销,但查询的时间可能会较长。总结和展望从Front文件存储和共享系统的运行试验中我们得知,Front系统的功能可行,但是由于时间和测试的限制,系统在较大网络规模上的性能还未知。之后的一项重要工作是进行更多的测试,发现系统性能在较大规模网络上的影响因素,并设计策略进一步提高可用性和性能。其他一些已知的需要改进的地方有:Front文件系统是只读的。无法显式删除一个已经发布的文件,以释放全局空间。文件块的复制,需要在更多的情况下触发。以避免文件内容慢慢地在网络中消失。现在的文件定位算法RandomWalk,还需要性能上的改进,例如避免查询路径出现环等。参考文献Makinggnutella-likeP2PsystemsscalableYChawathe,SRatnasamy,LBreslau,NLanham,etal-Proceedingsofthe2003conferenceonApplicationsFreeRidingonGnutellaEAdar,BAHubermanNapster,Chord:AScalablePeer-to-PeerLookupServiceforInternetApplications,RMorris,DKarger,FKaashoek,HBalakrishnan-ACMSIGCOMM2001Wide-areacooperativestoragewithCFS,FDabek,MFKaashoek,DKarger,RMorris,IStoicaTheFreeNetProject,/WhitePaper:ASurveyofPeer-to-PeerFileSharingTechnologies,StephanosAndroutsellis-Theotokis,AthensUniversityofEconomicsandBusiness,GreeceDistributedSystems:PrinciplesandParadigms,AndrewS.Tanenbaum,MaartenvenSteen,Prentice-Hall,2006DistributedSystems:ConceptsandDesign,byGeorgeCoulouris,JeanDollimore,andTimKindberg.AddisonWesley,2005SearchandReplicationinUnstructuredPeer-to-PeerNetworks,QinLv,et,al.,ICS’02附录资料:不需要的可以自行删除电脑故障检测及维修方法软件调试的方法和建议1、操作系统方面。主要的调整内容是操作系统的启动文件、系统配置参数、组件文件、病毒等。修复操作系统启动文件。1)对于Windows9x系统,可用SYS命令来修复(要保证MSDOS.SYS的大小在1KB以上),但要求,在修复之前应保证分区参数是正确的。这可使用诸如DiskMap之类的软件实现;2)对于Windows2000/XP系统,有两种方法――修复启动文件,使用fixboot命令;修复主引导记录,使用fixmbr命令。调整操作系统配置文件。A.对于Windows9x系统,可用的工具很多,如:Msconfig命令、系统文件检查器、注册表备份和恢复命令(scanreg.exe,它要求在DOS环境下运行。另外如果要用scanreg.exe恢复注册表,最好使用所列出的恢复菜单中的第二个备份文件)等;B.对于Windows2000系统,可用的工具与Windows9x相比比较少,但某些调试命令可用Win98中的一些命令(如win98下的Msconfig命令,就可用在windows2000下);C.对于WindowsXP系统,可用的工具主要是Msconfig命令;D.调整电源管理和有关的服务,可以使用的命令是,在“运行”文本框中输入gpedit.msc来进行;E.所有操作系统的调试,都可通过控制面板、设备管理器、计算机管理器(Windows9x系统无)来进行系统的调试。软件调试的方法和建议组件文件(包括.DLL、.VXD等)的修复A.通过添加删除程序来重新安装;B.通过从.CAB文件中提取安装;C.可用系统文件检查器(sfc.exe命令)来修复有错误的文件;D.从好的机器上拷贝覆盖。检查系统中的病毒。建议使用命令行方式下的病毒查杀软件,并能直接访问诸如NTFS分区软件调试的方法和建议2、设备驱动安装与配置方面。主要调整设备驱动程序是否与设备匹配、版本是否合适、相应的设备在驱动程序的作用下能否正常响应。A.最好先由操作系统自动识别(特别要求的除外,如一些有特别要求的显示卡驱动、声卡驱动、非即插即用设备的驱动等),而后考虑强行安装。这样有利于判断设备的好坏;B.如果有操作系统自带的驱动,则先使用,仍不能正常或不能满足应用需要,则使用设备自带的驱动;C.更换设备,应先卸载驱动再更换。卸载驱动,可从设备管理器中卸载;再从安全模式下卸载;进而在INF目录中删除;最后通过注册表卸载;D.更新驱动时,如直接升级有问题,须先卸载再更新。软件调试的方法和建议3、磁盘状况方面。检查磁盘上的分区是否能访问、介质是否有损坏、保存在其上的文件是否完整等。可用的调整工具:A.DiskMap,方便地找回正确的分区;B.Fdisk及Fdisk/MDR,检查分区是否正确及使主引导记录恢复到原始状态;C.当硬盘容量大于64GB时,如果要重新分区或查看分区,要求使用随机附带的磁盘分区软盘中的Fdisk命令。这个命令可用windowsMe下的Fdisk命令来代替;D.Format、Scandisk、厂商提供的磁盘检测程序,检查磁盘介质是否有坏道;E.文件不完整时,要求对不完整的文件先进行改名,再用在“操作系统方面”中所述的方法重建。软件调试的方法和建议4、应用软件方面。如应用软件是否与操作系统或其它应用有兼容性的问题、使用与配置是否与说明手册中所述的相符、应用软件的相关程序、数据等是否完整等;5、BIOS设置方面。1)在必要时应先恢复到最优状态。建议:在维修时先把BIOS恢复到最优状态(一般是出厂时的状态),然后根据应用的需要,逐步设置到合适值。2)BIOS刷新不一定要刷新到最新版,有时应考虑降低版本。软件调试的方法和建议6、重建系统。在硬件配置正确,并得到用户许可时,可通过重建系统的方法来判断操作系统之类软件故障,在用户不同意的情况下,建议使用自带的硬盘,来进行重建系统的操作。在这种情况下,最好重建系统后,逐步复原到用户原硬盘的状态,以便判断故障点。1)重建系统,须以一键恢复为主,其次是恢复安装,最后是完全重新安装。恢复安装的方法:对于Windows9x系统,直接从光盘安装,或执行tools\sysrec\pcrestor.bat,即可实现恢复安装。在进行恢复安装时,可能由于的存在而影响安装过程的正常进行,这时,可在Windows目录下,删除后,再重新安装。另一种恢复安装,是将根目录下的System.1st改名为System.dat后覆盖掉Windows目录下的同名文件,之后重启即可。但这种方法,不是真正意义上的重新安装,而类似于完全重新安装。对于WindowsXP或Windows2000系统,直接使用其安装光盘启动,在安装界面中选择修复安装,选择R时会出现两个选项:一是快速修复,对于简单问题用此选择;另一是故障修复台,只要选择正确的安装目录就可启用故障修复台。故障修复台界面类似于DOS界面。2)为保证系统干净,在安装前,执行Fdisk/MBR命令(也可用C)。必要时,在此之后执行Format<驱动器盘符>/u[/s]命令。3)一定要使用随机版的或正版的操作系统安装介质进行安装。引发硬件故障的原因1.硬件本身质量不佳。粗糙的生产工艺、劣质的制作材料、非标准的规格尺寸等都是引发故障的隐藏因素。由此常常引发板卡上元件焊点的虚焊脱焊、插接件之间接触不良、连接导线短路断路等故障。2.人为因素影响。操作人员的使用习惯和应用水平也不容小觑,例如带电插拔设备、设备之间错误的插接方式、不正确的BIOS参数设置等均可导致硬件故障。3.使用环境影响。这里的环境可以包括温度、湿度、灰尘、电磁干扰、供电质量等方面。每一方面的影响都是严重的,例如过高的环境温度无疑会严重影响设备的性能等等。4.其他影响。由于设备的正常磨损和硬件老化也常常引发硬件故障。检修硬件故障的原则1.先软件后硬件电脑发生故障后,一定要在排除软件方面的原因(例如系统注册表损坏、BIOS参数设置不当、硬盘主引导扇区损坏等)后再考虑硬件原因,否则很容易走弯路。2.先外设后主机由于外设原因引发的故障往往比较容易发现和排除,可以先根据系统报错信息检查键盘、鼠标、显示器、打印机等外部设备的各种连线和本身工作状况。在排除外设方面的原因后,再来考虑主机。3.先电源后部件作为电脑主机的动力源泉,电源的作用很关键。电源功率不足、输出电压电流不正常等都会导致各种故障的发生。因此,应该在首先排除电源的问题后再考虑其他部件。4.先简单后复杂目前的电脑硬件产品并不像我们想象的那么脆弱、那么容易损坏。因此在遇到硬件故障时,应该从最简单的原因开始检查。如各种线缆的连接情况是否正常、各种插卡是否存在接触不良的情况等。在进行检修硬件故障的步骤1.软件排障还原BIOS参数至缺省设置(开机后按[Del]键进入BIOS设置窗口→选中“LoadOptimizedDefaults”项→回车后按[Y]键确认→保存设置退出);恢复注册表(开机后按[F8]键→在启动菜单中选择“Commandpromptonly”方式启动至纯DOS模式下→键入“scanreg/restore”命令→选择一个机器正常使用时的注册表备份文件进行恢复);排除硬件资源冲突(右击[我的电脑]→[属性]→在[设备管理器]标签下找到并双击标有黄色感叹号的设备名称→在[资源]标签下取消“使用自动的设置”选项并单击[更改设置]按钮→找到并分配一段不存在冲突的资源)。检修硬件故障的步骤2.用诊断软件测试使用专门检查、诊断硬件故障的工具软件来帮助查找故障的原因,如NortonTools(诺顿工具箱)等。诊断软件不但能够检查整机系统内部各个部件(如CPU、内存、主板,硬盘等)的运行状况,还能检查整个系统的稳定性和系统工作能力。如果发现问题会给出详尽的报告信息,便于我们寻找故障原因和排除故障。3.直接观察即通过看、听、摸、嗅等方式检查比较明显的故障。例如根据BIOS报警声或Debug卡判断故障发生的部位;观察电源内是否有火花、异常声音;检查各种插头是否松动、线缆是否破损、断线或碰线;电路板上的元件是否发烫、烧焦、断裂、脱焊虚焊;各种风扇是否运转正常等。有的故障现象时隐时现,可用橡皮榔头轻敲有关元件,观察故障现象的变化情况,以确定故障位置。检修硬件故障的步骤4.插拔替换初步确定发生故障的位置后,可将被怀疑的部件或线缆重新插拔,以排除松动或接触不良的原因。例如将板卡拆下后用橡皮擦擦拭金手指,然后重新插好;将各种线缆重新插拔等。如果经过插拔后不能排除故障,可使用相同功能型号的板卡替换有故障的板卡,以确定板卡本身已经损坏或是主板的插槽存在问题。然后根据情况更换板卡。5.系统最小化最严重的故障是机器开机后无任何显示和报警信息,应用上述方法已无法判断故障产生的原因。这时我们可以采取最小系统法进行诊断,即只安装CPU、内存、显卡、主板。如果不能正常工作,则在这四个关键部件中采用替换法查找存在故障的部件。如果能正常工作,再接硬盘……以此类推,直到找出引发故障的罪魁祸首。硬件检修方法1、观察法观察,是维修判断过程中第一要法,它贯穿于整个维修过程中。观察不仅要认真,而且要全面。要观察的内容包括:a、周围的环境;b、硬件环境。包括接插头、座和槽等;c、软件环境;d、用户操作的习惯、过程硬件检修方法2、最小系统法最小系统是指,从维修判断的角度能使电脑开机或运行的最基本的硬件和软件环境。最小系统有两种形式:硬件最小系统:由电源、主板和CPU组成。在这个系统中,没有任何信号线的连接,只有电源到主板的电源连接。在判断过程中是通过声音来判断这一核心组成部分是否可正常工作;软件最小系统:由电源、主板、CPU、内存、显示卡/显示器、键盘和硬盘组成。这个最小系统主要用来判断系统是否可完成正常的启动与运行。硬件检修方法对于软件最小环境,就“软件”有以下几点要说明:a、硬盘中的软件环境,保留着原先的软件环境,只是在分析判断时,根据需要进行隔离如卸载、屏蔽等)。保留原有的软件环境,主要是用来分析判断应用软件方面的问题b、硬盘中的软件环境,只有一个基本的操作系统环境(可能是卸载掉所有应用,或是重新安装一个干净的操作系统),然后根据分析判断的需要,加载需要的应用。需要使用一个干净的操作系统环境,是要判断系统问题、软件冲突或软、硬件间的冲突问题。c、在软件最小系统下,可根据需要添加或更改适当的硬件。如:在判断启动故障时,由于硬盘不能启动,想检查一下能否从其它驱动器启动。这时,可在软件最小系统下加入一个软驱或干脆用软驱替换硬盘来检查。又如:在判断音视频方面的故障时,应需要在软件最小系统中加入声卡;在判断网络问题时,就应在软件最小系统中加入网卡等。最小系统法,主要是要先判断在最基本的软、硬件环境中,系统是否可正常工作。如果不能正常工作,即可判定最基本的软、硬件部件有故障,从而起到故障隔离的作用。硬件检修方法3、逐步添加/去除法逐步添加法,以最小系统为基础,每次只向系统添加一个部件/设备或软件,来检查故障现象是否消失或发生变化,以此来判断并定位故障部位。逐步去除法,正好与逐步添加法的操作相反。逐步添加/去除法一般要与替换法配合,才能较为准确地定位故障部位。4、隔离法是将可能防碍故障判断的硬件或软件屏蔽起来的一种判断方法。它也可用来将怀疑相互冲突的硬件、软件隔离开以判断故障是否发生变化的一种方法。软硬件屏蔽,对于软件来说,即是停止其运行,或者是卸载;对于硬件来说,是在设备管理器中,禁用、卸载其驱动,或干脆将硬件从系统中去除。硬件检修方法5、替换法替换法是用好的部件去代替可能有故障的部件,以判断故障现象是否消失的一种维修方法。好的部件可以是同型号的,也可能是不同型号的。替换的顺序一般为:a、根据故障的现象或故障类别,来考虑需要进行替换的部件或设备;b、按先简单后复杂的顺序进行替换。如:先内存、CPU,后主板,又如要判断打印故障时,可先考虑打印驱动是否有问题,再考虑打印电缆是否有故障,最后考虑打印机或并口是否有故障等;c、最先考查与怀疑有故障的部件相连接的连接线、信号线等,之后是替换怀疑有故障的部件,再后是替换供电部件,最后是与之相关的其它部件。d、从部件的故障率高低来考虑最先替换的部件。故障率高的部件先进行替换。硬件检修方法6、比较法比较法与替换法类似,即用好的部件与怀疑有故障的部件进行外观、配置、运行现象等方面的比较,也可在两台电脑间进行比较,以判断故障电脑在环境设置,硬件配置方面的不同,从而找出故障部位。7、升降温法可在用户同意的情况下,设法降低电脑的通风能力,靠电脑自身的发热来升温;降温的方法有:1)一般选择环境温度较低的时段,如一清早或较晚的时间;2)使电脑停机12~24小时以上等方法实现;3)用电风扇对着故障机吹,以加快降温速度。8、敲打法敲打法一般用在怀疑电脑中的某部件有接触不良的故障时,通过振动、适当的扭曲,甚或用橡胶锤敲打部件或设备的特定部件来使故障复现,从而判断故障部件的一种维修方法。硬件检修方法9、对电脑产品进行清洁有些电脑故障,往往是由于机器内灰尘较多引起的,这就要求我们在维修过程中,注意观察故障机内、外部是否有较多的灰尘,如果是,应该先进行除尘,再进行后续的判断维修。在进行除尘操作中,以下几个方面要特别注意:a、注意风道的清洁b、注意风扇的清洁风扇的清洁过程中,最好在清除其灰尘后,能在风扇轴处,点一点儿钟表油,加强润滑。c、注意接插头、座、槽、板卡金手指部分的清洁金手指的清洁,可以用橡皮擦拭金手指部分,或用酒精棉擦拭也可以。插头、座、槽的金属引脚上的氧化现象的去除:一是用酒精擦拭,一是用金属片(如小一字改锥)在金属引脚上轻轻刮擦。d、注意大规模集成电路、元器件等引脚处的清洁清洁时,应用小毛刷或吸尘器等除掉灰尘,同时要观察引脚有无虚焊和潮湿的现象,元器件是否有变形、变色或漏液现象。e、注意使用的清洁工具清洁用的工具,首先是防静电的。如清洁用的小毛刷,应使用天然材料制成的毛刷,禁用塑料毛刷。其次是如使用金属工具进行清洁时,必须切断电源,且对金属工具进行泄放静电的处理。用于清洁的工具包括:小毛刷、皮老虎、吸尘器、抹布、酒精(不可用来擦拭机箱、显示器等的塑料外壳)。f、对于比较潮湿的情况,应想办法使其干燥后再使用。可用的工具如电风扇、电吹风等,也可让其自然风干。系统报警提示含义1短系统启动正常
1短1短1短系统加电自检初始化失败
1短1短2短主板错误
1短1短3短CMOS或电池失败
1短1短4短ROM
BIOS校验和错误
1短2短1短系统时钟错误
1短2短2短DMA初始化失败
1短2短3短DMA页寄存器错误
1短3短1短RAM刷新错误
1短3短2短基本内存错误
1短3短3短基本内存错误
1短4短1短基本内存地址线错误
1短4短2短基本内存校验错误
BIOS故障案例1、BIOS设置错误,引起内存自检时出错(校验错误)
平常我们买到的内存一般都不带校验,校验内存会比不带校验的内存贵30%到50%,有的原装ECC校验内存更贵得惊人。但是有的用户在BIOS里却把校验一项设为Enable,在内存自检时,会检测不过去,提示内存检测错误,有的人会以为内存校
温馨提示
- 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
- 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
- 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
- 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
- 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
- 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
- 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。
最新文档
- 共享干衣架合同范本
- 舞蹈学校联营合同范本
- 购买冻鱼合同范本
- 学校木门维修合同范本
- 自家房租改造合同范本
- 福建塔吊租赁合同范本
- 合伙经营酒店合同范本
- 劳务木工轻工合同范例
- 分租整体出租合同范例
- 交货延期补偿合同范例
- 《材料分析测试技术》全套教学课件
- 高中生物知识点生物竞赛必备知识归纳总结
- 私募股权投资基金设立谅解备忘录签署版
- 消防水池 (有限空间)作业安全告知牌及警示标志
- 中国传统手工艺中英文介绍
- 土石临时围堰施工方案(内容丰富)
- 小学生认识货币-ppt课件
- 《图形创意设计》PPT课件(完整版)
- 胸腔积液.ppt1
- 建设工程竣工联合验收申请报告及意见表
- 内蒙古高中毕业生学籍表毕业生登记表学年评语表成绩单身体健康检查表完整版高中档案文件
评论
0/150
提交评论