iノードがディスク上で閉じているLinuxファイルシステム
Linuxで_ls -laR /media/myfs_をできるだけ速くしたいと思います。ファイルシステムには100万個のファイルがあり、合計ファイルサイズは2 TBで、一部のディレクトリには10000個ものファイルが含まれています。どのファイルシステムを使用し、どのように構成する必要がありますか？
私の知る限り、_ls -laR_が遅い理由は、各iノードをstat(2)する必要があるため（つまり、100万stat(2) s）、iノードがランダムに分散されているためです。ディスクの場合、各stat(2)には1つのディスクシークが必要です。
これが私が考えていたいくつかの解決策ですが、どれも私は満足していません：
SSDでのシーク操作は高速であるため、SSDでファイルシステムを作成します。 2TB SSDが存在しないか、非常に高価であるため、これは機能しません。
SSDとディスクの2つのブロックデバイスにまたがるファイルシステムを作成します。ディスクにはファイルデータが含まれ、SSDにはすべてのメタデータ（ディレクトリエントリ、iノード、POSIX拡張属性を含む）が含まれます。これをサポートするファイルシステムはありますか？システムクラッシュ（停電）に耐えられるでしょうか？
_
find /media/myfs_の代わりにext2、ext3、またはext4で_ls -laR /media/myfs_を使用します。前者は_d_type_フィールドを利用できるためです（getdents(2)のマニュアルページを参照）。したがって、統計をとる必要はありません。残念ながら、これは私の要件を満たしていません。_find /media/myfs_が印刷しないすべてのファイルサイズも必要だからです。ディレクトリエントリにiノードを格納するVFATなどのファイルシステムを使用します。私はこれが大好きですが、VFATは私にとって十分な信頼性と柔軟性がなく、それを実行する他のファイルシステムを知りません。あなたは？もちろん、ディレクトリエントリにiノードを格納することは、リンク数が1を超えるファイルでは機能しませんが、ユースケースではそのようなファイルが数十個しかないため、問題はありません。
_
/proc_またはsysctlのいくつかの設定を調整して、iノードがシステムメモリに永久にロックされるようにします。これは最初の_ls -laR /media/myfs_を高速化することはありませんが、その後のすべての呼び出しを驚くほど高速にします。これどうやってするの？このアイデアは、現在30分かかる最初の呼び出しを高速化しないため、好きではありません。また、POSIX拡張属性もメモリにロックしたいと思います。そのために私は何をしなければなりませんか？オンラインデフラグツールを備えたファイルシステムを使用します。このツールは、iノードをブロックデバイスの先頭に再配置するように指示できます。再配置が完了したら、_
dd if=/dev/sdb of=/dev/null bs=1M count=256_を実行して、シークせずにカーネルのメモリ内キャッシュにフェッチされたブロックデバイスの先頭を取得できます。そうすると、stat(2)操作が高速になります。キャッシュから読み取ります。それらが読み取られたら、それらのiノードやブロックをメモリにロックする方法はありますか？どのファイルシステムにそのようなデフラグツールがありますか？
残念ながら、私は最後の30分間、答えをグーグルで検索しましたが、答えはありません。
SSDとディスクの2つのブロックデバイスにまたがるファイルシステムを作成します。ディスクにはファイルデータが含まれ、SSDにはすべてのメタデータ（ディレクトリエントリ、iノード、POSIX拡張属性を含む）が含まれます。これをサポートするファイルシステムはありますか？システムクラッシュ（停電）に耐えられるでしょうか？
まさに私も欲しいものです。
複数のリンクを投稿することは許可されていないため、リンクについては、このPastebinを参照してください...
http://www.notehub.org/2014/10/2/external-metadata-more-information
Btrfsからのマルチデバイスサポートについてここで説明します。
Btrfs：複数のデバイスでの作業、Jonathan Corbet著、2013年12月30日（LWN）、[リンク] [1]
ただし、メタデータ（-m raid1）をSSDにミラーリングすることはできますが、少なくとも部分的には、データ（-d raid0）ストレージにもSSDを使用する必要があります。
良いニュースは、行われている作業があるということです：
専用メタデータドライブJanSchmidtとArneJansen（まだカーネルにはありません）分割できますデータとメタデータIO非常に簡単です。メタデータはシークによって支配される傾向があり、多くのアプリケーションでは、メタデータをより高速なSSDに配置するのが理にかなっています。[リンク] [2]
IBM独自のGeneralParallel File System（GPFS）を使用する場合は、これはすでに可能であるようです。 「すべてのGPFSファイルシステムメタデータをSSDにマイグレーションする方法」を読んでください：[リンク] [3]
ディスクにはファイルデータが含まれ、SSDにはすべてのメタデータが含まれています...これをサポートするファイルシステムはありますか？
btrfsはこれをある程度サポートしています btrfs Wiki 。メタデータにraid1を指定して（データにraid0-ほとんどのデータは大きなHDDに保存される）、SSDが常に読み取り用のメタデータのコピーを持つようにすることができます（btrfsがどのように賢いbtrfsを選択するかはわかりませんメタデータを読み取るためのソース）。私はそのような設定のベンチマークを見たことがありません。
私はあなたの質問に対する私の答えを私の答えと交換します：すべてのiノードをメモリに保持するために/ procまたは/ sysでどのノブをいじる必要がありますか？
今あなたの質問への私の答えのために：
私は同様の問題に苦しんでいます。サーバーの負荷が高いときに、数千のファイルがあるディレクトリに対してls-lをNFS上ですばやく動作させようとしています。
NetAppはタスクを見事に実行します。私がこれまでに試した他のすべてはそうではありません。
これを調べて、メタデータをデータから分離するファイルシステムをいくつか見つけましたが、それらにはすべていくつかの欠点があります。
- dualfs：2.4.19で利用できるパッチがいくつかありますが、それ以外はあまりありません。
- lustre：ls -lは最悪のシナリオです。これは、すべてのメタデータ（を除く）のファイルサイズがメタデータサーバーに保存されているためです。
- QFS for Solaris、StorNext/Xsan：多大な投資がなければ、優れたメタデータパフォーマンスで知られていません。
したがって、それは役に立ちません（デュアルフを復活させることができない限り）。
あなたの場合の最良の答えは、可能な限りスピンドル数を増やすことです。これを行うための最も醜い（しかし最も安価で最も実用的な）方法は、数年前のエンタープライズクラスのJBOD（または2つ）とファイバーチャネルカードをEbayから入手することです。あなたが一生懸命に見えるならば、あなたはあなたの費用を500ドルかそこら以下に保つことができるはずです。 「146gb」と「73gb」という検索用語は非常に役立ちます。あなたは売り手にこのようなもので取引をするように説得することができるはずです、なぜなら彼らは彼らの束を周りに座っていて、興味のある買い手はほとんどいないからです：
すべてのドライブにRAID-0ストライプを設定します。 1つまたは2つのドライブが必然的に故障するため、データを忠実にバックアップしてください。 cpやrsyncの代わりにtarをバックアップに使用して、受信側の単一ドライブが数百万のiノードを処理する必要がないようにします。
これは、ファイルシステムのIOPSを2〜4 TBの範囲で増やすために（とにかく、この特定の歴史的な瞬間に）私が見つけた最も安価な方法です。
それがお役に立てば幸いです-または少なくとも興味深いです！
Ext4を使用して、dir_indexが設定されていることを確認します。これを実行して、そのフラグを確認できます。
dumpe2fs /dev/drivepartition | grep "Filesystem features:"
遭遇する最大の問題は、ファイルシステム全体のファイル数だけです。ファイルシステム全体で実行する操作はすべて、各ファイルを確認する必要があります。これは、どのファイルシステムにも当てはまります。ディレクトリ内の10,000ファイルは多くのように思えるかもしれませんが、40,000ファイル以上になるまでファイルシステムの速度が低下しないことがわかりました。これは、ext2のようなファイルシステムの古い症状です。
汎用のファイルシステムだけでなく、特定のことをしようとしているようです。あなたがやろうとしていることを説明できれば、おそらくデータを最適化する方法を提案することができます。たとえば、データベース。