从根上理解 Node.js 的 fs 模块:一起设计一个文件系统

283次阅读  |  发布于3年以前

Node.js 提供了 File System 的 api,可以读写文件、目录、修改权限、创建软链等。

可能大家 api 用的比较熟练,但对于这些 api 的原理不一定理解。要想真正理解 File System,还得从根上来看。

下面我们从 0 到 1 设计一个文件系统试试。

从 0 到 1 设计一个文件系统

什么是文件呢?

这样一份比较完整的资料就是文件。

但是计算机的持久化存储是在硬盘,主要是磁盘和 SSD 固定硬盘:

计算机里的文件是一个逻辑概念,并不是物理上存在的一个个实体。

那么如果给了这样一个硬盘,让我们自己造一个文件系统出来,实现文件的功能。怎么做呢?

简单想了下:挨着放。

然后还要记录下索引,啥文件在啥位置:

这样是可以,但是有个问题,万一文件 B 被删除了,那对应的空间就要释放:

然后又来了一个文件 D,发现放不进去啊,这地方太小了。

A 和 B 中间这块空间就是碎片,碎片会把磁盘可用空间割裂成不连续的很多小块。

怎么办呢?如何更好的利用磁盘空间?

分块!把文件分成一小块一小块的,比如 1k 为一个块,可以不用连续存,把所有块记录在索引中就行了。

索引咋记录的看不清,放大点来看:

每个文件的索引中都记录了把数据存在了哪几个块,这样一块一块的读出来就行了。

而且文件删除了,那些块还可以继续用,不会有很大的碎片。

妙啊!

难怪文件系统第一步就是分块,内存管理第一步是分页,这样才能高效利用空间啊。

这种索引节点,可以叫做 index node,简称 inode 就好了。

而且,除了文件名和存放的块以外,还可以记录其他信息,比如创建时间、修改时间、文件权限、所属用户等等。

到这里就可以对文件下个物理层面上的定义了: 文件就是 inode 记录的信息和它所索引的一系列数据块。

那我写文件利用了一个块,删除文件释放了一个块,怎么知道呢?得单独记录下来块的状态。

数据块只有空闲和被占用两个状态,一个二进制位就行了。通过一段二进制数把所有块的空闲状态记录下来。一个位代表一个值,这叫做位图。在这里就是块位图。

硬盘中大部分是数据块,开头的一段来放 inode 所在的块和数据块的块位图。

inode 也是存在块里的,比如我们规定只能用 5 个块放 inode,那 inode 总量是有限的,也就是是说文件系统可以创建的文件是有上限的。

我们也要记录下所有 inode 的空闲状态,也就是 inode 位图。

简单理一下我们设计的文件系统:

为了更好的利用硬盘空间,我们对数据进行了分块,每个文件用到了哪些块记录在 inode 里。inode 还记录了文件的创建时间、修改时间、权限等信息。

通过块位图来记录数据块空闲状态,通过 inode 位图来记录 inode 的空闲状态。

但我如果想知道硬盘中有几个块、用了几个,有几个 inode、用了几个,怎么办呢?

简单,遍历一遍块位图和 inode 位图,就知道个数了。

但每次这么算太慢了,这就像我们设计数据库的时候,一个论坛下面有多少个帖子,这个数据不会是每次用 sql 查询的,而是在帖子增删的时候动态维护一个字段在数据库表中,直接查询即可。

那我们也设计一个块用来存这种统计信息,也就是:

这个块是较高层的统计信息,我们可以叫它超级块。

现在把我们设计好的文件系统交给用户,就可以通过它来高效利用硬盘了。

发布版本:神光文件系统 V1.0。

但现在我们的文件系统好像还不是很好用,只能创建文件,那如果我创建了 1000 个文件呢?

查询起来慢,也容易命名冲突。

怎么办呢?

命名空间!目录!就像文件夹的思想一样。

那怎么实现呢?

每个 inode 是一个文件,那把 inode 组织成树不就行了。

比如我们有两个文件 B 和 C:

我们创建一个目录 A:

在 inode 里面添加一个 isDirectory 的属性,如果是目录,那么就读取数据块的内容,找到其中的 inode 节点编号,就知道该目录下的文件了。

这就是目录的实现原理:通过 inode 的 isDirectory 属性区分是文件还是目录,如果是目录就读取数据块中的 inode 信息来查找子文件,如果是文件,则直接读取数据块作为文件内容。

从一个 inode 到另一个 inode 的查找顺序叫做路径(path)。

比如这样一个文件的 inode 查找顺序:

那文件路径就是 /A/D/dongdong.jpg

这就是文件路径的本质:文件路径就是 inode 查找顺序

现在我们支持目录的嵌套了,可以把文件、目录组织成树形结构方便管理。

发布版本:神光文件系统 v2.0。

现在一个 inode 只有一条路径过来,因为是树嘛,那如果我想两条路径都可以找到同一个 inode 呢?

比如 /A/D/dongdong.jpg 可以访问到该文件:

我想通过 /A/B/dongdong.jpg 也能访问,怎么办呢?

直接指过去不就行了。

这样确实可以有两条路径找到同一个文件,这个额外的链接我们起名叫做硬链接。

但是因为一个节点有两个父节点,就不再是树了,变成了图。所以,文件树这个概念严格意义上来说还是存在问题的,可能是个文件图。

但是我如果想给 dongdong.jpg 换个名字,叫 dongdong2.jpg 呢?

现在都是同一个 inode 节点,改了就都改了。但我只想改 /A/B 的 path 的文件名,别的不改。

那就再创建个 inode 节点,用来改名,然后这个 inode 节点指向 dongdong.jpg。

这种不直接指过去,多了一个 inode 来改名,之后再指过去,这种我们叫做软链接。

为什么叫硬呢?因为改不了,直接指向同一个 inode。

为什么叫软呢?因为可以改,多了一层 inode 用来改名。

所以我们分别起名硬软链接。

硬链接和软链接都是用于多条路径可以查找到同一个文件的,但是硬链接不能单独改名,软连接可以。

monorepo 的实现就是基于软连接的,可以指向同一个目录 inode,而且还可以起个别名。

实现了软硬链接,可以发新版本了。

发布版本:神光文件系统 v3.0。

复盘一下我们设计的文件系统:

v1.0:

通过数据块来存储文件内容,提高硬盘利用效率

通过 inode 记录所用的数据块和文件的创建时间、权限等信息

通过块位图记录数据块的空闲状态

通过 inode 位图记录 inode 空闲状态。

通过超级块记录 inode 和数据块的统计信息。

这个版本实现了文件的存取,但是不支持目录。

v2.0:

通过 inode 中添加一个属性来记录是文件还是目录

目录的数据块中存放具体文件列表的 inode 信息,读取目录的时候可以读取出文件列表。

按照目录 inode、文件 inode 的一层层的查找顺序叫做文件路径。

这个版本实现了目录和路径的功能。

v3.0:

通过多个目录 inode 包含同一个 inode 的方式,来实现多条路径查找同一文件的功能,叫做硬链接。

目录先创建一个 inode 节点用于改名,然后该 inode 节点指向目标 inode 节点,这叫做软连接。

这个版本实现了多条路径查找统一文件的软硬链接功能。

真实的文件系统也是类似的实现,目前有很多文件系统,比如 ext2、FAT 等,原理和我们设计的文件系统差不多。

文件系统设计完了,回到最开始的目标,我们是想深入理解 Node.js 的 File System 的 api。下面就来看一下。

Node.js 的文件系统 api

Node.js 通过 V8 注入了 fs 的 api 给 js 用,底层是通过 c++ 调用操作系统的文件系统功能,也就是我们上面设计的那种文件系统。

我们调用的 fs 的 api 最终就是调用了操作系统的文件系统功能。

自己设计了一个文件系统之后,我们再来看下 fs 的 api,是不是理解更深了:

具体 api 还有很多,但都是用来操作我们上面设计的那个文件系统的。

从根上理解了文件系统,用这些 api 也会得心应手。

总结

为了真正理解 Node.js 的 fs 模块,我们一起设计了一个文件系统:

我们得出一些重要结论:

文件本质上就是 inode + 数据块。

路径本质上就是查找目标 inode 的路径。

硬链接本质上就是多个目录 inode 包含同一个 inode。

软连接本质上就是多创建了一个 inode 用于改名,对应数据块中指向目标 inode。

Node.js 的 fs api 是通过 c++ 注入 v8 的对操作系统能力的调用,理解了文件系统,再学那些 api 就很轻松了。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8