计算机操作系统 综合设计实验报告.docx

上传人:b****7 文档编号:9065672 上传时间:2023-02-03 格式:DOCX 页数:25 大小:668.51KB
下载 相关 举报
计算机操作系统 综合设计实验报告.docx_第1页
第1页 / 共25页
计算机操作系统 综合设计实验报告.docx_第2页
第2页 / 共25页
计算机操作系统 综合设计实验报告.docx_第3页
第3页 / 共25页
计算机操作系统 综合设计实验报告.docx_第4页
第4页 / 共25页
计算机操作系统 综合设计实验报告.docx_第5页
第5页 / 共25页
点击查看更多>>
下载资源
资源描述

计算机操作系统 综合设计实验报告.docx

《计算机操作系统 综合设计实验报告.docx》由会员分享,可在线阅读,更多相关《计算机操作系统 综合设计实验报告.docx(25页珍藏版)》请在冰豆网上搜索。

计算机操作系统 综合设计实验报告.docx

计算机操作系统综合设计实验报告

 

西南科技大学计算机科学与技术学院

实验报告

 

课程名称:

计算机操作系统综合设计

实验项目名称:

文件系统的实现

班级:

成员:

 

 

一、概述

文件系统是操作系统用于明确存储设备(常见的是磁盘,也有基于NANDFlash的固态硬盘)或分区上的文件的方法和数据结构;即在存储设备上组织文件的方法。

操作系统中负责管理和存储文件信息的软件机构称为文件管理系统,简称文件系统。

文件系统由三部分组成:

文件系统的接口,对对象操纵和管理的软件集合,对象及属性。

从系统角度来看,文件系统是对文件存储设备的空间进行组织和分配,负责文件存储并对存入的文件进行保护和检索的系统。

具体地说,它负责为用户建立文件,存入、读出、修改、转储文件,控制文件的存取,当用户不再使用时撤销文件等。

二、背景

分成以下四个要点:

(1)文件系统的整体发展

在上个世纪八十年代中期,大多数开放系统文件系统都是标准Unix系统的一部分。

一些厂商如Cray和Amdahl编写了他们自己的文件系统。

这些厂商这么做的原因是标准unix操作系统文件不能满足日常工作的需求。

Solaris操作系统上的UFS来自另一个操作系统,即Multics系统。

现在,许多厂商如Convex、MultiFlow和ThinkingMachines等开发出大量的高性能文件系统。

任何拥有大规模系统的厂商都有自己的文件系统,所有的这些文件系统都试图去解决同样的问题。

我认为它们的可扩展性从大到小依次排列是这样的:

元数据性能、恢复性能、小模块性能、大模块性、存储管理

这里的关键字是可扩展性。

记住,在磁盘密度快速增加的时候,性能的可调整性比现在要强得多。

某些厂商已经开始考虑并行系统,某些则开始对曾经免费提供的文件系统进行收费。

我最近已经在博客中提到了这些内容。

这就象是deja-vu一样,周而复始。

但是由于这篇文章谈的是愚蠢的行为,就让我引用另一位瑜伽修行者瑜伽熊的话来说明问题吧:

“我是比普通的熊要聪明一些。

”试问:

这个行业是否比较聪明呢?

1990年左右,Veritas发布了第一款商用unix操作系统VxFS.这个文件系统试图解决除了存储管理之外的所有问题,Veritas后来还将存储管理功能也添加了进去,推出了VxVM.VxFS对于当时商用unix操作系统的推广是有革命性意义的。

大多数重要厂商都使用过这款产品,或者支持它,或者OEM它。

不久,Veritas又增加了其他一些东西进去,比如可以消除POSIX所要求的写锁限制的DB编辑功能。

虽然Veritas曾凭借这款产品纵横商用系统市场并赚了很多钱,但是SiliconGraphics决定编写自己的文件系统XFS.这款产品于九十年代中期发布。

该产品后来被开源并具备了某些与VxFS一样的功能,因为它的某些开发商与VxFS的开发商是同一批人。

到九十年代末期和新世纪初期,许多厂商拥有了共享文件系统,但是在高性能计算社区,大部分的共享文件系统都是收费的。

大部分的共享文件系统都是通过单一元数据服务器和客户端进行配置的。

同时,一小部分厂商试图利用共享域名空间和分布式空间分配技术来解决共享数据的问题。

结果怎么样呢?

没有一款文件系统是免费的,所有的文件系统都想要解决上面5个领域的所有问题。

从2004年到Sun收购CFS的2007年,只有Lustre一个并行文件系统是例外。

但是它的免费也是相对而言的,因为当时它的大部分资金都来自于美国政府。

它的资金很快就耗尽了,然后就被Sun收购过去。

Sun希望围绕着Lustre文件系统开发出一些硬件来收回这项交易的收购成本。

与此同时,在商用领域,文件系统却在快速向Linux发展。

XFS文件系统包括了许多标准Linux功能,满足了许多要求。

NAS厂商推出的基于设备的存储解决方案也满足了性能方面的许多要求,而且比文件系统厂商销售的许多文件系统更加易于管理。

现在,所有人都开始使用免费的文件系统了,这些文件系统不是八十年代那些厂商推出的免费文件系统,而是来自Linux发布或NAS设备厂商。

存储产品中内置了文件系统。

NAS厂商似乎也没有意识到它们处于可扩展存储行业之中,大型共享文件系统厂商正在开发各种产品以更好地解决上述5个方面的问题。

八十年代的情况与二十年的早期的文件系统行业非常相似,九十年代早期的情况与新世纪前十年的中期的情况相似。

九十年代中期的情况与我们现在的情况非常相似。

计算行业的其他领域可能也出现了类似的情况。

事物每过20年进行一次升级,解决问题的办法并没有太大的不同。

这是为什么呢?

这是因为没人记住历史吗?

这是因为所有人都认为他们比前人更聪明?

事情真有不同吗?

就象时尚、食品准备和无数其他行业的情况一样?

(2)分布式存储的发展演变

第一阶段是1980s的网络文件系统。

这一时期历史背景是以太网技术蓬勃发展,主要研究重点是实现网络环境下的文件共享,解决客户端与文件服务器的交互问题。

这一阶段的主要成果包括CMU/IBM合作研制的AFS文件系统和SUN公司推出的NFS文件系统。

题外话,SUN公司是一家伟大的公司,如Solaris,Java,ZFS,DTrace,每一个产品在技术上都是所向披靡,但可惜的是在商业模式和市场方面做得不好,最后沦落到被收购的结局。

第二阶段是1990s的共享SAN文件系统。

“天下大事,合久必分”。

这一时期存储系统开始独立于计算机系统快速发展,存储区域网络SAN兴起,研究重点转变为解决存储系统的可扩展性和面向SAN的共享文件系统。

在这一阶段重量级的产品是IBM研制的GPFS,以及由Redhat支持的开源项目GFS(GlobalFileSystem,不是Google的GFS哦!

)。

这里重点提一下,GPFS可谓是文件系统的常青树,而且能够保持与时俱进,不仅在HPC中占据重要地位,还能够通过SoNAS/GSS在云计算领域保持竞争力。

第三阶段是2000s的面向对象并行文件系统。

计算机技术不断发展,尤其是高速网络技术的发展,这对存储系统扩展性提出了更高的需求,急需突破容量和性能方面的瓶颈。

相应的,研究重点主要集中在对象存储技术,如何进行高效的元数据管理和提高数据访问的并发性。

这一阶段可谓是百家争鸣,尤其是开源系统异常繁荣,包括PVFS,Panasas,Lustre,Ceph,GFS(这里才是GoogleFileSystem)等。

简要说一下对象存储(Object-basedStorage),这是一种新的网络存储架构,综合了NAS和SAN的优点,同时具有SAN的高速直接访问和NAS的分布式数据共享等优势,提供了具有高性能、高可靠性、跨平台以及安全的数据共享的存储体系结构。

第四阶段是2010s的云文件系统。

云计算和大数据从噱头而起,现在已经慢慢开始真正落地。

在这样的背景下,数据呈现爆炸式增长趋势。

根据研究显示,2020年数字宇宙将达到40ZB,比2009年的0.8ZB猛增50倍,这其中80%以上为非结构化数据。

云存储要求弹性扩展、高可用、高性能、多租户和QoS保证,大数据则有4V(Volume、Velocity、Variety、Value)特征,这对数据存储和管理提出新的挑战。

在这一阶段,研究重点是EB级大规模存储系统,数据高可用性方法(如复制、HA、纠错码),高效智能存储技术(如消重、压缩、分层),以及新型的计算存储融合系统和应用感知(Application-aware,比如虚拟化)存储。

目前很多分布式文件系统都在往的云的方向发展,诸如GPFS、ISILON、OceanStor9000、GlusterFS、Ceph等,但离真正的云文件系统都还有很大的差距。

(3)不足及改进

分布式文件系统是云计算平台的核心技术之一,也是当前的研究热点。

业界先后涌现了很多分布式文件系统,如GFS、HDFS、KosmosFS、MooseFS、Haystack、TFS等。

其中,HDFS是GFS的开源版,研究较为广泛,已被Yahoo、Cloudera,Mapr等大量商用。

GFS和HDFS都是为海量大文件的高效存储和访问而设计的,它们首先将用户大文件切分为若干64M的数据块,并将元数据(如用户大文件、数据块以及数据服务器之间的映射关系)存放在一个元数据服务器中,将数据块以文件的形式存放在数据服务器中。

在处理小文件时,系统中的文件个数和数据块数急剧增加,带来两个问题:

a.文件总数受限问题:

元数据量急剧增加,使得文件个数和数据块数受元数据服务器内存容量限制;

b.性能问题:

传统文件系统处理小文件的性能较低,造成数据服务器处理小文件的性能急剧下降。

因此它们并不适合处理小文件任务。

如何提高分布式文件系统处理海量小文件的能力已经成为亟待解决的问题。

目前主要有三种方法来解决分布式文件系统处理小文件时文件总数受限问题。

a.将若干小文件合并到大数据块中,如Facebook的Haystack、淘宝的TFS、HadoopArchive、SequenceFile等。

前两者属于系统级解决方案,修改分布式文件系统本身,后两者属于应用级解决方案,是建立在HDFS之上的文件打包工具。

这种方法在数据访问时依赖多级索引,适合处理KB级的超小文件,效率较低。

b.分组存储技术,如FastDFS,将集群分为多个组,同组内的存储服务器之间是互备关系。

该技术的缺点是不支持大文件存储,且在组内数据服务器配置不一致的时候存在空间浪费现象。

c.减小数据块大小,如Google的下一代分布式文件系统GFS2,采用了分布式元数据服务器并将数据块大小从64M减小为1M。

但是由于传统文件系统处理小文件时性能较低,导致数据服务器的性能低下,整体性能受到很大制约。

所有的GFS开源实现版本,如HDFS、KosmosFS、MooseFS等,在处理小文件时均存在类似的问题。

对于大部分数据为MB级文件的应用场景,GFS2的方法更合适。

(4)发展情况

如何为文件系统提供更完备和更强伸缩性的安全保障是安全文件系统研究的重要方面。

NTFS文件系统是一个基于安全性的文件系统,是WindowsNT所采用的独特的文件系统结构,它是建立在保护文件和目录数据基础上,同时照顾节省存储资源、减少磁盘占用量的一种先进的文件系统。

使用非常广泛的WindowsNT4.0采用的就是NTFS4.0文件系统,相信它所带来的强大的系统安全性一定给广大用户留下了深刻的印象。

Win2000采用了更新版本的NTFS文件系统NTFS5.0,它的推出使得用户不但可以像Win9X那样方便快捷地操作和管理计算机,同时也可享受到NTFS所带来的系统安全性。

分层文件系统(HierarchicalFileSystem,HFS)是一种由苹果电脑开发,并使用在MacOS上的文件系统。

最初被设计用于软盘和硬盘,同时也可以在在只读媒体如CD-ROM上见到。

UFS文件系统:

基于BSD高速文件系统的传统UNIX文件系统,是Solaris的默认文件系统。

默认启用UFS日志记录功能。

在早期的Solaris版本中,UFS日志记录功能只能手动启用。

Solaris10在运行64位Solaris内核的系统上支持多TBUFS文件系统。

以前,UFS文件系统在64位系统和32位系统上的大小仅限于约1TB(Tbyte)。

现在,所有UFS文件系统命令和公用程序已更新为支持多TBUFS文件系统。

还有很多如FAT、CDFS、RAW、Ext等文件系统,分别基于不同原理进行的实现。

 

三、建立实现概要

1、在内存中开辟一个虚拟磁盘空间作为文件存储分区,在其上实现一个简单的基于多级目录的但用户单任务系统的文件系统。

在退出文件系统的使用时,应将虚拟文件系统以一个Windows文件的方式保存到磁盘中,以便下次再将它恢复到内存的虚拟磁盘空间中

2、文件存储空间的分配可采用显示链接分配或其它方法

3、空闲磁盘空间的管理可选择位示图或其它方法

4、文件目录结构采用多级目录结构

5、需要提供一以下操作命令

表3.1操作命令

命令

功能

format

对磁盘格式化

exit

安全退出该文件系统,保存信息

mkdirdirname

创建子目录

rmdirdirname

删除子目录

lsdirname

显示当前目录下信息

cddirname

更改当前目录

createfilename

创建一个新文件,并且打开

writefilename

选择一个打开的文件写入信息

readfilename

选择一个打开的文件读取信息

rmfilename

删除文件

openfilename

打开文件

closefilename

关闭文件

说明:

dirname:

代表文件夹的名称

filename:

代表文本文件的名称

6、在实现以上命令操作的同时,提供一些错误判断以及逻辑上的事务提示

 

四.实验步骤

4.1思路流程图

1、总体流程图

图4.1整体代码流程图

图4.1为整个代码思路的流程图,主要表明了从初始化到退出系统(即退出运行程序)的全部过程。

2、函数流程图

(1)创建子目录函数流程图

图4.2创建子目录函数流程图

(2)删除子目录函数流程图

图4.3删除子目录函数流程图

(3)当前目录下创建文本文件函数流程图

图4.4创建文本文件函数流程图

(4)查询子目录函数流程图

图4.5创建文本文件函数流程图

(5)删除文本文件函数流程图

图4.6删除文本文件函数流程图

(6)更改当前目录函数流程图

图4.7更改当前目录函数流程图

(7)退出系统函数流程图

图4.8更改当前目录函数流程图

(8)打开的文件中写入信息函数流程图

图4.9写入信息函数流程图

(9)初始化文件系统函数流程图

图4.10初始化函数流程图

(10)打开的文件读取信息函数流程图

图4.11读取信息函数流程图

 

(11)打开文件函数流程图

图4.12打开文件函数流程图

(12)关闭文件函数流程图

图4.13关闭文件函数流程图

4.2、代码实现

代码由c++语言编写,部分函数依赖c++自带的函数,具体代码主要由上述流程图的过程实现,以下在代码中定义的数据结构、函数及说明:

图4.14文件信息结构体

图4.14的结构体,主要记录文件各种标志详细

图4.15常量设置

图4.16用户文件打开表结构体

 

图4.17目录文件结构体

 

图4.18文件关系结构体

图4.19全局变量及函数声明

4.3函数说明

函数format():

初始化虚拟磁盘

具体操作:

清空当前状态下虚拟磁盘空间中的所有数据,打开根目录,从根目录开始从头操作。

函数mkdir(char*sonfname):

创建子文件夹

具体操作:

获取当前目录,判断当前目录下有没有和需要创建的名称和类型重复,再判断当前目录空间是否已满;最后查看磁盘空间是否已满;如以上三个条件已满足(不重名,目录空间充足,磁盘空间充足),就对子文件夹进行与之对应的分配。

函数rmdir(char*sonfname):

删除子文件夹

具体操作:

获取当前目录,查看当前目录中是否有此文件夹,如有再确定此文件夹是否为空,文件夹为空,则开始对此文件夹各数据进行初始化操作。

函数create(char*name):

创建文本文件

具体操作:

获取当前目录,判断当前目录下有没有和需要创建的名称和类型重复,再判断当前目录空间是否已满;最后查看磁盘空间是否已满;如以上三个条件已满足(不重名,目录空间充足,磁盘空间充足),就对文本文件进行与之对应的分配。

函数listshow():

查询当前目录下文件持有状况

具体操作:

获取当前目录,对当前目录进行扫描,将文件夹和文本文件区分开,并统计各自的个数。

函数delfile(char*name):

删除文本文件

具体操作:

获取当前目录,查看当前目录中是否有此文本文件如有,在此文件夹下对此文本文件的各数据进行初始化操作。

函数changePath(char*sonfname):

改变当前操作目录(进入只能是此时的子目录或根目录)

具体操作:

获取当前目录,判断子目录内有没有传参的目录(特别考虑根目录情况,用cd..表示进入根目录),再将当前目录的各种参数改成要进入目录的参数。

函数exit():

保存并退出系统

具体操作:

关闭所有文件,将现在的内存情况存入指定的电脑地址中,释放内存上的虚拟磁盘,释放用户打开文件表。

函数write(char*name):

在指定的文件里写入信息

具体操作:

在打开文件列表中查找需要写入信息的文本文件(考虑同名不同目录文件的情况),如各项符合,在文本中输入信息,还需考虑文件容量问题。

函数read(char*file):

选择一个打开的文件读取信息

具体操作:

在打开文件列表中查找需要写入信息的文本文件(考虑同名不同目录文件的情况),如各项符合,将文件中的内容读取出来,显示在运行框中。

函数open(char*file):

当前目录下添加一个打开文件

具体操作:

如该文本文件在当前目录下,确保该文件未被打开(考虑同名不同源的问题),确保未达到打开文件列表的上线,方可对该文本文件进行打开操作。

函数close(char*file):

关闭当前目录下的一个已打开的文件

具体操作:

查看该文件是否在打开列表中(考虑同名不同源的问题),如满足已打开的条件,则可以作相应关闭操作。

五、成果展示

运行界面如图5.1所示:

图5.1运行截图1

此时已创建了一个名称为myfire的文件,然后作如下操作:

(1)创建子文件,如图5.2:

图5.2运行截图2

如果再次创建的文件名字已经存在,则提示已经存在该文件夹:

如图5.3所示:

图5.2运行截图3

成功创建子文件,然后再创建两个文本文件,如下操作:

图5.4运行截图4

对其中一个文本文档添加内容,操作如下:

图5.5运行截图5

 

如果在文件加下打开文件而不是文本文档,则提示如上图说是的不存在改文件,然后我们再选择一个文本文档操作,先打开,然后在里面写下内容,如下图5.6:

图5.6运行截图6

 

将刚刚写入的内容读取出来,操作完成之后关闭文档,若再次想读取,则必须再次打开文档,否则提示文档未打开,如图:

图5.7运行截图7

 

然后进行删除操作,不同的删除方法对应不同的文件类型,如果调用错误,则找不到该文件或者我的那个,如下,如果成功删除则提示成功删除,如果删除的文件不存在,则提示不存在改文件,如图:

图5.8运行截图8

 

删除文本文档也一样如下图:

图5.9运行截图9

 

但是如果删除的文件夹下存在其他文件夹,则提示该文件不为空,如图:

图5.10运行截图10

 

接下来展示如何进入任意一个文件,然后任然可以进行以上所有操作,如下图所示:

图5.11运行截图11

然后如果要返回上一级,则操作如下:

图5.12运行截图12

操作完成之后,如果需要保存刚才的操作关闭,则如图:

图5.13运行截图13

 

然后我们再次进入检查是否保存了之前的操作,如图:

图5.14运行截图14

结果如图所示,则说明保存成功,然后对其进行格式化,如图:

图5.15运行截图15

由结果可知已经对其格式化。

六、综合小结

面向海量数据处理的分布式文件系统是当前的热点研究之一。

目前,大多数分布式文件系统侧重于大文件的高效存储和访问,在海量小文件处理研究方面仅解决了可用性问题而没有解决性能问题。

文件的系统是操作系统用于明确磁盘或分区上的文件的方法和数据结构;即在磁盘上组织文件的方法。

也指用于存储文件的磁盘或分区,或文件系统种类。

磁盘或分区和它所包括的文件系统的不同是很重要的。

少数程序(包括最有理由的产生文件系统的程序)直接对磁盘或分区的原始扇区进行操作;这可能破坏一个存在的文件系统。

大部分程序基于文件系统进行操作,在不同种文件系统上不能工作。

一个分区或磁盘在作为文件系统使用前,需要初始化,并将记录数据结构写到磁盘上。

这个过程就叫建立文件系统。

大部分UNIX文件系统种类具有类似的通用结构,即使细节有些变化。

其中心概念是超级块superblock,i节点inode,数据块datablock,目录块directoryblock,和间接块indirectionblock。

超级块包括文件系统的总体信息,比如大小(其准确信息依赖文件系统)。

i节点包括除了名字外的一个文件的所有信息,名字与i节点数目一起存在目录中,目录条目包括文件名和文件的i节点数目。

i节点包括几个数据块的数目,用于存储文件的数据。

i节点中只有少量数据块数的空间,如果需要更多,会动态分配指向数据块的指针空间。

这些动态分配的块是间接块;为了找到数据块,这名字指出它必须先找到间接块的号码。

 

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 解决方案 > 学习计划

copyright@ 2008-2022 冰豆网网站版权所有

经营许可证编号:鄂ICP备2022015515号-1