LWN：針對(duì)命名空間的文件系統(tǒng)！
關(guān)注了就能看到更多這么棒的文章哦～
A filesystem for namespaces
By Jonathan Corbet
December 3, 2021
DeepL assisted translation
https://lwn.net/Articles/877308/
在觀察內(nèi)核開發(fā)過程時(shí)，很自然地會(huì)關(guān)注到最終被接受并成為未來內(nèi)核一部分的那些 patch。但是，其他那些沒有被接受的工作也是很有用處的。這些 patch 的失敗往往揭示了內(nèi)核、以及內(nèi)核社區(qū)的一些特性。Yordan Karadzhov 最近發(fā)布的概念驗(yàn)證性的 namespacefs 這組 patch 就是這種情況了。在未來的內(nèi)核中應(yīng)該不會(huì)看到 namespacefs 了，但是，這項(xiàng)工作明明是針對(duì)一個(gè)有效的使用場景的，它為什么沒能在內(nèi)核中解決這個(gè)場景的問題呢？
Namespacefs 很明顯是一個(gè)由內(nèi)核來實(shí)現(xiàn)的虛擬文件系統(tǒng)，用來展示系統(tǒng)中運(yùn)行的各個(gè) namespace 的層次結(jié)構(gòu)。這些信息反映了正在運(yùn)行的容器（container）的層次結(jié)構(gòu)。管理員通過 namespacefs 可以更容易地看到他們的系統(tǒng)中正在發(fā)生哪些事情。它也可以在今后用在一些復(fù)雜的用例中，比如跟蹤多個(gè)容器并觀察它們是如何交互的。
最初實(shí)現(xiàn)的版本只限于 PID 和 time 這兩個(gè)命名空間。人們就可以遍歷 PID 命名空間的層次結(jié)構(gòu)（time 命名空間是沒有層次的），取得每個(gè)命名空間中運(yùn)行的進(jìn)程列表。其他類型的命名空間在這組 patch 中尚未支持，但如果 namespacefs 得到大家的贊同可以作為解決這個(gè)問題的正確方案的話，今后肯定會(huì)在未來的版本中增加相應(yīng)的支持。
正如 Karadzhov 所說：
能夠看到命名空間的結(jié)構(gòu)，在容器化的 workload 場景下可以是非常有用的。這將為檢測(cè)（detecting）、檢查（examining）和監(jiān)控（monitoring）系統(tǒng)上運(yùn)行的各種容器提供一個(gè)通用的方法，而不需要依靠某種特定的用戶空間軟件了。
其中大部分信息現(xiàn)在都可以在用戶空間中從 /proc 下的各個(gè)目錄來獲取，但還有一些缺失的部分，而且這些信息的組織方式?jīng)]有根據(jù)實(shí)際的命名空間層次來展示。當(dāng)然，容器的編排工具也可以展示它們所管理的這些容器，但它們并沒有一個(gè)統(tǒng)一的解決方案。命名空間的目的是希望使這些信息能夠隨時(shí)可用，無論使用的是哪種容器編排系統(tǒng)。
人們對(duì)這項(xiàng)工作提出了一些反對(duì)意見，首先是命名空間在 namespacefs 中的條目需要有一個(gè) name。目前還沒有跟命名空間相關(guān)的 name，所以 namespacefs 使用的是在內(nèi)核內(nèi)每個(gè)命名空間的 inode 編號(hào)。Eric Biederman 很快就批評(píng)了這種做法，他說。"使用 inode 編號(hào)作為命名空間的實(shí)際名稱是個(gè)錯(cuò)誤做法"。他接著說道，確實(shí)也沒有什么其他東西可以作為命名空間的名稱，這里的整個(gè)方案其實(shí)是不可行的。
看來，使用 inode 號(hào)作為命名空間的名稱有幾個(gè)問題。其中一個(gè)問題，Biederman 后來詳細(xì)解釋了一下，就是無法在今后用相同的名字來重新創(chuàng)建出命名空間的層次結(jié)構(gòu)。他說，這會(huì)導(dǎo)致很多問題，比如實(shí)時(shí)遷移（live-migration scheme）中使用了 CRIU 來抓取快照（checkpoint）和重啟容器的方案就會(huì)出問題。他說，正確處理這個(gè)問題的唯一方法就是為命名空間的名稱來創(chuàng)建一個(gè)命名空間，而這在過去的討論中已被證明是一個(gè)很困難的問題。
只有在使用了 checkpoint 的容器中也在使用 namespacefs 的情況下，CRIU 的問題才會(huì)出現(xiàn)。正如 Karadzhov 和 Steve Rostedt 所指出的，這是一個(gè)不可能的組合情況。使用 namespacefs 的意義在于能用它來展示某個(gè)特定機(jī)器上的情況。任何人都沒有理由會(huì)需要在不同的機(jī)器之間移動(dòng) namespacefs，也不會(huì)需要移動(dòng)那些使用了 namespacefs 的容器，甚至都不會(huì)去想要對(duì)它做 checkpoint。當(dāng)然，不應(yīng)該假設(shè)未來沒有人想以某種方式使用我們的功能，但是，除非有什么非常出乎意料的使用案例，那么其實(shí)這里的起名問題在實(shí)際使用中可能并不需要擔(dān)心。
不過，還有一個(gè)更深層次的問題，那就是命名空間可以被看作是在內(nèi)核中識(shí)別容器的一種嘗試方案，但是內(nèi)核天生設(shè)計(jì)上就是沒有 "container" 的概念的。相反，內(nèi)核是提供了若干個(gè)子功能，供用戶空間的容器系統(tǒng)來使用來組裝成不同類型的 container。namespacefs 這組 patch 使用了 PID 命名空間作為建立層次結(jié)構(gòu)的對(duì)象，完全忽略了 user 命名空間。Biederman 在他最初的回復(fù)中就批評(píng)了這個(gè)決定，他說 "沒有 user 名字空間的話，肯定沒有一個(gè)有意義的層次結(jié)構(gòu)"。不過，并不是所有的容器都使用了 user 命名空間，而且這些命名空間中也缺乏 Karadzhov 的 patch 中希望使用的 PID 信息。
但是，正如 James Bottomley 所指出的，也不是所有的容器都使用了 PID 命名空間的。試圖在 namespacefs 中來識(shí)別那些沒有 PID 命名空間的容器的話就什么信息都看不到了。
最終的結(jié)果看來是除非引入某種容器的概念，否則很難在內(nèi)核中實(shí)現(xiàn)類似命名空間的東西。比起過去幾年，現(xiàn)在更少有人愿意這樣做了，內(nèi)核中缺乏容器抽象概念這一點(diǎn)，人們認(rèn)為其反而引出了用戶空間方面的大量創(chuàng)新。僅僅因?yàn)檫@個(gè)原因，就很難在內(nèi)核社區(qū)推銷命名空間這個(gè)做法了。
不過，似乎也可以通過分析許多 /proc 文件從而完全在用戶空間來獲得所需的信息。如果有缺失的信息的話，可以繼續(xù)在 /proc 中添加進(jìn)去，而不是引入一個(gè)全新的文件系統(tǒng)。因此 Karadzhov 打算后續(xù)采用這個(gè)方法來解決問題。他正在準(zhǔn)備另一個(gè)概念驗(yàn)證性的改動(dòng)希望給大家展示這個(gè)方案。
如果這個(gè)實(shí)現(xiàn)后續(xù)被證明是很困難的、或無法有效地做到的，那么可能就有理由要重新考慮命名空間方案了。除非走到了這一天，否則像 namespacefs 這樣的機(jī)制似乎不太可能進(jìn)入內(nèi)核。這個(gè)具體方案雖然沒有能夠直接實(shí)現(xiàn)目標(biāo)，但是它確實(shí)引出了一個(gè)討論，提煉出了一個(gè)看起來更加好的解決方案。并且在這個(gè)過程中，也突出了內(nèi)核缺乏容器概念所帶來的一些限制?！氨M量不去實(shí)現(xiàn)（reluctance to implement）”的這種做法通常是個(gè)好的做法好事，但它最終會(huì)使用戶碰到一些更難解決的問題。
全文完
LWN 文章遵循 CC BY-SA 4.0 許可協(xié)議。
長按下面二維碼關(guān)注，關(guān)注 LWN 深度文章以及開源社區(qū)的各種新近言論～