LWN: Btrfs inode號引起的麻煩！
關注了就能看到更多這么棒的文章哦～
The Btrfs inode-number epic (part 1: the problem)
By Jonathan Corbet
August 20, 2021
DeepL assisted translation
https://lwn.net/Articles/866582/
類 Unix 系統(tǒng)（以及它的用戶）往往希望所有的文件系統(tǒng)的行為方式都能保持一致。但是這些用戶也經常會對新的文件系統(tǒng)感興趣，而這些時髦的文件系統(tǒng)通常提供了 Unix 文件系統(tǒng)模型的開發(fā)者以前從未設想過的功能。隨著時間的推移，這已經導致了一些有意思的互不兼容的行為差異。Btrfs 當然就是一個例子。它提供了許多在其他系統(tǒng)中很少見的功能，而其中一些功能與傳統(tǒng)上對文件系統(tǒng)的看法不太一致。最近，Neil Brown 一直在努力解決一個與 Btrfs 處理 inode 號有關的特定問題，這就是一個讓大家感到很混亂的行為。
Btrfs 的關鍵功能之一是 subvolume，這本質上是在一個存儲卷中維護的一個獨立文件系統(tǒng)。snapshot 則是 subvolume 中的一種常用形式，用來在一個給定的時間點上抓拍另一個 subvolume 當前狀態(tài)并生成副本，而底層的數據中一直沒有改變過的部分則會保持共享，不浪費空間。subvolume 還有其他的應用場景，而且往往得到了大量的使用。Btrfs 文件系統(tǒng)中可以包含成千上萬的 subvolume。
Btrfs subvolume 帶來了一些有趣的獨特之處。它們可以互相獨立 mount 進來，就像是完全互不相干的多個文件系統(tǒng)一樣，但它們也可以作為文件系統(tǒng)層次結構的一部分，就是從 root 目錄的角度來看的。因此，我們可以 mount subvolume，但如果 mount 了更高層級的目錄的話，subvolume 也可以不用 mount 就能直接被訪問到。想象一下，如果 /dev/sda1 包含一個 Btrfs 文件系統(tǒng)，并被 mount 到/butter，那么我們可以用以下命令來創(chuàng)建一對 subvolume：
> cd /butter
> btrfs subvolume create subv1
> btrfs subvolume create subv2
現在，/butter 的根目錄將包含兩個子目錄（subv1 和 subv2）：
> tree /butter
/butter
├── subv1
└── subv2
2 directories, 0 files
它們在大多數時候就像是一個目錄一樣，但是，由于它們實際上是 subvolume，所以其實會有一些區(qū)別。比如說，不能將文件從一個目錄中 rename 移動到另一個目錄中去。而有相應權限的用戶現在可以把 subv1 或 subv2（或兩者同時）mount 進來，當作獨立的文件系統(tǒng)來使用。但是，只要/butter 仍然是被 mount 的狀態(tài)，那么兩個 subvolume 都是可見的，就好像它們是同一個文件系統(tǒng)內的一部分一樣。這種行為會帶來一些有趣的后果，我們下面會看到。
Btrfs 在內部使用了一個 subvolume ID 號來標識不同的 subvolume，但是用戶空間沒法直接看到這個數字。而是通過文件系統(tǒng)為每個 subvolume 分配了一個獨立的設備號（就是常見的 major/minor 這種形式），這個可以通過 stat() 等系統(tǒng)調用查看到。不過，如果 subvolume 沒有明確 mount 進來的話，這個數字就不會顯示在 /proc/self/mountinfo 這個文件中，從而一些軟件查看系統(tǒng)中有哪些文件系統(tǒng)的時候會得到不同的結論。[更新：正如 Brown 私下告訴我們的，即使 subvolume 被明確 mount 上來，這里也不會顯示那些數字編號。] 在一個 subvolume 內的文件上調用 stat() 的話就會返回一個設備號，而這個設備號并不存在于 mountinfo 文件中，這種情況有時會讓那些不了解這個內情的應用程序處理時出現問題。
情況還可以更糟。由于 Btrfs 對每個 subvolume 都有一個內部的唯一 ID，它覺得沒有必要在這些 subvolume 之間確保 inode 編號不會重復。結果呢，某個進程從 root 路徑進入一個 Btrfs 文件系統(tǒng)的時候，很可能會看到多個具有相同 inode 號的文件。類似 find 這樣的工具就會使用 inode 號來跟蹤他們已經遍歷過的文件，從而檢測出發(fā)生了文件系統(tǒng)循環(huán)問題。對于本地 mount 的 Btrfs 文件系統(tǒng)，基本還是能夠按預期來進行的，因為即使不同 subvolume 上的兩個文件可能有相同的 inode 號，它們還是會有不同的設備號，因此能判斷出來兩者是不同的。
然而，內核的 NFS daemon 守護程序則會碰到更難處理的情況。它不能向 NFS 客戶端展示所有這些生成的設備號，因為那將需要所有的 subvolume（記得嗎，系統(tǒng)中可能會有有成千上萬的 subvolume）都要在客戶端這一側顯示為完全獨立的 mount 點。所以一個通過 NFS export 出來的 Btrfs 文件系統(tǒng)在所有 subvolume 顯示出來的都是相同的設備號（也就是 root 文件節(jié)點的設備號）。這在大多數情況下是不會出問題的，但這樣一來我們就無法在一個 NFS mount 過來的帶有 subvolume 的 Btrfs 文件系統(tǒng)上使用 find 這類工具了。這個完全統(tǒng)一的設備號會使得它無法區(qū)分不同 subvolume 上具有相同 inode 號的文件，導致 find 中止查找，并報出發(fā)現了文件系統(tǒng)循環(huán)的錯誤。于是我們會時不時看到有用戶抱怨，以及希望能用什么方法來改善這種情況。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關注，關注 LWN 深度文章以及開源社區(qū)的各種新近言論～