文件系统性能

前情提要：地址独立和地址保护是文件系统需要达到的两个目标。
已经论述地址独立如何实现的（地址独立通过文件或文件夹已经实现）
现在我们论述文件系统的第2个目标——地址保护是如何实现的。

首先要注意的是，地址保护不是文件系统必须实现的功能。如果没有这个功能，用户可以承担起文件保护的角色。

例如，用户可以将自己的文件放在一个单独的文件系统上，如U盘或移动硬盘。在工作完成后，将文件系统卸载从而使得自己的文件无法被其他人访问。但是，这种做法比较麻烦。另外，在一些大型主机上也不能实现。因此，由操作系统提供文件保护经常是更为可行的办法，有时甚至是唯一的办法。

文章知识点梳理：

18.1 文件授权管理

那么地址保护如何实现呢？

对文件里面的数据进行保护，使得文件数据不能被随意访问就是文件系统必须解决的一个问题。

而文件系统解决这个问题的方法就是文件系统的访问控制（access control）。

那么访问控制是如何实现的呢？或者说，如果要对文件进行保护，使得一个文件不能被任何人随便访问，我们有哪些办法呢？

我们只要看一下人类社会对贵重设施的保护就清楚了。例如，军事重地或关键设施的保护通常可以分为两种模式：在军事禁区设置哨兵，欲访问军事禁区的人必须经过哨兵的检查，即哨兵根据某种规则来确认某个人是否可以访问禁区。另外一种办法是设置安全门，有权限访问的人都备有通过安全门的钥匙。如果某个人需要进入禁区，他只需拿出自己的钥匙将安全门打开即可。如果打不开，则不能访问。在这种情况下，一个人可以有多把钥匙，用来访问不同的受保护设施。

如果对上述情况进行提炼，我们发现，这两类保护措施是从两个不同的角度来实施的：哨兵是从被保护的设施角度出发，即控制措施附在设施上；而使用钥匙则是从用户角度来实施的，即访问控制在用户身上。

既然文件保护的设计者是人，自然我们采取的措施就很难超越我们保护军事禁区的手段。事实上，对文件的保护所采取的措施跟保护军事禁区的手段非常类似。

因此，我们对文件的保护也可以从两个角度出发：从文件的角度和从用户的角度。从文件的角度实施将访问控制附在每个个体文件上。从用户角度出发则将访问控制附在用户身上。

18.2 主动控制：访问控制表

主动控制将保护措施构建在被保护者身上。对于文件系统来说，我们为每个文件设置一个哨兵。

这个哨兵对每个试图访问该文件的用户进行检查，看看其能否访问。而这个检查的规则存放在一张表里面。这张表称为访问控制表。

这张表存放在内核空间，对于每个具有访问权限的用户设置一个记录。该记录记载着用户ID和具体的访问权限，如读、写、执行、拷贝等。凡是不在这张表上的用户将不具备访问资格。图18-1显示的是有着3个用户进程和3个文件的访问控制表。
图 18-1 访问控制表

在图18-1中，文件F1的访问控制表为"A：RW；B：X"，这意味着用户A可以对文件F1进行读写访问，而用户B可以对文件F1执行访问，即可以执行文件F1，而用户C则不能访问文件F1。

对于文件F2来说，用户A的权限为读，用户B的权限为读写，用户C的权限为读。对于文件F3来说，用户A没有权限，用户B拥有读写执行权限，而用户C拥有读和执行权限。

这样，在每次访问前，操作系统将检查这个访问控制表来确认一个用户是否有权执行其所要求的操作。如果该用户ID在访问控制表里，且其权限与其所要求的操作匹配，则操作将被允许。否则，该操作将被终止。

这里需要注意的是，访问控制表是存放在内核空间，由操作系统进行设置与访问。用户不能直接修改访问控制表。

当然，访问控制表里的用户不一定非是个体用户，也可以是集体用户。例如，表18-1里面的用户名faculty就是一个用户组名，代表所有的教师。任何属于该组的用户都能够读文件Faculty＿Record。Sysadm也是一个用户组名，代表所有的拥有系统管理权限的用户。任何属于该用户组的用户均可以读写Student＿Record和Fac-ulty＿Record两个文件。

而且，这里的文件也不一定非是个体文件名，也可以是文件集合，如文件夹名。例如，表18-1里面的Faculty＿Record不一定需要是一个用户文件名，它也可以是一个文件夹名。这一点对于读者来说应该不奇怪。我们前面已经说过，文件夹就是文件，可以像对待文件一样对待文件夹。因此，对文件夹设置访问控制权限表就没有任何奇怪之处了。

访问控制表的优缺点：

优点：容易理解和实现，对个体用户的权限赋予与取消也容易。只需要将该用户从访问控制表里面删除即可终止该用户对文件的访问。

缺点：效率低。每次访问一个文件时，我们需要搜索访问控制表。对于那些不支持用户组的系统来说，将需要给每一位个体用户进行权限赋予，而这将是十分繁琐的。
访问控制表并不是十分可靠。它可以很容易攻破。攻破的办法也很简单：攻击者只要让系统认为他是某个拥有访问权限的用户即可。
例如，我们知道UNIX下的sendmail程序是在根用户下运行，即它具有根用户的权限。一个攻击者可以对sendmail进行颠覆，在其中间插入攻击代码。而这段攻击代码将具有根用户的所有权限，因为系统认为该程序就是根用户的程序。

18.3 能力表

另外一种访问控制手段是将控制措施附在用户身上。在这种情况下，每个用户手上拿着一把钥匙。这把钥匙就是用户具有的能力。

能力（capability）这个术语首先出现在邓尼斯（Dennis）和冯霍尔（Van Horn）发表于1966的一篇文章：《多道编程计算里的程序语义》（Programming Semantics for Multiprogrammed Computations）。其基本思想是：如果一个计算机程序需要访问一个对象，该程序必须具备一个特殊的令牌。这个令牌记录该程序可以进行的操作，而该令牌称为能力。

由于一个用户可以拥有对多个对象的访问能力，这些能力放在一起就形成一张表，称为能力表。

这张表为所有该用户具有访问权限的文件设置一个记录。该记录记载着文件名和具体的访问权限，如读、写、执行、拷贝等。例如，＜file2 R, file3 RW＞代表该用户对文件file2有读的权限，对file3有读写的权限。而凡是不在这张表上的文件该用户将不具备访问资格。图18-2显示的是3个用户和3个文件时系统维护的3张能力表。

在图18-2中，用户A的能力表为F1：R；F2：R，这意味着用户A可以对文件F1和F2进行读访问。用户B的能力表为F1：R；F2：RW；F3：RWX，意味着用户B可以对文件F1进行读访问，对F2进行读写访问，对F3进行读写执行访问。同理，用户C对文件F2有读的权限，对F3有读和执行权限。从图中我们也可以看出，用户A不能访问文件F3，用户C不能访问文件F1。

图 18-2 能力表

这样，在每次访问前，操作系统将检查这张能力表来确认一个用户是否有权限执行其所要求的操作。如果该用户所要访问的文件在其能力表里，且其权限与所要求的操作匹配，则操作将被允许。否则，该操作将被终止。

与访问控制表一样，能力表也保存在内核空间，由操作系统进行设置与访问。用户不能直接修改能力表。

如果把文件看做一辆辆汽车，对文件的访问权限看做汽车发动机的钥匙，则能力表代表的是一个用户的汽车钥匙集合。如果一个用户拥有特定文件的权限，就相当于一个人拥有特定汽车的发动机钥匙，就能够开动汽车。

能力表的优缺点：

（1）优点：效率高。如果用户要访问的文件是能力表所指向的文件，则无须进行任何检查。其次，能力表有较好的封装性。用户和他所能够访问的文件存放在同一个列表中。
（2）缺点则是删除文件对象困难。如果要禁止所有用户对某个文
件的访问，则需要对所有用户的能力表进行遍历。

与访问控制表一样，能力表也可以被黑客攻破。比如说，黑客可以伪造一个能力表。

为了保护能力表，我们可以将其置于操作系统的管辖内。为了保护能力表，我们可以将其置于操作系统的管辖内。例如，使用tagged结构。tagged结构就是在每个内存字设置一个额外的字位，用来表示该内存字是否包括能力。如果该标志被设置，则对该字的写操作只能由操作系统进行。例如，IBM的AS/400就使用了这种tagged结构来实现能力。显然，这种实现需要硬件的支持。

我们也可以对能力表进行加密。这样可以将能力表置于用户空间，但用户需要解密钥匙才能使用能力表，从而防止篡改。

18.4 访问控制的实施

有了访问控制表或能力表或者两者，我们就可以对文件访问进行控制。每次一个用户对文件进行访问时，操作系统将打开用户的能力表和其欲访问的访问控制表。

在访问控制表和能力表规模不大的情况下，操作系统通常直接使用这两种手段。

但如果访问控制表或能力表非常大，那么执行访问控制的时间成本将增大。这时就需要进行某种优化以控制访问控制表或能力表所需的时间。这个手段就是保护域。

保护域：

访问控制表和能力表的一个共同缺点就是针对个体的文件需要设置个体的访问控制。如果某些文件或对象的访问控制权限一样，这种个体区别的记录方式就显得有些浪费了。如果这个时候使用保护域就可以解决这个问题。

缺点：访问控制需要精确到个体，无法进行群体操作。

保护域就是将 访问控制权限一样的文件和对象组织成同一个域。

而访问控制权限与每个域直接相关。每个域的控制独立于其他域。每个进程都运行在一定的域里，从而具有访问该域里面文件和对象的权限。图18-4描述的是具有3个保护域的系统。
图 18-4 拥有3个保护域的文件系统

在图18-4中，file1和file2属于一个保护域，file3、file4、file5和printer1属于一个保护域，而file6、printer1和plotter2又属于一个保护域。一个进程在运行时必须处于某个域里。且在运行过程中可以改变保护域，如从用户空间切入到内核空间。

那么系统如何那么系统如何跟踪保护域及其相关权限呢？一个自然的措施是使用矩阵：矩阵的行代表域，列表示文件和对象。例如，图18-4的保护域系统可以用图18-5的矩阵来表示。
图 18-5 不包括保护域的保护矩阵

进程运行中的域切换也可以用矩阵实现，例如图18-6就表示了运行在域1的进程可以切换到域2（以进入表示）。

使用保护域的优缺点：

优点：可以将保护权限相同的对象组成一个集合进行处理。
缺点：实现方式可能浪费空间。

例如，在图18-5和图18-6中有许多的空白域。如果这种浪费
不可忍受，我们总是可以回到访问控制表和能力表两种办法上来。

需要特别提醒的是，本章论述的访问控制机制并不是只能应用于文件，也可以用来对其他计算机里的数据对象（即内存对象）进行保护。

18.5 其他文件安全措施

访问控制虽然能够保护文件不被没有授权的用户或进程非法访问，但这种保护措施十分脆弱，可以很容易被攻破。

由于文件存放的数据可能对于用户来说非常重要，设计额外的保护措施就显得非常重要。这些措施中最主要的是加密，即根据某个给
定算法和参数（密钥）对数据进行转换，使得转换后的数据无法辨认。要想正常阅读文件的内容，则需要先进行解密。加解密技术在过去的几十年中取得了很大的发展，现在仍然是很多人的研究课题。

一种较为新颖的数据保护方法是隐写文件或隐写文件系统（crypt file sys-tems）。隐写就是将要保护的数据嵌入到其他文件中而达到隐身的目的。例如，我们可以将一个文件甚至整个文件系统隐写在一系列音频文件中。

另外一种更有意思的技术是数据隐藏，即将数据隐藏起来，使得病毒或者试图进行非法访问的人无法看到数据，甚至无法得知数据的存在。加密、隐写、隐藏技术的细节繁多，各有特点（或缺点），由于其通常不由操作系统实现（不是操作系统的一部分），而是存
在于操作系统之外，因此详细论述已经超出本书的范围。有兴趣的者可参阅相关的书籍（加密方面的资料汗牛充栋，隐写和隐藏方面的资料相对较少）。

18. 6 文件系统性能

确保了地址独立和地址保护就实现了文件系统。但是实现了文件系统并不是一切就算结束。除了功能外，一个好的文件系统还需满足用户在性能上的要求。就像计算1000+1000一样，我们可以在1000上加上1000次1，结果虽然正确，但是效率无法让人接受。

文件的性能主要体现在两个方面：可靠性和速度。用于文件系统是用来存放数据的，其可靠性自然非常重要。否则存放的数据将没有人敢用。由于磁盘访问比内存访问慢很多，速度问题比起内存访问时更加重要。

18.6.1 文件系统可靠性

文件系统的可靠性体现在两个方面：持久性和一致性。

持久性是指经久耐用，就是存放在文件系统的文件一万年都不变。一致性则指里面存放的数据必须是好的。那么什么样的数据是好的数据呢？就是说存放在一个系统里面的数据之间必须一致，且必须符合客观现实。例如，如果某个人的年龄是500岁，则这个数据就不是好的，因为它与客观现实相悖。当然，数据不好不一定是文件系统的错误所导致。但作为文件系统的设计人员，我们必须保障不能因文件系统造成数据不好。

18.7 文件系统效率性能

不管做什么，性能总是我们要考虑的一个因素。我们在第11章里面就已论及性能。TLB和缓存就是为了提高内存管理的性能或效率而设计的机制。那么在文件系统里，性能自然也是非常重要的，甚至比内存对性能的重视程度更高，这是因为文件磁盘访问比内存访问慢多了。

• （1）当然，最能够想到的提高磁盘访问速度的办法就是提高磁盘自身的访问速度，即制造更高速度的磁盘。但这种方法不是我们研究操作系统的人所能控制的，而是由磁盘制造商决定。

而且，磁盘的旋转速度确实在稳步上升，从一开始的1500转到3600转到7200转再到20 000转，应该说已经提高了很多。旋转速度的提高既降低了旋转延迟，又提高了数据传输效率。

但是磁盘访问的瓶颈并不是旋转延迟，而是寻道延迟。

影响寻道延迟的因素是磁盘的机械磁臂的移动速度。虽然磁臂做的是直线移动，而直线运动可以做的很快，但对于磁臂来说却没有什么意义。这是因为磁臂寻道时需要准确地停在需要的磁道上。如果磁臂运动太快，将不能精准地停留在所需磁道，从而需要来回调整，反而变得更慢。因此，磁臂的移动速度很难不断提升，即磁盘自身访问速度的提升是有限的。

既然磁盘本身的速度提升有限，又不属于操作系统设计人员能够控制，那还有什么别的办法可以提升磁盘访问速度呢？我们在进程管理和内存管理部分讨论过几种提高系统性能的方法：合适的调度、缓存、提前读取等，而这些方法可以应用到文件系统上来：

• ●将经常访问的内容置于 缓存里。
• ●减少磁盘访问时磁臂移动的 距离。
• ●提前 将需要的数据块读入内存。

18.7.1 文件缓存

文件缓存就是将文件内容的部分置于缓存，从而从缓存满足用户的文件访问请求，而无须每次都到磁盘上去读写。这样可以大大提高访问效率。而放入缓存的数据既可以是用户数据，也可以是元数据。由于元数据的使用频率很高，例如，文件系统的自由空间表格、文件头（I-NODE）、间接数据块（次级I-NODE）、文件夹等数据结构在整个计算机系统运转过程中需要经常使用，缓冲元数据比缓存用户数据效果将更加明显。

那么文件缓存的实现有两种方式：

●缓存在虚地址空间。
●缓存在实地址空间。

• 缓存在虚地址空间就是缓存在虚拟内存里，即将文件映射到进程的虚拟地址空间，

即我们前面讲过的内存映射的文件。这样的话对文件的访问将变为对内存的访问。这种方式的优点就是简单，因为我们将工作交给了内存管理单元（MMU）。

缺点：

不一定能够提高文件访问效率。因为MMU不一定会把我们需要的文件保存在内存里，它随时可能被交换或替换出去。另外，如果有多个进程使用该文件的话也会出现问题

• 缓存在实地址空间就是缓存在物理内存里。

这种方式需要由文件系统自己负责管理。即文件系统需要决定什么数据需要缓存，什么数据需要更换等。这样自然导致文件系统变得复杂，但是可以确保需要的数据总是存放在缓存里。

18.8 文件系统设计分析：日志结构的文件系统

下面我们讨论一个文件系统设计案例，以加深对本章内容的理解。这个文件系统就是日志结构的文件系统（Log-Structured File System, LFS）。

日志结构的文件系统是美国加州大学伯克利分校（UCB）提出的一种文件系统。其目标是提高文件系统的效率。其工作原理的出现依赖于以下观测：随着CPU速度的提高和物理内存空间的增长，磁盘缓冲可以做得更大，使得越来越多的读操作可以从缓存得到满足。因此，大部分磁盘访问实际上只是磁盘写操作。

因此，要提高磁盘访问效率，就需要提高磁盘的写操作效率。那么磁盘的写操作效率的瓶颈在什么地方呢？当然是寻找适当的写位置。那么如何改善此处的效率呢？

显然，如果我们在磁盘写操作时不用寻找写的位置，则磁盘写操作效率将大大提高。

UCB正是看到了这点而设计了日志结构的文件系统。在这种系统中，整个磁盘被看做一个巨大的日志。所有的磁盘写操作从日志的尾端开始，这样就避免了寻道操作。因为我们刚才说过，磁盘访问主要是写操作，而每次写从上次写毕的位置直接开始。当写到磁盘末尾时，我们再从磁盘头接着写下去。即将磁盘看做一个循环日志。

为了进一步提高写的效率，我们还可以结合缓存进行。即不是将所有的写操作随时进行，而是将写操作在内存里缓存起来。

然后在系统闲暇时，或者周期性地将缓存起来的写操作写入磁盘日志。由于每次都写在新的地方，因此我们需要将I-NODE和文件内容一起写入。

由于I-NODE所处的位置随着日志的写入发生变化，LFS使用一个I-NODE表来记录每个I-NODE的当前位置。每次需要访问一个文件时，从目录里找到该文件的I-NODE位置，然后读取数据块并将其置于文件缓存里面。

由于每次文件修改后的内容都写入日志的末尾，即为该文件创建了一个新的版本，将造成一个文件在磁盘上存在多个版本。这样，磁盘空间将很快就会占满。下次需要空间时就会没有空间。为解决这个问题，LFS使用一个垃圾清理程序来清理已经废弃的文件。当然，这个垃圾清理程序只在磁盘空闲时或者磁盘空间已满时才运行。

所以LFS真的有提高文件系统的效率吗？

从表面上看，文件系统效率提高了。因为读从缓存满足，写的时候又不需要寻道，从而使得读写效率都获得提高。

那么LFS文件系统有什么缺点吗？当然有。“天下没有免费的午餐。”根据前面所述，LFS效率的提高需要满足多个条件：

• ●绝大部分读操作可以从内存满足。
• ●连续的写之间不会穿插磁盘读操作。
• ●磁盘的自由空间为连续的。

1. 绝大部分读操作可以从内存满足。

我们刚才说过，LFS效率提高的一个条件是磁盘的绝大部分读操作能在内存中满足。但是只要你的读不能在内存中满足，那么这个文件系统的优点就不能体现。那么读操作当真可以绝大部分在内存满足吗？这一点似乎不难做到。因为每次打开文件时可以一次性将文件全部读到内存。这样以后对此文件的读操作皆可以从内存满足。

但是，文件缓冲真的像UCB声称的那样可以满足绝大部分读请求吗？这实际上并不一定。这得看一个系统同时访问的文件夹数量有多少？文件的大小是多少？读文件的目的是什么？这些因素可能使得UCB的声称大打折扣。

第2和第3两个条件是保证每次写操作时无须寻道。如果在两次写日志之间发生磁盘读操作，则磁盘很有可能移动了位置，从而造成下次写操作时需要进行寻道。如果磁盘空间不是连续，则需要跳跃写，也将发生寻道操作，从而导致写操作效率的下降。

那么这两个条件是否可以保持满足呢？这可不一定。谁能保证磁盘的写操作之间不发生读磁盘操作？很有可能在写过一个文件后，需要打开另一个文件进行读操作，这样将造成磁头偏离日志的尾部。而随着每次文件写入，都会产生一个新版本，从而使前面的版本作废。问题是磁盘上可能作废的文件很多，但是磁头下面要写的部分却是没有作废的文件，这将严重妨碍LFS的顺利运转。

而且，由于I-NODE和数据块的位置在每次写操作时皆发生变化，I-NODE和文件夹的更新将比一般的文件系统更为频繁，管理起来自然更为复杂。另外，由于I-NODE分散存放，文件系统一致性检查和删除磁盘内容的操作将变得费时。

18.9 海量数据文件系统

随着计算机应用的不断扩大，文件系统所处理的数据量呈爆炸增长态势。当文件系统里面数据量增长到一定的程度，传统的文件系统将无法有效运转。例如，在NTFS下，如果单一目录下的文件数量超过十万个，文件系统的性能将急剧下降，达到几乎无法运转的地步。因此，针对大数据量的情况，文件系统的构造必须发生变化，即必须针对海量数据专门构造海量文件系统。

从原理上看，海量文件系统与普通文件系统并无太大区别，它所应该达到的目标仍然是磁盘抽象，提供地址独立与保护，但在性能上的挑战非常明显。挑战是因为数据量的增长突破了某一阈值，而这一阈值的突破导致传统文件系统的失效。这就是哲学上量变质变的规律在文件系统中的体现。

那么海量文件系统的构造与传统文件系统的不同在什么地方呢？要理解这一点，先要看看海量文件系统的几个特点：

• 数据量大：由于数据量巨大，在巨大的目录里面迅速找到所要的文件（文件头及其数据块）就不是一件琐细的事。
• 分布环境广：海量文件系统通常构建在分布式环境下，由于用来提供文件系统存储介质的可能是多个磁盘，且可能位于不同的节点上，如何判断所需文件位于哪个节点并迅速获取数据就变得很重要。这与构建在单一磁盘（阵列）上的普通文件系统相差甚大。

解决方法：

基于上述两个因素，海量文件系统在性能上面临巨大挑战。如果仍然使用普通文件系统那种将元数据与用户数据一起放置的办法，则搜索起来将费时费力。而避免这种窘况的办法就是将元数据与平面数据分开存放，从而减少搜索的数据量，以提升寻找所需文件的效率。如果元数据量本身也很大，则还需要将元数据分拆到多个节点存放。这种存放元数据的节点就称为元数据服务器。而存放平面数据的节点就是数据服务器。

如果上述手段还没有达到效率目标，或者我们还需要进一步提升处理的效率，则可以将目录数据从元数据中分离，构建专门的目录服务器，从而形成目录服务器、元数据服务器、平面数据服务器的3层架构。例如，Sun公司的Lustre分布式文件系统与EMC公司的多通道文件系统MPFS都是采取了元数据与平面数据分开放置的海量数
据文件系统。