Node.js 提供了 File System 的 api,可以读写文件、目录、修改权限、创建软链等。
可能大家 api 用的比较熟练,但对于这些 api 的原理不一定理解。要想真正理解 File System,还得从根上来看。
下面我们从 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 通过 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