14 操作系统第四章 文件管理 文件逻辑结构 文件目录结构

1 初识文件管理

文件——就是一组有意义的信息/数据集合

文件系统核心问题:

  1. 计算机中存放了各种各样的文件,一个文件有哪些属性? 文件内部的数据应该怎样组织起来? 文件之间又应该又应该怎么组织起来?
  2. 从下往上看,OS应提供哪些功能,才能方便用户、应用程序使用文件?
  3. 从上往下看,文件数据应该怎么存放在外存(磁盘)上?
    在这里插入图片描述
1.1文件属性
  1. 文件名:由创建文件的用户决定文件名,主要是为了方便用户找到文件,同一目录下不允许有重名文件。
  2. 标识符:一个系统内的各文件标识符唯一,对用户来说毫无可读性, 因此标识符只是操作系统用于区分各个文件的一种内部名称。
  3. 类型:指明文件的类型
  4. 位置:文件存放的路径(让用户使用)、在外存中的地址(操作系统 使用,对用户不可见)
  5. 大小:指明文件大小
  6. 创建时间、上次修改时间文件所有者信息
  7. 保护信息:对文件进行保护的访问 控制信息
1.2 文件内部的数据应该怎样组织起来?
  1. 无结构文件(如文本文件)——由一些二进制或字符流组成,又称“流式文件”
    在这里插入图片描述
  1. 有结构文件(如数据库表)——由一组相似的记录组成,又称“记录式文件”
    在这里插入图片描述
    数据项是文件系统中最基本的数据单位
    记录是一组相关数据项的集合

在这里插入图片描述

1.3 文件之间应该怎样组织起来?

在这里插入图片描述

1.4 操作系统应该向上提供哪些功能?
  1. “创建文件”, (点击新建后,图形化交互进程在背后调用了“create系统调用”)
  2. “读文件”,将文件数据读入内存,才能让CPU处理(双击后, “记事本”应用程序通过操作系统提供的“读文件”功能,即read系统调用,将文件数据从外存读入内存,并显示在屏幕上)
    在这里插入图片描述
  3. “写文件”,将更改过的文件数据写回外存(我们在“记事本”应用程序中编辑文件内容,点击“保存”后, “记事本”应用程序通过操作系统提供的“写文件”功能,即write系统调用, 将文件数据从内存写回外存
  4. “删除文件”(点了“删除”之后, 图形化交互进程通过操作系统提供的 “删除文件”功能,即delete系统调用, 将文件数据从外存中删除)

在这里插入图片描述

1.5 文件应如何存放在外存?

在这里插入图片描述
在这里插入图片描述

1.6 文件系统总览

在这里插入图片描述

2 文件逻辑结构

2.1 文件分类

在这里插入图片描述

按文件是否有结构分类,可以分为无结构文件、有结构文件两种。

  1. 无结构文件:文件内部的数据就是一系列二进制流或字符流组成。又称“流式文件”。如:Windows操作系统中的.txt文件。
  2. 有结构文件:由一组相似的记录组成,又称“记录式文件”。每条记录又若干个数据项组成。如:数据库表文件。一般来说,每条记录有一个数据项可作为关键字(作为识别不同记录的ID)
    在这里插入图片描述

有结构文件根据各条记录的长度(占用的存储空间)是否相等,又可分为定长记录和可变长记录两种。

  1. 定长记录
    在这里插入图片描述
  2. 可变长记录
    在这里插入图片描述
2.2 顺序文件

顺序文件:文件中的记录一个接一个地顺序排列(逻辑上),记录可以是定长的或可变长的。各个记录在物理上可以顺序存储或链式存储。
在这里插入图片描述
在这里插入图片描述
假设:已经知道了文件的起始地址(也就是第一个记录存放的位置)
思考1:能否快速找到第i个记录对应的地址?(即能否实现随机存取)
思考2:能否快速找到某个关键字对应的记录存放的位置?

结论:定长记录的顺序文件,若物理上采用顺序存储,则可实现随机存取;
若能再保证记录的顺序结构,则可实现快速检索(即根据关键字快速找到对应记录)
在这里插入图片描述

注:一般来说,考试题目中所说的“顺序文件”指的是物理上顺序存储的顺序文件。之后的讲解中提到的顺序文件也默认如此。
可见,顺序文件的缺点是增加/删除一个记录比较困难(如果是串结构则相对简单)

2.3 索引文件

对于可变长记录文件,要找到第i个记录,必须先顺序第查找前i-1个记录,但是很多应用场景中又必须使用可变长记录。如何解决这个问题?

在这里插入图片描述

  1. 索引表本身是定长记录的顺序文件。因此可以快速找到第i个记录对应的索引项。
  2. 可将关键字作为索引号内容,若按关键字顺序排列,则还可以支持按照关键字折半查找。
  3. 每当要增加/删除一个记录时,需要对索引表进行修改。由于索引文件有很快的检索速度,因此主要用于对信息处理的及时性要求比较高的场合。
2.4 索引顺序文件

思考索引文件的缺点:每个记录对应一个索引表项,因此索引表可能会很大。

比如:文件的每个记录平均只占8B,、而每个索引表项占32个字节,那么索引表都要比文件内容本身大4倍,这样对存储空间的利用率就太低了。

索引顺序文件是索引文件和顺序文件思想的结合。索引顺序文件中,同样会为文件建立一张索引表,但不同的是:并不是每个记录对应一个索引表项,而是一组记录对应一个索引表项。
在这里插入图片描述

若一个顺序文件有10000个记录,则根据关键字检索文件,只能从头开始顺序查找(这里指的并不是定长记录、顺序结构的顺序文件),平均须查找5000个记录。

若采用索引顺序文件结构,可把10000个记录分为V10000=100组,每组100个记录。则需要先顺序查找索引表找到分组(共100个分组,因此索引表长度为100,平均需要查50次),找到分维后,再在分组中顺序查找记录(每个分组100个记录,因此平均需要查50次)。可见,采用索引顺序文件结构后,平均查找次数减少为50+50=100次。

同理,若文件共有106个记录,则可分为1000个分组,每个分组1000个记录。根据关键字检索一个记录平均需要查找500+500=1000次。这个查找次数依然很多,如何解决呢?

2.5 多级索引顺序文件

为了进一步提高检索效率,可以为顺序文件建立多级索引表。

例如,对于一个含106个记录的文件,可先为该文件建立一张低级索引表,每100个记录为一组,故低级索引表中共有10000个表项(即10000个定长记录),再把这10000个定长记录分组,每组100个,为其建立顶级索引表,故顶级索引表中共有100个表项。
在这里插入图片描述

2.6 文件逻辑结构小结

在这里插入图片描述

3 文件目录结构

文件目录结构即我们很熟悉的Windows操作系统的“文件夹”

3.1 文件控制块

在这里插入图片描述

  1. FCB的有序集合称为“文件目录”,一个FCB就是一个文件目录项
  2. FCB中包含了文件的基本信息(文件名、物理地址、逻辑结构、物理结构等),存取控制信息(是否可读/可写、禁止访问的用户名单等),使用信息(如文件的建立时间、修改时间等)。最重要,最基本的还是文件名、文件存放的物理地址。
  3. FCB实现了文件名和文件之间的映射。使用户(用户程序)可以实现“按名存取

需要对目录进行哪些操作?

  1. 搜索:当用户要使用一个文件时,系统要根据文件名搜索目录,找到该文件对应的目录项
  2. 创建文件:创建一个新文件时,需要在其所属的目录中增加一个目录项
  3. 删除文件:当删除一个文件时,需要在目录中删除相应的目录项
  4. 显示目录:用户可以请求显示目录的内容,如显示该目录中的所有文件及相应属性
  5. 修改目录:某些文件属性保存在目录中,因此这些属性变化时需要修改相应的目录项(如:文件重命名)
3.2 目录结构——单级目录结构

早期操作系统并不支持多级目录,整个系统中只建立一张目录表,每个文件占一个目录项。
在这里插入图片描述

单级目录实现了“按名存取”,但是不允许文件重名。在创建一个文件时,需要先检查目录表中有没有重名文件,确定不重名后才能允许建立文件,并将新文件对应的目录项插入目录表中。
显然,单级目录结构不适用于多用户操作系统。

3.3 目录结构——两级目录结构

早期的多用户操作系统,采用两级目录结构。分为主文件目录(MFD,Master File Directory)和用户文件目录(UFD,User Flie Directory)。
在这里插入图片描述

3.4 目录结构——多级目录结构(树形目录结构)

在这里插入图片描述

用户(或用户进程)要访问某个文件时要用文件路径名标识文件,文件路径名是个字符串。各级目录之间用“/”隔开。从根目录出发的路径称为绝对路径。

  1. 系统根据绝对路径一层一层地找到下一级目录。
  2. 刚开始从外存读入根目录的目录表;找到“照片”目录的存放位置后,从外存读入对应的目录表;再找到“2015-08”目录的存放位置,再从外存读入对应目录表;最后才找到文件“自拍.jpg”的存放位置。整个过程需要3次读磁盘I/0操作。
  3. 很多时候,用户会连续访问同一目录内的多个文件(比如:接连查看“2015-08”目录内的多个照片文件),显然,每次都从根目录开始查找,是很低效的。因此可以设置一个“当前目录”。

引入“当前目录”和“相对路径”后,磁盘I/O的次数减少了。这就提升了访问文件的效率。

树形目录结构可以很方便地对文件进行分类,层次结构清晰,也能够更有效地进行文件的管理和保护。但是,树形结构不便于实现文件的共享。为此,提出了“无环图目录结构”。

3.5 目录结构——无环图目录结构

在这里插入图片描述

  1. 可以用不同的文件名指向同一个文件,甚至可以指向同一个目录(共享同一目录下的所有内容)。
  2. 需要为每个共享结点设置一个共享计数器,用于记录此时有多少个地方在共享该结点。用户提出删除结点的请求时,只是删除该用户的FCB、并使共享计数器减1,并不会直接删除共享结点。
  3. 只有共享计数器减为0时,才删除结点。
    注意:共享文件不同于复制文件。在共享文件中,由于各用户指向的是同一个文件,因此只要其中一个用户修改了文件数据,那么所有用户都可以看到文件数据的变化。
3.6 索引结点(FCB的改进)

在这里插入图片描述
其实在查找各级目录的过程中只需要用到“文件名”这个信息,只有文件名匹配时,才需要读出文件的其他信息。因此可以考虑让目录表“瘦身”来提升效率。

  1. 当找到文件名对应的目录项时,才需要将索引结点调入内存,索引结点中记录了文件的各种信息,包括文件在外存中的存放位置,根据“存放位置”即可找到文件。
  2. 存放在外存中的索引结点称为“磁盘索引结点”,当索引结点放入内存后称为“内存索引结点”。
  3. 相比之下内存索引结点中需要增加一些信息,比如:文件是否被修改、此时有几个进程正在访问该文件等。

在这里插入图片描述

思考有何好处?

假设一个FCB64B,磁盘块的大小为1KB,则每个盘块中只能存放16个FCB。若一个文件目录中共有640个目录项,则共需要占用640/16=40个盘块。因此按照某文件名检索该目录,平均需要查询320个目录项,平均需要启动磁盘20次(每次磁盘I/O读入一块)。
若使用索引结点机制,文件名占14B,索引结点指针站2B,则每个盘块可存放64个目录项,那么按文件名检索目录平均只需要读入320/64=5个磁盘块。显然,这将大大提升文件检索速度。

3.7 文件目录小结

在这里插入图片描述
每一级目录结构都是解决了上级目录结构留下的问题

  • 4
    点赞
  • 17
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
图书管理系统的项目结构通常包含以下文件和目录: 1. `index.html`:系统的入口页面,负责展示系统的功能和提供用户登录入口。 2. `css/` 目录:存放系统的样式表文件,包括系统的布局、颜色、字体等方面的定义。 3. `js/` 目录:存放系统的前端JavaScript文件,包括前端页面的逻辑处理、Ajax请求等方面的代码。 4. `images/` 目录:存放系统的图片资源文件,包括系统的图标、背景图片等方面的文件。 5. `lib/` 目录:存放系统所依赖的第三方库文件,包括jQuery、Bootstrap等常用的库文件。 6. `api/` 目录:存放系统后端API接口的代码文件,包括增删改查等操作的处理逻辑。 7. `config/` 目录:存放系统的配置文件,包括数据库连接信息、日志配置等方面的设置。 8. `utils/` 目录:存放系统的工具函数文件,包括一些通用的函数和工具类的定义。 9. `model/` 目录:存放系统的数据模型文件,包括系统中各个实体类的定义,如图书、用户等。 10. `dao/` 目录:存放系统的数据访问对象文件,包括对数据库的增删改查操作的具体实现。 11. `service/` 目录:存放系统的业务逻辑处理文件,包括对数据的校验、数据转换等方面的处理。 12. `controller/` 目录:存放系统的控制器文件,包括处理请求和响应的控制器,如登录控制器、图书管理控制器等。 以上文件和目录的功能是相互关联的,共同构成了一个完整的图书管理系统。我们可以根据需求对其进行扩展和调整,以满足实际业务的需要。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值