ファイルシステム

なぜ必要か：生のディスクは扱えない

HDD や SSD を OS から見ると、それは 固定サイズのブロックが連番で並んだ巨大な配列 にすぎません。「3番目のブロックから始まる、長さ12KBのまとまりが report.pdf だ」という対応づけは、ディスク自身は知りません。

この「どのブロックが、どのファイルの、何番目か」を管理し、人間に 名前・フォルダ・サイズ・更新日時 として見せる翻訳装置がファイルシステムです。

• ファイル = 名前のついたバイト列（中身そのものは構造を問わない）
• ディレクトリ = ファイル名と実体を結びつける「対応表」。それ自体も特殊なファイル

仕組み：ブロック・inode・メタデータ

多くの Unix 系ファイルシステムは、ファイルを 2つに分けて 管理します。

[ ディレクトリエントリ ]      [ inode ]              [ データブロック ]
  "report.pdf" → inode 1234 → サイズ/所有者/日時 → #305, #306, #307 ...
  "memo.txt"   → inode 2087 → 権限/リンク数 ...   → #842, #843 ...

• データブロック：ファイルの中身そのもの。固定サイズ（例：4KB）の単位で格納する。
• inode（アイノード）：1ファイルにつき1つの メタデータの入れ物。サイズ・所有者・権限・タイムスタンプ・そして 中身がどのブロックにあるか を持つ。
• メタデータ：データ「について」の情報。inode に入る情報の総称。

注目すべきは、ファイル名は inode に入っていない こと。名前は「ディレクトリエントリ」側にあり、inode 番号を指すだけです。この分離が、ハードリンク（同じ実体に複数の名前）やリネームの高速さ（実体は動かさず対応表だけ書き換える）を生みます。

パスとマウント：1本の木にまとめる

ファイルへの住所が パス です。Unix 系は単一のツリーで、すべてが /（ルート）から始まります。

/home/alice/report.pdf   ← 絶対パス（ルートからたどる）
./report.pdf             ← 相対パス（今いる場所から）

複数のディスクやパーティション、USB メモリなどを、この1本の木の どこかの枝（ディレクトリ）に接ぎ木する 操作が マウント です。例えば外付けドライブを /mnt/usb にマウントすると、以降 /mnt/usb/... でその中身にアクセスできます。

• Unix 系：すべてが1つのツリーに統合される（マウントポイント方式）
• Windows：C:・D: のように ドライブごとに別ツリー を持つ

ジャーナリング：電源断からの保護

ファイルの書き込みは、たいてい 複数の更新の組み合わせ（データブロック＋inode＋空き領域管理…）です。この途中で電源が落ちると、中途半端な状態＝ファイルシステムの破損 になりかねません。

ジャーナリング は、本番の更新前に「これからこう書く」という計画を ジャーナル（ログ）領域に先に記録 する仕組みです。途中でクラッシュしても、再起動時にログを見て やり直す／取り消す ことで、矛盾のない状態に復旧できます。

代表例：ext4 / NTFS / APFS

同じ「ファイルシステム」でも、実装ごとに設計思想と機能が違います。

ポイントは アプローチの違い。ext4 と NTFS は「上書きしながらジャーナルで守る」古典的な堅実派。一方 APFS や Btrfs/ZFS は CoW（コピーオンライト） ＝既存データを上書きせず別の場所に書いてから参照を切り替える方式で、スナップショットや破損耐性を得意とします。

つまずきポイント

• 削除＝即消滅ではない：ファイルを消しても、多くの場合 ディレクトリエントリとinodeの参照を外すだけ で、データブロックの中身はしばらく残る。だから復元ツールが成立する。
• 「容量はあるのに保存できない」：データブロックに空きがあっても、inode を使い切る と新規ファイルを作れない（小さなファイルが大量にあると起きやすい）。
• ブロックサイズと無駄：1ブロックが4KBなら、1バイトのファイルでも 4KBを占有 する（内部断片化）。小さいファイルが大量だと「実サイズ＜ディスク使用量」になる。

まとめ

• ファイルシステムは、生のブロック配列 を「ファイル・ディレクトリ」という人間向けの抽象に翻訳する層。
• 中身（データブロック） と 情報（メタデータ／inode） は分離されており、ファイル名は実体ではなく対応表側にある。
• 電源断対策が ジャーナリング、近年は CoW 方式（APFS など）も主流に。ストレージそのものをどう見せるかは 仮想メモリ と同じく「OSが作る巧妙な抽象」の好例です。