前幾天我們的 samba 伺服器（ubuntu 8.04 ltr）共享已滿，但當我查看它時，我看不到任何共享有太多內容
我們有 5 個群組共享，然後每個用戶都有一個單獨的共享
一個用戶有 22gigs 的東西，其他一些用戶有 10-20mb 的東西，其他人都是空的
所以大概總共有 26 場演出
我昨天刪除了一些文件，釋放了大約250MB 的空間，今天當我檢查它時，它再次完全滿了，我刪除了一些舊文件並釋放了大約170MB 的東西，但我可以看到它在可用空間中慢慢地蔓延。
我繼續運行df -h
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 241690180 229340500 169200 100% /
varrun 257632 260 257372 1% /var/run
varlock 257632 0 257632 0% /var/lock
udev 257632 72 257560 1% /dev
devshm 257632 52 257580 1% /dev/shm
lrm 257632 40000 217632 16% /lib/modules/2.6.24-28-generic
/易揮發的
我該怎麼做才能找到佔用我硬碟這麼多空間的東西？ （我對 UNIX 總體來說還很陌生，所以如果沒有很好地解釋，我深表歉意）
答案1
（這是一個針對 Linux 的答案。其他 UNIX 變體可能有所不同。）
有兩個資訊與您的問題相關：(1) 哪些檔案正在填滿您的檔案系統，以及 (2) 哪些進程正在寫入這些檔案。
筆記
下面，當我將$字元放入命令中時，這可能是一個佔位符，您需要在其中替換實際值。希望哪裡該做、哪裡不該做是顯而易見的。
哪些文件？
請注意，大多數檔案系統類型中實際上有兩種資源可供單一檔案使用：元資料（例如 inode）和實際資料。您可以使用以下命令查看 inode 的數量（在 Google 中搜尋定義，但它們是指向構成文件的結構的「指標」）：
df -i
……如您所知，類似這樣的內容將顯示真實數據正在使用的空間：
df -h
另外，請注意檔案系統空間可能會被磁碟上不存在的檔案佔用。這些檔案仍然透過某些進程處於開啟狀態，但已被刪除（我們將在下面介紹）。
一旦確定了完整的檔案系統，您就需要開始尋找大量小檔案、一些大檔案或兩者。元資料資源耗盡通常是由大量小檔案引起的，而真實資料資源耗盡通常是由少數大檔案引起的。我喜歡使用這個命令來幫助尋找大檔案：
sudo find $file_system -mount -ls | awk '{print $7, $11}' | sort -rn > $output
……這個指令可以幫助尋找包含大量小檔案的目錄（更新：：新增空終止以改善檔案名稱處理）：
sudo find . -mount -print0 | xargs -0n 1 dirname | sort | uniq -c | sort -rn > $output
....請注意，這些命令可能需要一段時間才能運行，並執行大量 I/O，具體取決於情況。運行後，您可以通讀$output以查找有問題的檔案或目錄。每個的名稱和位置可能會提示您資料的來源，但需要一些 Linux 經驗。
一旦確定了肇事者，您就可以rm $file解決問題。
哪些流程？
尋找可能填滿檔案系統的進程的最直接方法是執行以下命令：
fuser -c $file_system 2>/dev/null
....它將告訴您給定檔案系統具有開啟檔案描述符（檔案和網路套接字）的進程的PID（該2>/dev/null部分刪除了一些您不需要的資訊）。您也許可以只根據這些 PID 推斷出哪個進程正在填滿您的檔案系統。搜尋進程：
ps -ef | grep $pid
您也可以嘗試執行此命令，這將為您提供更多詳細資訊（並幫助識別磁碟上沒有相應檔案名稱的開啟檔案 - 我在上面提到過）：
sudo lsof $file_system | grep $directory_filling_up
....如果您從命令中識別出可疑的 PID fuser，您可以執行以下操作：
sudo lsof -p $pid
fuser和的問題lsof在於它們僅在您運行命令時為您提供系統快照。如果當你運行它們時，有問題的進程恰好沒有寫入，那麼你就不走運了。您可以透過隨著時間的推移重複運行它們並保存輸出來解決這個問題。這將需要閱讀輸出以查找模式，或編寫一個程式來為您完成此操作。另一種方法是使用類似的工具系統點擊。 SystemTap 可讓您捕捉各種有用的信息，並且是「可編程的」。它甚至附帶了一些範例來源文件，使您可以查看在一段時間內哪些進程正在寫入哪些文件。這將是完美的，但它是一個高級工具，需要大量的 Linux 知識。
一旦確定了有問題的進程，您就可以殺死（也可能重新啟動它們）。如果該進程與作業系統或某些封裝良好的軟體相關，則可能會有一種重新啟動它們的機制，但這取決於您的Linux發行版（我認為Ubuntu將允許您運行類似的東西/etc/init.d/$init_script restart，但您將有檢查您的發行版的文件）。否則，您可以使用kill $pid或kill -9 $pid如果它沒有行為來殺死它。請注意進程的運作方式（例如，中顯示的參數是什麼ps -ef），以防您需要重新啟動它（您可能需要參考該軟體的文件）。
答案2
用於du追蹤包含正在填充磁碟的檔案的目錄。
cd /
du -h --max-depth 1
將顯示 / 中哪個目錄使用的空間最多。運行 du 命令遍歷檔案系統以找到罪魁禍首。
例如
cd /
du -h --max-depth 1
顯示 /usr 正在使用系統上使用的 3.5G 中的 2.3G。
cd /usr
du -h --max-depth 1
顯示 /usr/lib 使用了 /usr 中 2.3 的 1.1G ...
這也可能是由已刪除的開啟檔案引起的。
您可以使用拉索夫尋找已開啟但未連結（已刪除）的文件
lsof +L1
應該可以解決問題。正如手冊頁所述：
表單的規格
+L1將選擇已取消連結的開啟檔案。表單的規格+L1 <file_system>將選擇指定檔案系統上未連結的開啟檔案。
答案3
/ 分割區已被某些東西填滿。它可能是/var/log或 中的東西/home。這取決於您的設定。也要查看您的用戶有權訪問的位置。
在每個相關目錄中執行以下命令。這將向您顯示空間消耗最大的子目錄。
cd /directory
du -cks -x * .* |sort -n
這個想法是從ducks腳本 ( du -cks)借用的Linux 伺服器駭客來自奧萊利。我經常運行這個命令。
根據我的經驗，這幾乎總是由於日誌檔案較大且不斷增長所致。在這種情況下，使用對數旋轉， 和一定要使用壓縮。使用預設壓縮比的 gzip 壓縮，您的記錄檔將縮小 80-95%（1GB /var/log/messages 可以輕鬆壓縮到 200MB 或更小）。這會給 CPU 帶來適度的負載，但我很少看到這會影響伺服器的實際效能。有些人喜歡使用 Bzip2 壓縮，或使用 Bzip2 壓縮，gzip --best但根據我的經驗，這會導致大量 CPU 開銷，但幾乎沒有額外好處。gzip使用預設比率通常就足夠了。
顯然，這個問題有時是因為使用者做了壞事造成的。使用du上面的命令來找到罪魁禍首。
答案4
可能的罪魁禍首是日誌，但這裡有一個命令將按大小對最近修改（或創建）的檔案進行排序：
D=$(date --rfc-3339 date);
sudo sh -c 'find / -xdev -mtime -1 -type f -print0 |xargs -0 du -0sbc' \
|tee ~/recent-files.$D |sort -zn |tee ~/recent-by-size.$D |xargs -0n1
您可以每天運行此命令；可能有一種方法可以執行類似 SQL 的操作來按每日增長對這些檔案進行排序。
（編）要監測生長情況，請使用GT5
sudo aptitude install gt5
cd /
gt5
一天後；尋找 ± 符號
gt5