當一個目錄內有上百萬、千萬個檔案時, rm -rf 會慢到很糟糕的地步, 而且砍檔案時會吃掉一堆 IO, 做其它事只要一開檔、關檔, 就會頓一下。
上網查了各種說法, 要驗證何者的說法最合理, 需要讀 rm 的原始碼和 benchmark, 所以就不提了。有人提到一次 rm 多個檔案會比每個檔案都執行一次 rm 快, 減少 fork 和 execute 的時間, 這到是很合理。不確定在要刪除目錄的情況下, rm -rf DIR 和批次砍掉 DIR 下的檔案, 何者較快。
後來發現以前寫的 《/bin/rm: argument list too long 的解法和原因》 滿有用的, 我可以用 find + xargs 只砍部份檔案, 分多次砍完。這個作法的另一好處是, 可以在沒人用的時候放著讓它砍部份檔案 (像是先砍 a*, 再砍 b*, ...), 方便分階段處理, 只要每次砍檔案的時間不長, 不會和人使用的時間重疊到, 就沒問題了。
2010年12月10日 星期五
訂閱:
張貼留言 (Atom)
在 Fedora 下裝 id-utils
Fedora 似乎因為執行檔撞名,而沒有提供 id-utils 的套件 ,但這是使用 gj 的必要套件,只好自己編。從官網抓好 tarball ,解開來編譯 (./configure && make)就是了。 但編譯後會遇到錯誤: ./stdio.h:10...
-
find -uid 可以找目錄下特定使用者有的檔案, 反過來不知怎麼找。 今天靈機一動, 想到可以這麼搞, 不夠直接, 至少能用就是了: ls -lR DIR | grep "^[-rw]\{10\} " | grep -v USER 2011-01-...
-
昨天意外發現 rsync 有 -z 的參數, 可以壓縮再傳。好奇它的效果就試了一下, 結果得到出人意外的結論: 有時候直接全部重新複製還比較快........, 雖然是很明顯的事實, 用慣 rsync 後到沒想到這點。 簡易的測試環境如下: 原始檔案: 一堆目錄合起來 7G...
-
以使用 LevelDB 為例。 抓好並編好相關檔案,編譯方式見第三方函式庫附的說明: $ ls include/ # header files leveldb/ $ ls out-shared/libleveldb.so* # shared library out-sha...
You should be able to use "find ... -delete" to delete files.
回覆刪除argument list too long 在不同的 freebsd/shell 也會有不同的命令列長度限制
回覆刪除對哦, 上篇就有人回 "find ... -delete", 這回還是忘了試, 大概是覺得命令串起來比較屌, 不自覺就想用串命令的作法......
回覆刪除