2億個の小さなファイルを保存およびバックアップする
私のディスクは10x1TB SAS 7200 RPM in RAID 10 with MegaRaid 9260 Hardware Controller with cache/BBU。これにより、4.6TB RAID10ボリュームになります。hdparm -t（デバイスが空の場合）は500MB /秒になります。
RAIDチャンクサイズは64KB、ファイルシステムブロックサイズは2KBです（最小チャンクサイズと4KBブロックサイズに変更します）。
ディレクトリパターンは/data/x/yz/zyxabc.gzです。
XFSへの移行を計画しているEXT4を使用しています。 OSはRHEL6です。
今のところ、それはうまく機能します。ワークロードは99％の読み取りであり、通常の状態では最大300ファイル/秒を読み取ることができます。問題はバックアップです。 scpでバックアップするには6日かかります。 rsyncはさらに遅くなります。 DDは約2MB /秒です。 LVMスナップショットは、スナップショットを取得してバックアップしてから削除する場合のオプションになる可能性があります。データの整合性は私にとって非常に重要です。
ファイルはそれぞれ約0.5〜4KBです。代わりにすべてのファイルをデータベースに保存すると、バックアップのパフォーマンスが向上しますか？妥当なウィンドウでこの多くの小さなファイルをバックアップする問題に取り組むために、他にどのような選択肢がありますか？
xFSに移行する予定です
その場合は、大量のプロザックを事前注文したほうがよいでしょう。 :-)悲しいかな、XFSはそのパターン（たくさんの小さなファイル）をたくさん吸います。
FS change Reiserは、その場合に試す価値のある唯一のオプション、IMOです。notailを使用すると、CPUオーバーヘッドが少なくなります。 w/o notail —ディスクスペースのオーバーヘッドが少なくなります。
64 KのRAIDチャンクも正気を超えています—なぜこのような小さなパターンでディスクI/Oキューをオーバーフローさせるのでしょうか。減らすのではなく増やす！多数の同時I/Oがあれば、問題はありません。
バックアップに関しては、COWFSについて言及することができます。 Btrfs、またはNilfsなど。 LVM-2スナップショットも問題ない可能性があるため、Reiser3への移行と組み合わせて試すことができます。しかし、COW FSには、必要なものを提供する機会が多いと思います。
[〜＃〜] amanda [〜＃〜] または Bacula のような解決策を検討しましたか？
すでに述べたような増分バックアップをサポートするバックアップソリューションを使用するか、ツリーをトラバースして特定の変更時間でのみファイルをコピーするスクリプトを使用できますか？
「一貫性が必要」とはどういう意味かわかりませんが。すべてのファイルを同じ時点（つまりスナップショット）でバックアップする必要があるということですか？その場合、tar、copy、rsyncなどが機能するかどうかはわかりません。ファイルシステムのスナップショットを作成できるものを使用するか、最初にこれらのファイルを作成しているプロセスを一時停止する必要があります。
「DDは約2MB /秒で動作します」
私は混乱しています、ddはデバイスのシーケンシャル（または試行）読み取りを行いませんか？これらのファイルのオンライン使用と競合していますか？その場合は、より多くのディスク/より高速なディスクが必要だと思います。 1TB SASは私が間違っていなければ7,200RPMのままです、600GB 15K SASを拾うことができます。これにより、シークが大幅に削減されます。
それをRAMDiskにダンプしていますか？そのため、宛先の場所がDDテストのボトルネックにならないようにします（ローカルディスクにダンプして戻さないため、シークが高くなります）。
可能な限り最速の読み取りパターンから抜け出すのに2MB /秒が最適な場合は、より高速なディスクが必要です。
ただし、ddは、他のスナップショットと組み合わせないと、一貫性のあるスナップショットを取得できません。