Btrfs – 日本語百科事典辞書

Btrfs

BitTorrentファイルシステムBTFS
と混同しないでください
Btrfs（ “better F S”、 “butter F S”、 “b-tree F S”、と発音、または単にそれを綴る）は、ファイルシステムを組み合わせたコンピューターストレージ形式です。一緒に開発された論理ボリュームマネージャー（LinuxのLVMと混同しないでください）を使用したコピーオンライト（COW）の原則に基づいています。これは当初、Linuxで使用するために2007年にOracle Corporationで設計され、2013年11月以降、ファイルシステムのオンディスクフォーマットはLinuxカーネルで安定していると宣言されています。 Oracleによると、Btrfsは「真の頭字語ではありません」。 Btrfs 開発者
Facebook、Fujitsu、Fusion-IO、Intel、Linux Foundation、Netgear、Oracle Corporation、Red Hat、STRATO AG、openSUSE
フルネーム
Bツリーファイルシステム
紹介された
Linuxカーネル2.6.29、2009年3月; 12年前（2009-03）
構造
ディレクトリの内容
Bツリー
ファイルアロケーション
エクステント
制限
最大ボリュームサイズ
16 EiB
最大ファイルサイズ
16 EiB
最大ファイル数
2 64
最大ファイル名の長さ
255個のASCII文字（Unicodeなどのマルチバイト文字エンコードの場合は少ない）
ファイル名に使用できる文字
‘/’およびNUL（’’）を除くすべて
特徴
記録された日付
作成（otime）、変更（mtime）、属性変更（ctime）、およびアクセス（atime）
日付範囲
1970-01-01T00：00：00Zからの64ビットsignedintオフセット
日付の解決ナノ秒属性
POSIXおよび拡張属性
ファイルシステムのアクセス許可 POSIXとACL 透過的な圧縮
はい（zlib、LZO および（4.14以降）ZSTD ）
透過的な暗号化
計画中
データの重複排除
はい
コピーオンライト
はい
他の
サポートされているオペレーティングシステム
Linux、ReactOS
Webサイト
btrfs .wiki .kernel .org
Btrfsは、Linuxファイルシステムでのプーリング、スナップショット、チェックサム、および統合マルチデバイススパニングの欠如に対処することを目的としています。 Btrfsの主執筆者であるChrisMasonは、その目標は「が利用可能なストレージに合わせて拡張できるようにすることでした。スケーリングとは、ストレージのアドレス指定だけでなく、ストレージの管理と管理も可能にすることです。何が使用されているかを人々が確認できるようにし、信頼性を高めるクリーンなインターフェイスを備えています。」

コンテンツ
1 歴史
2 特徴
2.1 実装 2.2 実装されていますが、実稼働での使用は推奨されていません 2.3 計画されているがまだ実装されていない 2.4 クローニング 2.5 サブボリュームとスナップショット 2.62.6 送受信 2.7 クォータグループ 2.8 ext2 / 3/4およびReiserFSからのインプレース変換 2.9 ユニオンマウント/シードデバイス 2.10 暗号化 2.11 チェックとリカバリ
3 設計
3.1 ファイルシステムツリー
3.1.1 エクステント
3.2 エクステント割り当てツリー 3.3 チェックサムツリーとスクラブ 3.43.4 ログツリー 3.5 チャンクツリーとデバイスツリー 3.6 再配置ツリー 3.7 スーパーブロック
4 商用サポート
4.1 サポートされています 4.2 サポートされなくなりました
5 も参照してください
6 ノート
7 参考文献
8 外部リンク

歴史

Btrfsファイルシステムの使用情報のスクリーンショット
Btrfs・コピー・オン・ライトのコアデータ構造Bツリーは、もともとのプレゼンテーションでIBMの研究者オハッドRodehによって提案され-たUSENIX 2007年クリス・メイソン、に取り組んでエンジニアReiserFSのためにSUSE時に、その年の後半にOracleに参加し、これらのBツリーに基づく新しいファイルシステムの作業を開始しました。
2008年、ext3およびext4ファイルシステムの主な開発者であるTheodore Ts’oは、ext4の機能は改善されましたが、大きな進歩ではないと述べました。それは古い技術を使用しており、一時的なギャップです。Ts’oは、「スケーラビリティ、信頼性、および管理の容易さを向上させる」ため、Btrfsの方が優れていると述べました。 Btrfsには、「reiser3 / 4が持っていたのと同じデザインアイデアがいくつかあります」。
完成したオンディスクフォーマットのBtrfs1.0は、もともと2008年後半のリリースが予定されていたが、2009年にLinuxカーネルのメインラインに受け入れられました。いくつかのLinuxディストリビューションは、ルートの実験的な選択肢としてBtrfsの提供を開始しました。インストール中のファイルシステム。
2011年7月、Btrfsの自動デフラグおよびスクラブ機能がLinuxカーネルメインラインのバージョン3.0に統合されました。 OracleのMasonの他に、FujitsuのMiaoXieがパフォーマンスの向上に貢献しました。 2012年6月、Chris MasonはOracleを離れてFusion-ioに向かい、1年後にJosefBacikと共にFacebookに参加しました。両方の会社にいる間、メイソンはBtrfsでの作業を続けました。
2012年に、2つのLinuxディストリビューションがBtrfsを実験的ステータスから本番またはサポートステータスに移行しました。3月にOracle Linux 、8月にSUSE LinuxEnterpriseが続きました。
2015年、はBtrfsをデフォルトのファイルシステムとして採用されたSUSE Linux Enterprise Serverの12
2017年8月、Red Hatは、Red Hat Enterprise Linux（RHEL）7.4のリリースノートで、RHEL6ベータ以降「テクノロジープレビュー」として含まれていたBtrfsを完全にサポートされている機能に移行する予定がなくなったことを発表しました。 RHEL7リリースシリーズでも引き続き利用可能であることに注意して Btrfsは2019年5月にRHEL8から削除されました。
2020年に、デスクトップバリアント用のFedora33のデフォルトファイルシステムとしてBtrfsが選択されました。

特徴
実装

Linuxカーネルのバージョン5.0以降、Btrfsは次の機能を実装しています。
コピーオンライトの性質により、一部の構成では主に自己回復します
オンラインデフラグと自動デフラグマウントオプション
オンラインボリュームの増加と縮小
オンラインブロックデバイスの追加と削除
オンラインバランシング（負荷を分散するためのブロックデバイス間のオブジェクトの移動）
オフラインファイルシステムチェック
エラーを見つけて冗長コピーのあるファイルを自動的に修正するためのオンラインデータスクラビング
RAID 0、RAID 1、およびRAID 10
サブボリューム（各ディスクパーティション内の1つ以上の個別にマウント可能なファイルシステムルート）
zlib、LZO および（4.14以降）ZSTDを介した透過的な圧縮、ファイルまたはボリュームごとに構成可能
アトミック書き込み可能（コピーオンライト経由）または読み取り専用サブボリュームのスナップショット
を介したファイルのクローン作成（reflink、コピーオンライト）cp –reflink
データとメタデータのチェックサム（CRC-32C ）。5.5以降、新しいハッシュ関数が実装されています： xxHash、SHA256、BLAKE2B。
ext3 / 4からBtrfsへのインプレース変換（ロールバックあり）。この機能は、4.6でゼロから書き直されたbtrfs-progsバージョン4.0を中心に後退しました。
ファイルシステムシード（書き込み可能なBtrfsのコピーオンライトバッキングとして使用される読み取り専用ストレージ）として知られる読み取り専用ストレージのユニオンマウント
ブロック破棄（一部の仮想化セットアップでスペースを再利用し、TRIMを使用してSSDのウェアレベリングを改善します）
送信/受信（スナップショット間の差分をバイナリストリームに保存）
増分バックアップ
帯域外データ重複排除（ユーザースペースツールが必要）
スワップファイルとスワップパーティションを処理する機能

実装されていますが、実稼働での使用は推奨されていません
サブボリュームごとの階層クォータ
RAID 5、RAID 6

計画されているがまだ実装されていない
帯域内データ重複排除
オンラインファイルシステムチェック
RAID5およびRAID6の信頼性を超える最大6つのパリティデバイスを備えたRAID
オブジェクトレベルのRAID0、RAID 1、およびRAID 10
暗号化
永続的な読み取りおよび書き込みキャッシュ（L2ARC + ZIL、lvmcacheなど）
2009年には、はBtrfsはと同等の機能セットを提供することが期待されたZFSによって開発された、サン・マイクロシステムズを。 2009年にOracleがSunを買収した後、MasonとOracleはBtrfsの開発を継続することを決定しました。

クローニング
Btrfsは、ファイルのコピーオンライトスナップショットをアトミックに作成するクローン操作を提供します。このようなクローンファイルは、提案されている関連するLinuxカーネルシステムコールに照らして、reflinksと呼ばれることも
クローンを作成することにより、ファイルシステムは既存のiノードを指す新しいリンクを作成しません。代わりに、元のファイルと同じディスクブロックを最初に共有する新しいiノードを作成します。その結果、クローン作成は同じBtrfsファイルシステムの境界内でのみ機能しますが、Linuxカーネルのバージョン3.6以降、特定の状況下ではサブボリュームの境界を越える可能性が実際のデータブロックは複製されません。同時に、Btrfsのコピーオンライト（CoW）の性質により、複製されたファイルへの変更は元のファイルには表示されません。その逆も同様です。
クローン作成は、複数のファイル名をファイルシステム上の実際のファイルに関連付けるディレクトリエントリであるハードリンクと混同しないでハードリンクは同じファイルの異なる名前と見なすことができますが、Btrfsでのクローン作成は、最初はすべてのディスクブロックを共有する独立したファイルを提供します。
このBtrfs機能のサポートは、コマンドのオプションを介して、GNUcoreutilsのバージョン7.5で追加されました。 –reflinkcp
データのクローン作成（FICLONE）に加えて、BtrfsはFIDEDUPERANGEを介した帯域外重複排除もサポートしてい
ます。この機能により、（部分的にでも）同一のデータを持つ2つのファイルでストレージを共有できます。

サブボリュームとスナップショット

snapperで管理されるBtrfsファイルシステムのスナップショットの例
Btrfsサブボリュームは、ユーティリティにまたはオプションを渡すことで個別にマウント可能な、個別のPOSIXファイル名前空間と考えることができます。トップレベルのサブボリュームをマウントしてアクセスすることもできます。この場合、サブボリュームはサブディレクトリとして表示され、アクセスできます。subvolsubvolidmount(8)
サブボリュームは、ファイルシステム階層内の任意の場所に作成でき、ネストすることもできます。ネストされたサブボリュームは、最上位のサブボリュームがそのサブボリュームをサブディレクトリとして表示するのと同じように、親サブボリューム内のサブディレクトリとして表示されます。サブボリュームを削除するには、ネスト階層内でその下にあるすべてのサブボリュームが削除されます。その結果、最上位のサブボリュームは削除できません。
すべてのBtrfsファイルシステムには常にデフォルトのサブボリュームがこれは最初は最上位のサブボリュームに設定されており、サブボリューム選択オプションがに渡されない場合はデフォルトでマウントされますmount。デフォルトのサブボリュームは、必要に応じて変更できます。
Btrfsスナップショットは、Btrfsのコピーオンライト機能を使用して、そのデータ（およびメタデータ）を他のサブボリュームと共有するサブボリュームであり、スナップショットへの変更は元のサブボリュームには表示されません。書き込み可能なスナップショットが作成されると、元のファイルシステムの代替バージョンとして扱うことができます。たとえば、スナップショットにロールバックするには、変更された元のサブボリュームをアンマウントし、その場所にスナップショットをマウントする必要がその時点で、元のサブボリュームも削除される可能性が
Btrfsのコピーオンライト（CoW）の性質は、スナップショットが迅速に作成されることを意味しますが、最初はほとんどディスクスペースを消費しません。スナップショットはサブボリュームであるため、ネストされたスナップショットを作成することもできます。サブボリュームのスナップショットを作成することは、再帰的なプロセスではありません。したがって、サブボリュームのスナップショットが作成されると、サブボリュームにすでに含まれているすべてのサブボリュームまたはスナップショットが、スナップショット内の同じ名前の空のディレクトリにマップされます。
サブボリュームのみがスナップショットを持つことができるため、ディレクトリのスナップショットを作成することはできません。ただし、サブボリューム全体に広がるreflinkを含む回避策がターゲットディレクトリのコンテンツへのクロスサブボリュームreflinkを含む新しいサブボリュームが作成されます。これが利用可能になると、この新しいボリュームのスナップショットを作成できます。
Btrfsのサブボリュームは、従来の論理ボリュームマネージャー（LVM）論理ボリュームとはかなり異なります。LVMでは、論理ボリュームは独立したブロックデバイスですが、Btrfsサブボリュームはそうではなく、そのように処理または使用することはできません。 btrfsのddまたはLVMスナップショットを作成すると、元のスナップショットまたはコピーのいずれかが同じコンピューター上にあるときにマウントされた場合、データが失われます。

送受信
サブボリューム（またはスナップショット）の任意のペアが与えられると、Btrfsはそれらの間にバイナリ差分を生成でき（btrfs sendコマンドを使用してbtrfs receive）、後で（を使用して）再生できます（おそらく別のBtrfsファイルシステムで）。送受信機能は、あるサブボリュームを別のサブボリュームに変換するために必要な一連のデータ変更を効果的に作成（および適用）します。
送信/受信機能は、定期的にスケジュールされたスナップショットとともに使用して、単純な形式のファイルシステムレプリケーションを実装したり、増分バックアップを実行したりできます。

クォータグループ

Btrfsクォータグループの例
クォータのグループは（又はqgroup）サブボリュームまたはスナップショットが消費できる空間に上限を課します。新しいスナップショットは、そのデータが親と共有されているため、最初はクォータを消費しませんが、その後、新しいファイルと既存のファイルのコピーオンライト操作の料金が発生します。クォータがアクティブな場合、クォータグループは新しいサブボリュームまたはスナップショットごとに自動的に作成されます。これらの初期クォータグループは、（btrfs qgroupコマンドを使用して）階層にグループ化してクォータプールを実装できるビルディングブロックです。
クォータグループはサブボリュームとスナップショットにのみ適用されますが、個々のサブディレクトリ、ユーザー、またはユーザーグループにクォータを適用することはできません。ただし、クォータを適用する必要があるすべてのユーザーまたはユーザーグループに異なるサブボリュームを使用することで、回避策が可能です。

ext2 / 3/4およびReiserFSからのインプレース変換
固定された場所に固定されたメタデータがほとんどないため、Btrfsは、バックエンドストレージデバイスの異常な空間レイアウトに合わせてワープする可能性がこのbtrfs-convertツールは、この機能を利用して、元のファイルシステムの変更されていないコピーを保持しながら、割り当てられていないスペースに同等のBtrfsメタデータをネストすることにより、ext2 / 3/4またはReiserFSファイルシステムのインプレース変換を実行します。
変換には、ext2 / 3/4メタデータ全体のコピーの作成が含まれますが、Btrfsファイルは、ext2 / 3/4ファイルで使用されるのと同じブロックを指すだけです。これにより、変換が永続的になる前に、2つのファイルシステム間で共有されるブロックの大部分が作成されます。Btrfsのコピーオンライトの性質のおかげで、ファイルデータブロックの元のバージョンは、すべてのファイル変更中に保持されます。変換が永続的になるまで、ext2 / 3/4で空きとしてマークされたブロックのみが、新しいBtrfsの変更を保持するために使用されます。つまり、変換はいつでも元に戻すことができます（ただし、そうすると、変換後に行われた変更はすべて消去されます） Btrfsへ）。
変換されたすべてのファイルは、Btrfsのデフォルトのサブボリュームで使用可能で書き込み可能です。元のext2 / 3/4ファイルシステムへのすべての参照を保持するスパースファイルは、別のサブボリュームに作成されます。このサブボリュームは、読み取り専用のディスクイメージとして単独でマウントできるため、元のファイルシステムと変換されたファイルシステムの両方にアクセスできます。同時。このスパースファイルを削除すると、スペースが解放され、変換が永続的になります。
メインラインのLinuxカーネルの4.xバージョンでは、インプレースext3 / 4変換はテストされていないと見なされ、ほとんど使用されませんでした。ただし、この機能は2016年にbtrfs-progs4.6用に最初から書き直されました。そしてそれ以来安定していると考えられてきました。
ReiserFSからのインプレース変換は、カーネル4.13で2017年9月に導入されました。

ユニオンマウント/シードデバイス
新しいBtrfsを作成する場合、既存のBtrfsを読み取り専用の「シード」ファイルシステムとして使用できます。新しいファイルシステムは、ユニオンマウントの形式として、シード上のコピーオンライトオーバーレイとして機能します。シードは後でBtrfsからデタッチできます。その時点で、リバランサーはデタッチする前に、新しいファイルシステムによってまだ参照されているシードデータをコピーするだけです。Masonは、これがLive CDインストーラーに役立つ可能性があることを示唆しています。LiveCDインストーラーは、光ディスクの読み取り専用Btrfsシードから起動し、ユーザーが作業を続けている間に、バックグラウンドでインストールディスクのターゲットパーティションにバランスを取り直してから、取り出します。再起動せずにインストールを完了するためのディスク。

暗号化
Chris Masonは、2009年のインタビューで、Btrfsの暗号化のサポートが計画されていると述べました。当面の間、暗号化とBtrfsを組み合わせるための回避策は、基盤となるデバイスでdm-crypt / LUKSなどのフルディスク暗号化メカニズムを使用し、そのレイヤーの上にBtrfsファイルシステムを作成することです。
2020年の時点で、開発者はHMAC（SHA256）のようなキー付きハッシュの追加に取り組んでいました。

チェックとリカバリ
このセクションの
事実上の正確性は、
Unixシステムは、伝統的に「fsck」プログラムに依存してファイルシステムをチェックおよび修復します。この機能は、btrfs checkプログラムを介して実装されます。バージョン4.0以降、この機能は比較的安定していると見なされます。ただし、2017年8月の時点で、btrfsのドキュメントでは、他の回復方法を試した後にのみ使用することが推奨されています。
btrfs-restore壊れたファイルシステム自体を変更せずに（つまり、非破壊的に）、マウントできないファイルシステムからファイルを回復するために使用できる、という名前の別のツールが
通常の使用では、Btrfsはほとんど自己回復型であり、デフォルトで30秒ごとに永続ストレージに定期的にデータをフラッシュするため、マウント時に壊れたルートツリーから回復できます。したがって、分離されたエラーにより、次のマウントで最大30秒のファイルシステム変更が失われます。この期間は、commitマウントオプションに必要な値（秒単位）を指定することで変更できます。

設計
USENIX2007でのOhadRodehの最初の提案では、データベースのディスク上のデータ構造として広く使用されているB +ツリーは、リーフノードが相互にリンクされているため、コピーオンライトベースのスナップショットを効率的に許可できないと述べています。 -書面では、ツリー全体がコピーされるまで、その兄弟と親、およびその兄弟と親なども同様である必要が彼は代わりに修正提案Bツリーをして、（何の葉のリンケージを持たない）参照カウント各ツリーノードに関連付けられているが、それらは、コピー・オン・ライトフレンドリーにするために、ツリーの分散アルゴリズムにアドホック無料のマップ構造と一定の緩和に保存されています。その結果、良好な同時実行性を維持しながら、コピーオンライトスナップショットを実行できる高性能オブジェクトストアに適したデータ構造が得られます。
その年の後半にオラクルで、Chris Masonは、メタデータとファイルデータだけでなく、ツリー自体のスペース割り当てを追跡するために、このデータ構造をほぼ排他的に使用するスナップショット対応のファイルシステムの作業を開始しました。これにより、すべてのトラバーサルと変更を単一のコードパスに集中させることができ、ファイルシステム全体にメリットをもたらすために、コピーオンライト、チェックサム、ミラーリングなどの機能を1回だけ実装する必要がありました。
Btrfsは、そのようなツリーの複数のレイヤーとして構造化されており、すべて同じBツリー実装を使用しています。ツリーには、136ビットのキーでソートされた一般的なアイテムが格納されます。キーの最上位64ビットは一意のオブジェクトIDです。真ん中の8ビットはアイテムタイプフィールドです。その使用は、ツリールックアップのアイテムフィルターとしてコードに組み込まれています。オブジェクトは、複数のタイプの複数のアイテムを持つことができます。残りの（最下位）64ビットは、タイプ固有の方法で使用されます。したがって、同じオブジェクトのアイテムは、タイプごとにグループ化されて、ツリー内で互いに隣接することになります。特定のキー値を選択することにより、オブジェクトは同じタイプのアイテムを特定の順序でさらに配置できます。
内部ツリーノードは、キーとポインタのペアの単純なフラットリストです。ここで、ポインタは子ノードの論理ブロック番号です。リーフノードには、ノードの前にパックされたアイテムキーと最後にパックされたアイテムデータが含まれ、リーフがいっぱいになると2つは互いに向かって大きくなります。

ファイルシステムツリー
各ディレクトリ内で、ディレクトリエントリはディレクトリアイテムとして表示されます。キー値の最下位ビットは、ファイル名のCRC32Cハッシュです。それらのデータは、ロケーションキー、またはそれが指すiノードアイテムのキーです。したがって、ディレクトリアイテムは一緒になって、iノードへのパスルックアップのインデックスとして機能できますが、ハッシュでソートされ、事実上ランダムに並べ替えられるため、反復には使用されません。つまり、ユーザーアプリケーションが大きなディレクトリでファイルを繰り返し開いて開くと、隣接していないファイル間でさらに多くのディスクシークが生成されます。これは、ReiserFS、 ext3（Htreeを使用）などのハッシュ順序のディレクトリを持つ他のファイルシステムでの顕著なパフォーマンスの低下です。-インデックスが有効になっている）およびext4。これらはすべてTEAでハッシュされたファイル名を持っています。これを回避するために、各ディレクトリエントリにはディレクトリインデックスアイテムがあり、そのアイテムのキー値は、新しいディレクトリエントリごとに増分するディレクトリごとのカウンタに設定されます。したがって、これらのインデックスアイテムを反復処理すると、ディスクに保存されているのとほぼ同じ順序でエントリが返されます。
複数のディレクトリにハードリンクがあるファイルには、親ディレクトリごとに1つずつ、複数の参照項目が同じディレクトリに複数のハードリンクがあるファイルは、すべてのリンクのファイル名を同じ参照項目にパックします。これは、同じディレクトリのハードリンクの数を1つのツリーブロックに収まる数に制限する設計上の欠陥でした。（デフォルトのブロックサイズが4 KiB、平均ファイル名長が8バイト、ファイル名ごとのヘッダーが4バイトの場合、これは350未満になります。）複数の同じディレクトリのハードリンクを多用するアプリケーション。git、GNUS、GMame、およびBackupPCは、この制限で失敗することが観察されました。制限は最終的に削除され（そして、2012年10月の時点でLinux 3.7でのリリースが保留されているマージされました）、他の方法では適合しないハードリンクファイル名を保持するスピルオーバー拡張参照アイテムが導入されました。

エクステント
ファイルデータは、ディスクデータブロックの連続した実行であるエクステントでツリーの外部に保持されます。エクステントブロックのサイズはデフォルトで4KiBで、ヘッダーはなく、（おそらく圧縮された）ファイルデータのみが含まれます。圧縮されたエクステントでは、個々のブロックは個別に圧縮されません。むしろ、圧縮ストリームは範囲全体に及びます。
ファイルには、その内容を保持するエクステントを追跡するためのエクステントデータ項目がアイテムのキー値は、エクステントの開始バイトオフセットです。これにより、特定のファイルオフセットの正しいエクステントを1回のツリールックアップで計算できるため、多くのエクステントを持つ大きなファイルで効率的なシークが可能になります。
スナップショットと複製ファイルはエクステントを共有します。そのような大きなエクステントの小さな部分が上書きされると、結果のコピーオンライトによって3つの新しいエクステントが作成される可能性が上書きされたデータを含む小さなエクステントと、上書きの両側に変更されていないデータを持つ2つの大きなエクステントです。変更されていないデータを再書き込みする必要をなくすために、コピーオンライトは代わりにブックエンドエクステント、または既存のエクステントの単なるスライスであるエクステントを作成する場合がエクステントデータアイテムは、追跡しているエクステントにオフセットを含めることでこれを可能にします。ブックエンドのアイテムは、オフセットがゼロ以外のアイテムです。

エクステント割り当てツリー
エクステント割り当てツリーは、ファイルシステムの割当マップとして作用します。他のツリーとは異なり、このツリーのアイテムにはオブジェクトIDがありません。それらは空間の領域を表します。それらのキー値は、それらが表す領域の開始オフセットと長さを保持します。
ファイルシステムは、割り当てられたスペースをブロックグループに分割します。ブロックグループは、メタデータエクステント（ツリーノード）とデータエクステント（ファイルの内容）の優先を交互に繰り返す可変サイズの割り当て領域です。データとメタデータブロックグループのデフォルトの比率は1：2です。これらは、Orlovブロックアロケーターの概念を使用して、関連ファイルを一緒に割り当て、グループ間に空き領域を残すことで断片化に抵抗することを目的としています。（ただし、Ext3ブロックグループにはファイルシステムのサイズから計算された固定の場所がありますが、Btrfsのブロックグループは動的であり、必要に応じて作成されます。）各ブロックグループはブロックグループアイテムに関連付けられます。ファイルシステムツリーのiノードアイテムには、現在のブロックグループへの参照が含まれています。
エクステントアイテムには、そのエクステントを占めるツリーノードまたはファイルへの後方参照が含まれます。エクステントがスナップショット間で共有されている場合、複数の後方参照が存在する可能性がアイテムに収まらない後方参照が多すぎる場合、それらは個々のエクステントデータ参照アイテムに流出します。次に、ツリーノードには、それらを含むツリーへの後方参照がこれにより、その領域を囲むオフセットのペアでBツリー範囲ルックアップを実行し、後方参照に従うことで、どのエクステントまたはツリーノードが空間の任意の領域にあるかを見つけることができます。データを再配置する場合、これにより、ファイルシステム全体をスキャンしなくても、再配置されたブロックから上向きに効率的にトラバースして、それらのブロックへのすべての下向きの参照をすばやく見つけて修正できます。これにより、ファイルシステムはストレージをオンラインで効率的に縮小、移行、および最適化できます。
エクステント割り当てツリーは、ファイルシステム内の他のすべてのツリーと同様に、コピーオンライトです。したがって、ファイルシステムへの書き込みによりカスケードが発生し、ツリーノードとファイルデータが変更されると、新しいエクステントが割り当てられ、エクステントツリー自体が変更される可能性がフィードバックループの作成を回避するために、まだメモリ内にあるがまだディスクにコミットされていないエクステントツリーノードは、新しいコピーオンライトエクステントを反映するようにインプレースで更新される場合が
理論的には、エクステント割り当てツリーは、BSPツリーのBツリーバージョンとして機能するため、従来の空き領域ビットマップは不要になります。しかし、実際には、メモリ内には、赤黒木のページ割り当てをスピードアップするために使用されるビットマップを-sized。これらのビットマップは、チェックサムとコピーオンライトが免除される特別なエクステントとしてディスクに永続化されます（Linux 2.6.37以降、space_cacheマウントオプションを介して）。

チェックサムツリーとスクラブ
参照：
サイレントデータの破損
CRC-32Cのチェックサムは、データおよびメタデータの両方のために計算され、として保存されたチェックサム項目にチェックサム木。256ビットのメタデータチェックサム用のスペースと、最大でフルノード（約4 KB以上）のデータチェックサム用のスペースがBtrfsには、ファイルシステムの将来のバージョンで追加される追加のチェックサムアルゴリズムのプロビジョニングが
割り当てられたブロックの連続実行ごとに1つのチェックサムアイテムがあり、ブロックごとのチェックサムがアイテムデータにエンドツーエンドでパックされます。収まるよりも多くのチェックサムがある場合、それらは新しいリーフの別のチェックサムアイテムにこぼれます。ファイルシステムがブロックの読み取り中にチェックサムの不一致を検出すると、内部ミラーリングまたはRAID技術が使用されている場合、最初に別のデバイスからこのブロックの適切なコピーを取得（または作成）しようとします。
Btrfsは、バックグラウンドで実行されるファイルシステムスクラブジョブをトリガーすることにより、ファイルシステム全体のオンラインチェックを開始できます。スクラブジョブは、ファイルシステム全体をスキャンして整合性を確認し、途中で見つかった不良ブロックを自動的に報告して修復しようとします。

ログツリー
fsyncを要求コミットはすぐに安定したストレージにデータを修正しました。fsyncの多いワークロード（OS fsyncを頻繁に実行するデータベースや仮想マシンなど）は、ファイルシステムにコピーオンライトを繰り返し実行させ、ツリーの頻繁に変更される部分をフラッシュすることにより、大量の冗長書き込みI / Oを生成する可能性がストレージ。これを回避するために、サブボリュームごとの一時的なログツリーが作成され、fsyncによってトリガーされるコピーオンライトがジャーナルされます。ログツリーは自己完結型であり、独自の範囲を追跡し、独自のチェックサム項目を保持します。それらのアイテムは、次のフルツリーコミット時、または（システムクラッシュが発生した場合）次の再マウント時に再生および削除されます。

チャンクツリーとデバイスツリー
ブロックデバイスは、データ用に1 GiB、メタデータ用に256MiBの物理チャンクに分割されます。複数のデバイスにまたがる物理チャンクは、単一の論理チャンクにミラーリングまたはストライピングすることができます。これらの論理チャンクは、ファイルシステムの残りの部分が使用する単一の論理アドレス空間に結合されます。
チャンクツリーのように、その中に各デバイスを格納することによって、これを追跡するデバイス項目と、論理チャンクのチャンクマップアイテムそのキーの最下位64ビットでそのオフセットを格納することにより物理アドレスに論理から前方へのマッピングを提供します。チャンクマップアイテムは、いくつかの異なるタイプのいずれかになります。
独身
1つの論理チャンクから1つの物理チャンク dup 1つのブロックデバイスで1つの論理チャンクから2つの物理チャンク raid0 N≥2ブロックデバイス全体でN論理チャンクからN≥2物理チャンク RAID1 N個の物理チャンクを持つ
従来のRAID1とは対照的に
、N≥2ブロックデバイスのうち2つで1つの論理チャンクから2つの物理チャンク raid1c3 N≥3ブロックデバイスからの1つの論理チャンクから3つの物理チャンク raid1c4 N≥4ブロックデバイスからの1つの論理チャンクから4つの物理チャンク raid5 N（N≥2の場合）論理チャンクからN +1ブロックデバイス全体のN + 1物理チャンク、1つの物理チャンクがパリティとして使用 raid6 N（N≥2の場合）論理チャンクからN +2ブロックデバイス全体のN + 2物理チャンク、2つの物理チャンクがパリティとして使用
Nは、チャンクが割り当てられたときにまだ空き領域があるブロックデバイスの数です。Nが選択したミラーリング/マッピングに対して十分に大きくない場合、ファイルシステムは事実上スペースが不足しています。

再配置ツリー
デフラグ、縮小、およびリバランス操作では、エクステントを再配置する必要がただし、再配置エクステントの単純なコピーオンライトを実行すると、スナップショット間の共有が中断され、ディスク領域が消費されます。共有を維持するために、更新と交換のアルゴリズムが使用され、影響を受けるメタデータのスクラッチスペースとして機能する特別な再配置ツリーが使用されます。再配置されるエクステントは、最初に宛先にコピーされます。次に、影響を受けるサブボリュームのファイルシステムツリーを上向きに後方参照することにより、古いエクステントを指すメタデータが徐々に更新され、新しいエクステントを指すようになります。新しく更新されたアイテムは、再配置ツリーに保存されます。更新が完了すると、再配置ツリー内のアイテムは、影響を受けるサブボリューム内の対応するアイテムと交換され、再配置ツリーは破棄されます。

スーパーブロック
チャンクツリー自体を含むすべてのファイルシステムのツリーはチャンクに格納されるため、ファイルシステムをマウントするときにブートストラップの問題が発生する可能性がブートストラップマウントに、チャンクと根の木に属するチャンクの物理アドレスのリストはに保存されているスーパーブロック。
スーパーブロックミラーは固定された場所に保持されます：すべてのブロックデバイスに64 KiB、64 MiB、256 GiB、および1PiBに追加のコピーがスーパーブロックミラーが更新されると、その世代番号が増加します。マウント時には、世代番号が最も大きいコピーが使用されます。すべてのスーパーブロックミラーは、ミラー間で更新を交互に行ってウェアレベリングを提供するSSDモードを除いて、タンデムで更新されます。

商用サポート

サポートされています
バージョン33からのFedoraワークステーション
オラクルのLinuxバージョン7から
SUSE Linux EnterpriseServerバージョン12から
Synology DiskStation Manager（DSM）バージョン6.0から
バージョン0.4.10からのReactOS

サポートされなくなりました
Btrfsは、Red Hat Enterprise Linux6および7の「テクノロジープレビュー」として含まれていました。、それが中で除去したRHEL 8 2018に

も参照してください
APFS – macOS、iPadOS、iOS、tvOS、watchOS用のコピーオンライトファイルシステム Bcachefs ファイルシステムの比較
HAMMER –データ破損の対策としてチェックサムと組み合わせてBツリーを使用するDragonFlyBSDのファイルシステム
ファイルシステムのリスト
ReFS – Windows Server2012用のコピーオンライトファイルシステム
ZFS

ノート
^ これは、Btrfs独自のディスク上のサイズ制限です。Linuxカーネルの内部制限により、カーネルの構成オプション（2.6.xカーネルシリーズ以降で使用可能）でこれらのカーネル制限を削除できない限り、制限は64ビットシステムでは8 EiB、32ビットシステムでは2EiBに削減されます。 CONFIG_LBD ^ はBtrfs内のすべての項目は、1つのファイルシステムが2ではBtrfsに持つことができ、ほとんどのファイルを意味し、64ビットの識別子で、持っている64。

参考文献
^ 「kernel.orgのBtrfsコントリビューター」。kernel.org。
^ 「Suseドキュメント：ストレージ管理ガイド–Linuxでのラージファイルサポート」。SUSE 。
^ メイソン、クリス。「Btrfsデザイン」。Btrfswiki 。
^ Jonathan Corbet「ファイル作成時間」。LWN.net 。
^ 「オンディスクフォーマット-btrfsWiki」。btrfs.wiki.kernel.org。
^ “”btrfsWiki””。kernel.org 。
^ “”Linux_4.14-Linuxカーネル初心者””。kernelnewbies.org。
^ マクファーソン、アマンダ「BTRfsでのChrisMasonとの会話：Linux用の次世代ファイルシステム」。LinuxFoundation。
^ “”重複排除””。kernel.org 。
^ 「ReactOS0.4.1がリリースされました」。reactos.org 。
^ 「アーカイブされたコピー」。イベントは1分15秒に発生します。取り出される6年2月2016。
^ ヘンソン、ヴァレリーChunkfs：ファイルシステムの高速チェックと修復。メルボルン、オーストラリア。イベントは18分49秒に発生します。それはButterFSまたはB-treeFSと呼ばれますが、すべてのクールな子供たちはButterFSと言います
^ 「Linuxカーネルはfs / btrfs / Kconfigの安定性ステータスの変更をコミットします」。
^ 「22.2Btrfsファイルシステムについて」。Docs.Oracle.com。Oracle。2018年。
^ Kerner、Sean Michael「Linux用のより良いファイルシステム？」。InternetNews.com。
^ Rodeh、Ohad（2007）。Bツリー、シャドウイング、およびクローン（PDF）。USENIXLinuxストレージおよびファイルシステムワークショップ。
また、
Rodeh、Ohad（2008）。「Bツリー、シャドウイング、およびクローン」。ストレージでのACMトランザクション。3（4）：1–27。土井：10.1145 /1326542.1326544。
^ “”LeadBtrfsファイルシステム開発者がFacebookに参加””。phoronix.com 。
^ ポール、ライアン「パネリストはLinuxコラボレーションサミットでカーネルについて熟考します」。ArsTechnica。
^ Ts’o、セオドア””Re：2.6.27-rc1″”のreiser4。linux-kernel（メーリングリスト）。
^ 「開発タイムライン」。Btrfswiki。
^ Wuelfing、Britta「カーネル2.6.29：CorbetはBtrfs次世代ファイルシステムと言っています」。LinuxMagazine。
^ “”Red Hat Enterprise Linux 6ドキュメント：テクノロジープレビュー””。
^ 「Fedoraウィークリーニュース第276号」。
^ 「Debian6.0「Squeeze」がリリースされました」（プレスリリース）。Debian。取り出される8年2月2011。ext4およびBtrfsファイルシステムのサポートも追加されました…
^ 「Linuxカーネル3.0、セクション1.1。Btrfs：自動デフラグ、スクラブ、パフォーマンスの向上」。kernelnewbies.org。
^ Leemhuis、Thorsten「カーネルログ：3.0で登場（パート2）-ファイルシステム」。Hオープン。
^ バルゲーゼ、サム。「iTWire」。ITWire.com 。
^ 「UnbreakableEnterpriseKernelリリース2がリリースされました」。
^ 「SLES11SP2リリースノート」。
^ 「SUSELinuxEnterprise Server12リリースノート」。
^ “”Red Hat Enterprise Linux 7.4リリースノート、第53章：非推奨の機能””。
^ “”RHEL8の採用に関する考慮事項””。Red Hat Enterprise Linux8の製品ドキュメント。RedHat 。
^ 「Fedora33に来るBtrfs」。Fedoraマガジン。
^ “”Btrfs Wiki：機能””。btrfs.wiki.kernel.org。
^ 「BtrfsWiki：変更ログ」。btrfs.wiki.kernel.org。
^ 「マンページbtrfs-check」。
^ 「複数のデバイスでのBtrfsの使用」。kernel.org。
^ 「圧縮」。kernel.org。
^ 「Btrfs：iノードプロパティのサポートを追加」。kernel.org。
^ 「btrfs：読み取り専用スナップショット」。
^ 「BtrfsとOCFS2でファイルのクローンを作成することにより、Linuxのディスクスペースを節約します」。
^ 「WikiFAQ：Btrfsはどのチェックサム関数を使用しますか？」。Btrfswiki 。
^ 「5.5のBtrfsハイライト：新しいハッシュ」。
^ “”Btrfsプログラムリリース4.6″” 。
^ メイソン、クリス「Btrfschangelog」。
^ Corbet、Jonathan（2012年7月11日）、Btrfs送信/受信、LWN.net 、
^ 「BtrfsWiki：増分バックアップ」。
^ Jansen、Arne（2011）、Btrfs Subvolume Quota Groups（PDF）、Strato AG 、
^ btrfs「RAID5 / 6」。kernel.org 。
^ コルベット、ジョナサン「LinuxConEuropeでのbtrfsアップデート」。
^ Mazzoleni、Andrea。「btrfs：lib：raid：最大6つのパリティをサポートする新しいRAIDライブラリ」。
^ 「Btrfsプロジェクトのアイデア」。
^ オーロラ、ヴァレリー「btrfsの短い歴史」。LWN.net 。
^ ヒルジンガー、マルセル「保護されたBtrfsの将来」。LinuxMagazine 。
^ コルベット、ジョナサン「reflink（）の両面」。LWN.net 。
^ “”UseCases –btrfsドキュメント””。kernel.org 。
^ 「btrfs：クロスサブボリュームファイルのクローンを許可する」。github.com 。
^ Lenz Grimmer「BtrfsとOCFS2でファイルのクローンを作成して、Linuxのディスク容量を節約してください」。oracle.com 。
^ 「シンボリックリンクは参照名を参照し、ハードリンクはメタデータを参照し、参照データを参照します」。pixelbeat.org。
^ Meyering、ジム「GNUcoreutilsニュース：リリース7.5での注目すべき変更」。savannah.gnu.org 。
^ Scrivano、ジュゼッペ「cp：-reflinkオプションを受け入れます」。savannah.gnu.org 。
^ ioctl_fideduperange(2) – Linuxプログラマーマニュアル–システムコール ^ “”SysadminGuide –Btrfsドキュメント””。kernel.org 。
^ “”5.6サブボリュームとスナップショットの作成””。oracle.com。2013 。
^ 「Gotchas-btrfsWiki」。btrfs.wiki.kernel.org。
^ 「センド/機能を受信を使用して5.7」。oracle.com。2013 。
^ メイソン、クリス「Ext3からの変換（Btrfsドキュメント）」。kernel.org 。
^ 「btrfs-convert（8）マニュアルページ」。
^ 「シードデバイス」。
^ Mason、Chris（2012年4月5日）、Btrfsファイルシステム：ステータスと新機能、Linux Foundation 、
^ マクファーソン、アマンダ「BTRfsでのChrisMasonとの会話：Linux用の次世代ファイルシステム」。LinuxFoundation。将来のリリースでは、長い間管理者の希望リストに載っていたオンラインfsck、重複排除、暗号化、およびその他の機能を追加する予定です。
^ スターバ、デビッド。「HMAC（SHA256）を使用して認証されたファイルシステム」。Lore.Kernel.org 。
^ 「Btrfsck-btrfsWiki」。btrfs.wiki.kernel.org。
^ 「復元-btrfsWiki」。btrfs.wiki.kernel.org。
^ 「問題に関するFAQ-btrfsWiki」。kernel.org。
^ “”kernel / git / torvalds / linux.git：ドキュメント：ファイルシステム：新しいbtrfsマウントオプションを追加（Linuxカーネルソースツリー）””。kernel.org。取り出される6年2月2014。
^ 「マウントオプション-btrfsWiki」。kernel.org。
^ Reiser、ハンス「Re：Ext2ディレクトリインデックス：ALSペーパーとベンチマーク」。ReiserFS開発者のメーリングリスト。
^ メイソン、クリス。「Acp」。Oracleの個人用Webページ。
^ 「ハードリンクの制限」。kerneltrap.org。
^ Fasheh、マーク「btrfs：拡張iノード参照」。
^ Torvalds、Linus「ChrisMasonからbtrfsアップデートをプルする」。git.kernel.org。
^ Larabel、Michael「Btrfsスペースキャッシュオプションのベンチマーク」。マイケル・ララベル。
^ 「FAQ-btrfsWiki：Btrfsはどのチェックサム関数を使用しますか？」。btrfsプロジェクト。
^ ビアマン、マーガレット; グリマー、レンツ。「Btrfsの高度な機能の使用方法」。
^ ソルター、ジム「BitrotおよびAtomicCOW：「次世代」ファイルシステムの内部」。ArsTechnica 。
^ Coekaerts、Wim「Btrfsスクラブ–ミラーコピーで破損を修正してください！」。
^ 「用語集」。BtrfsWiki 。
^ 「マンページ/mkfs.btrfs」。BtrfsWiki。プロファイル。
^ メイソン、クリス; ロデ、オハド; Bacik、Josef（2012年7月9日）、BTRFS：Linux Bツリーファイルシステム（PDF）、IBM Research 、
^ メイソン、クリス「複数のデバイスのサポート」。Btrfswiki。
^ Bartell、Sean「Re：BTRFSパーティションの復元」。linux-btrfs（メーリングリスト）。
^ 「Fedora33が正式に登場しました！」。
^ 「OracleはBtrfsRAID5 / 6をアンブレイカブルエンタープライズカーネルでサポートするようになりました-Phoronix」。Phoronix.com。
^ 「OracleLinux8でのBtrfsの管理」。docs.oracle.com。
^ 「SUSEはBtrfsのサポートを再確認します」。LWN.net。
^ 「SUSELinuxEnterprise Server12リリースノート」。SUSE.com 。
^ 「クラウドステーションホワイトペーパー」（PDF）。Synology.com。Synology。NS。11 。DSM 6.0以降、データボリュームはBtrfsとしてフォーマットできます。
^ 「ファイルシステム」。ReactOS.org 。
^ 「⁠BtrfsはRHEL | HackerNewsで非推奨になりました」。News.YCombinator.com。
^ 「RedHatはBtrfsの希望を放棄しているようです-Phoronix」。Phoronix.com。
^ Andreas Jaeger「Linuxでのラージファイルサポート」。users.suse.com 。
^ 「x86上の2.6.29のCONFIG_LBDのLinuxカーネル構成ヘルプ」。kernel.xc.net。

外部リンク
公式サイト
信じられないこれがバターだ！btrfsのツアーにYouTubeの -アビ・ミラー、オラクルのエンジニアが学会発表
Btrfs：複数のデバイスの操作 – LWN.net、2013年12月、Jonathan Corbet
MarcのLinuxBtrfsの投稿 –さまざまなBtrfs機能に関する詳細な洞察
Btrfsの概要、LinuxCon 2014、Marc Merlin
ファイルシステムエバンジェリストおよびソートリーダー：ヴァレリーオーロラへのインタビュー、Linux Magazine、2009年7月14日、ジェフリーB.レイトン

Btrfs&oldid=1047934134″