最近，看到很多文章都在介紹 Linux 中的文件系統，其中就包括：inode 節點、軟鏈接、硬鏈接等重要的概念。

于是就有小伙伴私信問我：這些概念我都懂，但是我能利用他們來完成什么工作呢？

或者說，在哪些情況下，軟鏈接和硬鏈接能夠提供提供更好的解決方案呢？

這篇文章我們就來簡單梳理一下，軟鏈接和硬鏈接的幾個使用場景。

什么是索引節點

什么是硬鏈接

什么是軟鏈接

軟鏈接應用之：靈活切換不同版本的目標程序

軟鏈接應用之：動態庫版本管理

軟鏈接應用之：快捷方式

硬鏈接之應用：從不同角度對文件進行分類

硬鏈接應用之：文件多人共享

硬鏈接之應用：文件備份

文件和索引節點 inode

在 Linux 系統中，我們可以把一個文件看做 3 個組成部分：

文件名：從用戶角度來描述一個文件；

文件內容：也就是文件中存儲的那些數據；

文件的描述信息：文件的類型、所有者、創建時間等等，可以稱之為元信息；

可以簡單的做一個類比：

文件本身的內容，可以看做一個實實在在的人。

文件的描述信息，可以看做是派出所里的戶籍卡。

戶籍卡上記錄了一個人的姓名、年齡、住址等信息，警察叔叔通過這個戶籍卡，就知道這個人的一切描述信息，除了你腦袋里的知識。

回到計算機中，文件的所有信息都需要存儲在硬盤上，因此就要對硬盤進行區域劃分：不同的區域存儲不同類型的數據，這就是文件系統的重要作用。

在 Linux 系統使用的 ext2／ext3 文件系統中，從硬盤上劃分一塊區域，用來存放文件本身的內容（數據），這塊區域按照一個最小單位：塊（block）來進行劃分。

然后從硬盤上劃分出另一塊區域，專門用來存放所有文件的描述信息。

每一個文件的描述信息，都用一個名為索引節點（inode）的數據結構來表示，所有文件的 inode 就統一放在這塊硬盤區域中。

就像戶籍卡上記錄了一個人的住址一樣，一個文件的索引節點（inode）中，也記錄了這個文件的所有描述信息，包括：文件類型、所有者、創建時間等待，當然也包括文件內容存儲在硬盤的哪些塊（block）中。

當我們調用打開文件 API 函數的時候，操作系統首先根據傳入的文件路徑，找到這個文件的 inode，然后進行一系列的權限檢查操作，最后從 inode 中獲得這個文件的內容存儲在哪些塊（block）中，從而可以對文件的內容進行讀取、寫入操作。

文件名稱只是給我們用戶來使用的，操作系統只是通過 inode 節點，來對文件進行管理的。

當我們創建一個新文件的時候，就同時創建了這個文件對應的 inode 節點。

當我們刪除一個文件的時候，就同時刪除了這個文件對應的 inode 節點。

此時，文件本身內容所在的那個塊中，數據并不會被抹除掉，因此有些數據恢復軟件就是利用這個特點來進行數據找回。

一句話總結：索引節點（inode）就像戶籍卡，操作系統通過 inode 來管理所有的文件。

硬鏈接

剛才已經說到，每一個文件都對應一個 inode 節點。

例如有一個文件 a．txt，文件內容長度是 1024 個字節，存放在硬盤上的某個塊（block）中，假設就是第 10000 個塊吧。

那么這個文件對應的 inode 節點中，就會把 10000 這個塊記錄下來。

同時，它還有一個 links 字段，表示：當前這個 inode 對應一個文件，此時 inode．links 的值為 1。

此時，如果我們用另一個文件名 a＿hard＿link．txt，也來表示 a．txt 這個文件。

也就是說：雖然我們用了 2 個文件名稱，但是本質上指向同一個文件，內容都指向第 10000 個塊中存儲的文件內容。

Linux 系統中提供了硬鏈接來支持這樣的目的，它僅僅是把 inode 節點中的 links 字段的值 加1 即可，也就是 inode．links 的值變成了 2。

硬鏈接的操作指令是：

＄ ln a．txt b．txt

基于硬鏈接，用戶就可以用不同的文件名來訪問同一個文件，所有的操作最終修改的都是同一個文件。

如果僅僅從用戶的角度來看，好像我們是在操作不同的文件，但是這些文件具有自動同步的功能。

這個行為有點類似于網盤：

在云存儲中有一個文件 hello．txt，然后我有兩臺電腦 A 和 B，這兩臺電腦會把云端的文件 hello．txt 都創建一個鏡像文件在本地，就好像這個文件就在自己的硬盤上一樣。

當我在電腦 A 上操作 hello．txt 時，電腦 B 中的同名文件會自動更新。

因此，從行為上來看，硬鏈接就相當于是：文件拷貝 ＋ 自動同步。

再來看一下硬鏈接文件的刪除操作。

在執行 ＄ ln a．txt a＿hard＿link．txt 指令之后，該文件對應的 inode 節點中，links 的值為 2。

如果我們刪除 a．txt，操作系統會把該文件對應的 inode 中的 links 值減1，結果為 1，操作系統發現不為 0，因此并不會刪掉這個 inode。

如果我們再刪除 a＿hard＿link．txt，操作系統再次執行 inode．links 減1 動作，發現值變成了 0，于是就把這個 inode 刪除了，于是這個文件就徹底不存在了。

這就相當于把一個人的戶籍卡給注銷掉了，從戶籍管理角度看，這個人就不存在了。即使存在，也是一個黑戶。

硬鏈接存在 2 個限制：

不允許用戶給目錄創建硬鏈接，即：用戶不可以，操作系統可以（想一下每個目錄下的 ． 和 ．．）；

只有在同一個文件系統中的文件，才能創建硬鏈接，也就是說：不能跨文件系統；

軟鏈接

為了克服硬鏈接的 2 個限制，軟鏈接被引入進來了。

軟鏈接也叫符號鏈接，它是一個獨立的文件。

軟鏈接文件的內容是一個文本字符串，存儲的是目標文件（即：鏈接到的文件）的路徑名。

這個路徑名可以指向任意一個文件系統的任意文件或者目錄，甚至可以指向一個不存在的文件。

與創建硬鏈接不同的是：當我們創建了一個軟鏈接之后，操作系統會創建一個新的 inode 來表示這個軟鏈接文件。

例如有一個文件 a．txt，我們創建一個軟鏈接 a＿soft＿link．txt 來指向它：

＄ ln －s a．txt a＿soft＿link．txt

此時，a．txt 和 a＿soft＿link．txt 各自都有自己的 inode 節點。

圖中的綠色虛線，就表示軟鏈接文件中的文件路徑。

正因為軟鏈接文件中存儲的僅僅是目標文件的路徑字符串，所以可以表示任意一個文件系統中的文件，或者是目錄。

當我們打開文件軟鏈接 a＿soft＿link．txt 時，操作系統從 a＿soft＿link．txt 對應的 inode 數據結構中發現：這是一個軟鏈接文件。

于是操作系統就根據其中的路徑信息，找到 a．txt 的 inode 節點，從而對最終的目標文件進行操作。

再來看一下軟鏈接文件的刪除操作。

如果我們把目標文件 a．txt 刪除掉之后，inode 節點會被刪除掉，就相當于它的戶籍卡被注銷掉了。

此時再次打開軟鏈接 a＿soft＿link．txt 時，雖然其中的路徑信息仍然存在，但是系統此時卻找不到 a．txt 對應的 inode 節點了。

因此，軟鏈接就類似于與 Windows 系統中的快捷方式。

當真正的目標文件被刪除之后，快捷方式也就沒有存在的意義了。

軟鏈接應用之：靈活切換不同版本的目標程序

在開發的過程中，對于同一個工具軟件，可能要安裝多個不同的版本，例如：Python2 和 Python3， JDK8 和 JDK9 等等。

此時就可以通過軟鏈接來指定當前使用哪個版本。例如在我的電腦中：

＄ ll －l ／usr／bin／python＊

lrwxrwxrwx 1 root root 9 12月 31 08：19 ／usr／bin／python －＞ python2．7＊

lrwxrwxrwx 1 root root 9 12月 31 08：19 ／usr／bin／python2 －＞ python2．7＊

－rwxr－xr－x 1 root root 3492624 3月 2 04：47 ／usr／bin／python2．7＊

lrwxrwxrwx 1 root root 9 12月 31 08：19 ／usr／bin／python3 －＞ python3．5＊

－rwxr－xr－x 2 root root 4456208 1月 27 02：48 ／usr／bin／python3．5＊

當在終端窗口中輸入：python 時，啟動的是 python2．7 版本。

如果有一天我需要使用 python3．5 版本，只需要把軟鏈接 python 指向 python3．5 即可。

軟鏈接應用之：動態庫版本管理

在 Linux 系統的動態庫版本管理中，有一個 SONAME 的概念。

我們在編譯一個動態鏈接庫時，一般使用如下編譯命令：

＄ gcc －fPIC －shared －o libhello．so hello．c

在使用這個動態庫時，需要鏈接這個庫：－llibhello。

簡單的 demo 可以這么來寫，但是如果遇到一些比較大的項目，需要執行嚴格的版本管理，那應該怎么來操作呢？

Linux 系統已經為我們想到了問題的解決方案，利用 SO－NAME。

首先，在編譯動態鏈接庫文件時，就指定產生 SO－NAME，它會被存儲在動態鏈接庫 ELF 文件中。

我們來直接看一個優秀的開源工具 libevent 的例子：

＄ ll ／usr／lib／libevent－2．1．so＊

lrwxrwxrwx 1 root root 17 Jul 27 2020 ／usr／lib／libevent－2．1．so －＞ libevent－2．1．so．7

lrwxrwxrwx 1 root root 21 Jul 27 2020 ／usr／lib／libevent－2．1．so．7 －＞ libevent－2．1．so．7．0．1

－rw－r－－r－－ 1 root root 412016 Jul 27 2020 ／usr／lib／libevent－2．1．so．7．0．1

此時使用 readelf 命令來查看生成的動態庫文件 libevent－2．1．so．7．0．1：

＄ readelf －a libevent－2．1．so．7．0．1 ｜ grep SONAME

0x000000000000000e （SONAME） Library soname： ［libevent－2．1．so．7］

它這么做有什么好處呢？

Linux 系統在查找動態鏈接庫文件時，會到下面這 3 個默認目錄下查找（當然然還有其他目錄，比如：當前目錄，LD＿LIBRARY＿PATH 指定的目錄）

／lib： 存放操作系統最關鍵和基礎的庫文件；

／usr／lib： 存放一些非系統運行時所需要的關鍵庫文件；

／usr／local／lib： 存放用戶自己安裝的一些第三方庫文件；

系統中安裝的所有動態鏈接庫，借助 ldconfig 這個程序，會自動的創建、更新或者刪除對應的 SONAME（它是一個軟鏈接，鏈接到 實際的庫文件），并把這些 SONAME 匯總到一個文件 ／etc／ld．so．cache 中緩存起來。

這樣，當動態庫加載器查找動態庫文件時，就可以直接在這個緩存文件中進行查找，加快了動態庫的查找速度。

軟鏈接應用之：快捷方式

利用軟鏈接的快捷方式功能就比較好理解了，想一想：我們為什么在 Windows 的桌面上創建很多軟件的快捷方式啊？

在 Linux 中同樣如此！

比如：最近一段時間的工作，每次都要打開一個路徑很深的文件。

如果在資源管理器中，一層一層的點擊鼠標，是不是比較浪費時間。

此時，就可以在桌面上創建一個軟鏈接，每次直接雙擊就打開所鏈接的目標文件了。

硬鏈接之應用：從不同角度對文件進行分類

比如我有一個文件夾，存儲了10 個G的照片。

這些照片中的人物、拍照地點、拍照時間都是不一樣的。

現在，我既想根據照片中的人物進行分類，也想根據拍照地點進行分類，還想根據拍照時間進行分類，那該怎么辦？

因為一張照片可能同時屬于多個不同的分類，難道每個分類中都復制一張照片？這樣也太浪費硬盤空間了！

解決方案是：

所有的照片仍舊放在一個總的文件夾中，然后創建不同的分類文件夾，在每個分類文件夾中，創建硬鏈接到目標照片文件。

這樣的話，不僅對照片進行了分類，而且一點都不占用硬盤空間。

硬鏈接應用之：文件多人共享

當很多人同時對同一個文件進行維護的時候，如果大家都直接操作這個文件，萬一不小心把文件刪除了，大家就都玩完了！

此時，可以在每個人自己的私人目錄中，創建一個硬鏈接。

每次只需要對這個硬鏈接文件進行操作，所有的改動會自動同步到目標文件中。

由于每個人都是操作硬鏈接文件，即使不小心刪除了，也不會導致文件的丟失。

因為刪除硬鏈接文件，僅僅是把該文件的 inode 節點中的 links 值減 1 而已，只要不為 0，就不會真正的刪除文件。

硬鏈接之應用：文件備份

一些小伙伴有定期備份文件、清理文件的好習慣。

在備份的時候，如果是實實在在的拷貝一份，那真的是太浪費磁盤空間，特別是對于我這種只有 256G 硬盤空間的筆記本。

此時，就可以利用硬鏈接功能，既實現文件備份的目的，又節省了大量的硬盤空間，一舉兩得！

很多備份工具利用的就是硬鏈接的功能，包括 git 工具，當克隆本地的一個倉庫時，執行 clone 指令：

git clone －－reference ＜repository＞

git 并不會把倉庫中的所有文件拷貝到本地，而僅僅是創建文件的硬鏈接，幾乎是零拷貝！