1.1 History Leading Up to BFS
1990年底 Jean Louis Gass´ee成立Be, Inc.，他认为底层硬件的速度并未得到充分利用。
为了解决这个问题，Be, Inc.重头开始研发BeOS和BeBox。BeOS管理文件的extra information使用单独的数据库（email message的header fields），这些信息独立于file system存在，独立数据库和文件系统的设计是为了在user space中保留尽可能多的代码。
但是，由于数据库与文件系统分开，因此使两者保持同步是有问题的。而且，进入通用计算领域带来了支持其他文件系统的愿望(such as ISO-9660, the CD-ROM file system)，但是在原始I/O体系结构中却没有提供这种支持。
The Solution
首先是需要更高级别的file system和device interface。为file systems和device drivers定义API，管理name space，将文件的程序请求连接到文件描述符中以及管理所有关联状态。该项目的后半部分涉及编写一个file system。
Cyril是Be的主要内核架构师，承担了任务的第一部分。 Cyril项目最困难的部分涉及以尽可能multithread，correct，deadlock-free且efficient的方式定义file system API。
Dominic Giampaolo的工作涉及定义磁盘上的data structures，管理raw disk blocks的所有实质性物理细节以及执行程序发出的I/O请求。由于disk block cache与file system（尤其是journaled file system）紧密地交织在一起，因此Dominic Giampaolo还承担了重写block cache的任务。
1.2 Design Goals
在开始对file system进行工作之前，我们必须定义我们的目标和想要支持的功能。有些功能不是可选的，例如OFS支持的数据库。其他功能，例如journaling功能（用于增加file system的完整性和快速的启动时间）极具吸引力，因为它们以较低的成本提供了许多好处。 BeOS的目标受众还需要其他功能，例如64-bit文件大小。
有几个激励因素促使我们在BFS中包括journaling功能。首先，journaled file systems在启动时不需要一致性检查。正如我们将在后面解释的，就其本质而言，journaled file systems始终是一致的。这有几个含义：boot时间非常快，因为不需要检查整个磁盘。接下来，由于file systems需要支持复杂的indexing data structures以实现数据库功能，因此journaling功能使从故障中恢复的任务变得更加简单。实现journaling的开发成本很小，因此我们决定支持它。
除了上述设计目标之外，我们还有一个长期目标，即使系统尽可能multithread且尽可能efficient，这意味着在任何地方都可以进行细粒度的锁定，并密切注意文件系统引入的开销。内存使用也是一个大问题。我们没有奢侈地假设buffers需要大量内存，因为BFS的主要开发系统是一个具有8 MB内存的BeBox。
1.3 Design Constraints
该项目还必须应对一些设计约束。 首先是缺乏工程资源。 Be工程人员非常少，当时只有13名工程师。 Cyril和我不得不一个人工作，因为其他人都忙于其他项目。 我们也没有太多时间来完成该项目。 Be Inc.尝试每四到六个月发布一次常规软件。 最初的目标是该项目需要六个月的时间。 完成项目所需的时间很短，而且工程资源不足，这意味着几乎没有时间去探索不同的设计并尝试完全未经测试的想法。 最终，BFS的第一个beta版本花了9个月的时间。 BFS的最终版本在下个月发布。
1.4 Summary
次章介绍了项目背景。 了解BeOS是什么以及BFS必须满足哪些要求，应该有助于更清楚地说明当有多个可用选项时为什么选择某些路径。
网友评论