看到這個錯誤，第一個反應是磁碟空間滿了；但 df 一看，每個分割槽的空間都還富餘的很。從 munin 的監控圖表上看 Filesystem usage 也很平穩，但下面的 Inode usage 就有問題了，其中一個分割槽的 usage 已經到了100%。趕緊跑到伺服器上 df -i 檢查，果然是 Inode 耗盡。原來這個分割槽是用來扔各種日誌和臨時檔案的，其中有某個程式產生的臨時檔案又小又多，又沒有進行定時回滾，造成在磁碟空間耗盡之前檔案系統的 Inode 就被用光了。

　　Linux/Unix like OS 的檔案系統中每個目錄樹中的節點並不是像 Windows 那樣直接包含檔案的具體資訊，而只包含了檔名和 Inode number 。通過 Inode number 所找到對應於檔名的 Inode 節點中才真正記錄了檔案的大小/實體地址/所有者/訪問許可權/時間戳/被硬連結的次數等實際的 metadata 。因此你可以在 Linux 系統中通過硬連結( hard link ) 的方式給某個檔案建立無數個位於不同目錄下的檔名，而實際的檔案資料只需要一份拷貝。

　　但也正因為這種檔案系統的結構，當你在 Linux 中進行 IO 操作的時候，需要的資源除了磁碟空間以外，還要有剩餘的 Inode 才行。預設情況下， Linux 在系統安裝過程中按照1個 Inode 對應 2k 磁碟空間來計算每個分割槽的最大 Inode 數。一旦檔案系統建立之後，每個分割槽可用 Inode 數就無法進行動態調整。

　　正常來說，一般不太會出現某個分割槽的 Inode 耗盡而磁碟空間尚餘的情況，除非像我碰到的這樣垃圾小檔案瘋長而又沒進行有效的清理。但如果確實需要的話，可以在建立檔案系統（比如用 mke2fs ）的時候根據實際需要來調整這個引數（比如分割槽如果用於存放超大視訊檔案的話 Inode 的數量可以少一些；如果打算存放的檔案是大量小於 2k 的迷你檔案的話就要考慮多建立一些 Inode）。

　　附：Inode Definition by The Linux Information Project

　　其它人碰到的 No space left on device 原因：

　　超出系統中同時執行的最大 message queue 個數限制 ： 在 root 下用 sysctl kernel.msgmni 檢查該引數， sysctl -w kernel.msgmni=XXX 重新設定即可。

　　cvs 異常斷開的連線在 /tmp 目錄下留下大量的臨時檔案導致 /tmp 目錄滿