介紹 tmpfs
如果我必須一下子說清楚 tmpfs，我會說 tmpfs
就象虛擬磁盤（ramdisk），但不一樣。象虛擬磁盤一樣，tmpfs 可以使用您的
RAM，但它也可以使用您的交換分區來存儲。而且傳統的虛擬磁盤是個塊設備，并需要一個
mkfs 之類的命令才能真正地使用它，tmpfs
是一個文件系統，而不是塊設備；您只是安裝它，它就可以使用了。總而言之，這讓
tmpfs 成為我有機會遇到的最好的基于 RAM 的文件系統。
tmpfs 和 VM
讓我們來看看 tmpfs 更有趣的一些特性吧。正如我前面提到的一樣，tmpfs
既可以使用 RAM， 也可以使用交換分區。剛開始這看起來可能有點武斷，但請記住
tmpfs 也是我們知道的"虛擬內存文件系統"。而且，您可能也知道，Linux
內核的虛擬內存資源同時來源于您的 RAM 和交換分區。內核中的 VM
子系統將這些資源分配到系統中的其它部分，并負責在后臺管理這些資源，通常是透明地將
RAM 頁移動到交換分區或從交換分區到 RAM 頁。
tmpfs 文件系統需要 VM 子系統的頁面來存儲文件。tmpfs
自己并不知道這些頁面是在交換分區還是在 RAM 中；做這種決定是 VM
子系統的工作。tmpfs 文件系統所知道的就是它正在使用某種形式的虛擬內存。
不是塊設備
這里是 tmpfs 文件系統另一個有趣的特性。不同于大多數"標準的"文件系統，如
ext3、ext2、XFS、JFS、ReiserFS 和其它一些系統，tmpfs
并不是存在于一個底層塊設備上面。因為 tmpfs 是直接建立在 VM
之上的，您用一個簡單的 mount 命令就可以創建 tmpfs 文件系統了。# mount
tmpfs /mnt/tmpfs -t tmpfs
執行這個命令之后，一個新的 tmpfs 文件系統就安裝在
/mnt/tmpfs，隨時可以使用。注意，不需運行 mkfs.tmpfs
；事實上，那是不可能的，因為沒有這樣的命令存在。在 mount
命令執行之后，文件系統立即就被安裝并且可以使用了，類型是 tmpfs 。這和
Linux 虛擬磁盤如何使用大相徑庭；標準的 Linux 虛擬磁盤是
塊設備，所以在使用它們之前必須用您選擇的文件系統將其格式化。相反，tmpfs
是一個文件系統。所以，您可以簡單地安裝它就可以使用了。

Tmpfs 的優勢
動態文件系統的大小
您可能想知道我們前面在 /mnt/tmpfs 安裝的 tmpfs
文件系統有多大。這個問題的答案有點意外，特別是在和基于磁盤的文件系統比較的時候。/mnt/tmpfs
最初會只有很小的空間，但隨著文件的復制和創建，tmpfs
文件系統驅動程序會分配更多的
VM，并按照需求動態地增加文件系統的空間。而且，當 /mnt/tmpfs
中的文件被刪除時，tmpfs 文件系統驅動程序會動態地減小文件系統并釋放 VM
資源，這樣做可以將 VM 返回到循環當中以供系統中其它部分按需要使用。因為 VM
是寶貴的資源，所以您一定不希望任何東西浪費超出它實際所需的 VM，tmpfs
的好處之一就在于這些都是自動處理的。 請參閱 參考資料。
速度
tmpfs 的另一個主要的好處是它閃電般的速度。因為典型的 tmpfs
文件系統會完全駐留在 RAM
中，讀寫幾乎可以是瞬間的。即使用了一些交換分區，性能仍然是卓越的，當更多空閑的
VM 資源可以使用時，這部分 tmpfs 文件系統會被移動到 RAM 中去。讓 VM
子系統自動地移動部分 tmpfs 文件系統到交換分區實際上對性能上是
好的，因為這樣做可以讓 VM 子系統為需要 RAM
的進程釋放空間。這一點連同它動態調整大小的能力，比選擇使用傳統的 RAM
磁盤可以讓操作系統有好得多的整體性能和靈活性。
沒有持久性
這看起來可能不象是個積極因素，tmpfs
數據在重新啟動之后不會保留，因為虛擬內存本質上就是易失的。我想您可能猜到了
tmpfs 被稱為"tmpfs"的一個原因，不是嗎？然而，這實際上可以是一件好事。它讓
tmpfs 成為一個保存您不需保留的數據（如臨時文件，可以在 /tmp 中找到，還有
/var 文件系統樹的某些部分）的卓越的文件系統。

使用 tmpfs
為了使用 tmpfs，您所需要的就是啟用了"Virtual memory file system
support（以前是 shm fs）"選項的 2.4
系列內核；這個選項在內核配置選項的"File systems"部分。一旦您有了一個啟用了
tmpfs 的內核，您就可以開始安裝 tmpfs 文件系統了。其實，在您所有的 2.4
內核中都打開 tmpfs 選項是個好主意，不管您是否計劃使用
tmpfs。這是因為您需要內核 tmpfs 支持來使用 POSIX 共享的內存。然而， System
V共享的內存不需要內核中有 tmpfs 就 可以工作。注意，您 不需要為了讓 POSIX
共享的內存工作而安裝 tmpfs 文件系統；您只需要在內核中支持 tmpfs
就可以了。POSIX
共享的內存現在使用得不太多，但這種情況可能會隨著時間而改變。
避免低 VM 情況
tmpfs 根據需要動態增大或減小的事實讓人疑惑：如果您的 tmpfs
文件系統增大到它耗盡了 所有虛擬內存的程度，而您沒有剩余的 RAM
或交換分區，這時會發生什么？一般來說，這種情況是有點討厭。如果是 2.4.4
內核，內核會立即鎖定。如果是 2.4.6 內核，VM
子系統已經以很多種方式得到了修正，雖然耗盡 VM
并不是一個美好的經歷，事情也不會完全地失敗。如果 2.4.6
內核到了無法分配更多 VM 的程度，您顯然不愿意不能向 tmpfs
文件系統寫任何新數據。另外，可能會發生其他一些事情。首先，系統的其他一些進程會無法分配更多的內存；通常，這意味著系統多半會變得
極度緩慢而且幾乎沒有響應。這樣，超級用戶要采取必要的步驟來緩解這種低 VM
的情況就會很困難，或異常地耗時。
另外，內核有一個內建的最終防線系統，用來在沒有可用內存的時候釋放內存，它會找到占用
VM 資源的進程并終止該進程。不幸的是，這種"終止進程"的解決方案在 tmpfs
的使用增加引起 VM 耗盡的情況下通常會導致不良后果。以下是原因。tmpfs
本身不能（也不應該）被終止，因為它是內核的一部分而非一個用戶進程，而且也沒有容易的方法可以讓內核找出是那個進程占滿了
tmpfs 文件系統。所以，內核會錯誤地攻擊它能找到的最大的占用 VM
的進程，通常會是 X 服務器（X server），如果您碰巧在使用它。所以，您的 X
服務器會被終止，而引起低 VM 情況的根本原因（tmpfs）卻沒有被解決。Ick.
低 VM：解決方案
幸運的是，tmpfs
允許您在安裝或重新安裝文件系統的時候指定文件系統容量的最大值上限。實際上，從
2.4.6 內核到 2.11g 內核，這些參數只能在
安裝時設置，而不是重新安裝時，但我們可以期望在不久的將來可以在重新安裝時設置這些參數。tmpfs
容量最大值的最佳設置依賴于資源和您特定的 Linux
主機的使用模式；這個想法是要防止一個完全使用資源的 tmpfs
文件系統耗盡所有虛擬內存結果導致我們前面談到的糟糕的低 VM 情況。尋找好的
tmpfs 上限值的一個好方法是使用 top
來監控您系統的交換分區在高峰使用階段的使用情況。然后，確保指定的 tmpfs
上限稍小于所有這些高峰使用時間內空閑交換分區和空閑 RAM 的總和。
創建有最大容量的 tmpfs 文件系統很容易。要創建一個新的最大 32 MB 的 tmpfs
文件系統，請鍵入：# mount tmpfs /dev/shm -t tmpfs -o size=32m
這次，我們沒有把 tmpfs 文件系統安裝在 /mnt/tmpfs，而是創建在
/dev/shm，這正好是 tmpfs 文件系統的"正式"安裝點。如果您正好在使用
devfs，您會發現這個目錄已經為您創建好了。
還有，如果我們想將文件系統的容量限制在 512 KB 或 1 GB
以內，我們可以分別指定 size=512k 和 size=1g
。除了限制容量，我們還可以通過指定 nr_inodes=x
參數限制索引節點（文件系統對象）。在使用 nr_inodes 時， x
可以是一個簡單的整數，后面還可以跟一個 k 、 m 或 g
指定千、百萬或十億（?。﹤€索引節點。
而且，如果您想把上面的 mount tmpfs 命令的等價功能添加到
/etc/fstab，應該是這樣： tmpfs /dev/shm tmpfs size=32m 0 0
在現存的安裝點上安裝
在以前使用 2.2 的時候，試圖在
已經安裝了東西的安裝點再次安裝任何東西都會引發錯誤。然而，重寫后的內核安裝代碼使多次使用安裝點不再成為問題。這里是一個示例的情況：假設我們有一個現存的文件系統安裝在
/tmp。然而，我們決定要開始使用 tmpfs 進行 /tmp
的存儲。過去，您唯一的選擇就是卸載 /tmp 并在其位置重新安裝您新的 tmpfs/tmp
文件系統，如下所示： # umount /tmp# mount tmpfs /tmp -t tmpfs -o size=64m
可是，這種解決方案也許對您不管用。可能有很多正在運行的進程在 /tmp
中有打開的文件；如果是這樣，在試圖卸載 /tmp
時，您就會遇到如下的錯誤：umount: /tmp: device is busy
然而，使用最近的 2.4 內核，您可以安裝您新的 /tmp
文件系統，而不會遇到"device is busy"錯誤：# mount tmpfs /tmp -t tmpfs -o
size=64m
用一條命令，您新的 tmpfs /tmp 文件系統就被安裝在
/tmp，并安裝在已經安裝的不能再被直接訪問的分區
之上。然而，雖然您不能訪問原來的
/tmp，任何在原文件系統上還有打開文件的進程都可以繼續訪問它們。而且，如果您
unmount 基于 tmpfs 的 /tmp，原來安裝的 /tmp
文件系統會重新出現。實際上，您在相同的安裝點上可以安裝任意數目的文件系統，安裝點就象一個堆棧；卸載當前的文件系統，上一個最近安裝的文件系統就會重新出現。
綁定安裝

使用綁定安裝，我們可以將所有甚至
部分已經安裝的文件系統安裝到另一個位置，而在兩個安裝點可以同時訪問該文件系統。例如，您可以使用綁定安裝來安裝您現存的根文件系統到
/home/drobbins/nifty，如下所示： # mount --bind / /home/drobbins/nifty
現在，如果您觀察 /home/drobbins/nifty
的內部，您就會看到您的根文件系統（/home/drobbins/nifty/etc、/home/drobbins/nifty/opt
等）。而且，如果您在根文件系統修改文件，您在 /home/drobbins/nifty
中也可以看到所作的改動。這是因為它們是同一個文件系統；內核只是簡單地為我們將該文件系統映射到兩個不同的安裝點。注意，當您在另一處安裝文件系統時，任何安裝在綁定安裝文件系統
內部的安裝點的文件系統都不會隨之移動。換句話說，如果您在單獨的文件系統上有
/usr，我們前面執行的綁定安裝就會讓 /home/drobbins/nifty/usr
為空。您會需要附加的綁定安裝命令來使您能夠瀏覽位于
/home/drobbins/nifty/usr 的 /usr 的內容： # mount --bind /usr
/home/drobbins/nifty/usr
綁定安裝部分文件系統
綁定安裝讓更妙的事情成為可能。假設您有一個 tmpfs
文件系統安裝在它的傳統位置 /dev/shm，您決定要開始在當前位于根文件系統的
/tmp 使用 tmpfs。雖然可以在 /tmp（這是可能的）安裝一個新的 tmpfs
文件系統，您也可以決定讓新的 /tmp 共享當前安裝的 /dev/shm
文件系統。然而，雖然您可以在 /tmp 綁定安裝 /dev/shm 就完成了，但您的
/dev/shm 還包含一些您不想在 /tmp 出現的目錄。所以，您怎么做呢？這樣如何：
# mkdir /dev/shm/tmp# chmod 1777 /dev/shm/tmp# mount --bind /dev/shm/tmp
/tmp
在這個示例中，我們首先創建了一個 /dev/shm/tmp 目錄，然后給它 1777 權限，對
/tmp 適當的許可。既然我們的目錄已經準備好了，我們可以安裝，也只能安裝
/dev/shm/tmp 到 /tmp。所以，雖然 /tmp/foo 會映射到
/dev/shm/tmp/foo，但您沒有辦法從 /tmp 訪問 /dev/shm/bar 文件。
正如您所見，綁定安裝非常強大，讓您可以輕易地修改文件系統設計，絲毫不必忙亂。

tmpfs介紹