# 初识文件管理

# 回顾

计算机中存放了各种各样的文件，一个文件有哪些属性？

$\color{red}文件内部$ 的数据应该怎样组织起来？

$\color{red}文件之间$ 又应该又应该怎么组织起来？

从下往上看， OS 应提供哪些功能，才能方便用户、应用程序使用文件？

从上往下看，文件数据应该怎么存放在外存（磁盘）上？

# 文件的属性

一个文件有哪些属性？

$\color{red}文件名$ ：由创建文件的用户决定文件名，主要是为了方便用户找到文件， $\color{red}同一目录下不允许有重名文件$ 。

$\color{red}标识符$ ：一个系统内的各文件标识符唯一，对用户来说毫无可读性，因此标识符只是操作系统用于区分各个文件的一种内部名称。

$\color{red}类型$ ：指明文件的类型

$\color{red}位置$ ：文件存放的路径（让用户使用）、在外存中的地址（操作系统使用，对用户不可见）

$\color{red}大小$ ：指明文件大小

$\color{red}创建时间、上次修改时间$

$\color{red}文件所有者信息$

$\color{red}保护信息$ ：对文件进行保护的访问控制信息

# 无结构文件 / 有结构文件

有结构文件中，各个记录间应该如何组织的问题―— 应该顺序存放？还是用索引表来表示记录间的顺序？――这是 “文件的逻辑结构” 重点要探讨的问题

# 文件之间应该怎样组织起来？

# 操作系统应该向上提供哪些功能？

读 / 写文件之前，需要 "打开文件"

读 / 写文件结束之后，需要 "关闭文件"

可用几个基本操作完成更复杂的操作

比如：“复制文件”：先创建一个新的空文件，再把源文件读入内存，再将内存中的数据写到新文件中

操作系统在背后做的处理会在之后进行探讨

# 从上往下看，文件应如何存放在外存？

与内存一样，外存也是由一个个存储单元组成的，每个存储单元可以存储一定量的数据（如 1 B）。

每个存储单元对应一个物理地址

类似于内存分为一个个 “内存块” ，外存会分为一个个 “ $\color{red}块/磁盘块/物理块$ ” 。

每个磁盘块的大小是相等的，每块一般包含 2 的整数幂个地址

如本例中，一块包含 210 个地址，即 1 KB。

同样类似的是，文件的逻辑地址也可以分为（逻辑块号，块内地址），操作系统同样需要将逻辑地址转换为外存的物理地址（物理块号，块内地址）的形式。块内地址的位数取决于磁盘块的大小

操作系统以 “ $\color{red}块$ ” 为单位为文件分配存储空间，因此即使一个文件大小只有 10 B，但它依然需要占用 1 KB 的磁盘块。外存中的数据读入内存时同样以块为单位

# 其他需要由操作系统实现的文件管理功能

文件共享：使多个用户可以共享使用一个文件

文件保护：如何保证不同的用户对文件有不同的操作权限

# 整体框架

# 文件的逻辑结构

所谓的 “逻辑结构”，就是指在用户看来，文件内部的数据应该是如何组织起来的。

而 “物理结构” 指的是在操作系统看来，文件的数据是如何存放在外存中的。

类似于数据结构的 “逻辑结构” 和 “物理结构”。

如 “线性表” 就是一种逻辑结构，在用户角度看来，线性表就是一组有先后关系的元素序列

如: a，b，c，d，e ......

“线性表” 这种逻辑结构可以用不同的物理结构实现，

如：顺序表 / 链表。

顺序表的各个元素在逻辑上相邻，在物理上也相邻；
而链表的各个元素在物理上可以是不相邻的。
因此，顺序表可以实现 “随机访问” ，而 “链表” 无法实现随机访问。

可见，算法的具体实现与逻辑结构、物理结构都有关

文件也一样，文件操作的具体实现与文件的逻辑结构、物理结构都有关

# 无结构文件（流式文件）

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

$\color{red}无结构文件$ ：文件内部的数据就是一系列二进制流或字符流组成。又称 “ $\color{red}流式文件$ ”。

如：Windows 操作系统中的 .txt 文件。

文件内部的数据其实就是一系列字符流，没有明显的结构特性。

因此也不用探讨无结构文件的 “逻辑结构 " 问题。

# 有结构文件

$\color{red}有结构文件$ ：由一组相似的记录组成，又称 “ $\color{red}记录式文件$ ”。每条记录又若干个数据项组成。

如：数据库表文件。一般来说，每条记录有一个数据项可作为 $\color{red}关键字$ （作为识别不同记录的 ID )

根据各条记录的长度（占用存储空间）是否相等，可分为 $\color{red}定长记录$ 和 $\color{red}可变长记录$ 两种

例如： mysql 中的 varchar 和 char

例如：定长记录

例如：可变长记录

# 顺序文件

$\color{red}顺序文件$ ：文件中的记录一个接一个地顺序排列（逻辑上），记录可以是 $\color{red}定长的$ 或 $\color{red}可变长的$ 。各个记录在物理上可以 $\color{red}顺序存储$ 或 $\color{red}链式存储$ 。

假设：已经知道了文件的起始地址（也就是第一个记录存放的位置）

思考 1：能否快速找到第 i 个记录对应的地址？（即能否实现随机存取）

思考 2：能否快速找到某个关键字对应的记录存放的位置？

结论：定长记录的顺序文件，若物理上采用顺序存储，则可实现随机存取；若能再保证记录的顺序结构，则可实现快速检索（即根据关键字快速找到对应记录）

注：一般来说，考试题目中所说的 “顺序文件” 指的是 $\color{red}物理上顺序存储的顺序文件$ 。之后的讲解中提到的顺序文件也默认如此。

可见，顺序文件的 $\color{red}缺点$ 是 $\color{red}增加/删除一个记录比较困难$ （如果是串结构则相对简单）

在实际应用当中，为了减少磁盘的 I/O 次数，一般操作系统会管理日志文件，用这个日志文件记录对各个文件修改的信息，每隔一段较长的时间，再把这些信息统一的合并到外存当中的文件数据当中

# 索引文件

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

$\color{red}索引表$ 本身是 $\color{red}定长记录的顺序文件$ 。因此可以快速找到第 i 个记录对应的索引项。

可将关键字作为索引号内容，若按关键字顺序排列，则还可以支持按照关键字折半查找。

每当要增加 / 删除一个记录时，需要对索引表进行修改。

由于索引文件有很快的检索速度，因此 $\color{red}主要用于对信息处理的及时性要求比较高的场合$ 。

另外， $\color{red}可以用不同的数据项建立多个索引表$ 。

如：学生信息表中，可用关键字 “学号” 建立一张索引表。也可用 “姓名” 建立一张索引表。这样就可以根据 “姓名” 快速地检索文件了。
（Eg： SQL 就支持根据某个数据项建立索引的功能）

# 索引顺序文件

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

比如：文件的每个记录平均只占 8 B，而每个索引表项占 32 个字节，那么索引表都要比文件内容本身大 4 倍，

这样对存储空间的利用率就太低了。

例如：分块查找。组间有序，组内无序

用这种策略确实可以让索引表 “瘦身”，但是是否会出现不定长记录的顺序文件检索速度慢的问题呢？

# 索引顺序文件（检索效率分析）

若一个 $\color{red}顺序文件$ 有 10000 个记录，则根据关键字检索文件，只能从头开始顺序查找（这里指的并不是定长记录、顺序结构的顺序文件）， $\color{red}平均须查找 5000 个记录$ 。

(1 + 2 + 3 + ...... + n) / (n + 1) ：设每次再任意位置找到记录的概率相同

若采用 $\color{red}索引顺序文件$ 结构，可把 10000 个记录分为 √10000 = 100 组，每组 100 个记录。

则需要先顺序查找索引表找到分组（共 100 个分组，因此索引表长度为 100 ，平均需要查 50 次)，找到分组后，再在分组中顺序查找记录（每个分组 100 个记录，因此平均需要查 50 次）。

可见，采用索引顺序文件结构后， $\color{red}平均查找次数减少为 50 + 50 = 100 次$ 。

可以理解为查字典，先查目录找到相应的位置范围，再位置范围内查找

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

# 多级索引顺序文件

为了进一步提高检索效率，可以为顺序文件 $\color{red}建立多级索引表$ 。例如，对于一个含 106 个记录的文件，可先为该文件建立一张低级索引表，每 100 个记录为一组，故低级索引表中共有 10000 个表项（即 10000 个定长记录），再把这 10000 个定长记录分组，每组 100 个，为其建立顶级索引表，故顶级索引表中共有 100 个表项。

例如：B+ 树

# 整体框架

# 文件目录

这种目录结构对于用户来说有什么好处？

文件之间的组织结构清晰，易于查找

编程时也可以很方便的用文件路径找到一个文件

从操作系统的角度来看，这些目录应该是如何实现的？

就是我们很熟悉的 Windows 操作系统的 "文件夹"

# 文件控制块

目录本身就是一种有结构的文件，由一条条记录组成。每一条记录对应一个放在该目录下的文件

当我们双击 “照片” 后，操作系统会在这个目录表中找到关键字 “照片” 对应的目录项（也就是记录)，

然后从外存中将 “照片” 目录的信息读入内存，于是，“照片” 目录中的内容就可以显示出来了。

FCB 的有序集合称为 “文件目录”，一个 FCB 就是一个文件 $\color{red}目录项$ 。

FCB 中包含了文件的 $\color{red}基本信息$ （ $\color{red}文件名$ 、 $\color{red}物理地址$ 、逻辑结构、物理结构等），存取控制信息（是否可读 / 可写、禁止访问的用户名单等），使用信息（如文件的建立时间、修改时间等）。

$\color{red}最重要, 最基本的$ 还是 $\color{red} 文件名、文件存放的物理地址$

FCB 实现了文件名和文件之间的映射。使用户（用户程序）可以实现 “按名存取”

$\color{red}目录文件$ ：是文件目录以文件的形式保存在外存中的文件

# 需要对目录进行哪些操作？

$\color{red}搜索$ ：当用户要使用一个文件时，系统要根据文件名搜索目录，找到该文件对应的目录项

$\color{red}创建文件$ ：创建一个新文件时，需要在其所属的目录中增加一个目录项

$\color{red}删除文件$ ：当删除一个文件时，需要在目录中删除相应的目录项

$\color{red}显示目录$ ：用户可以请求显示目录的内容，如显示该目录中的所有文件及相应属性

$\color{red}修改目录$ ：某些文件属性保存在目录中，因此这些属性变化时需要修改相应的目录项

如：文件重命名

# 单级目录结构

早期操作系统并不支持多级目录，整个系统中只建立一张目录表，每个文件占一个目录项。

单级目录实现了 "按名存取"，但是 $\color{red}不允许文件重名$

在创建一个文件时，需要先检查目录表中有没有重名文件，确定不重名后才能允许建立文件，并将新文件对应的目录项（ FCB ）插入目录表中。

显然，单级目录结构不适用于多用户操作系统

# 两级目录结构

早期的多用户操作系统，采用两级目录结构。分为 $\color{red}主文件目录$ （MFD，Master File Directory）和 $\color{red}用户文件目录$ （UFD，User Flie Directory) 。

$\color{red}允许不同用户的文件重名$ 文件民虽然相同，但是对应的其实是不同的文件

两级目录结构允许不同用户的文件重名，也可以在目录上实现实现访问限制（检查此时登录的用户名是否匹配）。

但是两级目录结构依然缺乏灵活性，用户不能对自己的文件进行分类。

# 多级目录结构

用户（或用户进程）要访问某个文件时要用文件路径名标识文件，文件路径名是个字符串。

各级目录之间用 “/” 隔开。从 $\color{red}根目录$ 出发的路径称为 $\color{red}绝对路径$ 。

例如： $\color{red}自拍.jpg 的绝对路径是 "照片/2015-08/自拍.jpg"$

系统根据绝对路径一层一层地找到下一级目录。

刚开 $\color{red}始从外存读入根目录的目录表$ ；找到 “照片” 目录的存放位置后，从外存读入对应的目录表；
再找到 “2015-08” 目录的存放位置，再从 $\color{red}外存读入对应目录表$ ；
最后才找到文件 “自拍.jpg” 的存放位置。
整个过程 $\color{red}需要 3 次读磁盘 l/O操作$ 。

很多时候，用户会连续访问同一目录内的多个文件

比如：接连查看 “2015-08" 目录内的多个照片文件

显然，每次都从根目录开始查找，是很低效的。因此可以设置一个 “ $\color{red}当前目录$ ”。

例如，此时已经打开了 “照片” 的目录文件，也就是说，这张目录表已调入内存，那么可以把它设置为 “当前目录”。当用户想要访问某个文件时，可以使用 $\color{red}从当前目录出发$ 的 “ $\color{red}相对路径$ ”。

可见，引入 “ $\color{red}当前目录$ ” 和 " $\color{red}相对路径$ " 后，磁盘 I/O 的次数减少了。这就提升了访问文件的效率。

只需要从当前目录开始，而不需要重新从根目录开始查询

$\color{red}树形目录结构$ 可以很方便地对文件进行分类，层次结构清晰，也能够更有效地进行文件的管理和保护。

但是，树形结构 $\color{red}不便于实现文件的共享$ 。为此，提出了 “ $\color{red}无环图目录结构$ ”。

# 无环图目录结构

$\color{red}可以用不同的文件名指向同一个文件$ ，甚至可以指向同一个目录（共享同一目录下的所有内容）。

需要为 $\color{red}每个共享结点设置一个共享计数器$ ，用于记录此时有多少个地方在共享该结点。用户提出删除结点的请求时，只是删除该用户的 FCB 、并使 $\color{red}共享计数器减 1$ ，并不会直接删除共享结点。

$\color{red}只有共享计数器减为 0 时，才删除节点$

注意：共享文件不同于复制文件。 $\color{red}在共享文件中，由于各用户指向的是同一个文件，因此只要其中一个用户修改了文件数据，那么所有用户都可以看到文件数据的变化。$

其实就是：硬链接

# 索引节点（FCB 的改进）

按照文件名搜索文件时，并不需要关心其他信息。

思考有何好处？

假设一个 FCB 是 64 B，磁盘块的大小为 1 KB，则每个盘块中只能存放 16 个 FCB 。若一个文件目录中共有 640 个目录项，则共需要占用 640 / 16 = 40 个盘块。因此按照某文件名检索该目录，平均需要查询 320 个目录项， $\color{red}平均需要启动磁盘 20 次（每次磁盘 I/O 读入一块）$ 。

若 $\color{red}使用索引结点机制$ ，文件名占 14 B，索引结点指针占 2 B，则每个盘块可存放 64 个目录项，那么按文件名检索目录 $\color{red}平均只需要读入 320 / 64 = 5 个磁盘块$ 。显然，这 $\color{red}将大大提升文件检索速度$

其实就是索引节点指针大小小，相应的该文件目录项也就小，一个磁盘块可以放更多的文件目录项

当找到文件名对应的目录项时，才需要将索引结点调入内存，索引结点中记录了文件的各种信息，包括文件在外存中的存放位置，根据 “存放位置” 即可找到文件。

存放 $\color{red}在外存中$ 的索引结点称为 “ $\color{red}磁盘索引结点$ ”，当索引结点 $\color{red}放入内存$ 后称为 “ $\color{red}内存索引结点$ ”。

相比之下 $\color{red}内存索引结点中需要增加一些信息$

比如：文件是否被修改、此时有几个进程正在访问该文件等。

# 整体框架

# 文件的物理结构（文件分配方式）（对非空闲磁盘块的管理）

# 文件块、磁盘块

类似于内存分页，磁盘中的存储单元也会被分为一个个 “块 / 磁盘块 / 物理块”。

很多操作系统中， $\color{red}磁盘块的大小与内存块、页面的大小相同$

内存与外存进行数据交换的时候会很方便

在内存管理中，进程的逻辑地址空间被分为一个一个页面

同样的，在外存管理中，为了方便对文件数据的管理， $\color{red}文件的逻辑地址空间也被分为了一个一个的文件“块”$ 。

于是文件的逻辑地址也可以表示为 $\color{red}（逻辑块号，块内地址）$ 的形式。

# 连续分配

$\color{red}连续分配$ 方式要求 $\color{red}每个文件在磁盘上占有一组连续的块$ 。

用户通过逻辑地址来操作自己的文件，操作系统如何实现从逻辑地址到物理地址的映射？

（逻辑块号，块内地址）→（物理块号，块内地址）。

只需转换块号就行，块内地址保持不变

用户给出要访问的逻辑块号，操作系统找到该文件对应的目录项（ FCB ）

$\color{red}物理块号 = 起始块号＋逻辑块号$

例如：访问文件 "aaa" 的逻辑块号为 2 的物理地址：4（起始块号）+ 2（逻辑块号）

当然，还需要检查用户提供的逻辑块号是否合法（逻辑块号 ≥ 长度就不合法）

可以直接算出逻辑块号对应的物理块号，因此 $\color{red}连续分配支持顺序访问和直接访问（即随机访问）$

顺序访问：若访问逻辑块号 2，则必须先访问逻辑块号 0 和 1
直接访问：若访问逻辑块号 2，则没有必要先访问逻辑块号 0 和 1，可以直接访问逻辑块号 2

# 优点

读取某个磁盘块时，需要移动磁头。访问的两个磁盘块相隔越远，移动磁头所需时间就越长。

若读取紫色的磁盘块，需要读取之间其他不需要的磁盘块

结论： $\color{red}连续分配的文件在顺序读/写时速度最快$

# 缺点

若此时文件 A 要拓展，需要再增加一个磁盘块（总共需要连续的 4 个磁盘块）。

由于采用连续结构，因此文件 A 占用的磁盘块必须是连续的。

因此只能将文件 A 全部 “迁移” 到绿色区域。

结论：物理上采用 $\color{red}连续分配的文件不方便拓展$

类比于在数组中插入一个数据，要么后面的数据右移，要么当前连续的数据移到其中空闲的区域

结论：物理上采用 $\color{red}连续分配，存储空间利用率低，会产生难以利用的磁盘碎片$

可以用 $\color{red}紧凑$ 来处理碎片，但是需要耗费很大的时间代价。

因为剩余空闲的磁盘块离散的存放，而导致当前连续的文件无法为其分配连续的足够的存储空间

# 总结

$\color{red}优点$ ：支持顺序访问和直接访问（即随机访问）；连续分配的文件在顺序访问时速度最快

$\color{red}缺点$ ：不方便文件拓展；存储空间利用率低，会产生磁盘碎片

# 链接分配

$\color{red}链接分配$ 采取离散分配的方式，可以为文件分配离散的磁盘块。分为 $\color{red}隐式链接$ 和 $\color{red}显式链接$ 两种。

# 隐式链接

# 如何实现文件的逻辑块号到物理块号的转变？

从目录项中找到起始块号（即 0 号块），将 0 号逻辑块读入内存，由此知道 1 号逻辑块存放的物理块号，于是读入 1 号逻辑块，再找到 2 号逻辑块的存放位置....… 以此类推。

因此，读入 i 号逻辑块，总共需要 i +1 次磁盘 l/O 。

结论：采用 $\color{red}链式分配（隐式链接）$ 方式的文件， $\color{red}只支持顺序访问，不支持随机访问$ ，查找效率低。

只有知道了前一个逻辑块号的物理地址，才知道当前逻辑块号（由前面一个逻辑块推出来）

另外，指向下一个盘块的指针也需要耗费少量的存储空间。

是否方便拓展文件？

只需随便在磁盘中找到一个空闲的块，并将其挂到链尾即可

结论：采用隐式链接的 $\color{red}链接分配方式，很方便文件拓展$ 。

另外，所有的空闲磁盘块都可以被利用， $\color{red}不会有碎片问题，外存利用率高$ 。

# 总结

$\color{red}隐式链接$ ――除文件的最后一个盘块之外，每个盘块中都存有指向下一个盘块的指针。文件目录包括文件第一块的指针和最后一块的指针。

$\color{red}优点$ ：很方便文件拓展，不会有碎片问题，外存利用率高。

$\color{red}缺点$ ：只支持顺序访问，不支持随机访问，查找效率低，指向下一个盘块的指针也需要耗费少量的存储空间。

# 显示链接（FAT）

把用于链接文件各物理块的指针显式地存放在一张表中。即文件分配表（ FAT ，File Allocation Table)

例如：数组模拟链表（静态链表）

假设某个新创建的文件 “aaa” 依次存放在磁盘块 2 -> 5 -> 0 -> 1

假设某个新创建的文件 “bbb” 依次存放在磁盘块 4 -> 23 -> 3

$\color{red}注意：一个磁盘仅设置一张 FAT。开机时，将 FAT 读入内存，并常驻内存。$

FAT 的各个表项在物理上连续存储，且每一个表项长度相同，因此 “物理块号” 字段可以是隐含的。

# 如何实现文件的逻辑块号到物理块号的转变？

用户给出要访问的逻辑块号 i ，操作系统找到该文件对应的目录项（ FCB ） ...

从目录项中找到起始块号，若 i > 0 ，则查询内存中的文件分配表 FAT ，往后找到 i 号逻辑块对应的物理块号。 $\color{red}逻辑块号转换成物理块号的过程不需要读磁盘操作$ 。

例：若用户想要访问一个文件 "aaa" 的 2 号逻辑块。操作系统首先找到文件 "aaa" 的 0 号逻辑块存放的物理块号是 2，操作系统查询文件分配表，0 号逻辑块下一个逻辑块（1 号逻辑块的）应该是存放在 5 号物理块当中的。1 号逻辑块的下一逻辑块（2 号逻辑块）存放在 0 号物理块当中。于是就知道用户想要访问的 2 号逻辑块存放的物理块号了

结论：采用 $\color{red}链式分配（显式链接）$ 方式的文件，支持顺序访问，也 $\color{red}支持随机访问（想访问 i 号逻辑块时，并不需要依次访问之前的 0 ~ i - 1号逻辑块)$ ，由于块号转换的过程不需要访问磁盘，因此相比于隐式链接来说，访问速度快很多。

对 FAT 表的顺序访问，来支持磁盘的随机访问
对内存访问的速度与 I/O 访问的速度不是一个数量级的，内存中的访问 FAT 表操作默认不耗时间

显然，显式链接 $\color{red}也不会产生外部碎片，也可以很方便地对文件进行拓展$ 。

只需要在 FAT 表中添加下一物理块号即可

# 总结

$\color{red}显式链接$ ――把用于链接文件各物理块的指针显式地存放在一张表中，即 $\color{red}文件分配表$ （ $\color{red}FAT$ ， File Allocation Table）。

一个磁盘只会建立一张文件分配表。开机时文件分配表放入内存， $\color{red}并常驻内存$

$\color{red}优点$ ：很方便文件拓展，不会有碎片问题，外存利用率高，并且 $\color{red}支持随机访问$ 。

相比于隐式链接来说， $\color{red}地址转换时不需要访问磁盘，因此文件的访问效率更高$ 。

$\color{red}缺点$ ：文件分配表的需要占用一定的存储空间。

若遇到未指明隐式 / 显式的 “链接分配”， $\color{red}默认$ 指的是 $\color{red}隐式链接$ 的链接分配

# 索引分配

$\color{red}索引分配$ 允许文件离散地分配在各个磁盘块中，系统会 $\color{red}为每个文件建立一张索引表$ ，索引表中 $\color{red}记录了文件的各个逻辑块对应的物理块$ （索引表的功能类似于内存管理中的页表――建立逻辑页面到物理页之间的映射关系）。

索引表存放的磁盘块称为 $\color{red}索引块$ 。文件数据存放的磁盘块称为 $\color{red}数据块$ 。

假设某个新创建的文件 “aaa” 的数据依次存放在磁盘块 2 → 5 → 13 → 9。

7 号磁盘块作为 “aaa” 的索引块，索引块中保存了索引表的内容。

注：在显式链接的链式分配方式中，文件分配表 FAT 是一个磁盘对应一张。

而索引分配方式中，索引表是一个文件对应一张。

可以用固定的长度表示物理块号

如：假设磁盘总容量为 1 TB = 240 B，磁盘块大小为 1 KB，则共有 230 个磁盘块，则可用 4 B 表示磁盘块号
因此，索引表中的 “逻辑块号” 可以是隐含的。

# 如何实现文件的逻辑块号到物理块号的转变？

用户给出要访问的逻辑块号 i ，操作系统找到该文件对应的目录项（ FCB ），从中找到这个文件对应的索引块的块号，再从这个索引块中读取这个文件的索引表的内容，然后通过逻辑块号 i 查询这个索引表得出该逻辑块号对应的物理块号即可

可见， $\color{red}索引分配方式可以支持随机访问$ 。

$\color{red}文件拓展也很容易实现$

只需要给文件分配一个空闲块，并增加一个索引表项即可

但是 $\color{red}索引表需要占用一定的存储空间$

若每个磁盘块 1 KB，一个索引表项 4 B，则一个磁盘块只能存放 256 个索引项。

如果一个文件的大小超过了 256 块，那么一个磁盘块是装不下文件的整张索引表的，如何解决这个问题？

# 链接方案

① $\color{red}链接方案$ ：如果索引表太大，一个索引块装不下，那么可以将多个索引块链接起来存放

若每个磁盘块 1 KB，一个索引表项 4 B，则一个磁盘块只能存放 256 个索引项。

采用链接方案，文件的 FCB 只需要存放第一个索引块号

假设磁盘块大小为 1 KB，一个索引表项占 4 B，则一个磁盘块只能存放 256 个索引项。

若一个文件大小为 256 * 256 KB = 65,536 KB= 64 MB

该文件共有 256 * 256（64 MB）个块，也就对应 256 * 256 个索引项，也就需要 256 个索引块来存储这些索引块用链接方案连起来。

若想要访问文件的最后一个逻辑块，就必须找到最后一个索引块（第 256 个索引块），而各个索引块之间是用指针链接起来的，因此必须先顺序地读入前 255 个索引块。

这显然是很低效的。

# 多层索引

② $\color{red}多层索引$ ：建立多层索引（ $\color{red}原理类似于多级页表$ ）。使第一层索引块指向第二层的索引块。还可根据文件大小的要求再建立第三层、第四层索引块。

假设磁盘块大小为 1 KB，一个索引表项占 4 B，则一个磁盘块只能存放 256 个索引项。

若某文件采用 $\color{red}两层索引$ ，则该 $\color{red}文件的最大长度$ 可以到 256 * 256 * 1 KB = 65,536 KB = 64 MB

如：要访问 1026 号逻辑块，则 1026 / 256 = 4，1026 % 256 = 2

因此可以先将一级索引表调入内存，查询 4 号表项，将其对应的二级索引表调入内存，再查询二级索引表的 2 号表项即可知道 1026 号逻辑块存放的磁盘块号了。

$\color{red}访问目标数据块，需要 3 次磁盘 I/O$ 。

若采用 $\color{red}三层索引$ ，则 $\color{red}文件的最大长度$ 为 256 * 256 * 256 * 1 KB =16 GB

采用 K 层索引结构，且 $\color{red}顶级索引表未调入内存$ ，则访问一个数据块只需要 K+1 次读磁盘操作

# 混合索引

③ $\color{red}混合索引$ ：多种索引分配方式的结合。例如，一个文件的顶级索引表中，既包含 $\color{red}直接地址索引$ （直接指向 $\color{red}数据块$ ），又包含 $\color{red}一级间接索引$ （指向单层索引表)、还包含 $\color{red}两级间接索引$ （指向两层索引表)。

若顶级索引表 $\color{red}还没读入内存$

访问 0 ~ 7 号逻辑块：两次读磁盘

根据 FCB 中的索引块号得出顶级索引表的物理地址，将顶级索引表读出内存后，根据相应的逻辑块号（0 ~ 7）读出目标数据块的物理块号

访问 8 ~ 263：三次读磁盘

访问 264 ~ 65799：四次读磁盘

对于小文件，只需较少的读磁盘次数就可以访问目标数据块。(一般计算机中小文件更多)

# 总结

索引表存放的磁盘块称为 $\color{red}索引块$ 。文件数据存放的磁盘块称为 $\color{red}数据块$ 。

若文件太大，索引表项太多，可以采取以下三种方法解决:

① $\color{red}链接方案$ ：如果索引表太大，一个索引块装不下，那么可以将多个索引块链接起来存放。

$\color{red}缺点$ ：若文件很大，索引表很长，就需要将很多个索引块链接起来。想要找到 i 号索引块，必须先依次读入 0 ~ i - 1 号索引块，这就导致磁盘 l/O 次数过多，查找效率低下。

② $\color{red}多层索引$ ：建立多层索引（ $\color{red}原理类似于多级页表$ ）。使第一层索引块指向第二层的索引块。还可根据文件大小的要求再建立第三层、第四层索引块。采用 K 层索引结构，且 $\color{red}顶级索引表未调入内存$ ，则访问一个数据块只需要 K + 1 次读磁盘操作。

$\color{red}缺点$ ：即使是小文件，访问一个数据块依然需要 K + 1 次读磁盘。

③ $\color{red}混合索引$ ：多种索引分配方式的结合。例如，一个文伴的顶级索引表中，既包含 $\color{red}直接地址索引$ （直接指向数据块），又包含 $\color{red}一级间接索引$ （指向单层索引表)、还包含 $\color{red}两级间接索引$ （指向两层索引表）。

$\color{red}优点$ ：对于小文件来说，访问一个数据块所需的读磁盘次数更少。

$\color{red}超级超级超级重要考点$ ：

① 要会根据多层索引、混合索引的结构计算出文件的最大长度（ $\color{red}Key$ ：各级索引表最大不能超过一个块）；
② 要能自己分析访问某个数据块所需要的读磁盘次数（ $\color{red}Key$ ： FCB 中会存有指向顶级索引块的指针，因此可以根据 FCB 读入顶级索引块。每次读入下一级的索引块都需要一次读磁盘操作。
另外，要 $\color{red}注意题目条件――顶级索引块是否已调入内存$ ）

# 总结

<table height="300" width="300" border="1" >
<thead>
<tr>
<th colspan="2"></th>
<th>How?</th>
<th> 目录项内容 </th>
<th> 优点 </th>
<th> 缺点 </th>
</tr>
</thead>
<tbody>
<tr>
<td colspan="2"> 顺序分配 </td>
<td> 为文件分配的必须是连续的磁盘块 </td>
<td> 起始块号、文件长度 </td>
<td> 顺序存取速度快，支持随机访问 </td>
<td> 会产生碎片，不利于文件拓展 </td>
</tr>
<tr>
<td rowspan="2"> 链接分配 </td>
<td> 隐式链接 </td>
<td> 出文件的最后一个盘块之外，每个盘块都存有下一个盘块的指针 </td>
<td> 起始块号、结束块号 </td>
<td> 可解决碎片问题，外村利用率高，文件拓展方便实现 </td>
<td> 只能顺序访问，不能随机访问 </td>
</tr>
<tr>
<td> 显式链接 </td>
<td> 建立一张文件分配表 ( FAT ), 显示记录盘块的先后关系 (开机后 FAT 常驻内存)</td>
<td> 起始块号 </td>
<td> 除了拥有隐式链接的优点外，还可以通过查询内存中的 FAT 实现随机访问 </td>
<td>FAT 需要占用一定的存储空间 </td>
</tr>
<td colspan="2"> 索引分配 </td>
<td> 为文件数据块建立索引表，若文件太大，可采用链接方案、多层索引、混合索引 </td>
<td> 链接方案记录的是第一个索引块的块号，多层 / 混合索引记录的是顶级索引块的块号 </td>
<td> 支持随机访问，易于实现文件的拓展 </td>
<td> 索引表需占用一定的存储空间。访问数据块前需要先读入索引块，查找索引块时可能需要多次都磁盘操作 </td>
</tr>
</tbody>
</table>

# 文件存储空间管理（对空闲磁盘块管理）

# 存储空间的划分与初始化

安装 Windows 操作系统的时候，一个必经步骤是――为磁盘分区（C: 盘、D: 盘、E: 盘等）

存储空间的划分：将物理磁盘划分为一个个文件卷（逻辑卷、逻辑盘)

# 空闲表法

适用于 "连续分配方式"

如何分配磁盘块：与内存管理中的动态分区分配很类似，为一个文件 $\color{red}分配连续的存储空间$ 。同样 $\color{red}可采用首次适应、最佳适应、最坏适应等算法$ 来决定要为文件分配哪个区间。

Eg：新创建的文件请求 3 个块，采用首次适应算法

每次都从第一个空闲盘块号开始查找，找到第一个能满足大小的空闲盘块。

如何回收磁盘块：与内存管理中的动态分区分配很类似，当回收某个存储区时需要有四种情况―—

① 回收区的前后都没有相邻空闲区；

② 回收区的前后都是空闲区；

合并

③ 回收区前面是空闲区；

合并

④ 回收区后面是空闲区。

合并

$\color{red}总之，回收时需要注意表项的合并问题$ 。

例如：② 回收区的前后都是空闲区；

# 空闲链表法

# 空闲盘块链

操作系统保存着 $\color{red}链头、链尾指针$ 。

如何分配：若某文件申请 K 个盘块，则从链头开始依次摘下 K 个盘块分配，并修改空闲链的链头指针。

如何回收：回收的盘块依次挂到链尾，并修改空闲链的链尾指针。

适用于离散分配的物理结构。为文件分配多个盘块时可能要重复多次操作

依次从链头摘下

# 空闲盘区链

操作系统保存着 $\color{red}链头、链尾指针$ 。

如何分配：若某文件申请 K 个盘块，则可以采用首次适应、最佳适应等算法，从链头开始检索，按照算法规则找到一个大小符合要求的空闲盘区，分配给文件。

若没有合适的连续空闲块，也可以将不同盘区的盘块同时分配给一个文件，注意分配后可能要修改相应的链指针、盘区大小等数据。

如何回收：若回收区和某个空闲盘区相邻，则需要将回收区合并到空闲盘区中。

若回收区没有和任何空闲区相邻，将回收区作为单独的一个空闲盘区挂到链尾。

离散分配、连续分配都适用。为一个文件分配多个盘块时效率更高

可以一次摘下多个盘块

# 位示图法

$\color{red}位示图$ ：每个二进制位对应一个盘块。在本例中，“0” 代表盘块空闲，“1” 代表盘块已分配。

位示图一般用连续的 “字” 来表示，如本例中一个字的字长是 16 位，字中的每一位对应一个盘块。

因此 $\color{red}可以用（字号，位号）对应一个盘块号$ 。当然有的题目中也描述为 $\color{red}（行<号，列号）$

注意： $\color{red}盘块号、字号、位号$ 到底是从 0 开始还是从 1 开始。

要能自己推出盘块号与（字号，位号）相互转换的公式

如本例中 $\color{red}盘块号、字号、位号从 0 开始$ ，若 n 表示字长，则...

（字号，位号）= （i，j）的二进制位对应的 $\color{red}盘块号 b = ni + j$

（0，1）-> 16 * 0 + 1 = 1
（1，10）-> 16 * 1 + 10 = 26

b 号盘块对应的 $\color{red}字号 i = b / n$ ， $\color{red}位号 j = b % n$

b = 13 -> i = 13 / 16 = 0，j = 13 % 16 = 13
b = 31 -> i = 31 / 16 = 1，j = 31 % 16 = 15

如何分配：若文件需要 K 个块

① 顺序扫描位示图，找到 K 个相邻或不相邻的 “0”;
② 根据字号、位号算出对应的盘块号，将相应盘块分配给文件；
③ 将相应位设置为 “1”。

如何回收：

① 根据回收的盘块号计算出对应的字号、位号；
② 将相应二进制位设为 “0”

连续分配、离散分配都适用

若采用连续分配，在位示图中找到连续的 k 个 "0"
若采用离散分配，在位示图中不需要找到连续的 k 个 "0"

# 成组链接法

空闲表法、空闲链表法不适用于大型文件系统，因为空闲表或空闲链表可能过大。 UNIX 系统中采用了 $\color{red}成组链接法$ 对磁盘空闲块进行管理。

$\color{red}文件卷的目录区$ 中专门用一个磁盘块作为 “ $\color{red}超级块$ ”，当系统启动时需要将 $\color{red}超级块读入内存$ 。并且要保证内存与外存中的 “超级块” 数据一致。

每一个分组最后一个盘块号记录者下一个分组的盘块地址

最后一个分组比其他分组要少一块，因为到此已经没有下一组盘块了

如何分配？

Eg：需要 1 个空闲块

① 检查第一个分组的块数是否足够。1 < 100，因此是足够的。

② 分配第一个分组中的 1 个空闲块，并修改相应数据

Eg：需要 100 个空闲块

① 检查第一个分组的块数是否足够。100 = 100，因此是足够的。

② 分配第一个分组中的 100 个空闲块。但是 $\color{red}由于 300 号块内存放了再下一组的信息，因此 300 号块的数据需要复制到超级块中$ 。

即：需要将这个分组指向下一分组的链接信息复制到超级块中

如何回收？

Eg：假设每个分组最多为 100 个空闲块，此时第一个分组已有 99 个块，还要再回收一个块

Eg：假设每个分组最多为 100 个空闲块，此时第一个分组已有 100 个块，还要再回收一个块

$\color{red}需要将超级块中的数据复制到新回收的块中，并修改超级块的内容，让新回收的块成为第一个分组$ 。

# 整体框架

# 文件的基本操作

# 创建文件

进行 Create 系统调用时，需要提供的几个主要参数:

所需的外存空间大小（如：一个盘块，即 1 KB）
文件存放路径（"D:/Demo"）
文件名（这个地方默认为 "新建文本文档.txt"）

操作系统在处理 Create 系统调用时，主要做了两件事：

$\color{red}在外存中找到文件所需的空间$ （空闲链表、位示图、成组链接法等管理策略，找到空闲空间）
根据文件存放路径的信息找到该目录对应的目录文件（此处就是 D:/Demo 目录），在目录中 $\color{red}创建该文件对应的目录项$ 。目录项中包含了文件名、文件在外存中的存放位置等信息。

# 删除文件

进行 Delete 系统调用时，需要提供的几个主要参数:

文件存放路径（“D:/Demo”)
文件名（“test.txt”)

操作系统在处理 Delete 系统调用时，主要做了几件事:

根据文件存放路径找到相应的目录文件，从目录中 $\color{red}找到文件名对应的目录项 FCB$ 。
根据该目录项记录的文件在外存的存放位置、文件大小等信息， $\color{red}回收文件占用的磁盘块$ 。（回收磁盘块时，根据空闲表法、空闲链表法、位图法等管理策略的不同，需要做不同的处理）

# 打开文件

在很多操作系统中，在对文件进行操作之前，要求用户先使用 open 系统调用 “打开文件”，需要提供的几个主要参数:

文件存放路径（“D:/Demo”）
文件名（“test.txt”）
要对文件的操作类型（如: r 只读；rw 读写等)

操作系统在处理 open 系统调用时，主要做了几件事:

根据文件存放路径找到相应的目录文件，从目录项中 $\color{red}找到文件名对应的目录项$ ，并检查该用户是否有指定的操作权限。
$\color{red}将目录项复制到内存中的 “打开文件表” 中$ 。并将对应表目的编号返回给用户。之后 $\color{red}用户使用打开文件表的编号来指明要操作的文件$ 。

打开计数器：记录此时有多少个进程打开了此文件

读写指针：记录了该进程对文件的读 / 写操作进行到的位置

可以方便实现某些文件管理的功能。

例如：在 Windows 系统中，我们尝试删除某个 txt 文件，如果此时该文件已被某个 “记事本” 进程打开，则系统会提示我们 “暂时无法删除该文件” 。

其实系统在背后做的事就是先检查了系统打开文件表，确认此时是否有进程正在使用该文件。

# 关闭文件

进程使用完文件后，要 “关闭文件”

操作系统在处理 Close 系统调用时，主要做了几件事:

将进程的打开文件表相应表项删除
回收分配给该文件的内存空间等资源
系统打开文件表的计数器 count 减 1，若 count = 0，择善书对应表项

# 读文件

进程使用 read 系统调用完成写操作。

需要指明是哪个文件（在支持 “打开文件” 操作的系统中，只需要提供文件在打开文件表中的索引号即可)，
还需要指明要读入多少数据（如：读入 1 KB ）
指明读入的数据要放在内存中的什么位置。

操作系统在处理 read 系统调用时，会从读指针指向的外存中，将用户指定大小的数据读入用户指定的内存区域中。

# 写文件

进程使用 write 系统调用完成写操作

需要指明是哪个文件（在支持 “打开文件” 操作的系统中，只需要提供文件在打开文件表中的索引号即可)，
还需要指明要写出多少数据（如：写出 1KB）
写回外存的数据放在内存中的什么位置

操作系统在处理 write 系统调用时，会从用户指定的内存区域中，将指定大小的数据写回写指针指向的外存。

# 整体框架

打开文件时并不会把文件数据直接读入内存。

只有读文件时，才会将文件数据从外村读入内存

“索引号” 也称 “ $\color{red}文件描述符$ ”

“读 / 写文件” 用 “文件描述符” 即可指明文件，不再需要用到 “文件名”

# 文件共享

操作系统为用户提供文件共享功能，可以让多个用户共享地使用同一个文件

$\color{red}注意$ ：多个用户共享同一个文件，意味着系统中只有 “一份” 文件数据。并且只要某个用户修改了该文件的数据，其他用户也可以看到文件数据的变化。

如果是多个用户都 “复制” 了同一个文件，那么系统中会有 “好几份” 文件数据。其中一个用户修改了自己的那份文件数据，对其他用户的文件数据并没有影响。

# 基于索引节点的共享方式（硬链接）

知识回顾：索引结点，是一种文件目录瘦身策略。由于检索文件时只需用到文件名，因此可以将除了文件名之外的其他信息放到索引结点中。这样目录项就只需要包含文件名、索引结点指针。

索引结点中设置一个链接计数变量 count ，用于表示链接到本索引结点上的用户目录项数。

若 count = 2 ，说明此时有两个用户目录项链接到该索引结点上，或者说是有两个用户在共享此文件。

若某个用户决定 “删除” 该文件，则只是要把用户目录中与该文件对应的目录项删除，且索引结点的 count 值减 1 。

若 count > 0 ，说明还有别的用户要使用该文件，暂时不能把文件数据删除，否则会导致指针悬空。

当 count = 0 时系统负责删除文件。

# 基于符号链的共享方式（软链接）

当 User3 访问 “ccc” 时，操作系统判断文件 “ccc” 属于 Link 类型文件，于是会根据其中记录的路径层层查找目录，最终找到 User1 的目录表中的 “aaa” 表项，于是就找到了文件 1 的索引结点。

删除文件后，在访问快捷方式

# 整体框架

# 文件保护

# 口令保护

为文件设置一个 “口令” (如: abc112233），用户请求访问该文件时必须提供 “口令” 。

口令一般存放在文件对应的 FCB 或索引结点中。用户访问文件前需要先输入 “口令”，操作系统会将用户提供的口令与 FCB 中存储的口令进行对比，如果正确，则允许该用户访问文件

优点：保存口令的空间开销不多，验证口令的时间开销也很小。

缺点：正确的 “口令” 存放在系统内部，不够安全。

若系统被入侵

# 加密保护

使用某个 “密码” 对文件进行加密，在访问文件时需要提供正确的 “密码” 才能对文件进行正确的解密。

Eg：一个最简单的加密算法 —―异或加密假设用于加密 / 解密的 $\color{red}“密码” 为 “01001”$

优点：保密性强，不需要在系统中存储 “密码”
缺点：编码 / 译码，或者说加密 / 解密要花费一定时间。

# 控制访问（(精简) 访问控制表）

在每个文件的 FCB （或索引结点）中增加一个 $\color{red}访问控制列表$ （Access-Control List，ACL)，该表中记录了各个用户可以对该文件执行哪些操作。

有的计算机可能会有很多个用户，因此访问控制列表可能会很大，可以用精简的访问列表解决这个问题

精简的访问列表：以 “组” 为单位，标记各 “组” 用户可以对文件执行哪些操作。如：分为系统管理员、文件主、文件主的伙伴、其他用户几个分组。

当某用户想要访问文件时，系统会检查该用户所属的分组是否有相应的访问权限

系统需要管理分组的信息

若想要让某个用户能够读取文件，只需要把该用户放入 "文件主的伙伴" 这个分组即可

# 整体框架

如果对某个目录进行了访问权限的控制，那也要对目录下的所有文件进行相同的访问权限控制

# 文件系统的层次结构

对于文件的逻辑结构，其中的索引文件，会问文件的记录建立索引表，为了查询这些记录对应的逻辑地址而需要查询索引表。在查询索引表之前需要将其调入到内存的文件信息缓冲区。

用一个例子来辅助记忆文件系统的层次结构:

假设某用户请求删除文件 “D:/ 工作目录 / 学生信息.xlsx” 的最后 100 条记录。

用户需要通过操作系统提供的接口发出上述请求―― $\color{red}用户接口$
由于用户提供的是文件的存放路径，因此需要操作系统一层一层地查找目录，找到对应的目录项 —― $\color{red}文件目录系统$ 4.3、文件目录
不同的用户对文件有不同的操作权限，因此为了保证安全，需要检查用户是否有访问权限 —― $\color{red}存取控制模块（存取控制验证层)$ 4.8、文件保护
- 因为权限的数据在 FCB 或者 FCB 瘦身后的索引节点里面
验证了用户的访问权限之后，需要把用户提供的 “记录号” 转变为对应的逻辑地址―― $\color{red}逻辑文件系统与文件信息缓冲区$ 4.2、文件的逻辑结构
知道了目标记录对应的逻辑地址后，还需要转换成实际的物理地址―― $\color{red}物理文件系统$ 4.4、文件的物理结构（文件分配方式）（对非空闲磁盘块的管理）
要删除这条记录，必定要对磁盘设备发出请求――$\color {red} 设备管理程序模块 $[ 5、设备管理](# 5、设备管理)
删除这些记录后，会有一些盘块空闲，因此要将这些空闲盘块回收―― $\color{red}辅助分配模块$ 4.5、文件存储空间管理（对空闲磁盘块管理）

# 磁盘的结构

# 磁盘、磁道、扇区

磁盘的表面由一些磁性物质组成，可以用这些磁性物质来记录二进制数据

# 如何在磁盘中读 / 写数据

需要把 "磁头" 移动到想要读 / 写的扇区所在的磁道

磁盘会转起来，让目标扇区从磁头下面划过，才能完成对扇区的读 / 写操作。

# 盘面、柱面

可用 $\color{red}（柱面号，盘面号，扇区号）$ 来定位任意一个 “磁盘块”。在 “文件的物理结构” 小节中，我们经常提到文件数据存放在外存中的几号块，这个块号就可以转换成（柱面号，盘面号，扇区号）的地址形式。

可根据该地址读取一个 “块”

① 根据 “柱面号” 移动磁臂，让磁头指向指定柱面；

② 激活指定盘面对应的磁头；

③ 磁盘旋转的过程中，指定的扇区会从磁头下面划过，这样就完成了对指定扇区的读 / 写。

# 磁盘的分类

# 整体框架

# 磁盘调度算法

# 一次盘读 / 写操作需要的时间

$\color{red}寻找时间（寻道时间）$ Ts ：在读 / 写数据前，将磁头移动到指定磁道所花的时间。

① $\color{red}启动磁头$ 臂是需要时间的。假设耗时为 s ;
② $\color{red}移动磁头$ 也是需要时间的。假设磁头匀速移动，每跨越一个磁道耗时为 m ，总共需要跨越 n 条磁道。则:

$\color{red}寻找时间 Ts = s + m * n$

现在的硬盘移动一个磁道大约需要 0.2 ms，磁臂启动时间约为 2 ms

$\color {red} 延迟时间 Tr $：通过旋转磁盘，使磁头定位到目标扇区所需要的时间。

设磁盘转速为 r （单位：转 / 秒，或转 / 分），则平均所需的延迟时间 Tr = (1/2) * (1/r) = 1/2r

1/r 就是转一圈需要的时间。找到目标扇区平均需要转半圈，因此再乘以 1/2

硬盘的典型转速为 5400 转 / 分，或 7200 转 / 分

$\color{red}传输时间 Tt$ ：从磁盘读出或向磁盘写入数据所经历的时间

假设磁盘转速为 r ，此次读 / 写的字节数为 b ，每个磁道上的字节数为 N 。

则： $\color{red}传输时间 Tt = (1/r) * (b/N) = b/(rN)$

每个磁道要可存 N 字节的数据，因此 b 字节的数据需要 b/N 个磁道才能存储。而读 / 写一个磁道所需的时间
刚好又是转一圈所需要的时间 1/r

总的平均存取时间 Ta = Ts+ 1/2r + b/(rN)

延迟时间和传输时间都与磁盘转速相关，宜为线性相关。而转速是硬件的固有属性，因此操作系统也无法优化延迟
时间和传输时间

但是操作系统的磁盘调度算法会直接影响寻道时间

# 先来先服务算法（FCFS）

根据进程请求访问磁盘的先后顺序进行调度。

假设磁头的初始位置是 100 号磁道，有多个进程先后陆续地请求访问 55、58、39、18、90、160、150、38、184 号磁道

按照 FCFS 的规则，按照请求到达的顺序，磁头需要依次移动到 55、58、39、18、90、160、150、38、184 号磁道

磁头总共移动了 45+3+19+21+72+70+10+112+146 = 498 个磁道

响应一个请求平均需要移动 498/9 = 55.3 个磁道（平均寻找长度)

优点：公平；如果请求访问的磁道比较集中的话，算法性能还算过的去

缺点：如果有大量进程竞争使用磁盘，请求访问的磁道很分散，则 FCFS 在性能上很差，寻道时间长。

# 最短寻找时间优先（SSTF）

SSTF 算法会优先处理的磁道是与当前磁头最近的磁道。可以保证每次的寻道时间最短，但是并不能保证总的寻道时间最短。(其实就是贪心算法的思想，只是选择眼前最优，但是总体未必最优)

假设磁头的初始位置是 100 号磁道，有多个进程先后陆续地请求访问 55、58、39、18、90、160、150、38、184 号磁道

磁头总共移动了 (100-18) + (184-18) = 248 个磁道

响应一个请求平均需要移动 248/9 = 27.5 个磁道（平均寻找长度)

优点：性能较好，平均寻道时间短

缺点：$\color {red} 可能产生 “饥饿” $ 现象

Eg：本例中，如果在处理 18 号磁道的访问请求时又来了一个 38 号磁道的访问请求，处理 38 号磁道的访问请求时又来了一个 18 号磁道的访问请求。如果有源源不断的 18 号、38 号磁道的访问请求到来的话，150、160、184 号磁道的访问请求就永远得不到满足，从而产生 “饥饿” 现象。
产生饥饿的原因在于：磁头在一个小区域内来回来去地移动

# 扫描 (电梯) 算法（SCAN）

SSTF 算法会产生饥饿的原因在于：磁头有可能在一个小区域内来回来去地移动。

为了防止这个问题，可以规定， $\color{red}只有磁头移动到最外侧磁道的时候才能往内移动，移动到最内侧磁道的时候才能往外移动$ 。

这就是 $\color{red}扫描算法（SCAN）$ 的思想。由于磁头移动的方式很像电梯，因此也叫 $\color{red}电梯算法$ 。

假设某磁盘的磁道为 0 ~ 200 号，磁头的初始位置是 100 号磁道，且 $\color{red}此时磁头正在往磁道号增大的方向移动$ ，有多个进程先后陆续地请求访问 55、58、39、18、90、160、150、38、184 号磁道

磁头总共移动了 (200-100) + (200-18) = 282 个磁道

响应一个请求平均需要移动 282/9 = 31.3 个磁道（平均寻找长度)

优点：性能较好，平均寻道时间较短， $\color{red}不会产生饥饿现象$

缺点：

① 只有到达最边上的磁道时才能改变磁头移动方向，事实上，处理了 184 号磁道的访问请求之后就不需要再往右移动磁头了。

② SCAN 算法对于各个位置磁道的响应频率不平均

如：假设此时磁头正在往右移动，且刚处理过 90 号磁道，那么下次处理 90 号磁道的请求就需要等磁头移动很长一段距离；而响应了 184 号磁道的请求之后，很快又可以再次响应 184 号磁道的请求了

# LOCK 调度算法

$\color{red}扫描算法（SCAN）$ 中，只有到达最边上的磁道时才能改变磁头移动方向，事实上，处理了 184 号磁道的访问请求之后就不需要再往右移动磁头了。

$\color{red}LOOK 调度算法$ 就是为了解决这个问题， $\color{red}如果在磁头移动方向上已经没有别的请求，就可以立即改变磁头移动方向$

边移动边观察，因此叫 LOOK

磁头总共移动了 (184 - 100) + (184 -18) = 250 个磁道

响应一个请求平均需要移动 250/9= 27.5 个磁道（平均寻找长度)

优点：比起 SCAN 算法来，不需要每次都移动到最外侧或最内侧才改变磁头方向，使寻道时间进一步缩短

# 循环扫描算法（C-SCAN）

SCAN 算法对于各个位置磁道的响应频率不平均，而 $\color{red}C-SCAN 算法$ 就是为了解决这个问题。规定只有磁头朝某个特定方向移动时才处理磁道访问请求，而 $\color{red}返回时直接快速移动至起始端而不处理任何请求$ 。

磁头总共移动了 (200-100) + (200 - 0)+ (90 - 0) = 390 个磁道

响应一个请求平均需要移动 390/9 = 43.3 个磁道（平均寻找长度)

优点：比起 SCAN 来，对于各个位置磁道的响应频率很平均。

缺点：只有到达最边上的磁道时才能改变磁头移动方向，事实上，处理了 184 号磁道的访问请求之后就不需要再往右移动磁头了；

并且，磁头返回时其实只需要返回到 18 号磁道即可，不需要返回到最边缘的磁道。
另外，比起 SCAN 算法来，平均寻道时间更长。

# C-LOOK 算法

C-SCAN 算法的主要缺点是只有到达最边上的磁道时才能改变磁头移动方向，并且磁头返回时不一定需要返回到最边缘的磁道上。

C-LOOK 算法就是为了解决这个问题。如果磁头移动的方向上已经没有磁道访问请求了，就可以立即让磁头返回，并且磁头只需要返回到有磁道访问请求的位置即可。

磁头总共移动了 (184 - 100) + (184 -18) + (90 - 18) = 322 个磁道

响应一个请求平均需要移动 322/9 = 35.8 个磁道（平均寻找长度)

优点：比起 C-SCAN 算法来，不需要每次都移动到最外侧或最内侧才改变磁头方向，使寻道时间进一步缩短

# 整体框架

寻找时间（寻道时间）：启动磁臂移动磁头所花的时间

磁盘调度算法影响的指标

# 减少磁盘延迟时间的办法

假设要连续读取橙色区域的 2、3、4 扇区:

磁头读取一块的内容（也就是一个扇区的内容）后，需要一小段时间处理，而盘片又在不停地旋转

因此，如果 2、3 号扇区相邻着排列，则读完 2 号扇区后无法连续不断地读入 3 号扇区

必须等盘片继续旋转，3 号扇区再次划过磁头，才能完成扇区读入

结论：磁头读入一个扇区数据后需要一小段时间处理，如果逻辑上相邻的扇区在物理上也相邻，则读入几个连续的逻辑扇区，可能需要很长的 “延迟时间”

# 交替编号

若采用交替编号的策略，即让逻辑上相邻的扇区在物理上有一定的间隔，可以使读取连续的逻辑扇区所需要的延迟时间更小。

如下所示，若读取 2 号扇区并处理该数据内容，磁头此时在 6 号扇区，可以直接划过 3 号扇区读取数据，而不需要再等盘片旋转一轮

# 磁盘地址结构的设计

思考：为什么？

磁盘的物理地址是（柱面号，盘面号，扇区号）

而不是（盘面号，柱面号，扇区号)

假设某磁盘有 8 个柱面 / 磁道（假设最内侧柱面 / 磁道号为 0 ） , 4 个盘面，8 个扇区。

则可用 3 个二进制位表示柱面，2 个二进制位表示盘面，3 个二进制位表示扇区。

$\color{red}若物理地址结构是（盘面号，柱面号，扇区号）$ ，且需要连续读取物理地址（00, 000, 000) ~ (00,001,111）的扇区:

（00, 000, 000） ~ （00, 000,111）转两圈可读完

第一圈读取 0，1，2，3
第二圈读取 4，5，6，7

之后再读取物理地址相邻的区域，即
（00, 001, 000） ~ （00, 001, 111 ）， $\color{red}需要启动磁头臂，将磁头移动到下一个磁道$

$\color{red}若物理地址结构是（柱面号，盘面号，扇区号）$ ，且需要连续读取物理地址（00, 000, 000) ~ (00,001,111）的扇区:

（000, 00, 000） ~ （000, 00,111）由盘面 0 的磁头读入数据

转两圈可读完

之后再读取物理地址相邻的区域，即

（000, 01, 000） ~ （000, 01, 111 ）， $\color{red}由于柱面号/磁道号相同，只是盘面号不同，因此不需要移动磁头臂。只需要激活相邻盘面的磁头即可$

柱面号放中间，读地址连续时，就需要移动磁头

盘面号放中间，读地址连续十，就不需要移动磁头，因为柱面是一致的

重点是：减少读取连续地址的时间

读取地址连续的磁盘块时，采用（柱面号，盘面号，扇区号）的地址结构可以减少磁头移动消耗的时间

# 错位命名

# 整体框架

# 磁盘的管理

# 磁盘初始化

Step 1 ：进行 $\color{red}低级格式化（物理格式化）$ ，将磁盘的各个磁道 $\color{red}划分为扇区$ 。一个扇区通常可分为头、数据区域（如 512 B 大小)、尾三个部分组成。

一个数据块指向下一个数据块的指针其实就可以保存在尾部部分

管理扇区所需要的各种数据结构一般存放在头、尾两个部分，包括扇区校验码（如奇偶校验、 CRC 循环冗余校验码等，校验码用于校验扇区中的数据是否发生错误)

Step 2 ：将磁盘分区，每个分区由若干柱面组成（即分为我们熟悉的 C 盘、D 盘、E 盘)

Step 3：进行 $\color{red}逻辑格式化$ ，创建文件系统。包括创建文件系统的根目录、初始化存储空间管理所用的数据结构（如位示图、空闲分区表)

# 引导块

计算机开机时需要进行一系列初始化的工作，这些初始化工作是通过执行 $\color{red}初始化程序（自举程序）$ 完成的

初始化程序程序（自举程序）放在 ROM 中存在什么问题？

万一需要更新自举程序，将会很不方便，因为 ROM 中的数据无法更改。如何解决呢？

完整的自举程序放在磁盘的启动块（即引导块 / 启动分区）上，启动块位于磁盘的固定位置。

自举程序的更新会很方便

拥有启动分区的磁盘称为启动磁盘或系统磁盘（C: 盘）

# 坏块的管理

坏了、无法正常使用的扇区就是 “坏块”。

这属于硬件故障，操作系统是无法修复的。应该将坏块标记出来，以免错误地使用到它

对于 简单的磁盘 ，可以在逻辑格式化时（建立文件系统时）对整个磁盘进行坏块检查，标明哪些扇区是坏扇区，比如：在 FAT 表上标明。（在这种方式中， $\color{red}坏块对操作系统不透明$ )

对于 复杂的磁盘 ，磁盘控制器（磁盘设备内部的一个硬件部件）会维护一个坏块链表。

在磁盘出厂前进行低级格式化（物理格式化）时就将坏块链进行初始化。

会保留一些 “备用扇区”，用于替换坏块。这种方案称为 $\color{red}扇区备用$ 。且这种处理方式中， $\color{red}坏块对操作系统透明$ 。