Linux ストレージスタック：物理ディスク、ファイルシステム、起動まで

1. ストレージ全体の流れ

#

Linux で一つのファイルをディスクから読むまでには、通常、次の層を通ります。

物理メディア
  ↓
ブロックデバイス：/dev/sda、/dev/nvme0n1
  ↓
パーティションテーブル：GPT または MBR
  ↓
パーティション：/dev/sda1、/dev/sda2、/dev/sda3
  ↓（必要な場合）
暗号化：LUKS / device-mapper
  ↓（必要な場合）
LVM：PV → VG → LV
  ↓
ファイルシステム：ext4、Btrfs、XFS、FAT32 など
  ↓
マウントポイント：/、/boot、/home、/mnt/data
  ↓
ファイル、ディレクトリ、inode、権限、タイムスタンプ

各層の役割を短くまとめると、次のようになります。

LVM はファイルシステムではありません。 ext4 や Btrfs がファイルを管理し、LVM はその下にあるブロックデバイスを提供します。

2. ブロックデバイス：なぜ /dev/sda を直接マウントできないのか

#

Linux はディスク、パーティション、LVM の論理ボリュームをブロックデバイスとして表します。SATA や USB ディスクでは、次のような名前になります。

/dev/sda       ディスク全体
/dev/sda1      1 番目のパーティション
/dev/sda2      2 番目のパーティション
/dev/sda3      3 番目のパーティション

NVMe は別の命名規則です。

/dev/nvme0n1       NVMe ディスク全体
/dev/nvme0n1p1     1 番目のパーティション
/dev/nvme0n1p7     7 番目のパーティション

最初に実行する確認コマンドは次のとおりです。

lsblk -o NAME,PATH,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,RO,RM
sudo blkid
sudo fdisk -l

lsblk はデバイスの階層、blkid はファイルシステムやストレージの署名、fdisk -l はパーティションテーブルを中心に表示します。

/dev/sda       disk
├─/dev/sda1    part  vfat
├─/dev/sda2    part  ext4
├─/dev/sda3    part  LVM2_member
└─/dev/sda4    part  BIOS boot

/dev/sda の最外層には GPT などのパーティションテーブルがあるため、次の操作は通常失敗します。

sudo mount /dev/sda /mnt

直接マウントできるのは、通常、ファイルシステムを含むデバイスです。/dev/sda3 が LVM2_member なら、LVM の層を通して論理ボリュームを見つける必要があります。

3. GPT、MBR、ファイルシステム署名を分けて考える

#

3.1 パーティションテーブルの役割

#

パーティションテーブルは次の情報を記録します。

• パーティションの開始・終了セクター
• パーティションの種類
• パーティション UUID
• パーティション名と属性

主な方式は次の二つです。

MBR / DOS partition table
GPT / GUID Partition Table

MBR はパーティション数やアドレス範囲に歴史的な制限があります。GPT は通常、より大きなディスク、より多くのパーティション、先頭と末尾のバックアップ、CRC による検査を扱いやすくします。

ただし、次の二つは別の情報です。

GPT のパーティション種別：Linux filesystem
内部の実際の署名：LVM2_member

前者は GPT 上の役割、後者は内部で使われているストレージ層を表します。

3.2 パーティション方式とファームウェア方式

#

パーティション方式とファームウェアの起動方式は別の軸です。

新しい Linux のインストールでは UEFI + GPT が一般的ですが、「GPT は UEFI そのもの」ではありません。GPT はディスク上の配置、UEFI はファームウェアが起動プログラムを見つけて実行する方法です。

3.3 ESP と BIOS Boot Partition

#

UEFI は通常、FAT32 の ESP から .efi プログラムを読み込みます。

EFI/
├── BOOT/BOOTX64.EFI
├── ubuntu/shimx64.efi
└── Microsoft/Boot/bootmgfw.efi

GPT ディスクを Legacy BIOS で起動する場合、GRUB の埋め込みコード用に、ファイルシステムを持たない BIOS Boot Partition が必要になることがあります。

ESP                  UEFI が読む FAT32 パーティション
BIOS Boot Partition  BIOS モードの GRUB 用。通常はファイルシステムなし

4. ファイルシステム：ブロックをファイルへ変える仕組み

#

ファイルシステムがなければ、ディスクは番号付きのブロックの集合にすぎません。ファイルシステムは次を管理します。

• ファイル名とディレクトリの関係
• inode などのメタデータ
• ファイル内容と空き領域
• 所有者、権限、タイムスタンプ
• journal、チェックサム、スナップショットなどの整合性機能

4.1 ext4

#

ext4 は成熟した Linux ファイルシステムです。inode、journal、extent、Unix 権限、e2fsck による検査と修復を備えています。

LVM 上のルートファイルシステムは、たとえば次のようになります。

/dev/sda3
└─ LVM PV
   └─ ubuntu-vg
      └─ ubuntu-lv
         └─ ext4
            └─ /

4.2 Btrfs

#

Btrfs は Copy-on-Write を採用した比較的新しい Linux ファイルシステムです。サブボリューム、スナップショット、データとメタデータのチェックサム、マルチデバイス、圧縮、scrub、オンライン拡張・縮小などを提供します。

Btrfs 自身にボリューム管理に近い機能があるため、LVM と重ねるかどうかは、暗号化、運用、バックアップ方式などに応じて決めます。

4.3 FAT32

#

FAT32 は互換性が高く、ESP でよく使われます。ext4 のような inode や journal はなく、Unix の所有者・権限を保存するためのファイルシステムでもありません。

FAT の内部には boot sector と backup boot sector があります。これは GPT のパーティションテーブル、MBR の起動コード、GRUB のファイルとは別のものです。

5. LVM：PV、VG、LV

#

通常のパーティションは直接ファイルシステムを載せます。

パーティション → ext4

LVM を使うと、間に柔軟な容量管理の層が入ります。

パーティション → PV → VG → LV → ext4

5.1 PV：Physical Volume

#

PV は LVM に渡す物理領域です。パーティション、ディスク全体、別のブロックデバイスなどを使えます。

sudo pvcreate /dev/sda3
sudo pvs
sudo pvdisplay

「Physical」という名前でも、必ずしもディスク全体を意味しません。

5.2 VG：Volume Group

#

VG は一つ以上の PV から作る容量プールです。

sudo vgcreate ubuntu-vg /dev/sda3
sudo vgs
sudo vgdisplay

VG に free space が残っている場合、それは LV にまだ割り当てていない領域です。容量が壊れて失われたとは限りません。

5.3 LV：Logical Volume

#

LV は VG から切り出した論理ブロックデバイスです。ファイルシステムから見ると、通常のパーティションに近い存在です。

sudo lvcreate -n data -L 100G ubuntu-vg
sudo lvs
sudo lvdisplay

同じ LV は通常、次の二つの名前で見えます。

/dev/ubuntu-vg/ubuntu-lv
/dev/mapper/ubuntu--vg-ubuntu--lv

/dev/mapper では、元の名前に含まれる - が -- としてエスケープされます。

5.4 extent

#

LVM は任意のバイト単位ではなく、extent という固定サイズの単位で容量を管理します。

Physical Extent（PE）
Logical Extent（LE）

LV の作成、拡張、移動は、これらの小さな単位を割り当て直す操作だと考えられます。

5.5 VG の有効化と無効化

#

救援環境で PV は見えているのに LV が見えない場合、VG が無効化されている可能性があります。

sudo vgscan
sudo vgchange -ay ubuntu-vg
lsblk

-a は activation、-y は有効化を表します。無効化する場合は次のようにします。

sudo umount /mnt
sudo vgchange -an ubuntu-vg

ディスク全体を QEMU や別の OS に渡す前に、ホスト側でファイルシステムがマウントされていないこと、二つの OS が同じファイルシステムへ同時に書き込まないことを確認してください。

6. マウント、UUID、/etc/fstab

#

Linux には Windows の C: や D: のような固定ドライブレターはありません。マウントとは、ファイルシステムを一つのディレクトリツリーへ接続することです。

sudo mkdir -p /mnt/data
sudo mount /dev/ubuntu-vg/data /mnt/data
findmnt /mnt/data
sudo umount /mnt/data

デバイス名は抜き差しの順番で変わることがあります。

/dev/sda2  →  /dev/sdb2 になる可能性がある

そのため、/etc/fstab では UUID を使うことが多いです。

UUID=ca53b6c9-3366-4bbd-a909-d10b89ed7a18  /boot  ext4  defaults  0  2

UUID の確認：

lsblk -f
sudo blkid

fstab を変更したら、再起動する前に確認します。

sudo findmnt --verify
sudo mount -a

7. 安全なディスク障害切り分け

#

最初からフォーマットや修復を実行せず、低リスクの読み取りから始めます。

7.1 デバイスとマウント状態

#

lsblk -e7 -o NAME,PATH,SIZE,TYPE,FSTYPE,FSVER,LABEL,UUID,MOUNTPOINTS,RO,RM
sudo blkid
findmnt

確認するのは、デバイスが認識されているか、どの層にいるか、何の署名があるか、どこへマウントされているかです。

7.2 パーティションテーブル

#

sudo fdisk -l /dev/sda
sudo gdisk -l /dev/sda

パーティションの境界、種類、GPT の検査結果を確認します。

7.3 LVM

#

sudo pvs
sudo vgs
sudo lvs -a -o +devices

必要な場合だけ、スキャンと VG の有効化を行います。

sudo vgscan
sudo vgchange -ay

7.4 マウントしていない状態でファイルシステムを検査

#

ext4：

sudo e2fsck -f -n /dev/ubuntu-vg/ubuntu-lv

-n は修復内容をディスクへ書き込まないため、初期診断に向いています。ext4 の五つの段階は、inode、ディレクトリ、連結性、参照数、ブロックグループの要約などを確認します。

FAT32：

sudo fsck.fat -n /dev/sda1

Dirty bit is set は、前回正常にアンマウントされなかった可能性を示すフラグです。停電、クラッシュ、強制終了、直接の抜去などで発生しますが、直ちに不良セクターを意味するわけではありません。

Btrfs：

sudo btrfs filesystem show
sudo btrfs filesystem usage /mountpoint
sudo btrfs scrub start -Bd /mountpoint

マウント中のファイルシステムに対して、意味を理解しないまま破壊的な検査や修復を行わないでください。

7.5 ディスクの健康状態

#

sudo smartctl -x /dev/sda
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

長時間テストを行う場合：

sudo smartctl -t long /dev/sda

まずバックアップを取り、その後にテストします。SMART はリスクを知らせる仕組みであり、将来の突然死を保証するものではありません。

7.6 起動状態

#

test -d /sys/firmware/efi && echo UEFI || echo Legacy-BIOS
cat /proc/cmdline
ls -l /boot
sudo efibootmgr -v
journalctl -b -p warning

現在のファームウェア方式、カーネルコマンドライン、カーネルと initramfs、UEFI の起動項目、今回の起動時の警告を確認できます。

8. fsck の出力を読む

#

ext4 の次のような表示は、必ずしも重大な破損を意味しません。

Inode ... extent tree could be shorter.

extent のインデックスをより短くできるという最適化の提案です。

Warning: skipping journal recovery because doing a read-only filesystem check.

-n によって書き込みが禁止されているため、journal を再生していないという意味です。journal が壊れたという意味ではありません。

1.4% non-contiguous

非連続に配置されたファイルの割合を示す情報であり、エラーコードではありません。数値だけを見て、すぐに整理処理を実行する必要はありません。

inode の使用量とディスク容量は別の制限です。大量の小さなファイルを保存する環境では、容量が残っていても inode を使い切ることがあります。

9. SMART、ベンチマーク、バックアップを分ける

#

三つの問いは別々です。

SMART       ディスクに健康上のリスクがあるか
benchmark   特定の負荷でどの程度速いか
backup      壊れた場合にデータを戻せるか

代表的な SMART 属性：

UDMA_CRC_Error_Count はケーブル、コネクター、変換アダプター、電源などを示すことが多く、プラッタの不良セクターと直接同じではありません。現在値、最悪値、しきい値、RAW_VALUE、増加傾向を組み合わせて判断します。

機械ディスクでは温度、起動停止回数、ヘッドのロード回数にも注意します。SMART PASSED はメーカーのしきい値を超えていないという意味であり、突然の故障を否定するものではありません。

10. ストレージ性能：スループット、遅延、IOPS、キャッシュ

#

10.1 Throughput

#

Throughput（スループット）は通常 MB/s または MiB/s で表し、大きなファイルの連続読み書きやバックアップに向いています。

MB  = 10^6 bytes
MiB = 2^20 bytes
Gbps = gigabits per second
GB/s = gigabytes per second

Gbps と GB/s は別の単位です。bit と byte の違いがあるため、換算時には 8 で割る必要があります。

10.2 Latency

#

Latency（遅延）は一つの I/O 要求が完了するまでの時間です。機械ディスクではヘッドのシークと回転待ちがあるため、小さなランダムアクセスは SSD より大幅に遅くなります。

10.3 IOPS

#

IOPS は 1 秒あたりに完了できる I/O の数です。4 KiB random I/O のような小さい要求では、MB/s より IOPS と遅延のほうが体感速度を説明しやすいことがあります。

10.4 キャッシュ

#

結果には OS の page cache、SSD の SLC/MLC キャッシュ、ディスク内キャッシュ、USB 変換アダプターなどが影響します。短時間だけ高い速度が出ても、長時間の書き込みで同じ速度を維持できるとは限りません。

fio を使った 4 KiB random、並列処理、キュー深度、結果の読み方については、リポジトリの How fast are your disks? を参照してください。

安全のため、ベンチマークは原始デバイスではなくテストファイルに対して実行します。

mkdir -p /tmp/fio-test
cd /tmp/fio-test
fio --name=read-test \
  --filename=./fio-testfile \
  --size=1G \
  --rw=randread \
  --bs=4k \
  --iodepth=1 \
  --numjobs=1 \
  --runtime=30 \
  --time_based \
  --direct=1

この例でも容量と I/O を消費するので、対象のファイルシステムと空き容量を確認してから実行します。

11. 起動チェーン：ファームウェアから systemd まで

#

電源投入
  ↓
CPU がリセットされ、ファームウェアを実行
  ↓
BIOS または UEFI が起動項目を選ぶ
  ↓
GRUB などの bootloader
  ↓
Linux kernel + initramfs
  ↓
デバイス検出、復号、LVM 有効化、ルートのマウント
  ↓
本来のルートファイルシステムへ切り替え
  ↓
systemd とユーザー空間サービス

UEFI の場合：

UEFI
→ ESP の .efi プログラム
→ shim または GRUB
→ kernel と initramfs
→ ルートファイルシステム

Legacy BIOS の場合：

BIOS
→ ディスク先頭セクターの起動コード
→ GRUB の埋め込みコードまたは core.img
→ /boot/grub のモジュールと設定
→ kernel と initramfs

GRUB の Stage 1、Stage 1.5、Stage 2 は理解の助けになる歴史的な説明です。すべての GRUB 2 インストールに三つの固定ファイルがあるという意味ではありません。UEFI モードの GRUB は通常、EFI プログラムとして直接読み込まれます。

root が LVM 上にある場合、initramfs は次の仕事をします。

ディスクを発見
→ PV をスキャン
→ VG を有効化
→ LV を発見
→ 本来の / をマウント

その後、実際のルートファイルシステムにある systemd へ処理が移ります。

12. QEMU で実ディスクの起動を切り分ける

#

古い PC の画面、メモリ、マザーボードに問題がありそうな場合、別の Linux マシンから実ディスクを QEMU で読ませ、システムディスク自体が起動できるかを分離して確認できます。

qemu-system-x86_64 \
  -name disk-inspection \
  -machine pc \
  -accel kvm \
  -cpu host \
  -m 2048 \
  -smp 2 \
  -drive file=/dev/sda,format=raw,if=ide \
  -snapshot \
  -boot menu=on \
  -vga std \
  -nic none \
  -display gtk \
  -no-reboot

特に重要なのは次のパラメーターです。

• file=/dev/sda：実ディスク全体をゲストのディスクとして読む
• format=raw：qcow2 のコンテナではなく生のブロックデバイスである
• -snapshot：ゲストの書き込みを一時的なオーバーレイへ送る
• -nic none：テスト中にネットワークへ接続しない
• -accel kvm：ゲスト CPU の実行をハードウェア支援で高速化する

これはディスクをコピーするのではなく、QEMU が元の GPT、GRUB、/boot、kernel、initramfs、LVM、ルートファイルシステムを読む実験です。

12.1 権限と GUI

#

sudo qemu-system-x86_64 -display gtk のように、QEMU 全体を root で起動するのは適切とは限りません。root のプロセスが Wayland/X11 の現在のユーザーセッションへ接続できず、GUI 初期化に失敗することがあります。

よりよい流れは次のとおりです。

1. ホスト側で元ディスクのファイルシステムがマウントされていないことを確認する
2. 普通のユーザーに一時的な読み書き権限を与える、または適切なデバイスグループ・udev ルールを使う
3. 普通のユーザーとして QEMU を実行する
4. -snapshot と -nic none を優先する

/dev/sda へ直接付けた ACL は、デバイスノードが udev によって再作成されるため、ディスクの抜き差し後も残るとは限りません。

12.2 QEMU で分かること

#

QEMU で元の OS が起動できれば、通常は次を確認できます。

• GPT または MBR を読み取れる
• GRUB が動作する
• /boot、kernel、initramfs を読める
• LVM をスキャンして有効化できる
• ルートファイルシステムをマウントできる
• systemd とユーザー空間を起動できる

一方、元の PC の LCD、ディスプレイケーブル、メモリスロット、映像出力、電源回路までは検査していません。元 PC が白画面でも、実ディスクを QEMU で起動できるなら、次は画面系とハードウェアを重点的に調べるべきです。

13. 再利用できる障害切り分けリスト

#

1. lsblk / blkid：デバイスは認識されているか
2. fdisk / gdisk：パーティションテーブルは正常か
3. pvs / vgs / lvs：LVM の層はそろっているか
4. findmnt / fstab：実際にどこへマウントされているか
5. fsck：アンマウント状態で整合性を検査する
6. smartctl：健康上の兆候とエラーの傾向を見る
7. fio：テストファイルに対して制御された性能測定を行う
8. efibootmgr / journalctl：起動方式と起動時のエラーを見る
9. QEMU：システムディスクと元 PC の故障を分離する
10. backup：修復や長時間テストの前にデータを守る

この順序は層を一つずつ切り分ける方法です。まずデバイスの存在、次に構造、ファイルシステム、ディスクの健康、最後に起動チェーンと外部ハードウェアを確認します。SMART PASSED だけを理由にバックアップを省略したり、fsck の警告だけでディスクをフォーマットしたりしないでください。

14. 各層を一言でまとめる

#

/dev/sda        ディスク全体
GPT / MBR       パーティションの配置
/dev/sda3       一つのパーティション
PV              LVM に渡した物理領域
VG              LVM の容量プール
LV              プールから切り出した論理ブロックデバイス
ext4 / Btrfs    ファイルとディレクトリを管理するファイルシステム
mount           ファイルシステムをディレクトリツリーへ接続する
UUID / fstab    安定した識別と自動マウント
fsck            ファイルシステムの整合性を検査する
SMART           ディスク内部の健康状態を観察する
fio             ワークロードに沿って性能を測定する
GRUB            起動プログラムや kernel を選んで読み込む
initramfs       起動初期に LVM を有効化してルートをマウントする
QEMU            実ディスクを仮想ハードウェアで検査する
KVM             仮想 CPU の実行を高速化する

一文だけ覚えるなら、次のとおりです。

パーティションテーブルは空間の切り方を決め、LVM はブロックデバイスの組み合わせを決め、ファイルシステムはファイルの整理方法を決め、マウントはディレクトリツリーへ接続し、起動チェーンは各層を順番に起動へつなげます。

関連する個別記事：

• ファイルシステムとボリュームの関係
• ディスク関連：ボリュームと LVM
• MBR と GPT パーティションの簡単なまとめ
• Linux の起動フロー：ファームウェア、パーティション、GRUB からカーネルまで
• How fast are your disks?