古いPCを再利用する際のファイルシステム！NTFSとBtrfsはどちらがシステム負荷が少ない？

クローゼットの奥や倉庫に眠る古いPCを、再度実用的なマシンとして蘇らせる際、単なるOSの再インストールだけでなく、根幹となるファイルシステムの選択が全体の応答性を大きく左右することをご存じでしょうか。
特にスペックに余裕のない旧世代の機器においては、ファイルシステムが生成するオーバーヘッドの差異が、日常使いのもたつきに如実に現れます。
Windowsの定番であるNTFSと、Linux環境で注目を集めるBtrfs。
どちらが古いハードウェアにとって優しい選択となるのか、本記事ではシステム負荷の観点から冷静に検討します。

NTFSは長年の実績を持つジャーナリングファイルシステムであり、Windowsとの親和性は言うまでもありません。
一方のBtrfsは、コピーオンライトやサブボリューム、内蔵型の圧縮機能を備えた次世代のファイルシステムとして、Linuxユーザーから高い支持を得ています。
しかし、これらの先進的な機能が古いCPUや限られたメモリ上でどのようなコストを生じさせるのかは、必ずしも自明ではありません。
機能の豊富さと、実際のリソース消費のトレードオフを見極める必要があります。

本記事では、古いPCの再利用という具体的な文脈の中で、NTFSとBtrfsのシステム負荷に焦点を当てて解説します。
ファイルシステムがCPUやメモリ、ディスクI/Oに与える影響を整理し、あなたのハードウェア構成に適した選択の指針を示すことが目的です。
古いマシンの可能性を最大限に引き出すための、ひとつの判断材料としてご覧ください。

古いPCを再利用するならファイルシステムの選定が応答性を左右する

クローゼットの奥や倉庫に眠る古いPCを、再度実用的なマシンとして蘇らせる際、単なるOSの再インストールだけでなく、根幹となるファイルシステムの選択が全体の応答性を大きく左右することをご存じでしょうか。
特にスペックに余裕のない旧世代の機器においては、ファイルシステムが生成するオーバーヘッドの差異が、日常使いのもたつきに如実に現れます。
Windowsの定番であるNTFSと、Linux環境で注目を集めるBtrfs。
どちらが古いハードウェアにとって優しい選択となるのか、本記事ではシステム負荷の観点から冷静に検討します。

なぜOSではなくファイルシステムが古いPCの速度を左右するのか

多くの方にとって、PCの動作速度というとCPUやメモリ容量、そしてストレージの種類がHDDかSSDかという点が最初に浮かぶでしょう。
確かにこれは無視できない要素です。
しかし、OSとストレージの間に位置するファイルシステムは、実際にはすべての読み書き処理に介入する中核的な層です。
ファイルの作成、削除、更新のたびにメタデータの管理やジャーナルの記録、空き領域の割り当てといった処理が発生し、これらがCPUとメモリ、さらにはディスクI/Oを消費します。

古いPCでは、比較的低速なCPUや限られたメモリ容量の中で、こうしたバックグラウンド処理の負担が相対的に大きくなります。
例えば、ジャーナリングファイルシステムはデータの整合性を保つためにログを記録しますが、その記録処理自体がCPUサイクルを消費し、メモリ上にキャッシュ構造を維持するコストも生じます。
また、高度な機能を持つファイルシステムでは、コピーオンライトや圧縮、チェックサム計算などの処理が追加され、古いハードウェアではその恩恵よりもオーバーヘッドが目立つことがあります。

つまり、ファイルシステムの選定とは、単なるデータの整理方法を決めるだけでなく、限られたリソースをどのように消費するかというシステム設計上の重要な判断です。
古いPCの再利用において、この層への注目が応答性の改善に直結します。

NTFSとBtrfsの比較が注目される背景と検証の目的

NTFSはWindowsの標準ファイルシステムとして長年にわたり実績を積み重ねてきました。
高い互換性と安定性を持ち、古いPCでWindowsを継続して使用する場合、事実上のデフォルト選択です。
一方、BtrfsはLinux環境で次世代ファイルシステムとして広く採用が進んでおり、コピーオンライトによるスナップショット機能や内蔵型の圧縮、サブボリューム管理など、運用面での利便性が高く評価されています。

しかし、こうした先進的な機能が古いCPUや限られたメモリ上でどのようなコストを生じさせるのかは、必ずしも自明ではありません。
機能の豊富さと、実際のリソース消費のトレードオフを見極める必要があります。

本記事では、古いPCの再利用という具体的な文脈の中で、NTFSとBtrfsのシステム負荷に焦点を当てて解説します。
ファイルシステムがCPUやメモリ、ディスクI/Oに与える影響を整理し、あなたのハードウェア構成に適した選択の指針を示すことが目的です。
古いマシンの可能性を最大限に引き出すための、ひとつの判断材料としてご覧ください。

NTFSの仕組みと古いPCにおけるシステム負荷の特徴を解説

NTFSはWindowsの標準ファイルシステムとして長年の実績を持ち、古いPCでも馴染み深い存在です。
しかし、その安定性の裏にあるジャーナリング機構やメタデータ管理が、限られたリソースの環境でどのような負荷を生じさせるのかを理解することは、再利用の成否を左右します。
ここではNTFSの基本的な構造から、低スペック環境での実際の動作負荷、そして旧バージョンWindowsにおける最適化のポイントまでを整理します。

NTFSのジャーナリングとメタデータ管理の基本構造

NTFSの中核にはMFT（Master File Table）があり、すべてのファイルやディレクトリの情報がこの特殊なファイル内に格納されます。
ファイルそのものが数百バイト程度の小さなデータであれば、MFTエントリ内に直接内容を保持するリゾナントファイルという仕組みも働き、ディスク上の別領域を消費せずに済みます。
一方、大きなファイルはMFTがアトリビュートとしてデータランのポインタを保持し、実データへの参照を行います。

この構造の重要な特徴は、ジャーナリング機能です。
電源断やシステムクラッシュ時にファイルシステムの整合性を保つため、NTFSはメタデータの変更履歴を$LogFileと呼ばれる専用の領域に記録します。
このログ書き込みは多くの場合同期的に行われるため、ファイル作成や削除のたびにディスクI/Oが発生し、CPUの待ち時間を生じさせます。
また、MFT自体のサイズが増大するほど、エントリの走査やインデックスの維持に必要なメモリ量も増加します。

低スペック環境でのNTFSの実際の動作負荷

古いPC、特にメモリが2GBや4GB程度で、CPUがデュアルコア世代の機器では、NTFSのメタデータ処理が無視できない負荷となります。
Windows Update後の大量のファイル書き換え時には、ジャーナルの記録とMFTの更新が頻発し、タスクマネージャでディスク使用率が100%に張り付く事象が起こりやすくなります。

また、NTFSはボリューム上の空き領域を$Bitmapというファイルで管理しますが、このビットマップの参照と更新も細かいファイル操作のたびに発生します。
メモリが少ない環境では、これらのメタデータをキャッシュに乗せきれず、ディスクからの再読み込みが増大して応答性が低下します。
古いHDDを搭載したPCでは、このランダムアクセスの増加が致命的なもたつきを生じさせることがあります。

Windows旧バージョンでのNTFS最適化ポイント

Windows 7や8.1、あるいは10の初期バージョンを動かす古いPCでは、NTFSの動作をある程度制御して負荷を軽減できます。

• 8.3形式ファイル名の生成を無効化する：互換性のための短いファイル名（MS-DOS互換）を生成する機能を止めることで、MFTエントリ作成時やディレクトリ走査のオーバーヘッドを減らせます。コマンドプロンプトで管理者権限を持って「fsutil behavior set disable8dot3 1」を実行します
• 最終アクセス時刻の更新を無効化する：ファイルを読み取るたびに最終アクセス時刻を更新する処理を停止することで不要なメタデータ書き込みを削減できます
• 圧縮機能の慎重な利用：NTFSのボリューム圧縮は古いCPUでは圧縮・解凍処理が負荷となります。HDD容量に余裕がない場合を除き、無効にしておくのが無難です
• SSDとHDDで異なるアプローチ：SSDを搭載した古いPCでは、NTFSの自己整理機能に任せ、従来のデフラグツールは使用しないよう注意が必要です。一方HDDでは、適度なデフラグメンテナンスはシーケンシャルアクセスの効率を維持するために有効です

これらの設定を見直すことで、NTFSのオーバーヘッドを一定程度抑制し、古いPCでも実用的な応答性を取り戻すことが可能です。

Btrfsの機能と古いPCでのリソース消費の実情

BtrfsはLinux環境で次世代ファイルシステムとして広く採用が進んでいるコピーオンライト方式のファイルシステムです。
サブボリュームによる柔軟な領域管理や内蔵型の圧縮機能、データのチェックサム検証など、運用面での利便性は高く評価されています。
しかし、こうした先進的な機能が古いCPUや限られたメモリ上でどのようなコストを生じさせるのかは、必ずしも自明ではありません。
機能の豊富さと、実際のリソース消費のトレードオフを冷静に見極める必要があります。

コピーオンライトとサブボリュームの仕組みとオーバーヘッド

Btrfsの中核にあるコピーオンライト（CoW）は、既存のファイルに変更を加える際に、元のデータブロックを上書きせず、新たなブロックに書き込む仕組みです。
これにより、電源断時のデータ破損リスクを大幅に低減し、スナップショットの作成を極めて軽量に行えます。
しかし、この設計は古いPCでは断片化の増加という副作用をもたらすことがあります。
特にデータベースや仮想マシンイメージのような頻繁にランダム書き込みが発生する用途では、ブロックの散在が進み、読み込み時のシーク回数が増加します。

また、サブボリュームは独立したファイルシステムのように振る舞う軽量な名前空間です。
複数のサブボリュームを同一パーティション内に作成でき、それぞれにスナップショットを適用できるため、システム領域とユーザーデータの分離が容易になります。
一方で、サブボリュームごとにBツリー構造を管理するため、メタデータのメモリ使用量はやや増加する傾向があります。
メモリが2GB程度の古い機器では、大量のサブボリュームを多用することは控えめにした方が無難です。

圧縮機能とチェックサムによるCPU負荷の実態

BtrfsはZSTDやLZOなどの圧縮アルゴリズムを内蔵しており、透過的なデータ圧縮が可能です。
これによりストレージ容量の節約と、圧縮されたデータの連続読み書きによるI/O効率化が期待できます。
しかし、圧縮と解凍の処理はCPUサイクルを消費します。
特にZSTDは高い圧縮率を誇りますが、古いデュアルコアCPUや低クロック世代のプロセッサでは、ファイルの読み書き時に明確なレイテンシ増加が観測されることがあります。

さらに、Btrfsはチェックサムによってデータとメタデータの整合性を検証します。
読み込み時にハッシュ値を計算し、記録時の値と比較することで、静寂的なデータ破損を検出できます。
この検証はデータ保護にとって極めて有効ですが、読み取りアクセスのたびにハッシュ計算が走るため、CPU負荷が増加します。
古いPCで大量のファイルをコピーしたり、メディアをスキャンしたりする際には、このチェックサム処理がボトルネックとなる可能性があります。

LinuxディストリビューションでのBtrfs実用設定

近年のLinuxディストリビューションでは、Btrfsへの対応が進んでいます。
FedoraはデフォルトでBtrfsを採用しており、Ubuntuでもインストール時に選択可能です。
古いPCでBtrfsを実用する際は、マウントオプションの調整が有効です。

• 圧縮レベルの調整：古いCPUでは「compress=zstd:1」など低いレベルを指定するか、圧縮自体を無効にすることで負荷を抑えられます。テキストファイルやログが多い用途では圧縮の恩恵が大きい一方、既に圧縮されたメディアファイルが多い場合は効果が薄く、CPUコストだけが残ります
• 自動デフラグの判断：「autodefrag」オプションは断片化を緩和しますが、古いHDDではバックグラウンドでの再書き込みがI/O負荷を増大させることがあります。SSD搭載機であれば有効ですが、HDDのみの環境では慎重に検討すべきです
• スクラビングの頻度：データ整合性を保つためのスクラビングは有用ですが、古いPCでは高頻度での実行は負荷となります。月に一度程度に抑え、実行中は他の重い作業を避ける運用が現実的です

これらの設定を適切に調整することで、Btrfsの先進機能を活かしつつ、古いPCの限られたリソースとのバランスを取ることが可能です。

CPU負荷の観点で比較するNTFSとBtrfsの処理効率

ファイルシステムの選択がシステム全体の応答性に与える影響を測る上で、CPU負荷は最も分かりやすい指標のひとつです。
NTFSとBtrfsは、それぞれ異なる設計思想に基づいてメタデータを管理しており、その差異はファイル作成や削除のような日常的な操作、そしてバックグラウンドでのメンテナンス処理において顕著に現れます。
古いPCでは、こうしたCPUサイクルの消費が容赦なく蓄積し、実用的な速度低下を招くことがあります。

ファイル作成・削除時のCPU使用率の比較結果

ファイルの作成や削除は、データそのものの書き込みだけでなく、ファイルシステム内部のメタデータ更新を伴います。
NTFSでは、MFTへのエントリ追加や更新、$LogFileへのジャーナル記録、$Bitmapの空き領域管理といった処理が同期的に発生します。
特に数千から数万の小さなファイルを連続して作成する場面では、これらのメタデータ操作がCPUを頻繁に介入させ、ディスクI/O待ちと合わさって使用率が上昇します。

一方、Btrfsではコピーオンライトの性質上、新規ブロックの割り当てとBツリーの更新が中心となります。
ファイル作成時には親ディレクトリのBツリーへの挿入処理が発生し、削除時には対応するエクステントの解放とツリーの再構築が行われます。
さらにチェックサムの計算が加わるため、単純なメタデータ更新だけでなく、ハッシュ演算のCPUコストも考慮する必要があります。

実際の傾向を整理すると、以下のようになります。

古いデュアルコアCPUでの計測では、小ファイルI/Oが密集するワークロードにおいて、両者ともにCPU使用率が20%から40%程度に達するケースが見られます。
ただし、NTFSはWindowsのキャッシュマネージャとの統合が長年にわたり洗練されているため、メモリに余裕がある場合には再読み込みの効率が良い一方、Btrfsは初回アクセス時のメタデータ展開にややコストがかかる傾向があります。

バックグラウンドメンテナンス処理の負荷差

日常的なファイル操作以外に、バックグラウンドで動作するメンテナンス処理もCPU負荷の重要な発生源です。
NTFSでは、Windowsのスケジュールタスクとして動作するデフラグや、システム起動時のMFT自己修復処理が代表的です。
特にHDD搭載の古いPCでは、デフラグ処理中にディスクI/OとCPUが同時に消費され、他の作業が著しくもたつきます。

Btrfsでは、スクラビングとバランシングが主要なメンテナンス処理です。
スクラビングは全データブロックのチェックサムを検証する処理であり、ストレージ全体を走査するため、実行中はCPU負荷が継続的に発生します。
バランシングは各チャンクの使用率を均等化する処理で、古いPCではI/O負荷とともにCPUも消費します。
ただし、これらの処理は実行頻度をユーザーが細かく制御できるため、NTFSの自動メンテナンスに比べて計画的な運用が可能です。

古いPCにおいては、NTFSの自動デフラグを無効化するか、実行時間帯を制限することで負荷を抑えられます。
Btrfsにおいては、スクラビングを月一度に抑え、圧縮レベルを下げることで、バックグラウンド処理全体のCPU消費を実用的な範囲に収めることができます。
どちらのファイルシステムも、デフォルト設定のまま古いハードウェアに任せると、予期しないタイミングでCPUリソースを奪うことがあるため、メンテナンスの計画性が応答性を左右します。

メモリ使用量の違いが古いPCのもたつきに与える影響

CPU負荷と並んで、ファイルシステムのメモリ消費は古いPCの体感速度を左右する決定的な要素です。
メモリが4GBや2GBといった限られた容量である場合、ファイルシステムがキャッシュとして確保するメタデータやバッファのサイズが大きければ、アプリケーションに回せる空きが減少し、スワップの発生頻度が増えます。
NTFSとBtrfsはそれぞれ異なるキャッシュ戦略を持ち、その差異はメモリが少ない環境で顕著に現れます。

NTFSのキャッシュ機構とメモリ消費の傾向

NTFSはWindowsのシステムキャッシュマネージャと密接に統合されており、ファイルのメタデータや最近アクセスしたデータを物理メモリ上に積極的に保持します。
MFTのエントリ、ディレクトリインデックス、そして遅延書き込み用のダーティページは、空きメモリが許す限りキャッシュに乗せられ、再アクセス時のディスク読み取りを回避します。
この設計はメモリに余裕がある現代のPCでは極めて効果的ですが、古いPCでは裏目に出ることがあります。

メモリ容量が2GBから4GB程度の機器では、NTFSキャッシュが占める割合が相対的に大きくなり、ブラウザやオフィスソフトといったアプリケーションが確保すべきワークセットを圧迫します。
その結果、ページングの増加が発生し、ディスクへのスワップ出入力が頻繁になることで、まるでPC全体が沈み込んだようなもたつきを生じさせます。
また、Windows Update後の大量のファイル変更では、MFTのキャッシュ無効化と再読み込みが走り、一時的にメモリとディスクの両方が逼迫する事態も起こりえます。

BtrfsのBツリー管理がメモリに与える影響

BtrfsはメタデータをBツリー（B-tree）構造で管理しており、ファイルの場所、サブボリュームの階層、空き領域のマッピングなどがツリーのノードとして保持されます。
アクセスのたびにこのツリーを走査するため、頻繁に参照されるノードはLinuxのページキャッシュ上に展開されます。
サブボリュームを多用したり、スナップショットを多数保持したりすると、ツリーの深さと広がりが増し、メモリ上に保持すべきメタデータ量も増加します。

古いPCでBtrfsを運用する際、特にメモリ2GB前後の環境では、このメタデータキャッシュが他のプロセスと競合します。
チェックサム検証のためのハッシュテーブルや、CoWによる古いブロックの追跡情報もメモリを消費するため、メタデータ密集型の作業では空きメモリが急速に減少する傾向があります。
ただし、Linuxのカーネルはキャッシュの圧迫時に比較的素直にページを解放する傾向があり、NTFSのようにキャッシュが膨張し続ける挙動とは性格が異なります。

両者の傾向を整理すると、以下のようになります。

古いPCにおいては、NTFSではキャッシュ動作を意識したメモリ増設や不要なサービスの停止が有効です。
Btrfsではサブボリュームとスナップショットの数を抑え、メタデータの肥大化を防ぐことで、限られたメモリの中で実用的な応答性を維持できます。
メモリが4GB以下の環境では、どちらのファイルシステムもデフォルトのままでは厳しく、運用面での配慮が応答性の鍵となります。

ディスクI/O負荷とストレージ寿命におけるNTFSとBtrfsの違い

古いPCではCPUやメモリの不足が注目されがちですが、実際の体感速度を大きく左右するのがディスクI/Oです。
特にHDD搭載機ではヘッドのシーク回数が応答性を決定づけ、SSDでは書き込みパターンが寿命と密接に関わります。
NTFSとBtrfsは根本的に異なる書き込み哲学を持っており、ストレージへの負荷のかかり方も大きく異なります。
古いPCの再利用を考える上で、このI/O特性の違いを見誤ると、思わぬ速度低下やストレージの早期消耗を招くことがあります。

書き込みパターンの違いとHDD・SSDへの負荷

NTFSは基本的にインプレース更新を行います。
既存ファイルを上書きする際、元のデータが存在するブロックに直接新しい内容を書き込みます。
これにより論理的には連続した領域の書き込みが維持されやすく、HDDにおけるシーケンシャルアクセスの効率は比較的良好です。
しかし、ジャーナル（$LogFile）やMFT、$Bitmapへのメタデータ更新は別領域に発生するため、1回の書き込み操作がデータ領域とメタデータ領域の両方に跨るランダムI/Oを生じさせます。

Btrfsはコピーオンライト（CoW）を徹底しており、既存ファイルの更新は必ず新しいブロックに書き込まれます。
元のブロックは解放されるまで保持されます。
この性質はデータ整合性に優れますが、HDDでは書き込み位置が分散しやすく、特に頻繁に書き換えられるファイルでは断片化が進み、シーク回数の増加を招きます。

SSDの観点では状況が異なります。
SSDはNANDフラッシュの消去・書き込み単位の制約から、内部的に書き込み増大（Write Amplification）が発生します。
BtrfsのCoWは論理的に書き込み回数を増やす傾向があり、古いSSDでWAFの増加が寿命への懸念となることがあります。
ただし、Btrfsには「ssd」マウントオプションがあり、SSDのセクタサイズに合わせた書き込み最適化が可能です。
NTFSはインプレース更新のため、論理的な書き込み量は少なく見えますが、ジャーナルの同期的書き込みやMFTの更新も細かく発生し、結果的にSSDコントローラへの負担は無視できません。

長期運用時のフラグメンテーションと整理機能の比較

NTFSは長期運用に伴い、ファイルの追加・削除・更新が繰り返されることで断片化が進行します。
特にボリュームの空き容量が少ない状態では、連続した空きブロックが確保できず、ファイルが複数の断片に分割されて記録されることが増えます。
HDDでは断片化がシーク時間の増加を直接招くため、Windowsのデフラグツールによる定期的な整理が有効です。
ただし、古いPCでデフラグ処理中はI/Oが専有され、他の作業が滞ります。
SSDでは断片化がアクセス速度に与える影響は小さいため、デフラグは不要どころか寿命を縮める可能性があります。

BtrfsもCoWの性質上、時間の経過とともに断片化は避けられません。
特に仮想ディスクイメージやデータベースのようなランダム書き込みが多いファイルでは、ブロックが随時新しい場所に書き込まれるため、読み込み時のヘッド移動やランダムアクセスが増加します。
Btrfsには「autodefrag」マウントオプションがあり、バックグラウンドで断片化を緩和しますが、古いHDDではこの再書き込み処理自体がI/O負荷を増大させることがあります。
SSDではautodefragの恩恵は限定的です。

長期運用における整理の考え方も両者で異なります。
NTFSはデフラグで「物理的な連続配置」を目指しますが、Btrfsは「バランシング」によってチャンクの使用率を均等化し、空き領域の連続性を確保することで間接的にI/O効率を維持しようとします。
古いPCでHDDを使い続ける場合、NTFSはデフラグの実行タイミングを計画的に設けることで、日常の応答性を確保できます。
Btrfsではautodefragを有効にするか、手動でのデフラグを低負荷な時間帯に行う運用が現実的です。

ディスクI/Oの観点から見れば、NTFSとBtrfsはいずれも古いPCでは注意が必要です。
HDD搭載機ではNTFSのデフラグ計画と空き容量の確保が、BtrfsではCoWによる断片化への事前対策が応答性を左右します。
SSDでは書き込みパターンの違いが寿命と速度のバランスに関わるため、ファイルシステムごとの最適化オプションを理解した上での選定が求められます。

実際の古いPCテストから導くNTFSとBtrfsの使い分け方

これまでNTFSとBtrfsのCPU負荷、メモリ消費、ディスクI/Oの違いを整理してきました。
ここからは、実際の古いPCを再利用する場面で、どちらを選ぶべきかという実用的な結論に踏み込みます。
結論から申し上げると、どちらが絶対的に優れているかではなく、維持するOSとハードウェア構成、そして用途に応じた選択が重要です。

Windowsを維持する場合のファイルシステム選択の結論

古いPCでWindowsを引き続き使用する場合、NTFS以外の選択肢は事実上ありません。
WindowsのシステムパーティションとしてBtrfsを利用するにはサードパーティ製ドライバに依存することになり、古いPCではそのオーバーヘッドと安定性の懸念が大きすぎます。
したがって、Windows環境ではNTFSを標準として採用し、その負荷を運用で抑えるのが現実的な道です。

Windowsを維持する場合のポイントは以下の通りです。

• メモリ増設を優先する：NTFSのキャッシュ機構はメモリに依存するため、2GBから4GBの機器では可能であれば4GBまたは8GBへの増設が最も効果的な対策です
• 8.3ファイル名生成と最終アクセス時刻更新を無効化する：前述の通り、これらの設定変更はMFTとジャーナルの負荷を軽減します
• NTFS圧縮は慎重に：古いCPUでは圧縮・解凍のコストが無視できません。空き容量に余裕があるなら無効にするのが無難です
• SSDならデフラグを停止、HDDなら計画的に実行する：SSDではWindowsの自動デフラグを無効化し、HDDでは空き時間にデフラグを行う運用が推奨されます

Linuxへ移行する場合のBtrfs推奨構成と注意点

古いPCをLinuxに移行させる場合、Btrfsは有力な選択肢です。
特にUbuntuやFedoraなど主要ディストリビューションでサポートが進んでおり、スナップショットによるシステム保護や、圧縮による容量節約が期待できます。
ただし、古いハードウェアではデフォルト設定のままでは負荷が大きいため、マウントオプションの調整が前提となります。

Linux移行時のBtrfs推奨構成は以下の通りです。

• 圧縮はzstd:1または無効に：古いCPUでは「compress=zstd:1」であっても負荷がかかります。テキストデータ中心の用途なら有効ですが、既に圧縮されたメディアが多い場合は圧縮自体を無効にする判断も有りです
• autodefragはSSDで有効、HDDでは慎重に：SSDでは断片化の緩和に有効ですが、HDDではバックグラウンド書き込みがI/O負荷を増大させるため、無効にして手動デフラグを低負荷時間帯に行う方が安全です
• サブボリュームは最小限に：「@」と「@home」の2つ程度に抑え、メタデータのメモリ消費を抑制します。スナップショットも古いものは適宜削除し、ツリーの肥大化を防ぎます
• スクラビングの頻度を下げる：月に一度程度に抑え、実行中は重い作業を避ける運用が現実的です

デュアルブートやデータ共有を考慮した実用的な運用方法

古いPCをデュアルブート構成にする場合、WindowsとLinux間でのデータ共有が必要になることがあります。
この際、BtrfsパーティションをWindowsから直接読み書きすることは推奨されません。
サードパーティドライバの信頼性と、古いPCにおける追加のCPU負荷がネックとなります。

実用的なアプローチは以下の通りです。

• 共有データ領域はNTFSでフォーマットする：WindowsとLinuxの両方から安定して読み書きできるため、文書やメディアの共有領域として最も無難です。Linux側ではntfs-3gドライバでマウントします
• Linuxシステム領域はBtrfs、Windowsシステム領域はNTFS：それぞれのOSの標準ファイルシステムを採用し、相互のシステムパーティションは原則として読み取り専用または非マウントにしておくのが安全です
• 外付けHDDやUSBメモリはexFATを検討：デュアルブート間で外付けストレージを頻繁にやり取りする場合、exFATは両OSでネイティブに読み書きでき、ファイルサイズ制限も緩やかです。ただしジャーナリングがないため、必ず安全な取り外しを徹底します

古いPCのファイルシステム選びは、理想論ではなくハードウェアと用途の現実との折り合いです。
Windowsを維持するならNTFSの最適化に注力し、Linuxへ移行するならBtrfsの設定を丁寧に調整することが、限られたリソースの中で最も実用的な応答性を引き出す近道です。

まとめ：古いPCのファイルシステム選びでシステム負荷を抑えるポイント

古いPCを再利用する際、ファイルシステムの選定はOSやハードウェアの選定と同等か、それ以上に応答性を左右する重要な判断です。
NTFSとBtrfsはそれぞれ異なる設計思想に基づき、CPU負荷、メモリ消費、ディスクI/Oの面で異なる特性を示します。
結論として、どちらが絶対的に優れているかではなく、維持するOSとハードウェア構成、そして用途に応じた選択と運用の調整が、古いPCの限られたリソースを最大限に活かす鍵となります。

NTFSはWindows環境において事実上の標準であり、長年の実績と互換性が強みです。
ジャーナリングとMFTによるメタデータ管理は安定した動作を支えますが、古いPCではキャッシュの肥大化やジャーナル書き込みによるI/O負荷が無視できません。
Windowsを継続して使用する場合は、NTFSのまま運用しつつ、8.3ファイル名生成の無効化や最終アクセス時刻更新の停止、メモリ増設、そしてSSDとHDDに応じたデフラグ戦略によって負荷を抑制するのが現実的です。
特にメモリが4GB以下の環境では、NTFSのキャッシュ機構がアプリケーション領域を圧迫しやすいため、可能であれば増設を優先的に検討すべきです。

BtrfsはLinux環境で次世代ファイルシステムとして高い評価を得ており、スナップショットや圧縮、チェックサムなどの先進機能を備えます。
しかし、コピーオンライトによる断片化や、チェックサム・圧縮処理によるCPU負荷、Bツリー管理のメモリ消費は古いハードウェアでは注意が必要です。
Linuxへ移行する場合は、圧縮レベルの調整、サブボリュームの最小化、スクラビング頻度の抑制など、マウントオプションと運用方針を丁寧に設計することが求められます。
古いCPUではZSTD圧縮を無効にする判断も有りであり、機能の豊富さとリソース消費のトレードオフを常に意識する必要があります。

デュアルブート構成を検討する場合も、相互のシステムパーティションを直接読み書きすることは避け、共有データ領域はNTFSやexFATで確保するのが無難です。
ファイルシステムの越境利用は古いPCでは追加のドライバ負荷と安定性の懸念を招き、結果的に応答性を損なう原因となります。

最終的に、古いPCのファイルシステム選びで最も大切なのは、デフォルト設定のまま任せることの回避です。
NTFSもBtrfsも、現代の高性能PCを前提に設計された機能が含まれており、古いハードウェアではその恩恵よりオーバーヘッドが目立つことがあります。
自分のPCのスペックと用途を冷静に見極め、必要な機能だけを有効にし、不要なバックグラウンド処理を抑制することで、クローゼットの奥から蘇ったマシンも、十分に実用的な相棒として活躍します。
ファイルシステムという見えにくい層への配慮が、古いPCの再利用を成功へと導く、ひとつの確かな判断材料となるでしょう。