多くの小さなファイル（SSDではなくHDD）を保存するための最も高性能なLinuxファイルシステムは何ですか？

43

多数の小さなファイルと少数の大きなファイルを含むディレクトリツリーがあります。ファイルの平均サイズは約1キロバイトです。ツリーには210158個のファイルとディレクトリがあります（この番号はを実行して取得されましたfind | wc -l）。

週に数回、ファイルのごく一部が追加/削除/書き換えされます。これは、小さなファイルだけでなく、（少数の）大きなファイルにも適用されます。

私が試したファイルシステム（ext4、btrfs）には、ディスク上のファイルの配置にいくつかの問題があります。長い時間をかけて、ディスク上のファイル（物理ディスクではなく回転メディア）の物理的な位置がよりランダムに分散されています。このランダムな分布のマイナスの結果は、ファイルシステムが遅くなっていることです（たとえば、新しいファイルシステムよりも4倍遅い）。

このパフォーマンス低下の影響を受けず、回転メディア上で安定したパフォーマンスプロファイルを維持できるLinuxファイルシステム（またはファイルシステムメンテナンスの方法）はありますか？ファイルシステムはFuseで実行できますが、信頼性が必要です。

linux  filesystems  performance 
どのファイルが大きく/あまり頻繁に変更されず、どのファイルが小さく/頻繁に変更されるかがわかっている場合は、それぞれのシナリオにより適した、異なるオプションを持つ2つのファイルシステムを作成できます。それらが同じ構造の一部であるためにアクセス可能にする必要がある場合は、マウント、シンボリックリンクを使用していくつかのトリックを行うことができます。
— マーチン
btrfs（copy-on-write機能付き）がしばらくの間あなたに反応しないことを知って、私は静かに驚いています。私は結果をあなたから共有してもらいたいと思います。おそらくそれを使ってパフォーマンス調整の新しい方向でお互いを助けます。
— ニキルマレー
Linuxには新しい動物のオンラインzfsがあり、ご覧になりたい場合に備えて、ネイティブモードとヒューズの実装で利用できます。
— ニキルMulley
一度Linuxでzfsを試してみましたが、非常に不安定でした。ファイルシステムを頻繁に完全にロックすることができました。Boxは機能しますが、FSへのアクセスはすべてハングします。
— パトリック
— のNikhil Mulley

回答:

47

性能

私は小さなベンチマーク（source）を書いて、何十万もの小さなファイルでどのファイルシステムが最高のパフォーマンスを発揮するかを見つけました。

  • / dev / urandomのデータを使用して300000ファイル（512Bから1536B）を作成します
  • 30000個のランダムファイルを書き換えてサイズを変更する
  • 30000個の順次ファイルを読み取る
  • 30000個のランダムファイルを読み取る

  • すべてのファイルを削除する

  • すべてのステップの後にキャッシュを同期およびドロップします

結果（秒単位の平均時間、低いほど良い）：

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

結果：
Ext4の全体的なパフォーマンスは良好でしたが、ReiserFSはシーケンシャルファイルの読み取りが非常に高速でした。XFSは多くの小さなファイルで低速であることが判明しました。このユースケースには使用しないでください。

フラグメンテーションの問題

ファイルシステムがドライブにファイルを配布するのを防ぐ唯一の方法は、パーティションを本当に必要な大きさだけに保つことですが、ファイル内の断片化を防ぐために、パーティションを小さくしすぎないように注意してください。LVMを使用すると非常に役立ちます。

参考文献

Arch Wikiには、ファイルシステムのパフォーマンスに関する素晴らしい記事があります。

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

— タッファー
ソース
4
その比較の基になっているカーネルのバージョンを指定する必要があります。XFSは、最近のカーネルの1つで非常に重要な速度の改善を実現しました（2.6.31であると考えてください。しかし、そのことについては引用しないでください）。
— パトリック
1
btrfsは内部でlvmトリックを行います。ディスクの小さなチャンクを割り当て、それらのチャンクにファイルを配置し、既存のチャンクがいっぱいになったときにのみディスクの別のチャンクを割り当てます。
— -psusi
1
これは、どのファイルシステムにも当てはまります。アプリケーションがfsync（）のようなものを使用する理由です。
— プーシィ
2
@taffer、そうです。トランザクションは、他のファイルシステムのジャーナルと同じ効果があります：fsメタデータを保護します。理論的には、あなたが説明する方法でアプリケーションで使用できますが、現在、アプリケーションがトランザクションを開いたり閉じたりできるAPIはありません。
— psusi
1
@taffer「最近のベンチマーク」は3年以上前の2015年4月のもので、デフォルトのオプションのみでXFSを使用しています。これはxfsprogs 3.2.3より前のバージョンであり、XFS v5がデフォルトであり、XFS v5がもたらすすべての利点があります。また、-m finobt = 1でフォーマットされていませんでした。これは、小さなファイルと大量のメタデータの更新を伴うXFSパフォーマンスのゲームチェンジャーです。いいえ、特効薬はありませんが、特にパフォーマンスを変更する主要な機能を無視、使用不可、または無効にした場合、古いベンチマークに基づいて意見を述べることは賢明ではありません。
— ジョディリーブルション
7

私はこのタスクにReiserFSを使用していますが、特に多くの小さなファイルを処理するために作られています。funtoo wiki には、読みやすいテキストがあります。

ReiserFSには、特に小さなファイルのパフォーマンスを向上させることを目的とした多くの機能があります。ext2とは異なり、ReiserFSは固定の1 kまたは4 kブロックのストレージスペースを割り当てません。代わりに、必要な正確なサイズを割り当てることができます。

— バールン
ソース
1
ReiserFSには安定性の問題もあるため、RHとSuSEはそのFSを削除しました。原則（BTreeベースのFS）から、BTRFSは匹敵するはずです。
— ニルス
0

XFSは、このような状況で非常に優れたパフォーマンスを発揮することで知られています。これが、メールストア（1つのディレクトリに数十万のファイルを含むことができる）の仕事で使用する理由の一部です。ReiserFSよりも耐障害性に優れており、広く使用されており、一般に非常に成熟したファイルシステムです。

さらに、XFSはオンラインでの最適化をサポートしています。ただし、遅延割り当て技術を使用しているため、最初は他のファイルシステムよりも断片化が少なくなります。

— パトリック
ソース
20
XFSは、このような状況で非常に優れたパフォーマンスを発揮することで知られています。[引用が必要]
— -taffer
8
ええと、xfsは特に逆のことで知られています。大きなファイルでは本当にうまく機能しますが、小さなファイルではうまく機能しません。例えば、この徹底的なベンチマークを見て（または10ページ^^上の結論に右ジャンプ）：ilsistemista.net/index.php/linux-a-unix/...
— レビ
1
@Levitそのレポートを読み間違えていると思います。このレポートは、XFSがランダムIOに対して非常にうまく機能することを非常に明確に示しています。しかし、それはさておき、レポートはこの質問のシナリオの種類、多くのファイルを扱っていません。ランダムIOは1つのことで、多数のファイルがext *に直面します。
— パトリック14
2
ランダムな読み取り/書き込み操作がある場合、XFSが本当に優れている唯一の場所です（メカニカルディスク上の真にランダムな読み取りパターンが10MB / sを取得できることはまだ奇妙に思えます-現実の世界では飛ばない最適化のようです） （imho））、7ページで私が以前言ったことを示しているのに対し、XFSは大きなファイルを扱うのに本当に良いです！ページ3と5を見てください。特に3を見ると、明らかに小さいサイズのファイルを処理していることがわかります。私は本当にXFSに対して何もありませんが、あなたがどこでも見つけることから、それは多くの小さなファイルのための最良の最適ではありません、私が言っているすべてです！
— レビテ14
5
XFS は、大きなファイルに関しては、これらのファイルが長期間にわたって小さなチャンクでランダムに/ゆっくりと拡張されると、非常に遅くなる可能性もあります。（典型的なsyslogdパターン。）たとえば、XFS over MDセットアップの私の側では、1.5 GBファイルの削除に4.75分（！）かかったのに、書き込み速度でディスクドライブが100トランザクション/秒の制限に制限されていた2 MB /秒以上。これは、ドライブが既に最大になっているため、同じドライブでの他の並列I / O操作のパフォーマンスにも悪影響を及ぼします。他のFSでそのようなものを見たことがない（またはベンチマークでテストされている）。
— ティノ
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.