Btrfs
Btrfs は、耐障害性、自己修復特性、管理のしやすさに焦点を当てつつ、先進的な機能を実装することも主眼としている、Linux 向けのコピーオンライト (CoW) ファイルシステムです。Btrfs は Oracle、Red Hat、富士通、Intel、SUSE、STRATO などによって共同で開発されており、GPL の条件下でライセンスされて広く貢献を受け入れています。
機能
Ext4 が安全確実で、広い領域をもつ巨大なファイルシステムも扱えるのにもかかわらず、なぜ Btrfs に切り替えるのでしょうか。たしかに Btrfs は未だ試験的なものと思われており、安定性の向上途上です。しかし、Linux システムのデフォルトのファイルシステムとなる時が近づきつつあります。Linux のディストリビューションのなかには、最新のリリースにおいて既に Btrfs に切り替え始めたものもあります。Btrfs は、ZFS にも備わっている一般的な先進機能に対応しています。こうした機能は、 BSD 系ディストリビューションや NAS 機器において ZFS の人気が高くなっている理由でもあります。
- コピーオンライト (CoW) とスナップショット - "ホット" なファイルシステムや仮想マシン (VM) からでさえも、増分バックアップを容易にします。
- ファイルレベルチェックサム - ファイル毎のメタデータがチェックサムを含み、エラーの検出と修復に使用されます。
- 圧縮 - ファイルは動的に圧縮・展開され、読み込み性能を向上させます。
- 自動デフラグメンテーション - ファイルシステムは使用中に、バックグラウンドスレッドによって調整されます。
- サブボリューム - 複数のファイルシステムは、それぞれのパーティションの中に入れて使う代わりに、単一の容量プールを共有できます。
- RAID - Btrfs は固有の RAID 実装を持っており、RAID を行うのに LVM あるいは mdadm は必要ではありません。現時点では RAID 0、1、10 がサポートされています; RAID 5 と 6 は不安定と見られています。
- パーティションは任意です - Btrfs はパーティションに入れて使うことができる一方で、生デバイス (/dev/<device>) を直接使用する能力も持っています。
- データ重複排除 - 限定的なデータ重複排除サポートを持っています; しかしながら、重複排除は将来的に Btrfs の標準的機能となる予定です。これにより、Btrfs はバイナリ差分によってファイル比較を行うことで、容量を節約できます。
- クォータ - Btrfs はクォータサポートを提供しており、これによりサブボリュームをクォータとしてグループ化することができます。
機能に関する最新で膨大な一覧は、公式 Wiki のステータスページをみてください。すべての機能が一般の使用に堪えるほど十分に成熟しているわけではありませんが。
将来的には、新しいクラスタ化ファイルシステムが、コピーオンライトやその他オブジェクトストアのための先進的機能を持つ Btrfs をすぐさま活用するでしょう。Ceph は、とても将来性があり Btrfs を活用できるクラスタ化ファイルシステムの一例です。
Btrfs is said to be a stable and well-tested single-disk filesystem and ext4 replacement, but caution is advised when using advanced features such as Btrfs-RAID.[1]
注意事項
btrfs では内部断片化 (空き領域が DATA + SYSTEM チャンクにピン留めされているが、METADATA チャンクが必要としている) のために、df が空き領域を報告したのに ENOSPC でファイルシステムの操作に失敗するという、直感に反することが起きることがあります。
加えて、a single 4K reference to a 128M extent inside btrfs は、空き領域が存在するが割り当てには利用できないということを引き起こすことがあります。これも df が空き領域を報告するのに btrfs は ENOSPC を返す原因になり得ます。
sys-fs/btrfsmaintenance をインストールして定期的に実行するスクリプトを構成することで、btrfs をリバランスして ENOSPC 問題の可能性を減らすことができますが、空き領域が存在するのに ENOSPC のリスクは消えはしないでしょう。ENOSPC が発生するかは用途によります。運用中の ENOSPC のリスクが許容できない場合は、別のものを使うべきです。btrfs を使うなら、問題が発覚している構成を避けることを確実にしてください。
ENOSPC は例外として、最新のカーネルブランチに存在する問題についての情報は btrfs wiki status page で確認できます。
インストール
カーネル
Btrfs に対応するには、つぎのカーネルオプションを有効にしてください:
File systems --->
<*> Btrfs filesystem
Emerge
sys-fs/btrfs-progs パッケージには、 Btrfs を扱うために必要なユーティリティが入っています。インストールするには:
root #
emerge --ask sys-fs/btrfs-progs
使い方
定期的なバランシング、デフラグ、トリミング、およびスクラビングを行うためには、sys-fs/btrfsmaintenance のセットアップを検討してください。
Btrfs の長いコマンドをタイプすることはすぐに手間になるでしょう。それぞれのコマンド(最初の btrfs コマンド以外)はとても短い命令に短縮できます。この方法は、コマンドラインから作業するときにタイプする文字数を減らすのに役立ちます。
例えば、/ にあるファイルシステムをデフラグするには、長いコマンドは次のようになります:
root #
btrfs filesystem defragment -v /
Shorten each of the longer commands after the btrfs command by reducing them to their unique, shortest prefix. In this context, unique means that no other btrfs commands will match the command at the command's shortest length. The shortened version of the above command is:
root #
btrfs fi de -v /
fi
で始まる btrfs コマンドは他にありません; filesystem
が唯一です。filesystem
コマンドの下で、de
サブコマンドも同様です。
作成
mkfs.btrfs コマンドは、フォーマットするよう指定されたパーティションのすべての内容を不可逆的に破壊します。mkfs コマンドを実行する前に、正しいドライブとパーティションが選択されていることを必ず確認してください!
/dev/sdXN パーティションを Btrfs で作成するには:
root #
mkfs.btrfs /dev/sdXN
上の例の、N
をフォーマットしたいパーティション番号で、X
をフォーマットしたいディスクレターで置き換えてください。例えば、システムの 1 番目のディスクの 3 番目のパーティションを Btrfs でフォーマッしたい場合には、次を実行してください:
root #
mkfs.btrfs /dev/sda3
すべての Btrfs パーティションについて、/etc/fstab の最後の数値カラムは
0
とすべきです。fsck.btrfs と btrfsck はシステム起動時に毎回実行すべきではありません。ラベル
btrfs ファイルシステムにラベルを追加して、マウントと整理をしやすくすることができます。
ラベルは一般的に UUID よりも一意性が低いですが、/ に rootfs そして /home に homedir のようなラベルを設定することで、整理の助けになります。
システム上に同じラベルを持つファイルシステムが複数存在する場合、fstab 内で最初のシステムか、blkid によって最初に返されるものがマウントされるでしょう。一般的にはこの挙動に依存するのは避けるのがベストで、一意なラベルを使用するべきです。
btrfs ファイルシステムを作成した後なら、以下を使用してラベルを追加することができます:
root #
btrfs filesystem label /dev/sda1 rootfs
btrfs ファイルシステムの作成時には、以下でラベルを追加することもできます:
root #
mkfs.btrfs -L rootfs /dev/sda1
マウント
ファイルシステムを作成したら、さまざまな方法でマウント可能です:
- mount - 手動マウント。
- /etc/fstab - /etc/fstab にマウントポイントを定義することで、システム起動時に自動でマウントされます。
- Removable media - 必要に応じた自動マウント (USB ドライブに便利です)。
- AutoFS - ファイルシステムアクセス時に自動マウント。
ext* ベースのファイルシステムから変換する
btrfs-convert ユーティリティを使用して、ext2、ext3、ext4 ファイルシステムを Btrfs に変換することができます。
次の手順はアンマウントされたファイルシステムの変換のみサポートしています。ルートパーティションを変換するためには、システムレスキューディスク(SystemRescueCD は上手く働きます)で起動してから、ルートパーティションに対して変換コマンドを実行してください。
まず、マウントポイントを確実にアンマウントしてください:
root #
umount <mounted_device>
適切な fsck ツールを使用してファイルシステムの整合性を確認してください。次の例ではファイルシステムは ext4 としています:
root #
fsck.ext4 -f <unmounted_device>
btrfs-convert を使用して、ext* フォーマットされたデバイスを Btrfs フォーマットされたデバイスに変換してください:
root #
btrfs-convert <unmounted_device>
デバイスがフォーマットされたら、忘れずに /etc/fstab を編集して、ファイルシステムのカラムを ext4 から Btrfs に変更してください:
<device> <mountpoint> btrfs defaults 0 0
デフラグ
Btrfs の機能のひとつに、オンラインでのデフラグメンテーションがあります。ルート Btrfs ファイルシステムをデフラグするには、次を実行してください:
root #
btrfs filesystem defragment -r -v /
autodefrag
マウントオプションはデフォルトの挙動をオンラインデフラグに設定します。
Defragmenting with kernel versions < 3.9 or ≥ 3.14-rc2 as well as with Linux stable kernel versions ≥ 3.10.31, ≥ 3.12.12 or ≥ 3.13.4 breaks up ref-links between files and their COW copies[2] and thus may increase space usage considerably. Make sure to have enough free space available and not too many snapshots on the drive as full btrfs partitions can get really slow.
圧縮
Btrfs は zlib、lzo、zstd (v5.1.0)[3] 圧縮アルゴリズムを使用した透過的圧縮をサポートしています。
ファイルの属性を設定することで特定のファイルのみ圧縮することも可能です:
user $
chattr +c
compress
マウントオプションは、新しく作成されたファイルをすべて圧縮するように、デフォルトの振る舞いを設定します。lzo 圧縮を利用してファイルシステム全体を再圧縮するには、次のコマンドを実行してください:
root #
btrfs filesystem defragment -r -v -clzo /
CPU とディスク性能によっては、lzo 圧縮を使うと全体のスループットが向上するかもしれません。
lzo の代わりに zlib または zstd 圧縮アルゴリズムを使用することもできます。zlib は遅いですが高い圧縮率を持ち、zstd は両者の間でいい比率となっています[4]。
ファイルシステム全体で zlib 圧縮を強制するには:
root #
btrfs filesystem defragment -r -v -czlib /
zstd 圧縮を有効化するには、上の例の zlib の部分を zstd に置き換えてください。
圧縮レベル
カーネルバージョン 4.15.0 以降[5]、zlib 圧縮はレベルを 1-9 の間で設定することができます。カーネルバージョン 5.1.0 以降、zstd はレベル 1-15 の間で設定することができます。例えば、マウント時に zlib を最高圧縮に設定するには:
root #
mount -o compress=zlib:9 /dev/sdXY /path/to/btrfs/mountpoint
または最低圧縮に設定するには:
root #
mount -o compress=zlib:1 /dev/sdXY /path/to/btrfs/mountpoint
また、再マウントすることで圧縮率を調節するには:
root #
mount -o remount,compress=zlib:3 /path/to/btrfs/mountpoint
圧縮率は /proc/mounts を開いて、または次のコマンドを使用して最新の dmesg の出力を確認することで、見ることができるはずです。
root #
dmesg | grep -i btrfs
[ 0.495284] Btrfs loaded, crc32c=crc32c-intel [ 3010.727383] BTRFS: device label My Passport devid 1 transid 31 /dev/sdd1 [ 3111.930960] BTRFS info (device sdd1): disk space caching is enabled [ 3111.930973] BTRFS info (device sdd1): has skinny extents [ 9428.918325] BTRFS info (device sdd1): use zlib compression, level 3
fstab を圧縮に対応させる
ドライブを再マウント、またはデータを圧縮するように調整したら、/etc/fstab ファイルに適切な変更を加えるのを忘れないでください。この例では、マウント時に zstd 圧縮がレベル 9 に設定されます:
/dev/sdb /srv btrfs compress=zstd:9,relatime,rw 0 0
圧縮率とディスク使用量
du や df など、使用中および空き容量を確認するための一般的なユーザ空間ツールは、Btrfs パーティションに対しては不正確な結果を返す場合があります。これは、例えば ext2/3/4 などと比較して、ファイルの書き込みがどのように行われるかに Btrfs 固有の設計の違いがあるためです[6]。
それゆえ、btrfs のユーザ空間ツール btrfs filesystem
が提供する du/df 代替を利用することを推奨します。加えて sys-fs/compsize パッケージに含まれる compsize ツールは、圧縮率と圧縮されたファイルのディスク使用量を考慮した追加情報を提供するので、役に立つでしょう。次の例は、/media/drive の下にマウントされた btrfs パーティションに対して、これらのツールを使用する例です。
user $
btrfs filesystem du -s /media/drive
Total Exclusive Set shared Filename 848.12GiB 848.12GiB 0.00B /media/drive/
user $
btrfs filesystem df /media/drive
Data, single: total=846.00GiB, used=845.61GiB System, DUP: total=8.00MiB, used=112.00KiB Metadata, DUP: total=2.00GiB, used=904.30MiB GlobalReserve, single: total=512.00MiB, used=0.00B
user $
compsize /media/drive
Processed 2262 files, 112115 regular extents (112115 refs), 174 inline. Type Perc Disk Usage Uncompressed Referenced TOTAL 99% 845G 848G 848G none 100% 844G 844G 844G zlib 16% 532M 3.2G 3.2G
複数のデバイス (RAID)
Btrfs は RAID を形成するために、複数のブロックデバイスとともに使用することができます。Btrfs を使用して複数のデバイスにまたがるファイルシステムを作成するのは、mdadm を使用して作成するのと比較して、作成時に初期化にかかる時間が不要なため、とても簡単です。
Btrfs はデータとメタデータを分離して扱います。マルチデバイスファイルシステムを使うときには、これに留意しておくことが重要です。データとメタデータのブロックグループに個別のプロファイルを使用することができます。例えば、メタデータは複数のデバイスをまたいだ RAID1 として構成する一方で、データは RAID5 として構成する、ということが可能です。RAID5 は最低でも 3 個のブロックデバイスを必要とするため、このプロファイルは 3 個以上のブロックデバイスを使用するときに可能なものです。
この種のプロファイルは、すべてのデバイスにメタデータを持たせることによる冗長性と、データをデバイスをまたいでストライピングすることで読み込み速度を向上させるメリットを提供します。このプロファイルのデメリットは、メタデータのための必要以上の容量と、RAID5 がパリティビットを使用することによるデータブロックへの書き込み速度の低下です。
作成
最も簡単な方法は、複数のデバイスにまたがるファイルシステムを作成するために、パーティションで分けられていない複数のブロックデバイス全体を使用する方法です。例えば、2 個のデバイスをまたいで RAID1 モードのファイルシステムを作成するには:
root #
mkfs.btrfs -m raid1 <device1> <device2> -d raid1 <device1> <device2>
変換
RAID プロファイル間の変換は balance サブコマンドによって行えます。例えば、現在 3 個のブロックデバイスが RAID1 で構成されて、/srv にマウントされているとします。次のコマンドで、このプロファイルに含まれるデータを RAID1 から RAID5 に変換することができます:
root #
btrfs balance start -dconvert=raid5 --force /srv
ファイルシステムがオンラインで使用中でも、変換を行うことができます。Btrfs で利用可能な RAID モードは RAID0、RAID1、RAID5、RAID6、そして RAID10 を含みます。さらなる情報については 上流の Btrfs wiki をご覧ください。
現時点で RAID 5 または 6 モードを使用するのは安全ではありません[7]。 RAID 5 および 6 モードは Linux 4.12 でいくつかのバグ修正がなされました[8]が、全体としてのステータスはまだ unstable としてマークされています。[9][10]。Btrfs の RAID5 または RAID6 の機能を使用したいユーザは、これらのモードを活用する前に使用したいモードの安定性ステータスを Btrfs ステータスページでチェックすることが推奨されます。
追加
既存のマルチデバイスファイルシステムに、追加のデバイスを足すことができます。以下の削除のセクションに従ってください。
安全にデバイスを取り除くための、より危険な、しかしより速いもうひとつの方法は、システムをシャットダウンして (または、システムがホットスワップ可能なドライブをサポートしている場合は、ファイルシステムをアンマウントするだけで済みます)、交換されるデバイスを物理的に切断して取り除き、新しいデバイスに交換し、(必要であれば) システムを起動することです。
メモ: 電源を切って再投入されたシステムは、デバイスがプールから物理的に取り除かれていることにより、マルチデバイスファイルシステムのマウントに失敗するでしょう。
システムが起動したら、mount -odegraded でマルチデバイスファイルシステムをマウントして、新しいデバイスを追加するための次のステップを実行してください。
root #
mount -odegraded /srv
root #
btrfs device add --force /dev/sdd /srv
デバイスが再度追加されたら、新しく追加されたデバイスにもまたがってデータが分散されるように、ファイルシステムを再平衡化する必要があります:
root #
btrfs balance start /srv
削除
デバイスパスによる指定
btrfs device remove サブコマンドを使用して、ブロックデバイス(ディスク)をマルチデバイスファイルシステムから取り除くことができます:
root #
btrfs device remove /dev/sde /srv
デバイス ID による指定
usage サブコマンドを使用してデバイス ID を特定してください:
root #
btrfs device usage /srv
/dev/sdb, ID: 3 Device size: 1.82TiB Device slack: 0.00B Data,RAID1: 25.00GiB Data,RAID5: 497.00GiB Data,RAID5: 5.00GiB Metadata,RAID5: 17.00GiB Metadata,RAID5: 352.00MiB System,RAID5: 32.00MiB Unallocated: 1.29TiB /dev/sdc, ID: 1 Device size: 1.82TiB Device slack: 0.00B Data,RAID1: 25.00GiB Data,RAID5: 497.00GiB Data,RAID5: 5.00GiB Metadata,RAID5: 17.00GiB Metadata,RAID5: 352.00MiB System,RAID5: 32.00MiB Unallocated: 1.29TiB /dev/sdd, ID: 4 Device size: 1.82TiB Device slack: 0.00B Data,RAID1: 25.00GiB Data,RAID5: 497.00GiB Data,RAID5: 5.00GiB Metadata,RAID5: 17.00GiB Metadata,RAID5: 352.00MiB System,RAID5: 32.00MiB Unallocated: 1.29TiB /dev/sde, ID: 5 Device size: 0.00B Device slack: 0.00B Data,RAID1: 75.00GiB Data,RAID5: 5.00GiB Metadata,RAID5: 352.00MiB Unallocated: 1.74TiB
次に、デバイスを取り除くためにデバイス ID を使用してください。次の例では /dev/sde が取り除かれます:
root #
btrfs device remove 5 /srv
リサイズ
btrfs パーティションは、組み込みの resize サブコマンドを使用して、オンラインにリサイズすることができます。
これはファイルシステムのサイズにのみ影響し、パーティション自体のサイズには影響しません。
ルートファイルシステムのサイズを 128gb に設定するには:
root #
btrfs filesystem resize 128g /
rootfs に 50 ギガバイトの領域を追加するには:
root #
btrfs filesystem resize +50g /
このコマンドは、利用可能なすべての領域を埋めることもできます:
root #
btrfs filesystem resize max /
サブボリューム
上の特徴リストで書いた通り、Btrfs はサブボリュームを作成することができます。サブボリュームはデータをより良く整理し管理するために使用することができます。サブボリュームはスナップショットと組み合わせると特に強力になります。Btrfs サブボリュームと、Logical Volume Management (LVM) によって作成されたサブボリュームの間には重要な違いがあります。Btrfs サブボリュームはブロックレベルデバイスではなく、POSIX ファイル名前空間です。[11]サブボリュームはファイルシステム上の好きな場所に作成することができ、一点の違いを除いて、システム上の他のディレクトリと同様に振る舞います。違いは、サブボリュームはマウント・アンマウントできるという点です。サブボリュームはネストすることができて (サブボリュームの中にサブボリュームを作成できて)、簡単に作成・削除できます。
異なる Btrfs ファイルシステムをまたいでサブボリュームを作成することはできません。/dev/sda と /dev/sdb がともに別々の(非 RAID の)Btrfs ファイルシステムを含んでいるとして、これらふたつのファイルシステムをまたいでサブボリュームを拡張する方法はありません。スナップショットはあるファイルシステムから別のファイルシステムへ移動することができますが、両方を覆うことはできません。/dev/sda または /dev/sdb のいずれかにしか存在できません。
作成
サブボリュームを作成するには、Btrfs ファイルシステムの名前空間の中で次のコマンドを実行してください:
root #
btrfs subvolume create <dest-name>
<dest-name>
をお好みの作成先とサブボリューム名で置き換えてください。例えば、Btrfs ファイルシステムが /mnt/btrfs に存在する場合、次のコマンドを使ってその中にサブボリュームを作成することができます:
root #
btrfs subvolume create /mnt/btrfs/subvolume1
一覧
作成されたサブボリュームを確認するには、subvolume list
コマンドに Btrfs ファイルシステムの場所を続けて使用してください。カレントディレクトリが Btrfs ファイルシステム内のどこかである場合、次のコマンドはそのファイルシステムに存在するサブボリュームを表示します:
root #
btrfs subvolume list .
上のコマンド例で作成されたマウントポイントに、サブボリュームを持つ Btrfs ファイルシステムが存在する場合、list コマンドからの出力は次のようになるでしょう:
root #
btrfs subvolume list /mnt/btrfs
ID 309 gen 102913 top level 5 path mnt/btrfs/subvolume1
削除
Btrfs ファイルシステム内で利用可能なサブボリュームパスの一覧は、上の list コマンドを使用して確認することができます。
サブボリュームは、subvolume delete
コマンドにサブボリュームへのパスを続けて使用することで、適切に削除することができます:
root #
btrfs subvolume delete <subvolume-path>
上と同様に、<subvolume-path>
を実際に削除するサブボリュームへのパスで置き換えてください。上の例で使用されているサブボリュームを削除するには、次のコマンドを実行します:
root #
btrfs subvolume delete /mnt/btrfs/subvolume1
Delete subvolume (no-commit): '/mnt/btrfs/subvolume1'
スナップショット
スナップショットは、データおよびメタデータを他のサブボリュームと共有するサブボリュームです。これは Btrfs のコピーオンライト (CoW) の能力により実現されています。[11] スナップショットは複数の目的に使用することができ、そのうちのひとつは、特定の時点でのファイルシステム構造のバックアップを作成することです。
ルートのファイルシステムが Btrfs であるときには、 subvolume snapshot
コマンドを用いてスナップショットの作成が可能です:
root #
mkdir -p /mnt/backup/rootfs
root #
btrfs subvolume snapshot / /mnt/backup/rootfs/
Btrfs でフォーマットされたルートファイルシステムの、タイムスタンプ付きスナップショットバックアップを作成するために、以下の短いシェルスクリプトを定時 cron ジョブに追加することができます。タイムスタンプの形式はユーザの好みに応じて調節できます。
#!/bin/bash
NOW=$(date +"%Y-%m-%d_%H:%M:%S")
if [ ! -e /mnt/backup ]; then
mkdir -p /mnt/backup
fi
cd /
/sbin/btrfs subvolume snapshot / "/mnt/backup/backup_${NOW}"
マウント
サブボリュームは、それが作成された場所とは別の場所にマウントすることができ、またユーザはサブボリュームをマウントしないことを選ぶこともできます。例えば、ユーザが Btrfs ファイルシステムを /mnt/btrfs に作成し、/mnt/btrfs/home と /mnt/btrfs/gentoo-repo サブボリュームを作成したとします。このとき、元のトップレベルサブボリュームをマウントしないまま、2 個のサブボリュームをそれぞれ /home と /var/db/repos/gentoo にマウントすることさえできます。その結果、各サブボリュームのトップレベルサブボリュームからの相対パスが、実際のパスとは異なる場所にある構成となります。
サブボリュームをマウントするには、次のコマンドを実行してください。ここで <rel-path>
は、subvolume list
コマンドによって得られる、サブボリュームのトップレベルサブボリュームからの相対パスです:
root #
mount -o subvol=<rel-path> <device> <mountpoint>
同様のパラメータでファイルシステムテーブルを更新して、Btrfs サブボリュームをマウントさせることができます:
<device> <mountpoint> btrfs subvol=<rel-path> 0 2
トラブルシューティング
ファイルシステムチェック
故障したディスクや破損したデータがある場合、ファイルシステムチェックを実行する必要があるかもしれません。典型的にはファイルシステムチェックのコマンドは fsck. で始まるコマンドで処理されますが、btrfs ファイルシステムに関しては、チェックは btrfs check サブコマンドによって処理されます:
root #
btrfs check --progress /dev/<device>
マルチデバイスファイルシステムのチェックは、ファイルシステム中のどれかひとつのデバイスを btrfs check に渡すことで処理されます。すべてのデバイスがアクセスできる限り、チェックは実行されるはずです。
マルチデバイスファイルシステムのマウントに失敗する
マルチデバイスファイルシステムから、行儀の悪い方法でデバイスを除去してしまった場合、その後ファイルシステムをマウントしようとすると失敗するでしょう:
root #
mnt /srv
mount: /srv: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error.
この種のマウント失敗は、マルチデバイスファイルシステムから 1 つまたは複数のデバイスが欠けていることによって発生することがあります。欠けたデバイスは、filesystem show サブコマンドを使用することで検出できます。以下の例では、/dev/sdb はまだマルチデバイスファイルシステムに接続されているデバイスのひとつです:
root #
btrfs filesystem show /dev/sdb
Label: none uuid: 9e7e9824-d66b-4a9c-a05c-c4245accabe99 Total devices 5 FS bytes used 2.50TiB devid 1 size 1.82TiB used 817.03GiB path /dev/sdc devid 3 size 1.82TiB used 817.00GiB path /dev/sdb devid 5 size 10.91TiB used 2.53TiB path /dev/sde devid 6 size 10.91TiB used 2.53TiB path /dev/sdd *** Some devices missing
欠けているデバイスは、以下のコマンドを使ってファイルシステムから行儀悪く抜けてしまったのかもしれません:
root #
btrfs device delete missing /srv
マルチデバイスファイルシステムが RAID 0 モードの場合、データ損失が発生するでしょう!
VM のディスクイメージで使用する
仮想マシンのディスクイメージで Btrfs を使用する場合は、IO 性能を向上させるために、ディスクイメージのコピーオンライトを無効化するのが良いでしょう。この効果は、新しく作成されるファイルに対してのみ発揮されます。特定のディレクトリの中で作成されるすべてのファイルに対して CoW を無効化することもできます。例えば、chattr コマンドを使用して:
root #
chattr +C /var/lib/libvirt/images
空き領域キャッシュをクリアする
clear_cache
マウントオプションを指定してファイルシステムをマウントすることで、Btrfs 内の空きのキャッシュ領域を開放することが可能です。例えば:
root #
mount -o clear_cache /path/to/device /path/to/mountpoint
Btrfs がメモリを食い潰している (ディスクキャッシュ)
Btrfs の特殊な機能のうち一部 (多数の --reflink
コピーを作成したり、大量のスナップショットを作成したりするなど) を活用しているときに、大量のメモリが消費されて、かつそれがカーネルの inode キャッシュによって十分な速さで解放されないことがあります。伝統的なシステム監視ユーティリティでは、ディスクキャッシュ専用のメモリははっきりと可視化されないことがあるため、この問題は発見されないまま潜んでいるかもしれません。カーネルオブジェクトがどれだけのメモリを消費しているかを決定する目的に特化して、slabtop ユーティリティ (sys-process/procps パッケージの一部として利用可能です) が作成されました:
root #
slabtop
Active / Total Objects (% used) : 5011373 / 5052626 (99.2%) Active / Total Slabs (% used) : 1158843 / 1158843 (100.0%) Active / Total Caches (% used) : 103 / 220 (46.8%) Active / Total Size (% used) : 3874182.66K / 3881148.34K (99.8%) Minimum / Average / Maximum Object : 0.02K / 0.77K / 4096.00K OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 2974761 2974485 99% 1.10K 991587 3 3966348K btrfs_inode 1501479 1496052 99% 0.19K 71499 21 285996K dentry
inode キャッシュが過剰なメモリを消費している場合、/proc/sys/vm/drop_caches ファイルに整数値を echo することで、カーネルにキャッシュを破棄するように手動で指示することができます[12]。
安全のために、そしてカーネルが解放できるメモリの最大量を決定するのを助けるために、下の echo コマンドを実行する前に sync を確実に実行してください。
user $
sync
おそらくほとんどの場合、Btrfs ユーザはスラブオブジェクト (dentries と btrfs_inodes) だけを再利用するために、echo 2 したいでしょう。
root #
echo 2 > /proc/sys/vm/drop_caches
ディスクキャッシュ全体 (スラブオブジェクトとページキャッシュ) をクリアするには、代わりに echo 3 を使用してください:
root #
echo 3 > /proc/sys/vm/drop_caches
上のコマンドは (実行する前に sync が完了している限り) 非破壊的ではありますが、カーネルが必要な項目のみをメモリに読み戻している間、一時的にですが深刻にシステムの動作を遅くします。システムに高負荷がかかっている状態では、上のコマンドを実行する前にもう一度考え直してください!
カーネルスラブについてのさらなる情報は、この dedoimedo ブログエントリで見つかります。
Btrfs のマウントが mount: unknown filesystem type 'btrfs' を返して失敗する
以下の解決策は、Stack Exchange での Tim によるオリジナルの解決策からヒントを得たものです: genkernel を使用する代わりに、手動でカーネルをビルドしてください:
#
cd /usr/src/linux
#
make menuconfig
#
make && make modules_install
#
cp arch/x86_64/boot/bzImage /boot
#
mv /boot/bzImage /boot/whatever_kernel_filename
#
genkernel --install initramfs
Btrfs ルートが起動しない
下のコマンドで作成された Genkernel の initramfs は btrfs をロードしません:
root #
genkernel --btrfs initramfs
モジュールとしてではなく、カーネルに組み込んで btrfs サポートをコンパイルするか、initramfs を生成するのに Dracut を使用してください。
関連項目
- Btrfs/snapshots — script to make automatic snapshots with Btrfs filesystem, using btrfs subvolume list-new function to create snapshots only when files have changed, so as to create fewer snapshots.
- Btrfs/System Root Guide — one example for re-basing a Gentoo installation's root filesystem to use btrfs
- Btrfs/Native System Root Guide — alternative guide on using a subvolume in a Btrfs filesystem as the system's root
- Ext4 — オープンソースのディスクファイルシステムで、extended filesystem シリーズの最新バージョンです。
- Btrbk — a tool for creating incremental snapshots and remote backups of Btrfs subvolumes.
- Samba shadow copies — expose Shadow Copies as 'Previous Versions' to Windows clients.
- Snapper — a command-line program to create and manage filesystem snapshots, allowing viewing or reversion of changes.
- ZFS — a next generation filesystem created by Matthew Ahrens and Jeff Bonwick.
外部資料
- https://wiki.debian.org/Btrfs - Debian wiki 内の記事
- https://wiki.archlinux.org/index.php/Btrfs - ArchWiki 内の記事
- http://www.funtoo.org/BTRFS_Fun - Funtoo wiki 内の BTRFS Fun 記事
- http://marc.merlins.org/perso/btrfs/post_2014-05-04_Fixing-Btrfs-Filesystem-Full-Problems.html - いくつかの状況における、Btrfs ファイルシステムのニッチな問題を修復するためのヒントと小技。
参照
- ↑ Examining btrfs, Linux’s perpetually half-finished filesystem
- ↑ man page for btrfs-filesystem(8), Btrfs wiki. Retrieved on 6th February, 2017.
- ↑ https://btrfs.readthedocs.io/en/latest/Compression.html#compression-levels
- ↑ https://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git/commit/?h=next&id=5c1aab1dd5445ed8bdcdbb575abc1b0d7ee5b2e7
- ↑ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f51d2b59120ff364a5e612a594ed358767e1cd09
- ↑ https://btrfs.wiki.kernel.org/index.php/Compression#How_can_I_determine_compressed_size_of_a_file.3F
- ↑ パリティ RAID コードに深刻なデータ損失バグが複数存在することに言及した記事、 Btrfs wiki 2017 年 1 月 1 日閲覧。
- ↑ Michael Larabel、Btrfs RAID56 "Mostly OK"、Phoronix. 2017 年 7 月 8 日。
- ↑ btrfs: scrub: Fix RAID56 recovery race condition、ソースコミット、2017 年 4 月 18 日。
- ↑ GIT PULL Btrfs from Chris Mason、Linux カーネルメーリングリスト、2017 年 5 月 9 日。
- ↑ 11.0 11.1 サブボリュームと LVM の論理ボリュームの違いを説明するページ、Btrfs wiki。2023 年 4 月 2 日閲覧。
- ↑ Documentation for /proc/sys/vm/*, Kernel.org. 2017 年 1 月 1日閲覧。