回答:
フォロニクスによるテストによれば、それは常に多くの要因に依存します。1つのケースでBtrfsはEXT4、SSDで大きなファイルを読み取る場合よりもはるかに優れたパフォーマンスを発揮します。同様に、ディスクトランザクションのパフォーマンスを考慮しながら、Ext4後者よりもパフォーマンスを向上できます。
これらのテストについては、こちら、こちら、こちらをご覧ください（警告：長い記事）。
しかし、合計すると、Btrfsには現在、EXT4ファイルシステムよりも定量的なパフォーマンス上の利点はありません（ SSDモードで使用している場合でも）。
したがってExt4、今のところ選択できます。
2016年にこの質問につまずいた人のために... ext4を使用してください。私はbtrfsを試してみましたが、その違いは相当なものです。10日間でext4にIOを書き込むと、17,800セクターになりました。Btrfs？490,400セクター。同じSSD、同じファイルシステム、異なるパーティション。基本的に、同じワークロード。
ドライブで書き込みアクティビティがゼロの場合、ext4とbtrfsの両方が「静か」になります。それは良い。
Ext4は、変更されたデータに加えてオーバーヘッドを書き込みます。オーバーヘッドは、書き込まれたデータに関連しています。4K書き込み（1ブロック）は、次のコミット時に約50〜80ブロックのオーバーヘッドをプッシュします。（ext4 Journalは完全に有効化されています）
btrfsの単一の4Kブロックを変更すると、次のコミット時に4000〜5000ブロックのオーバーヘッドをプッシュします。デフォルトのコミットは30秒です。120を使用しました。
現在、SSDの使用方法に依存しています。ルートとしては、通常、かなり一定した低レベルの書き込みストリームが進行しています。ログファイル、ntpドリフトファイル、man dbの再構築、opensmトポロジの更新など。各イベントは、別の4000〜5000の書き込みでbtrfsドライブを破壊します。
上記の10日間の数値は、私の「書き込み制限」SSDのものです。これらの17,800セクターの大部分は、小規模なシステムアップデートの結果です。1つのbtrfsコピーは影響を受けませんでした。私のライターは、正確には、ntp drift、opensmトポロジ、およびman dbの更新（夜間）です。システムのアップグレードvim /etc/whateverなどの積極的に開始されたものを除き、そのディスクにヒットするものはありません。
本当に、SSD全体で多くの書き込みが発生します。ニュースメディアがバニーや虹を追いかけているからです。COWにこの価格を支払いたい場合は、それを選択してください。「パフォーマンス」についてはそれほどではありません。それはSSDであり、おそらく人に知られている最悪の「ファイルシステム」を搭載しても、ある程度のパフォーマンスを得ることができます-総当たりで。Ext4は、人に知られている最悪のファイルシステムではありません。
毎月のfsチェックはありません。以下のスクリプトを試してください。100％ハックであり、mdマウントポイントでは機能しません。
#! /bin/bash
dev=`cat /proc/mounts | grep " $1 " | awk '{print $1}'`
x=`basename $dev`
vmnam=`lsblk $dev -o MOUNTPOINT,PKNAME | grep "$1" | awk '{print $2}'`
vmx=`vmstat -d | grep $vmnam | awk '{print $8}'`
lbax=`smartctl -a $dev | grep LBA | awk '{print $10}'`
tmpnam=`mktemp XXX`
echo "Tracking device: $dev, mounted on $1 (vmstat on $vmnam)"
tim=`date +%s`
timx=`date +%s`
while true
do
vm=`vmstat -d | grep "$vmnam" | awk '{print $8}'`
lba=`smartctl -a $dev | grep LBA | awk '{print $10}'`
if [ "$vm" != "$vmx" ]
then
tim=`date +%s`
dif=`dc <<< "$vm $vmx - p"`
lbad=`dc <<< "$lba $lbax - p"`
timd=`dc <<< "$tim $timx - p"`
echo `date` " (sec=$timd) writes=$vm (dif=$dif) (lba=$lbad)"
vmx="$vm"
lbax="$lba"
timx="$tim"
find "$1" -mount -newer "$tmpnam" -print | grep -v "/tmp"
touch "$tmpnam"
fi
sleep 1
doneドライブ自体に応じて書き込まれたブロック数、および正確に更新されたファイルが表示されます。ルート権限が必要です。自分で見て。ルートファイルシステムでSSDを実行し、スクリプトstat.shを呼び出します。そう...sudo ./stat.sh /
前回テストしたとき、まだどこにも聞いたことがないので、ext4 はソリッドステートメディアを食べます。（サムドライブ、ソリッドステートドライブなど）そのようなデバイスで使用することはお勧めしません。代わりにext3を使用してください。SSDのほとんどの場合、違いを区別することはできません。
BTRFSはまだ非常に安定していません。ただし、重要ではないアプリケーションには十分安定しています。ブート可能なフラッシュドライブの作成に使用するものです。マウントオプションとしてcompress = zlibとssdを使用すると、ほとんどのソリッドステートメディアの書き込み速度が遅くなり、ssdが割り当てアルゴリズムをそのようなデバイスで非常に優れたパフォーマンスを発揮するものに変更し、ハードウェアによる不十分なウェアレベリング。まだ問題となっているパフォーマンス領域の1つは、同期呼び出しが遅いことです。これは一般的な使用では問題ありませんが、dpkgは操作のたびに同期を呼び出すため、ソフトウェアのインストールと更新が遅くなる可能性があります。BTRFSは、特定の状況で非常に役立つスナップショットやその他の高度な機能も提供します。
BTRFSを使用する場合は、カーネル3.2.0-2以降を使用したディストリビューションを必ず使用してください。3.1.xは必要に応じて実行可能です。古いカーネルの場合、最新のBTRFSモジュールを自分でコンパイルする必要があります。組み込みのものはほぼ安定していますが、エラー修正は古いバージョンでは機能しないため、何か問題が発生した場合にクリークを残すことができます。最新バージョンには、最も一般的な障害を実際に修復できるfsckがあります。
最後の警告として、BTRFSファイルシステム上のスワップファイルが破損するという報告を聞きました。この問題は修正されている可能性がありますが、実装する前に必ず確認してください。
BTRFSセットアップを希望どおりに構成するためのサポートが必要な場合は、お知らせください。特定の事柄に対してかなりうまく機能するいくつかのクレイジーなものを作成しました。
事例証拠に基づいたソリッドステートドライブでext4を使用することはなく、ext4がファイルシステムに関連付けられた読み取りと書き込みの数のためにSSDの寿命を大幅に短縮できることを示唆する私自身の経験もあります。最近読んだ記事の1つでは、SSD上の最適化されていない（ページサイズなどを考慮した）ext4によってディスクの寿命を半分に短縮できることが示唆されました。1週間のトラブルシューティングの後、私は自分のSSDがこの問題のためにたった8か月しか続かないという結論に達しました。SSDを使用している場合は、フラッシュページサイズなど、ファイルシステムが設定されている一般的なシリンダーサイズとは異なる可能性があることに基づいて、ファイルシステムを最適化する方法をよく読んでください。