快速ls命令

Question

我必須得到一個包含大約200萬個文件的目錄列表，但是當我對它做一個ls命令時，什麼都不會回來。我等了3個小時。我試過ls | tee directory.txt，但似乎永遠掛不住。

我假設服務器正在做很多inode排序。有沒有什麼辦法可以加快ls的命令來獲取文件名的目錄列表？我現在不關心大小，日期，許可等。

Answer 1

find ./ -type f（它會查找當前目錄中的所有文件）？取下-type f找到一切。

Answer 2

嘗試使用：

find . -type f -maxdepth 1 

這將只列出在目錄中的文件，如果你想列出的文件和目錄離開了-type f說法。

Answer 3

可以嘗試的事情：

Check ls is not aliased？

alias ls 

也許試試找？

find . \(-type d -name . -prune \) -o \(-type f -print \) 

希望這會有所幫助。

Answer 4

您可以重定向輸出並在後臺運行ls進程。

ls > myls.txt & 

這將允許您繼續關於您的業務，而其運行。它不會鎖定你的shell。

不知道運行ls和獲取更少數據的選項。您始終可以運行man ls進行檢查。

Answer 5

我假設你使用的是GNU ls？ 嘗試

\ls 

它將unalias通常的LS（LS --color =自動）。

Answer 6

ls -U 

將做ls沒有排序。

Answer 7

你使用什麼分區類型？

在一個目錄中有數百萬個小文件，使用JFS或ReiserFS可能是一個不錯的主意，它對許多小文件具有更好的性能。

Answer 8

您應該提供有關您所使用的操作系統和文件系統類型的信息。在某些特定的UNIX和某些文件系統上，您可以使用命令ff和ncheck作爲替代。

Answer 9

如果一個進程「不回來」，我建議strace分析進程與操作系統的交互方式。

在LS的情況下：

$strace ls 

你會看到，它讀取的所有目錄條目（getdents(2)）之前，它實際上輸出任何東西。 （整理...因爲它已經被這裏提到）

Answer 10

好處多多的解決方案在這裏，但在完整的利益：

echo * 

Answer 11

您也可以使用xargs的。只需輸入ls到xargs。

ls | xargs 

如果不工作和找到上面的例子都沒有工作，試戴管道到xargs的因爲它可以幫助內存使用，可能會造成您的問題。

Answer 12

一些後續步驟： 您沒有提及您正在運行的操作系統，這將有助於指出您正在使用哪個版本的ls。這可能不是一個'bash'問題，而是一個ls問題。我的猜測是你使用的是GNU ls，它有一些在某些情況下很有用的功能，但是在大目錄上會讓你失望。

GNU ls試圖更漂亮地安排列。 GNU ls試圖對所有文件名進行智能排列。在一個巨大的目錄中，這需要一些時間和內存。

爲 '修復' 這一點，你可以嘗試：

ls -1＃在所有

沒有列找到BSD LS某個地方，http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/ls/和使用你的大目錄。

使用其他工具，如發現

Answer 13

這可能不是一個有用的答案，但如果你沒有find您可以湊合着用tar

$ tar cvf /dev/null . 

有人告訴我比我更年長的人，「回到當天」，單用戶和恢復環境比現在更受限制。這就是這個技巧的來源。

Answer 14

這將是最快的選擇AFAIK：ls -1 -f。

• -1（無柱）
• -f（不排序）

Answer 15

有幾種方式來獲得文件的列表：

使用此命令來獲取列表不排序：

ls -U 

或者將文件列表通過u唱：

ls /Folder/path > ~/Desktop/List.txt 

Answer 16

使用

ls -1 -f 

快10倍左右，這是很容易做到（我用1萬個文件進行測試，但我原來的問題，有6個800 000 000文件）

但在我的情況下，我需要檢查一些特定的目錄是否包含超過10 000個文件。如果有超過10 000個文件，我不再感興趣那裏有多少個文件。我剛剛退出該程序，以便它運行得更快，並且不會嘗試逐個讀取其餘的內容。如果少於10 000，我會打印確切的金額。如果您指定的參數值大於文件大小，我的程序速度與ls -1 -f非常相似。

您可以通過鍵入使用當前目錄下的我的程序find_if_more.pl：如果你只是有興趣，如果有N多的文件，腳本將完成的速度比LS -1 -f非常

find_if_more.pl 999999999 

大量的文件。

#!/usr/bin/perl 
    use warnings; 
    my ($maxcount) = @ARGV; 
    my $dir = '.'; 
    $filecount = 0; 
    if (not defined $maxcount) { 
     die "Need maxcount\n"; 
    } 
    opendir(DIR, $dir) or die $!; 
    while (my $file = readdir(DIR)) { 
     $filecount = $filecount + 1; 
     last if $filecount> $maxcount 
    } 
    print $filecount; 
    closedir(DIR); 
    exit 0; 

Answer 17

這個問題似乎很有趣，我正在瀏覽發佈的多個答案。爲了解發布的答案的效率，我已經在200萬個文件上執行了這些文件，結果如下。

$ time tar cvf /dev/null . &> /tmp/file-count 

real 37m16.553s 
user 0m11.525s 
sys  0m41.291s 

------------------------------------------------------ 

$ time echo ./* &> /tmp/file-count 

real 0m50.808s 
user 0m49.291s 
sys  0m1.404s 

------------------------------------------------------ 

$ time ls &> /tmp/file-count 

real 0m42.167s 
user 0m40.323s 
sys  0m1.648s 

------------------------------------------------------ 

$ time find . &> /tmp/file-count 

real 0m2.738s 
user 0m1.044s 
sys  0m1.684s 

------------------------------------------------------ 

$ time ls -U &> /tmp/file-count 

real 0m2.494s 
user 0m0.848s 
sys  0m1.452s 


------------------------------------------------------ 

$ time ls -f &> /tmp/file-count 

real 0m2.313s 
user 0m0.856s 
sys  0m1.448s 

------------------------------------------------------ 

總結的結果

1. ls -f命令跑快一點比ls -U。禁用顏色可能會導致此改進。
2. find命令以2.738秒的平均速度跑第三。
3. 只跑ls花了42.16秒。在我的系統中ls是ls --color=auto的別名
4. 使用shell擴展功能echo ./*運行50.80秒。
5. 基於tar的解決方案需要約37 miuntes。

當系統處於閒置狀態時，所有測試都是單獨完成的。

這裏要注意的一件重要事情是，文件列表不是打印在終端上，而是 ，它們被重定向到一個文件，稍後使用wc命令計算文件計數。 如果在屏幕上打印輸出，則命令運行速度太慢。

任何想法，爲什麼會發生這種情況？

Answer 18

我有在它400萬個文件和必由之路目錄我LS立即吐出文件，而無需大量的第一翻騰的是

ls -1U