web-dev-qa-db-ja.com

SSDにbtrfsまたはExt4を使用する必要がありますか？

オフィスマシンのUbuntu 11.10（Oneiric）AMD64デスクトップルートパーティションのSSDにbtrfs（discard、compress = lzoおよびspace_cacheオプション）またはExt4（discardオプション）を使用する必要がありますか？

/ homeはHDDになるため、fsの信頼性はデータではなくOSに影響します。

11.10partitioningext4ssdbtrfs
16
Graham

phoronixによるテストによれば、それは常に多くの要因に依存します。ある場合には、Btrfsは、SSD上の大きなファイルを読み取るときにEXT4よりもはるかに優れています。同様に、ディスクトランザクションのパフォーマンスを考慮しながら、Ext4のパフォーマンスは後者よりも優れています。

これらのテストを見ることができます here 、 here および here （警告：長い記事）。

ただし、合計すると、Btrfsには、SSDモードで使用している場合でも、EXT4ファイルシステムよりも定量的なパフォーマンス上の利点はありません。

したがって、今のところExt4を選択できます。

13
nbkdotdev

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 "追跡デバイス：$ dev、$ 1にマウント（vmstatのvmstat）"

tim = date +%s

timx = date +%s

本当の間に

行う

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

やった

ドライブ自体に応じて書き込まれたブロック数、および正確に更新されたファイルが表示されます。ルート権限が必要です。自分で見て。ルートファイルシステムでSSDを実行し、スクリプトstat.shを呼び出します。だから... "Sudo ./stat.sh /"

6
wkirk

前回テストしたとき、どこでも聞いたことはありません。ext4eats solid-state media。 （サムドライブ、ソリッドステートドライブなど）そのようなデバイスで使用することはお勧めしません。代わりにext3を使用してください。 SSDのほとんどの場合、違いを区別することはできません。

BTRFSはまだ非常に安定していません。ただし、重要ではないアプリケーションに対しては十分に安定しています。ブート可能なフラッシュドライブを作成するために使用するものです。マウントオプションとしてcompress = zlibとssdを使用すると、ほとんどのソリッドステートメディアの書き込み速度の低下を圧縮が補い、ssdは割り当てアルゴリズムをそのようなデバイスで非常に優れたパフォーマンスを発揮するものに変更し、ハードウェアによる不十分なウェアレベリング。まだ問題となっているパフォーマンス領域の1つは、同期呼び出しが遅いことです。これは一般的な使用では問題ありませんが、dpkgは操作のたびに同期を呼び出すため、ソフトウェアのインストールと更新が遅くなる可能性があります。 BTRFSは、特定の状況で非常に役立つスナップショットやその他の高度な機能も提供します。

BTRFSを使用する場合は、カーネル3.2.0-2以降を使用したディストリビューションを必ず使用してください。 3.1.xは必要に応じて実行可能です。古いカーネルの場合、最新のBTRFSモジュールを自分でコンパイルする必要があります。組み込みのものはほぼ安定していますが、エラー修正は古いバージョンでは機能しないため、何か問題が発生した場合にクリークを残すことができます。最新バージョンには、最も一般的な障害を実際に修復できるfsckがあります。

最後の警告として、BTRFSファイルシステム上のスワップファイルが破損するという報告を聞きました。この問題は修正されている可能性がありますが、実装する前に必ず確認してください。

BTRFSセットアップを希望どおりに構成するためのサポートが必要な場合は、お知らせください。特定の事柄に対してかなりうまく機能するいくつかのクレイジーなものを作成しました。

2
Perkins

事例証拠に基づいたソリッドステートドライブでext4を使用することはなく、ext4がファイルシステムに関連付けられた読み取りと書き込みの数のためにSSDの寿命を大幅に短縮できることを示唆する私自身の経験もあります。最近読んだ記事の1つでは、SSD上の最適化されていない（ページサイズなどを考慮した）ext4によってディスクの寿命を半分に短縮できることが示唆されました。 1週間のトラブルシューティングの後、私は自分のSSDがこの問題のためにたった8か月しか続かないという結論に達しました。 SSDを使用する場合は、フラッシュページサイズなど、ファイルシステムが設定されている一般的なシリンダーサイズとは異なる可能性があることに基づいて、ファイルシステムを最適化する方法をよく読んでください。

2
user75153