ファイルシステムは、普段は意識しない種類の基盤だ。何かが起きた日には、すべてを決めてしまう。

書き込み時複製がもたらす連鎖

Btrfs は Linux 向けの現代的な書き込み時複製のファイルシステムだ。公式文書の冒頭は一文で定義を示し、設計の目標もそこに並べる。先進的な機能を実現しながら、障害への耐性、修復、管理のしやすさも両立するという並びだ。この順序は注目に値する。失敗した後の立て直しを目標の側に置くということは、最初から長く動かす前提で作られているという意味になる。

書き込み時複製がこの設計の支点だ。データを書き換えるときは元の場所を上書きせず、別の場所に書いてからポインタを移す。だから変更の前後どちらの状態も残る。チェックサム、スナップショット、送受信が小さな負担で成り立つのは、根っこがここにあるからだ。公式の一覧は長い。チェックサム、圧縮、重複排除、断片化の整理、インラインのファイル、クォータグループ、reflink、稼働中の容量変更、チェックサムによる修復、送信と受信、サブボリューム、スワップファイル、TRIM、ボリューム管理が並ぶ。

ただし只というわけではない。ブロックが永久に無料で増えるのではない。変更されたブロックはもう一度書かれるので、同じファイルを書き続ける使い方では二重に払うことになる。新しい割り当てと、古い領域を後から片づける手間の二つだ。だから以下の手入れは飾りではなく、この設計の日常的な費用の一部になる。

実際に使われる機能

壊れたデータに気づくのがチェックサムだ。公式はこれに独立した章を割き、データとメタデータをどう検証するかを書く。読み取り時の自動修復という章もあり、使える複製があるときに読み出した内容をどう直すかを説明する。二つ合わせて、データの完全性についての基本の約束になる。

整理を担うのがサブボリュームとスナップショットだ。サブボリュームには独立した章があり、スナップショットはサブボリュームに対する普通の操作で、書き込み時複製と組み合わさることで作成の負担も占有量も小さく済む。運搬を担うのが送信と受信で、サブボリュームやスナップショットを流れとして別の Btrfs へ送る。差分のバックアップに向く。ボリューム管理は複数の装置を一つのファイルシステムにまとめるもので、バランス、装置の入れ替え、シード装置といった項目が並ぶ。

道具立てと版

日々の操作は btrfs-progs という一連のコマンドで行う。mkfs、check、scrub、balance がそこに入る。公式の変更記録は現行を 7.1、日付を 2026 年 7 月 14 日とし、そのあとに 2026 年 5 月 9 日の 7.0、2025 年 2 月 13 日の 6.19 が続く。道具は GPL-2.0 で公開され、リポジトリ直下にライセンス文書があり、ライブラリ部分には別のものが付く。

7.1 の変更は、組み立てと検査という二箇所の効率に集まっている。公式の記録によれば、mkfs はルートのディレクトリを指定したときに GET_CSUMS の口を使って既存のチェックサムを再利用でき、reflink と合わせてファイルのデータを読み直さずに済む。check にはクォータグループの検査を飛ばす選択肢が加わり、検査が速くなる。地味に見えるが、大きなファイルシステムでは浮いた時間は本物だ。

もう一点、このファイルシステムをそもそも選ぶかどうかも考えておきたい。どこでも既定というわけではなく、提供する配布側はたいてい、より素朴な選択肢と並べて見せる。機能の一覧をメニューのように読むのは筋が違う。その機械が実際に使う二つか三つはどれか、と問うのが正しい。入れた機能はどれも、誰かが手入れし、見張り、理解しなければならない。

保存の仕組みの値打ちは、仕様表の長さではなく、データを入れたあとに触らずにいられるかどうかにある。

使い方の提案。新しい盤はまず全体を検査し、悪い場所を把握してからデータを置く。戻せる地点が要るならサブボリュームのスナップショットを作る。盤の丸ごと複製よりはるかに安い。複数装置の構成は稼働前に冗長の段階を確かめ、一本の故障で全体を失わないようにする。機械をまたぐ移動は送信と受信を使い、差分の転送で丸ごと複製の時間を省く。