回答:
データをどの程度評価していますか？
真剣に、各ファイルシステムには独自のトレードオフがあります。先に進む前に、私はXFSとReiserの両方の大ファンですが、Ext3を頻繁に実行しています。したがって、ここでは実際のファイルシステムの偏りはありません。ただ知らせます...
ファイルシステムがコンテナにすぎない場合は、最高のアクセス時間を提供するものを使用してください。
データに大きな価値がある場合は、XFSを避けたいでしょう。どうして？ジャーナリングされているファイルの一部を回復できない場合、ブロックをゼロにし、データを回復不能にするためです。この問題はLinux Kernel 2.6.22で修正されています。
ReiserFSは、ハードクラッシュしない限り、優れたファイルシステムです。ジャーナルリカバリは正常に機能しますが、何らかの理由でパーティション情報が失われたり、ファイルシステムのコアブロックが吹き飛ばされた場合、ディスク上に複数のReiserFSパーティションがある場合、リカバリメカニズムが基本的にディスク全体、セクターごとに、それが「考える」ものを探すことがファイルシステムの始まりです。ReiserFSで3つのパーティションがあり、そのうち1つだけが破壊されている場合、回復プロセスが他の2つのシステムからのフランケンシュタインの混乱をつなぎ合わせるため、これが引き起こす混乱を想像できます。
Ext3は「遅い」です。「32,000個のファイルがあり、すべてが実行されているのを見つけるのに時間がかかりますls」。いたるところに何千もの小さな一時テーブルを作成する場合、ほんの少しの悲しみがあります。新しいバージョンには、ディレクトリトラバーサルを劇的に削減するインデックスオプションが含まれるようになりましたが、それでも痛みを伴う場合があります。
私はJFSを使用したことがありません。私が今まで読んだすべてのレビューは、「堅実だが、ブロック上で最速の子供ではない」という線に沿ったものであったとコメントすることができます。調査に値する場合があります。
十分な短所、長所を見てみましょう：
XFS：
ReiserFS：
Ext3：
ご覧のとおり、それぞれに独自の癖があります。問題は、あなたにとって最も風変わりなものはどれですか？
また、ファイルシステムなしでInnoDBを実行し、ファイルシステムのオーバーヘッドなしでパフォーマンスを改善できることも注目に値します。推奨するかどうかはわかりませんが、以前に問題なく使用しました。
さらに、90％の読み取りと10％の書き込みで実行している場合、InnoDBのトランザクション機能が必要でない限り、読み取りパフォーマンスを向上させるためにMyISAMへの移植を検討することがあります。
ここでの回答は非常に非推奨であり、Googleの結果に表示されるため、更新が必要です。
生産環境の場合、XFS。毎回。XFSはジャーナリングされ、非ブロッキングです。本番環境でInnoDBを使用する最新の（2011/2012）MySQLデータベースに対して、次の変数があることを確認してください。
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT
EXT3またはEXT4を使用しないでください。ある日、BTRFSがそこに到着します。
EXT3、おそらくEXT4は、iノードレベルでロックしますが、スマートではありません！
出典：-www.mysqlperformanceblog.com- http ://dev.mysql.com/doc/internals/en/index.html-Sasha Pachevによる MySQL内部の理解-https: //www.facebook.com/note.php？ note_id = 10150210901610933 - http ://oss.sgi.com/projects/xfs/training/- 一部のスイングキット、試行錯誤。
編集：更新。EXT4は2013年半ばの時点でかなりうまくいっているようです！BTRFSはまだ良い選択肢ではありません。また、RHELはXFSを新しいデフォルトのファイルシステムにする可能性があります。繰り返しますが、EXT3は使用しないでください。
大した違いはないでしょう。ディストリビューションがデフォルトとして使用しているものがあれば、それで十分です。
他のことを調整する努力を費やします-十分なRAMを取得します-吸わないRAIDコントローラを取得します-データベースのアプリケーションの不十分な（ab）使用を修正します行われて）。
ただし、mysql tmpdirを配置するファイルシステムを慎重に検討してください。これはパフォーマンス、特にディスクベースのfilesort（）を実行するクエリに影響します（詳細についてはEXPLAINを参照してください）。
遅延割り当てをサポートするファイルシステムは、キャッシュ内に保持するのに十分なRAMがある場合、短命のファイルのIOを完全に回避できるため、ここで本当に便利だと思います。たとえば、XFSは、割り当てられる前に削除されて閉じられるファイルをまったく作成しません。
もちろん、tmpfsにtmpdirを配置することはパフォーマンスの観点からは魅力的ですが、スペースを使い果たして、ディスクの一時ファイルが使用されていても成功するクエリが失敗するリスクにつながります。
さまざまなファイルシステムで実行されているMySQLのベンチマーク「ラウンドアップ」を含む最近の記事は見つかりません。あなたが説明するワークロードを考えると、ファイルレベルの断片化が大きな問題になるとは思いません。正式なベンチマークがなければ、信頼できるものとは言えませんが、上記のすべてのファイルシステムはほぼ同じ球場でパフォーマンスを発揮します（つまり、パフォーマンスの数値はすべて同程度）。 。
ファイルシステムはストレージエンジンがアクセスしている大規模なエクステントを管理しているだけなので、データベースは実際にショーを実行しています。
それでも、これらすべてのファイルシステムでパフォーマンスのラウンドアップを行うことは興味深いでしょう。（しかし、MySQLに対する熱意はまったくないので、引き受けません。Postgres、OTOHのベンチマークは興味深いかもしれません...）
私見Linuxで利用可能なFSは注目に値します：
XFS（読み取り速度の低さ）は、システムリソースは軽く、大きなファイルでは高速ですが、多くの小さなファイルを処理するには不十分であることが知られています。
ReiserFS（書き込み速度が遅い）はシステムリソースにはあまり適していませんが、多数の小さなファイルで非常にうまく機能します。
EXT3はその中間に位置し、すべてのフィールドで許容可能なパフォーマンスを発揮します（デフォルトの Linux FS と見なされた理由）。
私はまだReiserFS4ではなくEXT4を使用していませんが、いくつかのベンチマークを調べましたが、ReiserFSは読み取り速度に関して最高のパフォーマンスを持っているようです。
これを見てください：ReserFS4 X Ext4 X Ext3
安定性、セキュリティ、および成熟度からExt3をお勧めしますが、読み取り速度が最も重要な場合は、ReiserFSを検討する必要があります。
FSを選択する前に、CPU使用率、安定性、セキュリティなども考慮する必要があることに注意してください。
そしてもちろん、特定の環境でパイロット、テスト、およびベンチマークを作成することは、何があなたにとって最適かを知るための常に最良の方法です。
PS：もっと多くのベンチマークを投稿したはずですが、複数のリンクを投稿することはできません。