Btrfs - btrfs

Btrfs は COW 原則に基づいたローカルファイルシステムです。 COW はデータが修正された後に既存のデータを上書きするのではなく別のブロックに保管され、データ破壊のリスクが低くなることを意味します。 他のファイルシステムと異なり、Btrfs はエクステントベースです。これはデータを連続したメモリー領域に保管することを意味します。

基本的なファイルシステムの機能に加えて、Btrfs は RAID、ボリューム管理、プーリング、スナップショット、チェックサム、圧縮、その他の機能を提供します。

Btrfs を使うにはマシンに btrfs-progs がインストールされているか確認してください。

用語

Btrfs ファイルシステムはサブボリュームを持つことができます。これはファイルシステムのメインツリーの名前をつけられたバイナリサブツリーでそれ自身の独立したファイルとディレクトリー階層を持ちます。 Btrfs スナップショットは特殊なタイプのサブボリュームで別のサブボリュームの特定の状態をキャプチャーします。 スナップショットは読み書き可または読み取り専用にできます。

Incus の btrfs ドライバー

Incus の btrfs ドライバーはインスタンス、イメージ、スナップショットごとにサブボリュームを使用します。 新しいエンティティを作成する際（たとえば、新しいインスタンスを起動する）、 Btrfs スナップショットを作成します。

Btrfs はブロックデバイスの保管をネイティブにはサポートしていません。 このため、仮想マシンに Btrfs を使用する場合、 Incus は仮想マシンを格納するディスク上に巨大なファイルを作成します。 このアプローチはあまり効率的ではなく、スナップショット作成時に問題を引き起こすかもしれません。

Btrfs はネストした Incus 環境内のコンテナ内部でストレージバックエンドとして使用できます。 この場合、親のコンテナ自体は Btrfs を使う必要があります。 しかし、ネストした Incus のセットアップは親から Btrfs のクォータは引き継がないことに注意してください（以下の クォータ 参照）。

クォータ

Btrfs は qgroups 経由でストレージクォータをサポートします。 Btrfs qgroups は階層的ですが、新しいサブボリュームは親のサブボリュームの qgroups に自動的に追加されるわけではありません。 これはユーザーが設定されたクォータから逃れることができることは自明であることを意味します。 このため、厳密なクォータが必要な場合は、別のストレージドライバーを検討すべきです（たとえば、refquotas ありの ZFS や LVM 上の Btrfs）。

クォータを使用する際は、 Btrfs のエクステントはイミュータブルであることを考慮に入れる必要があります。 ブロックが書かれると、それらは新しいエクステントに現れます。 古いエクステントはその上のすべてのデータが参照されなくなるか上書きされるまで残ります。 これはサブボリューム内で現在存在するファイルで使用されている合計容量がクォータより小さい場合でもクォータに達することがあり得ることを意味します。

注釈

この問題は Btrfs 上で仮想マシンを使用する際にもっともよく発生します。これは Btrfs サブボリューム上に生のディスクイメージを使用する際のランダムな I/O の性質のためです。

このため、仮想マシンには Btrfs ストレージプールは決して使うべきではありません。

どうしても仮想マシンに Btrfs ストレージプールを使う必要がある場合、インスタンスのルートディスクの size.state をルートディスクのサイズの2倍に設定してください。 この設定により、ディスクイメージファイルの全てのブロックが qgroup クォータに達すること無しに上書きできるようになります。 btrfs.mount_options=compress-force ストレージプールオプションでもこのシナリオを回避できます。圧縮を有効にすることの副作用で最大のエクステントサイズを縮小しブロックの再書き込みが2倍のストレージを消費しないようになるからです。 しかし、これはストレージプールのオプションなので、プール上の全てのボリュームに影響します。

設定オプション

btrfs ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。

ストレージプール設定

btrfs.create_options

プール作成時にmkfs.btrfsに渡す追加のオプション

Key: btrfs.create_options
Type:

string
Default:
Scope:

global
btrfs.mount_options

ブロックデバイスのマウントオプション

Key: btrfs.mount_options
Type:

string
Default:

user_subvol_rm_allowed
Scope:

global
size

ループベースのプールを作成する際のストレージプールのサイズ（バイト単位、接尾辞のサポートあり、増やすとストレージプールのサイズを拡大）

Key: size
Type:

string
Default:

自動（空きディスクスペースの 20%, >= 5 GiB and <= 30 GiB）
Scope:

local
source

既存のブロックデバイス、ループファイル、あるいはBtrfsサブボリュームのパス

Key: source
Type:

string
Default:
Scope:

local
source.wipe

ストレージプールを作成する前にsourceで指定されたブロックデバイスの中身を消去する

Key: source.wipe
Type:

bool
Default:

false
Scope:

local

Tip

これらの設定に加えて、ストレージボリューム設定のデフォルト値を設定できます。 ストレージボリュームのデフォルト値を変更する を参照してください。

ストレージボリューム設定

initial.gid

インスタンス内のボリュームの所有者のGID

Key: initial.gid
Type:

int
Default:

volume.initial.gidと同じか0
Condition:

コンテントタイプfilesystemのカスタムボリューム
initial.mode

インスタンス内のボリュームのモード

Key: initial.mode
Type:

int
Default:

volume.initial.modeと同じか711
Condition:

コンテントタイプfilesystemのカスタムボリューム
initial.uid

インスタンス内のボリュームの所有者のUID

Key: initial.uid
Type:

int
Default:

volume.initial.uidと同じか0
Condition:

コンテントタイプfilesystemのカスタムボリューム
security.shared

複数のインスタンスでのボリュームの共有を有効にする

Key: security.shared
Type:

bool
Default:

volume.security.sharedと同じかfalse
Condition:

カスタムブロックボリューム
security.shifted

ID シフトオーバーレイを有効にする (複数の分離されたインスタンスによるアタッチを許可する)

Key: security.shifted
Type:

bool
Default:

volume.security.shiftedと同じかfalse
Condition:

カスタムボリューム
security.unmapped

ボリュームへのIDマッピングを無効にする

Key: security.unmapped
Type:

bool
Default:

volume.security.unmappedと同じかfalse
Condition:

カスタムボリューム
size

ストレージボリュームのサイズ/クォータ

Key: size
Type:

string
Default:

volume.sizeと同じ
Condition:

適切なドライバー
snapshots.expiry

新しく作ったスナップショットをいつ削除するかを制御（1M 2H 3d 4w 5m 6y のような式を期待）

Key: snapshots.expiry
Type:

string
Default:

volume.snapshots.expiryと同じ
Condition:

カスタムボリューム

この値は新しく作ったスナップショットの有効期限を算出するのに使います。 スナップショットが作られた日時にこの値が加算され、結果のタイムスタンプがスナップショットの個別の有効期限として保管されます。 この値を変更しても、変更後に作られたスナップショットのみに影響します。既存のスナップショットの有効期限は変更されません。

サポートされる単位はS（秒）、M（分）、H（時）、d（日）、w（週）、m（月) and y（年)です。 Mが分を意味し、mが月であることに注意してください。 それぞれの単位は1度だけ指定でき、月と年は固定の日数ではなくカレンダーの月として計算されます。

snapshots.expiry.manual

新しく作ったスナップショットをいつ削除するかを制御（1M 2H 3d 4w 5m 6y のような式を期待）

Key: snapshots.expiry.manual
Type:

string
Default:

volume.snapshots.expiry.manualと同じ
Condition:

カスタムボリューム

この値は新しく作ったスナップショットの有効期限を算出するのに使います。 スナップショットが作られた日時にこの値が加算され、結果のタイムスタンプがスナップショットの個別の有効期限として保管されます。 この値を変更しても、変更後に作られたスナップショットのみに影響します。既存のスナップショットの有効期限は変更されません。

サポートされる単位はS（秒）、M（分）、H（時）、d（日）、w（週）、m（月) and y（年)です。 Mが分を意味し、mが月であることに注意してください。 それぞれの単位は1度だけ指定でき、月と年は固定の日数ではなくカレンダーの月として計算されます。

snapshots.pattern

スナップショットの名前を表す Pongo2 テンプレート文字列 (スケジュールされたスナップショットと名前無しのスナップショットで使用) [1]

Key: snapshots.pattern
Type:

string
Default:

volume.snapshots.patternと同じかsnap%d
Condition:

カスタムボリューム
snapshots.schedule

Cron 表記 (<minute> <hour> <dom> <month> <dow>)、またはスケジュールエイリアスのカンマ区切りリスト(@hourly, @daily, @midnight, @weekly, @monthly, @annually, @yearly)、または自動スナップショットを無効にする場合は空文字(デフォルト)

Key: snapshots.schedule
Type:

string
Default:

volume.snapshots.scheduleと同じ
Condition:

カスタムボリューム

ストレージバケット設定

ローカルのストレージプールドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするにはcore.storage_buckets_addressサーバー設定を調整する必要があります。

size

ストレージバケットのサイズ/クォータ

Key: size
Type:

string
Default:

volume.sizeと同じ
Condition:

適切なドライバー