ls -fのポイントは何ですか（または、なぜこれがハングしているのですか？）

約100,000個のファイルを含むディレクトリがあります。ls -fが1分以上ハングします。私はstraceを実行し、すぐにgetdentsを確認し始めたので、lsは明らかにディレクトリを読み取っています。また、brkへの呼び出しが多いので、lsは明らかにメモリにバッファリングしています。readdirを呼び出してファイル名を出力する簡単なプログラムを書いたところ、すぐに応答しました。ただし、ls -fは出力を提供しません。何ができますか？-fの要点は、lsがreaddir以外に何も行わないことだと思いました。ディレクトリの内容をリストするポータブルで信頼できる方法はありますか？（これはLinux上のgnuのcoreutilsからのlsであることに注意してください。）

-編集-

エイリアスがありましたが、「/ bin / ls -1f> / dev / null」には8〜15秒かかります。「/ bin / ls -1fx> / dev / null」には4〜11秒かかりますが、簡単なプログラムreaddirは.011秒かかります。GNU lsが吸わないようにするために何をする必要がありますか？

重要なの-fは、すべてのファイルエントリをstatする必要をなくし、すべてが表示される前にそれらをすべて読み取る必要がないようにすることです。これは、他のオプションを無効にするだけの「メタ」オプションです。

だから、はい、それはあなたが期待することをするはずです。なぜそうなのかはわかりませんが、シェルエイリアスや、コマンドに追加オプションを挿入する何かがあると思います。-f無効にするよりも機能を再度有効にし、「より具体的」と見なされる可能性があるため、優先してください。

coreutils 7.0に最適化が追加されました（commit 8d974b00fbbc2025de63e1e6d54827648fefa1c4）：

2008-08-01  Kamil Dudka  <kdudka@redhat.com>
    ls -U1 now uses constant memory
    When printing one name per line and not sorting, ls now uses
    constant memory per directory, no matter how many files are in
    the directory.
    * ls.c (print_dir): Print each file name immediately, when possible.
    * NEWS: Mention the improvement.

最初に頭に浮かぶのは、古いバージョンのcoreutilsを実行しているということです。アップグレードする必要があります。