虛擬文件系統是一種神奇的抽象，它使得 “一切皆文件” 哲學(xué)在 Linux 中成為了可能。
-- Alison Chariken（作者）
虛擬文件系統是一種神奇的抽象，它使得 “一切皆文件” 哲學(xué)在 Linux 中成為了可能。
什么是文件系統？根據早期的 Linux 貢獻者和作家 Robert Love 所說(shuō)，“文件系統是一個(gè)遵循特定結構的數據的分層存儲?！?不過(guò)，這種描述也同樣適用于 VFAT（ 虛擬文件分配表(Virtual File Allocation Table)）、Git 和 Cassandra （一種 NoSQL 數據庫 ）。那么如何區別文件系統呢？
Linux 內核要求文件系統必須是實(shí)體，它還必須在持久對象上實(shí)現 open()、read() 和 write() 方法，并且這些實(shí)體需要有與之關(guān)聯(lián)的名字。從 面向對象編程 的角度來(lái)看，內核將通用文件系統視為一個(gè)抽象接口，這三大函數是“虛擬”的，沒(méi)有默認定義。因此，內核的默認文件系統實(shí)現被稱(chēng)為虛擬文件系統（VFS）。
如果我們能夠 open()、read() 和 write()，它就是一個(gè)文件，如這個(gè)主控臺會(huì )話(huà)所示。
VFS 是著(zhù)名的類(lèi) Unix 系統中 “一切皆文件” 概念的基礎。讓我們看一下它有多奇怪，上面的小小演示體現了字符設備 /dev/console 實(shí)際的工作。該圖顯示了一個(gè)在虛擬電傳打字控制臺（tty）上的交互式 Bash 會(huì )話(huà)。將一個(gè)字符串發(fā)送到虛擬控制臺設備會(huì )使其顯示在虛擬屏幕上。而 VFS 甚至還有其它更奇怪的屬性。例如，它 可以在其中尋址 。
我們熟悉的文件系統如 ext4、NFS 和 /proc 都在名為 file_operations 的 C 語(yǔ)言數據結構中提供了三大函數的定義。此外，個(gè)別的文件系統會(huì )以熟悉的面向對象的方式擴展和覆蓋了 VFS 功能。正如 Robert Love 指出的那樣，VFS 的抽象使 Linux 用戶(hù)可以輕松地將文件復制到（或復制自）外部操作系統或抽象實(shí)體（如管道），而無(wú)需擔心其內部數據格式。在用戶(hù)空間這一側，通過(guò)系統調用，進(jìn)程可以使用文件系統方法之一 read() 從文件復制到內核的數據結構中，然后使用另一種文件系統的方法 write() 輸出數據。
屬于 VFS 基本類(lèi)型的函數定義本身可以在內核源代碼的 fs/*.c 文件 中找到，而 fs/ 的子目錄中包含了特定的文件系統。內核還包含了類(lèi)似文件系統的實(shí)體，例如 cgroup、/dev 和 tmpfs，在引導過(guò)程的早期需要它們，因此定義在內核的 init/ 子目錄中。請注意，cgroup、/dev 和 tmpfs 不會(huì )調用 file_operations 的三大函數，而是直接讀取和寫(xiě)入內存。
下圖大致說(shuō)明了用戶(hù)空間如何訪(fǎng)問(wèn)通常掛載在 Linux 系統上的各種類(lèi)型文件系統。像管道、dmesg 和 POSIX 時(shí)鐘這樣的結構在此圖中未顯示，它們也實(shí)現了 struct file_operations，而且其訪(fǎng)問(wèn)也要通過(guò) VFS 層。
How userspace accesses various types of filesyste
VFS 是個(gè)“墊片層”，位于系統調用和特定 file_operations 的實(shí)現（如 ext4 和 procfs）之間。然后，file_operations 函數可以與特定于設備的驅動(dòng)程序或內存訪(fǎng)問(wèn)器進(jìn)行通信。tmpfs、devtmpfs 和 cgroup 不使用 file_operations 而是直接訪(fǎng)問(wèn)內存。
VFS 的存在促進(jìn)了代碼重用，因為與文件系統相關(guān)的基本方法不需要由每種文件系統類(lèi)型重新實(shí)現。代碼重用是一種被廣泛接受的軟件工程最佳實(shí)踐！唉，但是如果重用的代碼 引入了嚴重的錯誤 ，那么繼承常用方法的所有實(shí)現都會(huì )受到影響。
找出系統中存在的 VFS 的簡(jiǎn)單方法是鍵入 mount | grep -v sd | grep -v :/，在大多數計算機上，它將列出所有未駐留在磁盤(pán)上，同時(shí)也不是 NFS 的已掛載文件系統。其中一個(gè)列出的 VFS 掛載肯定是 /tmp，對吧？
誰(shuí)都知道把 /tmp 放在物理存儲設備上簡(jiǎn)直是瘋了！
圖片： https://tinyurl.com/ybomxyfo
為什么把 /tmp 留在存儲設備上是不可取的？因為 /tmp 中的文件是臨時(shí)的（?。?，并且存儲設備比內存慢，所以創(chuàng )建了 tmpfs 這種文件系統。此外，比起內存，物理設備頻繁寫(xiě)入更容易磨損。最后，/tmp 中的文件可能包含敏感信息，因此在每次重新啟動(dòng)時(shí)讓它們消失是一項功能。
不幸的是，默認情況下，某些 Linux 發(fā)行版的安裝腳本仍會(huì )在存儲設備上創(chuàng )建 /tmp。如果你的系統出現這種情況，請不要絕望。按照一直優(yōu)秀的 Arch Wiki 上的簡(jiǎn)單說(shuō)明來(lái)解決問(wèn)題就行，記住分配給 tmpfs 的內存就不能用于其他目的了。換句話(huà)說(shuō)，包含了大文件的龐大的 tmpfs 可能會(huì )讓系統耗盡內存并崩潰。
另一個(gè)提示：編輯 /etc/fstab 文件時(shí)，請務(wù)必以換行符結束，否則系統將無(wú)法啟動(dòng)。（猜猜我怎么知道。）
除了 /tmp 之外，大多數 Linux 用戶(hù)最熟悉的 VFS 是 /proc 和 /sys。（/dev 依賴(lài)于共享內存，而沒(méi)有 file_operations 結構）。為什么有兩種呢？讓我們來(lái)看看更多細節。
procfs 為用戶(hù)空間提供了內核及其控制的進(jìn)程的瞬時(shí)狀態(tài)的快照。在 /proc 中，內核發(fā)布有關(guān)其提供的設施的信息，如中斷、虛擬內存和調度程序。此外，/proc/sys 是存放可以通過(guò) sysctl 命令 配置的設置的地方，可供用戶(hù)空間訪(fǎng)問(wèn)。單個(gè)進(jìn)程的狀態(tài)和統計信息在 /proc/<PID> 目錄中報告。
/proc/meminfo 是一個(gè)空文件，但仍包含有價(jià)值的信息。
/proc 文件的行為說(shuō)明了 VFS 可以與磁盤(pán)上的文件系統不同。一方面，/proc/meminfo 包含了可由命令 free 展現出來(lái)的信息。另一方面，它還是空的！怎么會(huì )這樣？這種情況讓人聯(lián)想起康奈爾大學(xué)物理學(xué)家 N. David Mermin 在 1985 年寫(xiě)的一篇名為《 沒(méi)有人看見(jiàn)月亮的情況嗎？ 現實(shí)和量子理論》。事實(shí)是當進(jìn)程從 /proc 請求數據時(shí)內核再收集有關(guān)內存的統計信息，而且當沒(méi)有人查看它時(shí)，/proc 中的文件實(shí)際上沒(méi)有任何內容。正如 Mermin 所說(shuō) ，“這是一個(gè)基本的量子學(xué)說(shuō)，一般來(lái)說(shuō)，測量不會(huì )揭示被測屬性的預先存在的價(jià)值?！保P(guān)于月球的問(wèn)題的答案留作練習。）
當沒(méi)有進(jìn)程訪(fǎng)問(wèn)它們時(shí)，/proc 中的文件為空。（ 來(lái)源 ）
procfs 的空文件是有道理的，因為那里可用的信息是動(dòng)態(tài)的。sysfs 的情況則不同。讓我們比較一下 /proc 與 /sys 中不為空的文件數量。
procfs 只有一個(gè)不為空的文件，即導出的內核配置，這是一個(gè)例外，因為每次啟動(dòng)只需要生成一次。另一方面，/sys 有許多更大一些的文件，其中大多數由一頁(yè)內存組成。通常，sysfs 文件只包含一個(gè)數字或字符串，與通過(guò)讀取 /proc/meminfo 等文件生成的信息表格形成鮮明對比。
sysfs 的目的是將內核稱(chēng)為 “kobject” 的可讀寫(xiě)屬性公開(kāi)給用戶(hù)空間。kobject 的唯一目的是引用計數：當刪除對 kobject 的最后一個(gè)引用時(shí)，系統將回收與之關(guān)聯(lián)的資源。然而，/sys 構成了內核著(zhù)名的“ 到用戶(hù)空間的穩定 ABI ”，它的大部分內容 在任何情況下都沒(méi)有人能“破壞” 。但這并不意味著(zhù) sysfs 中的文件是靜態(tài)，這與易失性對象的引用計數相反。
內核的穩定 ABI 限制了 /sys 中可能出現的內容，而不是任何給定時(shí)刻實(shí)際存在的內容。列出 sysfs 中文件的權限可以了解如何設置或讀取設備、模塊、文件系統等的可配置、可調參數。邏輯上強調 procfs 也是內核穩定 ABI 的一部分的結論，盡管內核的 文檔 沒(méi)有明確說(shuō)明。
sysfs 中的文件確切地描述了實(shí)體的每個(gè)屬性，并且可以是可讀的、可寫(xiě)的，或兩者兼而有之。文件中的“0”表示 SSD 不可移動(dòng)的存儲設備。
了解內核如何管理 sysfs 文件的最簡(jiǎn)單方法是觀(guān)察它的運行情況，在 ARM64 或 x86_64 上觀(guān)看的最簡(jiǎn)單方法是使用 eBPF。eBPF（ 擴展的伯克利數據包過(guò)濾器(extended Berkeley Packet Filter)）由 在內核中運行的虛擬機 組成，特權用戶(hù)可以從命令行進(jìn)行查詢(xún)。內核源代碼告訴讀者內核可以做什么；而在一個(gè)啟動(dòng)的系統上運行 eBPF 工具會(huì )顯示內核實(shí)際上做了什么。
令人高興的是，通過(guò) bcc 工具入門(mén)使用 eBPF 非常容易，這些工具在 主要 Linux 發(fā)行版的軟件包 中都有，并且已經(jīng)由 Brendan Gregg 給出了充分的文檔說(shuō)明 。bcc 工具是帶有小段嵌入式 C 語(yǔ)言片段的 Python 腳本，這意味著(zhù)任何對這兩種語(yǔ)言熟悉的人都可以輕松修改它們。據當前統計， bcc/tools 中有 80 個(gè) Python 腳本 ，使得系統管理員或開(kāi)發(fā)人員很有可能能夠找到與她/他的需求相關(guān)的已有腳本。
要了解 VFS 在正在運行中的系統上的工作情況，請嘗試使用簡(jiǎn)單的 vfscount 或 vfsstat 腳本，這可以看到每秒都會(huì )發(fā)生數十次對 vfs_open() 及其相關(guān)的調用。
vfsstat.py 是一個(gè)帶有嵌入式 C 片段的 Python 腳本，它只是計數 VFS 函數調用。
作為一個(gè)不太重要的例子，讓我們看一下在運行的系統上插入 USB 記憶棒時(shí) sysfs 中會(huì )發(fā)生什么。
用 eBPF 觀(guān)察插入 USB 記憶棒時(shí) /sys 中會(huì )發(fā)生什么，簡(jiǎn)單的和復雜的例子。
在上面的第一個(gè)簡(jiǎn)單示例中，只要 sysfs_create_files() 命令運行， trace.py bcc 工具腳本就會(huì )打印出一條消息。我們看到 sysfs_create_files() 由一個(gè) kworker 線(xiàn)程啟動(dòng)，以響應 USB 棒的插入事件，但是它創(chuàng )建了什么文件？第二個(gè)例子說(shuō)明了 eBPF 的強大能力。這里，trace.py 正在打印內核回溯（-K 選項）以及 sysfs_create_files() 創(chuàng )建的文件的名稱(chēng)。單引號內的代碼段是一些 C 源代碼，包括一個(gè)易于識別的格式字符串，所提供的 Python 腳本 引入 LLVM 即時(shí)編譯器（JIT） 來(lái)在內核虛擬機內編譯和執行它。必須在第二個(gè)命令中重現完整的 sysfs_create_files() 函數簽名，以便格式字符串可以引用其中一個(gè)參數。在此 C 片段中出錯會(huì )導致可識別的 C 編譯器錯誤。例如，如果省略 -I 參數，則結果為“無(wú)法編譯 BPF 文本”。熟悉 C 或 Python 的開(kāi)發(fā)人員會(huì )發(fā)現 bcc 工具易于擴展和修改。
插入 USB 記憶棒后，內核回溯顯示 PID 7711 是一個(gè) kworker 線(xiàn)程，它在 sysfs 中創(chuàng )建了一個(gè)名為 events 的文件。使用 sysfs_remove_files() 進(jìn)行相應的調用表明，刪除 USB 記憶棒會(huì )導致刪除該 events 文件，這與引用計數的想法保持一致。在 USB 棒插入期間（未顯示）在 eBPF 中觀(guān)察 sysfs_create_link() 表明創(chuàng )建了不少于 48 個(gè)符號鏈接。
無(wú)論如何，events 文件的目的是什么？使用 cscope 查找函數 __device_add_disk() 顯示它調用 disk_add_events()，并且可以將 “mediachange” 或 “ejectrequest” 寫(xiě)入到該文件。這里，內核的塊層通知用戶(hù)空間該 “磁盤(pán)” 的出現和消失?？紤]一下這種檢查 USB 棒的插入的工作原理的方法與試圖僅從源頭中找出該過(guò)程的速度有多快。
確實(shí)，沒(méi)有人通過(guò)拔出電源插頭來(lái)關(guān)閉服務(wù)器或桌面系統。為什么？因為物理存儲設備上掛載的文件系統可能有掛起的（未完成的）寫(xiě)入，并且記錄其狀態(tài)的數據結構可能與寫(xiě)入存儲器的內容不同步。當發(fā)生這種情況時(shí)，系統所有者將不得不在下次啟動(dòng)時(shí)等待 fsck 文件系統恢復工具 運行完成，在最壞的情況下，實(shí)際上會(huì )丟失數據。
然而，狂熱愛(ài)好者會(huì )聽(tīng)說(shuō)許多物聯(lián)網(wǎng)和嵌入式設備，如路由器、恒溫器和汽車(chē)現在都運行著(zhù) Linux。許多這些設備幾乎完全沒(méi)有用戶(hù)界面，并且沒(méi)有辦法干凈地讓它們“解除啟動(dòng)”。想一想啟動(dòng)電池耗盡的汽車(chē)，其中 運行 Linux 的主機設備 的電源會(huì )不斷加電斷電。當引擎最終開(kāi)始運行時(shí)，系統如何在沒(méi)有長(cháng)時(shí)間 fsck 的情況下啟動(dòng)呢？答案是嵌入式設備依賴(lài)于 只讀根文件系統 （簡(jiǎn)稱(chēng) ro-rootfs）。
ro-rootfs 是嵌入式系統不經(jīng)常需要 fsck 的原因。
來(lái)源： https://tinyurl.com/yxoauoub
ro-rootfs 提供了許多優(yōu)點(diǎn)，雖然這些優(yōu)點(diǎn)不如耐用性那么顯然。一個(gè)是，如果 Linux 進(jìn)程不可以寫(xiě)入，那么惡意軟件也無(wú)法寫(xiě)入 /usr 或 /lib。另一個(gè)是，基本上不可變的文件系統對于遠程設備的現場(chǎng)支持至關(guān)重要，因為支持人員擁有理論上與現場(chǎng)相同的本地系統。也許最重要（但也是最微妙）的優(yōu)勢是 ro-rootfs 迫使開(kāi)發(fā)人員在項目的設計階段就決定好哪些系統對象是不可變的。處理 ro-rootfs 可能經(jīng)常是不方便甚至是痛苦的， 編程語(yǔ)言中的常量變量 經(jīng)常就是這樣，但帶來(lái)的好處很容易償還這種額外的開(kāi)銷(xiāo)。
對于嵌入式開(kāi)發(fā)人員，創(chuàng )建只讀根文件系統確實(shí)需要做一些額外的工作，而這正是 VFS 的用武之地。Linux 需要 /var 中的文件可寫(xiě)，此外，嵌入式系統運行的許多流行應用程序會(huì )嘗試在 $HOME 中創(chuàng )建配置的點(diǎn)文件。放在家目錄中的配置文件的一種解決方案通常是預生成它們并將它們構建到 rootfs 中。對于 /var，一種方法是將其掛載在單獨的可寫(xiě)分區上，而 / 本身以只讀方式掛載。使用綁定或疊加掛載是另一種流行的替代方案。
運行 man mount 是了解 綁定掛載(bind mount)和 疊加掛載(overlay mount)的最好辦法，這種方法使得嵌入式開(kāi)發(fā)人員和系統管理員能夠在一個(gè)路徑位置創(chuàng )建文件系統，然后以另外一個(gè)路徑將其提供給應用程序。對于嵌入式系統，這代表著(zhù)可以將文件存儲在 /var 中的不可寫(xiě)閃存設備上，但是在啟動(dòng)時(shí)將 tmpfs 中的路徑疊加掛載或綁定掛載到 /var 路徑上，這樣應用程序就可以在那里隨意寫(xiě)它們的內容了。下次加電時(shí)，/var 中的變化將會(huì )消失。疊加掛載為 tmpfs 和底層文件系統提供了聯(lián)合，允許對 ro-rootfs 中的現有文件進(jìn)行直接修改，而綁定掛載可以使新的空 tmpfs 目錄在 ro-rootfs 路徑中顯示為可寫(xiě)。雖然疊加文件系統是一種適當的文件系統類(lèi)型，而綁定掛載由 VFS 命名空間工具 實(shí)現的。
根據疊加掛載和綁定掛載的描述，沒(méi)有人會(huì )對 Linux 容器 中大量使用它們感到驚訝。讓我們通過(guò)運行 bcc 的 mountsnoop 工具監視當使用 systemd-nspawn 啟動(dòng)容器時(shí)會(huì )發(fā)生什么：
在 mountsnoop.py 運行的同時(shí)，system-nspawn 調用啟動(dòng)容器。
讓我們看看發(fā)生了什么：
在容器 “啟動(dòng)” 期間運行 mountsnoop 可以看到容器運行時(shí)很大程度上依賴(lài)于綁定掛載。（僅顯示冗長(cháng)輸出的開(kāi)頭）
這里，systemd-nspawn 將主機的 procfs 和 sysfs 中的選定文件按其 rootfs 中的路徑提供給容器。除了設置綁定掛載時(shí)的 MS_BIND 標志之外，mount 系統調用的一些其它標志用于確定主機命名空間和容器中的更改之間的關(guān)系。例如，綁定掛載可以將 /proc 和 /sys 中的更改傳播到容器，也可以隱藏它們，具體取決于調用。
理解 Linux 內部結構看似是一項不可能完成的任務(wù)，因為除了 Linux 用戶(hù)空間應用程序和 glibc 這樣的 C 庫中的系統調用接口，內核本身也包含大量代碼。取得進(jìn)展的一種方法是閱讀一個(gè)內核子系統的源代碼，重點(diǎn)是理解面向用戶(hù)空間的系統調用和頭文件以及主要的內核內部接口，這里以 file_operations 表為例。file_operations 使得“一切都是文件”得以可以實(shí)際工作，因此掌握它們收獲特別大。頂級 fs/ 目錄中的內核 C 源文件構成了虛擬文件系統的實(shí)現，虛擬文件系統是支持流行的文件系統和存儲設備的廣泛且相對簡(jiǎn)單的互操作性的墊片層。通過(guò) Linux 命名空間進(jìn)行綁定掛載和覆蓋掛載是 VFS 魔術(shù)，它使容器和只讀根文件系統成為可能。結合對源代碼的研究，eBPF 內核工具及其 bcc 接口使得探測內核比以往任何時(shí)候都更簡(jiǎn)單。
非常感謝 Akkana Peck 和 Michael Eager 的評論和指正。
Alison Chaiken 也于 3 月 7 日至 10 日在加利福尼亞州帕薩迪納舉行的第 17 屆南加州 Linux 博覽會(huì )（ SCaLE 17x ）上演講了 本主題 。
via: https://opensource.com/article/19/3/virtual-filesystems-linux
作者： Alison Chariken 選題： lujun9972 譯者： wxy 校對： wxy
本文由 LCTT 原創(chuàng )編譯， Linux中國 榮譽(yù)推出
聯(lián)系客服
