ファイルシステム on KnightLiブログ

Btrfs Scrub 使用ガイド：データ検証、自動修復、定期メンテナンス

Sat, 09 May 2026 07:11:01 +0800

Btrfs scrub は、Btrfs の日常メンテナンスで最も重要で、同時に誤解されやすい機能の一つである。これは伝統的な意味の fsck ではない。filesystem data と metadata を読み、checksum、superblock、metadata block header、disk read error を検証し、信頼できる replica がある場合に修復を試みる online validation pass である。

NAS、home server、backup disk、multi-device array で Btrfs を使っているなら、scrub は定期メンテナンスに入れるべきだ。価値は「壊れてから修理する」ことではなく、disk がまだ読めて、array に good replica が残っている段階で silent corruption を早期に見つけることにある。

scrub は何を確認するのか

Btrfs の公式ドキュメントによると、scrub は filesystem data と metadata を走査し、主に次を確認する。

data block checksum error。
basic super block error。
basic metadata block header error。
disk read error。

RAID1 のような replicated block group profile を使う filesystem では、read-write mount 上の scrub が一部の損傷を自動修復できる。修復は魔法ではない。別の replica から検証済みの good data をコピーするだけである。

ここが重要だ。scrub の修復能力は「利用可能な good copy が存在すること」に依存する。single disk に data が一つしかない場合、scrub は checksum error を検出できても、元の内容を自力で復元することは通常できない。

よく使うコマンド

mount point に対して scrub を開始する。

`1`	`sudo btrfs scrub start /`

foreground で実行し、結果を手動で観察する。

`1`	`sudo btrfs scrub start -B /`

status を確認する。

`1`	`sudo btrfs scrub status /`

実行中の scrub を cancel する。

`1`	`sudo btrfs scrub cancel /`

中断された scrub を resume する。

`1`	`sudo btrfs scrub resume /`

Btrfs の mount path を指定すると、その filesystem 内の全 device を並列に scrub する。device を指定した場合は、その device だけを scrub する。ただし指定 device 上の replica が読めない、または検証に失敗した場合、Btrfs は他の device から good copy を読むことを試みる。

scrub は fsck ではない

最もよくある誤解がこれだ。scrub は btrfs check ではなく、伝統的な filesystem checker でもない。

scrub ができること：

checksum を使って data または metadata corruption を検出する。
他に信頼できる replica がある場合に自動修復する。
disk read error と一部の基本構造 error を検出する。

scrub ができないこと：

good replica がない data を再構築する。
offline filesystem check を置き換える。
複雑な tree structure corruption をすべて修復する。
application-level file content が必ず正しいと保証する。

filesystem structure が深刻に壊れている場合、専門家の助言のもとで btrfs check などの tool が必要になることがある。scrub を万能修復コマンドとして扱ってはいけない。

NOCOW file のリスク

Btrfs 公式ドキュメントは重要な注意点を挙げている。chattr +C で file に NOCOW attribute を設定すると、現在の実装では暗黙に NODATASUM が有効になる。つまり、その file data 自体には checksum がない。

scrub はこれらの file の metadata を検証し修復できるが、file data の内容は検証できない。multi-replica setup では特に問題になる。ある NOCOW file の一つの copy が壊れても、Btrfs にはどの replica が正しいか判断する data checksum がないため、壊れた内容を user space tool に返す可能性がある。

一部の application は performance のために +C を default で使う。systemd journal や一部の libvirt storage pool が代表例である。VM image、database、log directory では性能上の理由があるが、普通の COW file と同じように scrub が data content を守ってくれるとは期待できない。

read-only scrub でも書き込みが起こり得る

もう一つ直感に反する点がある。read-write mounted filesystem で read-only scrub を実行しても、いくつかの write が発生する可能性がある。

公式ドキュメントによると、これは block group を read-only として mark することと block group items を write back することの race を避けるための design limitation である。完全に write のない scrub を望むなら、read-only mounted filesystem 上で read-only scrub を実行する必要がある。read-write mount に read-only scrub option を付けるだけでは不十分だ。

一般ユーザーにとっての意味は次の通り。

日常の online scrub は read-write mount 上で実行できる。
forensic、failure analysis、非常に保守的な read-only check では、先に mount state を確認する。
read-only scrub を絶対に zero-write だと解釈しない。

中断と再開

新しい kernel では、scrub は suspend、hibernate、filesystem freezing、cgroup freezing、pending signals などで中断されることがある。中断後、実行中の scrub は cancel されるが、btrfs scrub resume で保存位置から再開できる。

scrub status は次の場所に記録される。

`1`	`/var/lib/btrfs/`

file name は通常次のようになる。

1
2

scrub.status.UUID
scrub.progress.UUID

status file は定期的に更新される。resume した scrub は、完全に最初からではなく、最後に保存された位置から続行する。

どれくらいの頻度で実行するか

公式の推奨は月 1 回である。実際には data の重要性と disk 状態に合わせて調整する。

よくある schedule：

Home NAS：月 1 回。
Backup disk：長時間接続した後、または月 1 回。
重要な multi-device array：月 1 回、必要ならより頻繁に。
New disk migration や disk 不良の疑い：migration 後すぐに実行。

scrub は idle filesystem でも device bandwidth の約 80% を使う可能性があるため、peak workload 中に実行しないほうがよい。HDD array では scrub 中に latency がかなり上がることがある。SSD でも read amplification と background pressure は増える。

scrub の bandwidth を制限する

以前は ionice で foreground I/O への影響を下げる方法がよく使われた。しかし公式ドキュメントは、すべての I/O scheduler で同じように support されるわけではないと注意している。CFQ はすでに一般的ではない。BFQ は関連 priority behavior を support するが、使う前に理解しておく必要がある。mq-deadline のような一般的 scheduler では、cgroup2 I/O controller や Btrfs 専用の limit のほうが適している。

systemd で read bandwidth を制限する例：

`1`	`sudo systemd-run -p "IOReadBandwidthMax=/dev/sdx 10M" btrfs scrub start -B /`

Linux 5.14 以降では、Btrfs 専用の sysfs interface で device ごとの scrub limit を設定できる。

`1`	`echo 100m \| sudo tee /sys/fs/btrfs/FSID/devinfo/DEVID/scrub_speed_max`

現在の limit を表示する。

`1`	`sudo btrfs scrub limit /`

この設定は永続化されず、filesystem を unmount すると失われる。実際の system に合わせて FSID と DEVID を置き換える必要がある。まず次を確認する。

1
2

sudo btrfs filesystem show /
ls /sys/fs/btrfs/

実用的なメンテナンス手順

堅実な Btrfs メンテナンス手順は次のようにできる。

sudo btrfs scrub start -B /
sudo btrfs scrub status /
sudo btrfs device stats /
dmesg -T | grep -Ei "btrfs|checksum|i/o error|read error"

scrub が corrected errors を報告した場合、Btrfs は good replica から data を修復したという意味だが、無視してよいわけではない。disk SMART、cable、power、controller、Btrfs device stats を続けて確認するべきだ。

scrub が uncorrectable errors を報告した場合、Btrfs は good copy を見つけられなかった。まだ読める data をできるだけ早く backup し、affected file または device を特定し、必要に応じて disk replacement や backup からの restore を行う。

まとめ

Btrfs scrub の役割は明確だ。online data verification と replica repair の tool であり、fsck ではなく、backup でもない。

checksum と redundant replica がある Btrfs filesystem で、silent corruption を定期的に見つけ、good copy から復元する用途に最も向いている。checksum のない NOCOW file data は保護できず、good replica がない場合に壊れた内容を復元することもできない。

重要な data を Btrfs に置くなら、月 1 回 scrub を実行し、SMART、device stats、backup、alerting と組み合わせるべきだ。信頼できる data safety は、checksum、redundancy、monitoring、backup が一緒に働くことで実現する。単一の command に依存するものではない。

参考リンク：

Btrfs 公式ドキュメント：Scrub

Linux 7.0 と 7.1 における NTFS ドライバー変更の整理

Sat, 02 May 2026 10:46:20 +0800

Linux 7.0 の公開後、7.1 は次の機能マージ期間に入りました。そこで注目される変更の一つが、新しい NTFS カーネルドライバーです。

ここでいう「新しい」は、Linux が初めて NTFS に対応するという意味ではありません。また、ntfs3 が置き換えられるという意味でもありません。より正確には、Linux 7.1 に新しい任意のカーネル内 NTFS 読み書きドライバーが追加されます。これは昔からあるカーネル内 ntfs ドライバーを整理し直し、より完全な書き込み機能を補ったものです。

まず結論

Linux での NTFS 対応は、現在おもに三つのルートがあります。

方式	場所	読み書き	向いている場面
`ntfs-3g`	ユーザー空間 FUSE	読み書き	安定性優先。長く使われてきたディストリビューション標準
`ntfs3`	カーネル空間	読み書き	より直接的なカーネル統合と性能を求める場合
新 `ntfs`	カーネル空間	読み書き	Linux 7.1 で追加される任意の実装

今回の変更は強制移行ではなく、選択肢が一つ増えるという話です。普通のユーザーは、当面ディストリビューションの標準設定に従えば十分です。

7.0 と 7.1 の関係

Linux 7.0 は、カーネルのバージョンが 7.x 系列に入ったことを示します。7.0 で NTFS 対応が突然書き換えられたわけではありません。NTFS に関する新しい変更は、7.1 の機能マージ段階で入ります。

NTFS は Linux デスクトップユーザーにとって避けて通れないファイルシステムです。デュアルブート、外付けドライブ、USB メモリ、Windows データディスクでよく使われます。問題は、NTFS の書き込み経路が複雑なことです。ファイルシステムドライバーにバグがあると、ユーザーデータへ直接影響します。そのため、カーネルコミュニティは NTFS ドライバーの変更に慎重です。

`ntfs-3g`、`ntfs3`、新 `ntfs`

ntfs-3g はユーザー空間の FUSE ドライバーで、Linux 上の NTFS 読み書きを長く担ってきました。常に最速とは限りませんが、成熟しており、互換性が高く、情報も豊富です。

ntfs3 は Paragon Software が提供し、Linux メインラインに入ったカーネル内 NTFS ドライバーです。経路が短く、VFS との統合も直接的で、理論上の性能も高くなります。ただし、ファイルシステムドライバーには高い保守品質が求められるため、ntfs3 のマージ後も保守ペースやコード品質について議論がありました。

Linux 7.1 で追加される ntfs ドライバーは、Namjae Jeon が保守しています。ゼロから作られたものではなく、古いカーネル ntfs ドライバーを現代化し、読み書き能力を補った別の任意実装です。ntfs3 と併存します。

三者の関係は次のように考えると分かりやすいです。

ntfs-3g：保守的で成熟したユーザー空間実装。
ntfs3：すでにメインラインにあるカーネル内実装。
新 ntfs：7.1 で追加されるカーネル内実装。安定性は今後の観察が必要。

どれを使うべきか

日常利用で急いで切り替える必要はありません。保守的には次の順番が無難です。

重要なデータでは、ディストリビューション標準の方式を使う。多くの場合は ntfs-3g、または検証済みの ntfs3。
性能が必要な場合は ntfs3 を試す。
新しい ntfs ドライバーは、まずテスト用ディスク、一時データ、復旧可能なデータで試す。
重要な NTFS パーティションへ書き込む前にバックアップする。

ntfs3 を手動で使う場合の一般的なマウント例です。

`1`	`sudo mount -t ntfs3 /dev/sdX1 /mnt/ntfs`

一時的に読み取りだけしたい場合は、読み取り専用でマウントできます。

`1`	`sudo mount -o ro /dev/sdX1 /mnt/ntfs`

現在どのドライバーでマウントされているかは、次のように確認できます。

1
2

findmnt -T /mnt/ntfs
mount | grep ntfs

デュアルブート環境での注意

NTFS パーティションが Windows のシステムディスク由来の場合、書き込む前に Windows が完全にシャットダウンされていることを確認してください。高速スタートアップや休止状態は NTFS ボリュームを未完了の状態に残すため、Linux から書き込むと整合性問題が起きることがあります。

確認したい項目は次の通りです。

Windows の高速スタートアップを無効にする。
パーティションが hibernation 状態でないことを確認する。
BitLocker などの暗号化がアクセスを妨げていないことを確認する。
外付けドライブは Windows で正しく取り外す。

これは ntfs-3g、ntfs3、新しい ntfs のどれを使う場合でも同じです。

なぜ複数の NTFS ドライバーが必要なのか

同じファイルシステムに複数の実装が存在することは、Linux では珍しくありません。古い実装、新しい実装、ベンダー実装、コミュニティ実装がしばらく併存し、保守状況と実利用のフィードバックによって主流が決まっていきます。

NTFS では特に保守的な扱いが必要です。

ユーザーデータへのリスクが高い。
互換性の場面が複雑。
実装ごとに性能と安定性の取捨選択が異なる。
ディストリビューションが標準設定を検証する時間が必要。

そのため、Linux 7.1 の新 ntfs ドライバーは、ntfs-3g や ntfs3 をすぐ不要にするものではありません。カーネルコミュニティに、もう一つ保守可能な選択肢を与えるものです。

まとめ

Linux 7.1 で追加される ntfs ドライバーは、任意で使えるカーネル内 NTFS 読み書き実装です。ntfs-3g や ntfs3 と併存し、どちらかを直接置き換えるものではありません。

普通のユーザーは、引き続きディストリビューション標準の方式を使えば十分です。性能や新しいファイルシステム実装を試したい場合は、ntfs3 と新 ntfs の今後の安定性を見ながら、重要データでは必ずバックアップを取ってから切り替えるのが安全です。

Linux Kernel 7.0 更新内容の整理

Fri, 01 May 2026 14:46:07 +0800

Linux カーネルのバージョン番号は、以前からセマンティックバージョニングではない。メジャーバージョンの上昇は、主にメンテナンス周期上のロールアップに近い。 Linus Torvalds もリリースメールで 7.0 を通常のリリースとして説明しており、最後の週はネットワーク、アーキテクチャ、ツール、セルフテスト、ドライバまわりの小さな修正が中心だった。

本当に注目すべきなのは、この増分更新の中身である。 Linux 7.0 は、ファイルシステム、メモリ管理、ハードウェアサポート、セキュリティ分離、Rust サポート、ドライバ整理など、複数の領域にまたがっている。

ファイルシステム：XFS、EXT4、NTFS3 に変更

Linux 7.0 で最も体感しやすい更新の一つはファイルシステムだ。

XFS には自己修復に関連する機能が入った。新しい汎用ファイルシステムエラー報告の仕組みと組み合わせることで、ファイルシステムは metadata の破損や I/O エラーを、より統一された方法でユーザー空間へ伝えられる。適切なシステムサービスと連携すれば、XFS はファイルシステムをマウントしたまま一部の修復処理を自動で扱える。すべてのディスク破損を無痛で直せるという意味ではないが、サーバーや長時間稼働するシステムでは、エラー検出から修復までの経路がより整う。

EXT4 は並行 direct I/O 書き込み性能を引き続き改善している。バックアップ、ビルド、ダウンロード、データベース、ログ処理などが同時にディスクへ書き込む環境では、こうした最適化により並行書き込み経路がより安定する。すべてのデスクトップユーザーがすぐ体感する変化ではないが、高 I/O の場面では意味がある。

NTFS3 も比較的大きなドライバ更新を受けている。内容には delayed allocation、iomap ベースのファイル操作、大きなディレクトリを走査する場面での readahead 改善が含まれる。 Linux から Windows パーティションや外付け NTFS ディスクをよく使う場合は、注目してよい更新だ。

さらに exFAT は複数 cluster の順次読み取りを改善しており、一部の小さな cluster のデバイスでは順次読み取りが速くなる。

メモリと swap：メモリ圧迫時の挙動を引き続き改善

Linux 7.0 は、ここ数バージョンで進んできた swap サブシステムの整理を継続している。今回の重点の一つは、swap からメモリへ読み戻す経路の改善だ。特に、複数のプロセスが同じスワップアウト済みページを共有している場合、スループットが向上する。

デスクトップユーザーにとっては、「急にシステムが速くなった」と感じる種類の変化ではないかもしれない。しかし、メモリが厳しい環境、コンテナが密集したホスト、永続化を有効にした Redis 系サービス、または zram とバックエンドディスクを組み合わせた構成では、メモリ圧迫時の揺れを減らす助けになる。

zram 関連の経路も最適化されている。以前は一部のケースで、カーネルが zram ページをいったん展開してからバックエンドデバイスへ書き込む必要があった。新しい経路では圧縮データを直接書き込めるため、不要な処理を減らせる。

CPU と性能：Intel TSX auto、スレッドとファイル操作の高速化

Linux 7.0 は Intel TSX のデフォルト方針を調整した。過去のセキュリティ問題により、多くのプロセッサでは TSX がデフォルトで無効化されていた。現在のカーネルはより細かい auto 方針を採用し、影響を受ける CPU では引き続き無効化し、影響を受けない、または有効化に適した CPU では自動的に有効化できる。

これは一部のマルチスレッドワークロード、特にトランザクショナル同期拡張に依存するアプリケーションに役立つ可能性がある。ただし、汎用的な高速化スイッチではない。実際の効果は CPU 型番とアプリケーションがその機能を使うかどうかに依存する。

また、Linux 7.0 には PID 割り当て、スレッドの作成/破棄、ファイルの open/close 経路の最適化も含まれる。これらは単独で大きく宣伝される機能ではないが、システム応答性や高並行サービスでの小さな改善として積み上がる。

ハードウェアサポート：新プラットフォームの準備と既存デバイスの改善

Linux 7.0 は大量のハードウェア有効化作業を継続している。この種の更新は、まだ広く出回っていない新プラットフォームへの準備と、すでにユーザーの手元にあるデバイスの改善に分けられる。

新プラットフォームでは、Linux 7.0 に Intel Nova Lake、Intel Crescent Island、AMD の新しいグラフィックス IP、AMD Zen 6 に関する準備がさらに含まれる。普通のユーザーにとってすぐ役立つとは限らないが、新しいハードウェアが登場した後に、より早くメインラインカーネルで対応できるかを左右する。

ARM64 とシングルボードコンピュータでは、Rockchip RK3588/RK3576 の H.264/H.265 ハードウェア動画デコードがメインラインサポートの範囲に入った。これは Orange Pi 5 や Radxa ROCK 5 などのデバイスが、ハードウェアデコード体験のためにベンダー BSP カーネルへ完全に依存しなくてよくなることを意味する。

ノートPCや周辺機器にも細かな更新が多い。

ASUS WMI は ROG、TUF 機種のバックライト、キーボードライト、ファンホットキー対応を改善。
HP WMI は一部 Victus 機種の手動ファン制御を追加し、音声インジケーターライトを修正。
Lenovo WMI は Legion デバイス向けにより多くの HWMON 監視情報を公開。
Intel Xe グラフィックスドライバはより多くの温度センサーを公開。
Intel Arc B シリーズのディスクリートGPUは、より深い PCIe 省電力状態へ入れる。
Rock Band 4 Bluetooth ギターと Logitech K980 Bluetooth キーボードのカーネルサポートが改善。

一つ一つは小さな変更だが、ノートPC、ゲームデバイス、開発ボード、周辺機器のユーザーにとっては、メインラインカーネルでの対応が進むほど、その後のディストリビューション保守が楽になる。

セキュリティと分離：io_uring で BPF フィルタリングが可能に

Linux 7.0 は io_uring に BPF フィルタリング機能を追加した。これはコンテナ、サンドボックス、高いセキュリティ要件を持つ環境で重要になる。

以前は攻撃面を減らすため、管理者が io_uring を丸ごと無効化することがあった。現在は BPF フィルタリングにより、許可する操作をより細かく制限できる。つまり、「全開」か「全停止」だけを選ぶ必要がなくなる。

これで io_uring のセキュリティリスクが自動的に消えるわけではない。しかし、システム管理者やランタイムフレームワークにとって、より制御しやすい分離手段が増える。

Rust サポートは単なる実験ラベルではなくなった

Linux 7.0 では、Rust for Linux の状態がさらに安定した。これはカーネルが大規模に Rust へ書き換えられるという意味ではなく、C が置き換えられるという意味でもない。

より正確には、カーネル内で Rust を使うための基盤が、より正式な段階に入ったということだ。今後、新しいドライバ、新しいサブシステム、または一部のセキュリティに敏感なコードでは、適した場面で Rust を選べる。これは段階的な道筋である。まずインターフェース、ビルド、ドキュメント、保守プロセスを安定させ、その後で具体的なコードを少しずつ増やしていく。

古い機能の整理：laptop_mode の削除

Linux 7.0 は laptop_mode を削除した。これは長い歴史を持つ省電力機能で、主に機械式ハードディスク時代のノートPCを対象に、ディスクのスピンアップを減らして電力を節約するものだった。

現在のノートPCは SSD が主流であり、カーネル内のメモリ回収、ブロックデバイス、ファイルシステム経路も大きく変化している。この古い仕組みを残し続けると保守コストが増え、テストカバレッジも理想的ではない。削除により、古いコードが現代的な経路へ与える影響を減らせる。

AI 関連キー：新世代のキーボード操作に向けた準備

Linux 7.0 は、コンテキスト AI 操作向けにいくつかの新しい HID keycode を追加した。たとえば、選択中の内容に対して操作を実行する、コンテキスト生成内容を挿入する、コンテキスト検索を開始するといった用途である。

これはカーネルに AI 機能が組み込まれたという意味ではない。将来のノートPCキーボードや周辺機器のために入力イベント定義を用意し、デスクトップ環境、アプリ、ベンダーツールがそれらのキーを認識できるようにするものに近い。実際に何ができるかは、ディストリビューション、デスクトップ環境、アプリケーション層の統合に依存する。

すぐにアップグレードすべきか

ローリングリリース系のディストリビューションを使っている場合、Linux 7.0 は通常のシステム更新として自然に入ってくる可能性が高い。 Ubuntu 26.04 LTS のような新しいディストリビューションでは、7.0 がデフォルトまたは主要なカーネルバージョンとして採用されることもある。

ただし、対象のマシンが本番環境、NAS、仮想化ホストである場合、またはクローズドソースドライバや独自カーネルモジュールに依存している場合は、バージョン番号が 7.0 になったという理由だけで手動アップグレードするのは勧めにくい。より安全な進め方は次の通り。

ディストリビューションが正式なカーネルパッケージを提供するのを待つ。
GPU、ネットワークカード、ZFS、VirtualBox、VMware、DKMS モジュールの互換性を確認する。
テスト機またはスナップショット環境で先に検証する。
7.0.x のポイントリリースでの修正状況を追う。

kernel.org の v7.x ディレクトリを見る限り、7.0.1、7.0.2、7.0.3 はすでに順次公開されている。手動でビルドまたはテストするなら、最初の 7.0 tarball だけを見るのではなく、最新の安定版 7.0.x を優先したほうがよい。

まとめ

Linux Kernel 7.0 は、「メジャーバージョンが上がったからすべてを書き換えた」リリースではない。むしろ、範囲の広い通常のカーネル更新に近い。ファイルシステムはより信頼性を増し、swap と I/O 経路は引き続き最適化され、新しいハードウェア対応は前進し、Rust、io_uring の分離、HID 入力定義も長期的な進化に必要な基盤を補っている。

一般的なデスクトップユーザーにとって、最も実用的な変化はハードウェアサポート、グラフィックスドライバ、省電力、ファイルシステム修復にあるかもしれない。サーバーや開発者にとっては、XFS のエラー報告、自己修復、io_uring BPF フィルタリング、swap 最適化、新プラットフォーム対応がより注目に値する。

参考ソース：