ext4 機能 dir_index の実装におけるバグ
解決策:dir_index なしでファイルシステムを再作成します。または、tune2fs を使用して機能を無効にします (注意が必要です。関連リンク Novell SuSE 10/11:Disable H-Tree Indexing on an ext3 Filesystem を参照してください。 同様の注意が必要な場合があります。
(get a really good backup made of the filesystem)
(unmount the filesystem)
tune2fs -O ^dir_index /dev/foo
e2fsck -fDvy /dev/foo
(mount the filesystem)
- ext4:不思議な「デバイスに空き容量がありません」エラー
ext4 には、デフォルトで有効になっている dir_index と呼ばれる機能があり、ハッシュ衝突の影響を非常に受けやすくなっています。
......
ext4 には、その内容のファイル名をハッシュする可能性があります。これによりパフォーマンスが向上しますが、「小さな」問題があります。ext4 は、ハッシュテーブルがいっぱいになり始めると、そのハッシュテーブルを拡張しません。代わりに、-ENOSPC または「デバイスにスペースが残っていません」を返します。
大量の小さなファイルを保存するための ext4 よりも優れた選択肢の提案:
ファイル システムをオブジェクト ストアとして使用している場合は、それを専門とするファイル システムの使用を検討すると、他の特性が損なわれる可能性があります。簡単な Google 検索で Ceph が見つかりました 、オープンソースのようで、POSIXファイルシステムとしてマウントできますが、他のAPIでアクセスすることもできます.レプリケーションを利用せずに、単一のホストで使用する価値があるかどうかはわかりません.
もう 1 つのオブジェクト ストレージ システムは、OpenStack の Swift です。 .その設計ドキュメントによると、各オブジェクトは個別のファイルとして保存され、メタデータは xattrs に含まれています。ここにそれに関する記事があります。彼らの導入ガイドによると、XFS がオブジェクト ストレージに最適なパフォーマンスを発揮することがわかりました。ワークロードは XFS が得意とするものではありませんが、RackSpace がテストを行ったときは明らかに競合他社よりも優れていました。 XFS は拡張属性を適切かつ高速にサポートしているため、Swift は XFS を好む可能性があります。追加のメタデータが必要ない場合 (またはバイナリ ファイル内に保持されている場合)、ext3/ext4 はオブジェクト ストア バックエンドとして単一のディスクで問題なく動作する可能性があります。
Swift はレプリケーションとロード バランシングを行い、RAID ではなく raw ディスク上に作成されたファイル システムを提供することを提案します。 .そのワークロードは本質的に RAID5 の最悪のケースであることが指摘されています (小さなファイルの書き込みを伴うワークロードについて話している場合、これは理にかなっています。XFS は通常、それらを完全にパックするわけではないので、フルストライプ書き込みを取得し、RAID5 はパリティストライプを更新するためにいくつかの読み取りを行う必要があります.Swift のドキュメントでは、ドライブごとに 100 個のパーティションを使用することについても言及されています.これは Swift の用語であり、それぞれに 100 個の異なる XFS ファイルシステムを作成することについて話しているわけではありません. SATA ディスク。
ディスクごとに個別の XFS を実行することは、実際には大きな違いです . 巨大の代わりに free-inode マップを使用すると、各ディスクには個別の空きリストを持つ個別の XFS が作成されます。また、小さな書き込みに対する RAID5 のペナルティを回避します。
レプリケーションや負荷分散を処理するために Swift などを使用するのではなく、ファイルシステムを直接オブジェクト ストアとして使用するようにソフトウェアを構築している場合は、少なくともすべてのファイルを単一のディレクトリに配置することを避けることができます。 (Swift のドキュメントで、ファイルを複数のディレクトリに配置する方法について言及されているのを見たことがありませんが、確かにそうです。)
ほとんどすべての通常のファイルシステムでは、次のような構造を使用すると役立ちます
1234/5678 # nested medium-size directories instead of
./12345678 # one giant directory
おそらく約 10,000 のエントリが妥当なので、適切に分散された 4 文字のオブジェクト名を取得し、それらをディレクトリとして使用するのが簡単な解決策です。バランスがよく取れている必要はありません。奇妙な 100k ディレクトリはおそらく目立った問題ではなく、いくつかの空のディレクトリも同様です。
XFS 大量の小さなファイルには理想的ではありません。できることはしますが、より大きなファイルの書き込みをストリーミングするために最適化されています。とはいえ、一般的な使用には全体的に非常に優れています。 ENOSPC がありません ディレクトリのインデックス付け（AFAIK）での衝突について、そして何百万ものエントリを持つ1つのディレクトリを持つことを処理できます。 (ただし、少なくとも 1 レベルのツリーを使用することをお勧めします。)
Dave Chiner は、膨大な数の inode が割り当てられた XFS のパフォーマンスについてコメントし、遅い touch につながりました。 パフォーマンス。空き i ノードのビットマップが断片化されるため、割り当てる空き i ノードを見つけるのに、より多くの CPU 時間がかかり始めます。これは、1 つの大きなディレクトリと複数のディレクトリの問題ではなく、ファイルシステム全体で多くの inode が使用されている問題であることに注意してください。ファイルを複数のディレクトリに分割すると、OP で ext4 がチョークしたような問題の解決に役立ちますが、空き領域を追跡するというディスク全体の問題には役立ちません。 RAID5 上の巨大な XFS と比較して、Swift のディスクごとの個別ファイルシステムがこれに役立ちます。
btrfs かどうかはわかりません はこれが得意ですが、そうかもしれないと思います。 Facebook が主任開発者を雇っているのには理由があると思います。 :P Linux カーネル ソースの解凍など、私が見たいくつかのベンチマークでは、btrfs がうまく機能することが示されています。
reiserfs を知っています この場合に最適化されましたが、維持されていたとしてもほとんど維持されていません。 reiser4 を使用することはお勧めできません。でも、実験してみるのも面白いかもしれません。しかし、これは将来性のない選択肢です。古い reiserFS でのパフォーマンス低下の報告も見ましたが、適切なデフラグ ツールはありません。 (google filesystem millions of small files 、既存の stackexchange の回答のいくつかを見てください。)
おそらく何かが足りないので、最終的な推奨事項:serverfault で質問してください! 今何かを選ぶ必要がある場合は、BTRFS を試してみるといいでしょうが、バックアップがあることを確認してください。 (特に、RAID の上で実行する代わりに、BTRFS の組み込みの複数ディスク冗長性を使用する場合。読み取りが主なワークロードでない限り、小さなファイルは RAID5 にとって悪いニュースであるため、パフォーマンスの利点は大きくなる可能性があります。)
この問題について、以下は私が修正したことです (以下の手順では sudo アクセスが必要になる場合があります):
<オール>以下のコマンドを使用して取得できる Inode の使用済みスペースは 100% でした
df-i/
ファイルシステム i ノード IUsed IFree IUse% マウント済み
/dev/xvda1 524288 524288 o 100% /
- iNoted を解放する必要があるため、以下のコマンドを使用して i ノードの数を持つファイルを見つける必要があります:
これが i ノードの問題であるかどうかを確認してください:
<ブロック引用>
df -ih
i ノード数が多いルート フォルダを探してください:
for i in /*; do echo $i; find $i |wc -l; done
特定のフォルダーを検索してみてください:
for i in /src/*; do echo $i; find $i |wc -l; done
- これで、多数のファイルが含まれるフォルダーにゼロダウンしました。エラーを回避するために、以下のコマンドを次々に実行します (私の場合、実際のフォルダーは /var/spool/clientmqueue でした):
find /var/spool/clientmqueue/ -type f -mtime +1050 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +350 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +150 -exec rm -f {} + find /var/spool/clientmqueue/ -type f -mtime +50 -exec rm -f {} +