從根上理解 Node.js 的 Fs 模塊：一起設計一個文件系統
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，是不是理解更深了：
- fs.stat 獲取 inode 中的信息的
- fs.chmod 修改文件權限，也是修改 inode 信息
- fs.chown 修改所屬用戶，也是修改 inode 信息
- fs.copyFile 復制 inode 和數據塊，把新的 inode 添加到對應目錄的 inode 內容中
- fs.link 創建軟硬鏈接的，也就是多條路徑查找同一個文件的 inode，軟連接還可以改名
- fs.mkdir 創建目錄 inode 的
- fs.rmdir 讀取目錄 inode 包含的所有文件 inode 的
具體 api 還有很多，但都是用來操作我們上面設計的那個文件系統的。
從根上理解了文件系統，用這些 api 也會得心應手。
總結
為了真正理解 Node.js 的 fs 模塊，我們一起設計了一個文件系統：
- 把文件分成不同數據塊，這樣可以高效利用磁盤空間。
- 文件的索引節點 index node 中記錄了所包含的數據塊和創建時間、權限、是否是目錄等信息。
- 通過塊位圖記錄數據塊空閑狀態。
- 通過 inode 位圖記錄 inode 空閑狀態。
- 通過超級塊記錄硬盤的 inode、數據塊的使用信息。
- 通過 inode 對應的數據塊內容包含文件 inode 信息列表的方式實現了目錄節點。
我們得出一些重要結論：
文件本質上就是 inode + 數據塊。
路徑本質上就是查找目標 inode 的路徑。
硬鏈接本質上就是多個目錄 inode 包含同一個 inode。
軟連接本質上就是多創建了一個 inode 用于改名，對應數據塊中指向目標 inode。
Node.js 的 fs api 是通過 c++ 注入 v8 的對操作系統能力的調用，理解了文件系統，再學那些 api 就很輕松了。
