btrfsはファイルの最適化も行いますか?


9

を実行するとbtrfs filesystem balance、これは暗黙的にファイルを最適化しますか?既存の断片化を維持しながら、バランスが各ファイルエクステントを個別に再割り当てするだけだと想像できます。

FAQエントリは、ある「『バランス』は何をしますか?」、これはこの点では不明確です:

btrfsファイルシステムバランスは、ファイルシステム上のすべてのデータとメタデータを取得し、ディスク上の別の場所に再書き込みして、途中でアロケータアルゴリズムに渡します。もともとマルチデバイスファイルシステム用に設計され、デバイス間でデータをより均等に分散します(つまり、使用量を「分散」するため)。これは、ほぼ完全なファイルシステムに新しいデバイスを追加するときに特に役立ちます。

バランスが機能する方法により、いくつかの有用な副作用があります。

  • 割り当てられているが使用されていないデータまたはメタデータのチャンクがたくさんある場合、バランスがその割り当てられたスペースの一部を取り戻す可能性があります。これが、単一デバイスのファイルシステムでバランスを実行する主な理由です。
  • レプリケーションが破損しているファイルシステム(たとえば、停止していてディスクが削除されたRAID-1 FS)では、FSは現在アクティブなデバイスの1つで失われたデータのコピーを再構築し、RAID-1の機能を復元します。ファイルシステム。

回答:


9

TL; DR

Btrfsのデフラグ機能は、フォルダーのメタデータとファイルの内容の断片化を修正するために固有ですが、バランス機能は、ドライブが追加または削除されるたびにドライブ間で共有されるデータの量を「バランス」するために作成されました。これらの機能には理論的な重複がありますが、直接関連していないため、ドキュメントでは2つの機能をリンクしていません。

以下の詳細な回答。もちろん、私の長い答えは、直面している問題の完全な状況を知らない人たちを助けることを期待しています。


チャンク割り当て

btrfsの重要な概念は、チャンクの割り当てです。データをbtrfsに書き込むと、そのデータは「現在の」チャンク(通常は1GBのサイズ1)に書き込まれます。「現在の」チャンクがいっぱいになると、新しいチャンクが割り当てられます。既存のチャンクが空になると、新しいチャンクが必要になったときに、そのストレージスペースが再割り当てに使用できるようになります。

ファイルシステムが「dup」、「single」、または「raid1」ストレージプロファイルを持つ複数のドライブを使用している場合、チャンクアロケーターは常に、利用可能な空き容量が最も多いドライブに次の新しいチャンクを配置することを優先します。これにより、通常、ドライブが均等に使用されます。


バランスはどのように機能するか

バランス機能は、既存のデータチャンクを取得して「現在の」チャンクに再書き込みすることで機能します。この方法で既存のチャンクが空になると、アロケーターは自動的にそれを使用できるようになります。空にされている既存のチャンクが最初からいっぱいではなかった場合(おそらくチャンク内の古いデータが削除された場合)、新しいチャンクは関連データで「より緊密にパック」されているため、最終的にディスクスペースが解放されます。

これは、理論的には、最適化戦略の一部として使用できる部分です。私は、多くの人がすでにそうであると想定している理由だと思います。ただし、当然のことながら、バランス機能は特定の目的を念頭に置いて構築されているため、ファイルの内容が表示されませ。それは唯一のデータは、それが既存のチャンクを取り出していることは適切であるかどうかをチェック2新しいチャンクにそのデータをコピーする前に。

バランス部分はどこにありますか?

ファイルシステムに新しいドライブを追加すると、アロケータは最初にすべての新しいデータを新しいドライブに書き込む傾向があります。これは、主に既存のドライブよりも利用可能な空き領域が多いためです。すべてのチャンクを再書き込みすることにより、すべての初期バランスのチャンクは新しいドライブにのみ書き込まれます。均等化されると(バランスがとれる)、残りのデータはドライブ間で均等に再割り当てされます。

典型的なバランスシナリオ:

500GBドライブが2台あり、それぞれに240GBが使用されています。さらに500GBドライブを追加します。私は通常持っています:

  • ドライブa:240GB使用
  • ドライブb:240 GB使用
  • ドライブc:0 GB使用

すべてのデータのバランスを開始します。残りの約4分の1は、次のような状況になると思います。

  • ドライブa:180 GB使用
  • ドライブb:180 GB使用
  • ドライブc:120GB使用

約3分の1のマークで、バランスが取れているように見えます。

  • ドライブa:使用済み160GB
  • ドライブb:160GB使用
  • ドライブc:160GB使用

もちろん、この時点でバランス操作を停止することもできますが、終了させる理由には(良い点と悪い点があります)3


btrfsで断片化が発生するしくみ

BtrfsはCoW(Copy on Write)ファイルシステムです。つまり、データが上書きされることはありません4。既存の100MBファイルがあり、ファイルの1MB部分を上書きした場合、その1MB部分はドライブ上の既存のデータに上書きされません。代わりに、「現在の」チャンクの別の場所に書き込まれます。Btrfsは、新しいデータのこれらの「フラグメント」が格納されている場所を追跡します。これは、古いデータがデフォルトで保持されることを意味するため、データのスナップショットを維持するのに最も役立ちます。SSDも非常によく似た方法でデータを上書きすることはないため、このCoWメカニズムはSSDが寿命とパフォーマンスを維持できるようにするのに適しています。

デフラグが登場する場所

利点に関係なく、一部のファイルは非常に頻繁に上書きされるため(通常はデータベースファイル)、最終的にこれらのフラグメントが何百にもなることがあります。SSDを使用すると、短期的にはパフォーマンスの低下はほとんどありません。しかし、スピンドルドライブでは、パフォーマンスの低下が深刻です。

もちろん、1つの解決策は、btrfsのデフラグ機能を使用することです。デフラグ操作は、現在のチャンクのファイルコンテンツを現在の状態の論理的な順序で再書き込みします。これにより、フラグメントは、多数の個別のピースではなく、1つの大きな100MBデータセットに削減されます。

別の解決策は、特にこのようなファイルに対して「nocow」機能を使用することです。nocow機能により、ファイルが上書きされます。nocow 5 6への警告があることに注意してください。


まとめ

  • バランスはチャンクとストライプを調べます。これらのチャンク内のデータがまだ関連しているかどうかを除いて、実際にはファイルの内容を認識していません。

  • デフラグ操作は、フォルダーデータと個々のファイルの内容を調べ、可能な限り連続した方法でデータを書き換えます。欠点は、デフラグが重複と余分なドライブの使用を引き起こすスナップショットです。


ノート:

  1. チャンクのサイズは通常1GBですが、それより大きくても小さくてもかまいません。RAIDタイプを使用する場合、チャンクは通常、1GBの倍数で複数のドライブにストライプ化されます。たとえば、raid0を備えた5つのドライブは、通常、1GBのチャンクで構成される5GBのストライプを各ドライブに書き込みます。

  2. Btrfsはファイルコンテンツへの「参照」を使用します。ファイルの一部が上書きされると、ライブファイルシステムはそのデータが書き込まれた場所を「参照」します。ただし、スナップショットはまだ古い場所を「参照」している可能性があります。スナップショットがない場合、または古いスナップショットが削除された場合、元の上書きされたコンテンツを参照する「参照」参照は残りません。このコンテンツは無関係と見なされ、バランス操作で他の関連データと共にコピーされません。

  3. この時点で、ストレージは単純な「シングル」プロファイル使用していると仮定すると7を、バランス最初の160ギガバイトのでしょう、すべての新しいドライブに移動すること-も、この時点で、それはまだ320ギガバイトのバランスに委ねについて持っています。残りはドライブ間で均等にバランスが取られます。スピンドルを使用する場合、理想的には、btrfsが3つのドライブすべてを再バランスしてデータをより適切に「分散」する前に、160チャンクのみのバランスを取る必要があります。SSDを使用すると、データの均等な「広がり」を維持しようとすると、非常に複雑になり、おそらく無意味になり、SSDの寿命にとって非常に悪い可能性が高くなります。

  4. 例外は「nocow」機能です。

  5. スナップショットがある場合、「ライブ」ファイルをデフラグすると、スナップショットと「ライブ」ファイルがディスク上の異なるデータの場所を参照するため、データが複製され、余分なディスクスペースが必要になります。汎用の重複除外機能が利用可能になれば、これはそれほど問題にはなりません。

  6. nocowを使用すると、btrfsはファイル内容のチェックサムを維持しません。

  7. ほとんどのRAIDタイプ(RAID 1は例外)では、いずれにしてもストライプは通常すべてのドライブに書き込まれるため、ドライブ全体の「分散」は重要ではありません。


うわー、素晴らしい答え。本などでBTRFSのユーザー関連情報が深刻に不足していることがわかります(ZFSとは異なります)。あなたはブログやこのようなもっと良いものを持っていますか?
Andrew Keech、2018年

1
ありがとう!本当にもっと最新のコンテンツをそこに取り入れるべきです。:-| 時間はひどく欠けています:dogma.swiftspirit.co.za
zaTricky

6

たぶん見て、コマンドのソースコードかもしれないのヘルプ

好む btrfs balance start

「btrfs filesystem balance」コマンドは廃止されました。代わりに「btrfs balance start」コマンドを使用してください。

そして、コマンド文字列で

"btrfs [filesystem] balance start [options] <path>",
"Balance chunks across the devices",
"Balance and/or convert (change allocation profile of) chunks that",
"passed all filters in a comma-separated list of filters for a",
"particular chunk type.  If filter list is not given balance all",
"chunks of that type.  In case none of the -d, -m or -s options is",
"given balance all chunks in a filesystem."

私はそれを再確認するかもしれませんが、構造体やioctl()呼び出しでデフラグへの参照を見ることができません。したがって、明示的なデフラグはありません。

ある場所から別の場所にコピーし、プロセスでデフォルトのアロケータを使用するだけです。ここから撮影

目的の割り当てと割り当てモードに応じて、アルゴリズムは適切な各割り当てグループ(btrfsのグループは上記のチャンクに対応します)で連続した空き領域のエクステントを直接検索します

したがって、割り当てモード、デバイスの空き領域などに応じて、btrfsは最適化が不要になるような方法で割り当てられると言えます。暗黙的なデフラグの形式と考えることができます。

HTH


3

バランスはチャンクレベルで機能します。チャンクは、BtrfsがRAID冗長性を実装する方法です。Btreeレベルでは何もせず、デフラグもしません。


0

アクセス待機時間が長いメディアを使用する場合、使用されるファイルシステムに関係なく、フレーム化は常にカウントされます。シークは、シーク、ピリオドのままです。


3
SSDドライブからデータにアクセスしているのでなければ、何の意味もありません。
Matt

1
それは質問に答えません。
カールリヒター

-2

デフラグは過大評価されています。もちろん、FAT16では実際の違いはありますが、ほとんどの場合、最新のものではありません。効果的には、リバランスによってファイルシステムの構成が改善され、ファイルの断片化が少なくなります。


6
断片化は、ext2 / 3/4、xfs、jfsなどの問題ではありませんが、btrfsでは重大な問題になる可能性があります。btrfs.wiki.kernel.org/index.php/Gotchasを参照してください。「ランダムな書き込みが多いファイルは、非常に断片化され(10000以上のエクステント)、HDDでトラッシングが発生したり、 SSDまたは大量のRAM。」一般的な使用例(bittorrentでダウンロードされたファイル、sqliteデータベースなど)であっても、それは誇張ではありません。
nemequ 14

2
特に従来のHDDでドライブがいっぱいになり始めると、より新しいファイルシステムでもデフラグは大きな違いを生む可能性があります。一部のファイルシステムは他のファイルシステムよりも適切に処理し、一部のタイプのファイルは他のファイルシステムよりもかなり劣っています。スラックスペース、シナリオの最適化が不可能な、読み取り/書き込みキャッシュ、先読み、アプリケーションの最適化などは、多くの場合これを隠す傾向があります。ほとんどの場合、人々はそれを心配する必要はなく、実際に断片化によって引き起こされる可能性のある深刻な問題がある場合にのみ心配する必要があります。
jgmjgm
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.