多数の（小さな）ファイルがファイルシステムのパフォーマンスを低下させる可能性はありますか？
私はアーカイブプロジェクトに取り組んでおり、現在514600の画像（200kbから2mbの範囲）を4TB NASドライブに保存しています。ドライブ自体はext4としてフォーマットされており、私は書いていますcifs/smbを介したネットワーク経由のファイル。
このような膨大な数のファイルを保存することの意味はありますか？ファイルシステムは断片化の犠牲になりますか？
すでにディスク上にあるファイルが以前よりも大きくなるように変更された場合に断片化が発生し、 クラスターサイズ よりも小さいファイルが断片化されることはありません。質問に正しく答えるには、クラスターサイズ、使用中のドライブの割合、およびディスク領域の初期割り当て後にファイルが変更されるかどうかを知る必要があります。
すべてのファイルシステムのオーバーヘッド（およびスキャン/シーク時間）のために、多くの小さなファイルといくつかの大きなファイルのIO操作ははるかに遅くなります。したがって、パフォーマンスの低下を考慮すると、そうです。一度に5000個にアクセスするのか、一度に数個にアクセスするのかによって異なります。
特にExt4はデフラグを必要としません ファイルにスペースを割り当てる方法のためにWindowsファイルシステムが行うのと同じ方法です。パーティションが90％いっぱいでない限り、私は心配しません。それ。
このような膨大な数のファイルを保存することの意味はありますか？
ファイルシステムが処理できるファイルの最大数に注意する必要があることを付け加えておきます。 （使用するext4上の）ファイルはiノードを消費します。 iノードテーブルは、ファイルシステムの作成時に静的に割り当てられます。これを増やす唯一の方法は、ファイルシステムを再作成することです。
現在のiノードの使用済み/空き番号はdf -iまたはtune2fs -l /path/to/deviceで確認できます。
デフォルト値は、非常に小さなファイルを保存する場合にのみ問題になります。
アクセス速度が大幅に低下します。 Javaプロジェクトでは、比較的小さなファイルが大量にあるため、これはよくある問題です。1つのアーカイブに保存する方が効率的であり、アクセスは高速ですが、開梱する必要があります。
あなたの場合、ファイルは小さくないので、断片化の問題はおそらくないでしょう。
アーカイブプロジェクトに取り組んでいるので、おそらくZipまたは TAR/GZIP を使用する必要があります。ファイルがすでにパックされている場合は、TARだけを使用して、ファイルを1つの大きなファイルにまとめることができます。妥当な「梱包単位」を見つけてください。後ですべてのファイルを簡単に見つけることができます。