Linuxサーバーの設計・運用において、ストレージ管理は可用性と拡張性を左右する極めて重要な基盤領域です。LinuCレベル2（201試験）の主題2.02「ファイルシステムとデバイス」では、物理ディスクの初期化からファイルシステムのチューニング、ソフトウェアRAIDによる冗長化、そしてLVM（Logical Volume Manager）を用いた動的な容量管理まで、多層的なストレージアーキテクチャへの理解が求められます。
特に記述式問題（コマ問）では、ファイルシステムごとのコマンド構文の違い（resize2fsとxfs_growfsの引数指定の差異など）や、mdadmによるアレイ操作のオプション、LVMの階層（PV・VG・LV）に応じたコマンドの使い分けが頻出します。本記事では、AlmaLinux 9の実機検証ログに基づき、各技術の内部挙動と運用保守の手順を体系的に整理して解説します。
- ホスト名: linuc-node01 (192.168.2.138)
- OS: AlmaLinux 9.8 (x86_64)
- カーネル: 5.14.0-570.el9.x86_64
- ストレージ管理ツール: mdadm 4.2 / lvm2 2.03 / e2fsprogs 1.46.5 / xfsprogs 5.14.0
| 公式試験の必須出題範囲 | 主題2.02.1（マウント・/etc/fstab）、主題2.02.2（ext4/xfs/btrfs管理・tune2fs）、主題2.02.3（LVMボリューム管理・スナップショット） |
|---|---|
| 現場で役立つ実務拡張 | ソフトウェアRAID（mdadm）によるディスク冗長化と障害復旧実証（※現行試験範囲外ですが現場のストレージ下層設計に直結する必須技術） |
目次
1. ファイルシステムの基本操作と保守（ext4 vs XFS）
近年のエンタープライズLinux環境では、デフォルトファイルシステムとして採用されているXFSと、従来の標準であり細かな制御が可能なext4の双方が広く使われています。LinuC 201試験では、両者の設計思想の違いや、それぞれの専用保守コマンドの役割を明確に区別して解答する必要があります。
1.1 ext4ファイルシステムの作成とtune2fsによるチューニング
ext4ファイルシステムは、mkfs.ext4（またはmke2fs -t ext4）コマンドで作成します。作成時には、ボリュームラベル（-L）やブロックサイズなどを指定できます。
$ sudo mkfs.ext4 -F -L myext4 /dev/loop0
mke2fs 1.46.5 (30-Dec-2021)
Discarding device blocks: 0/131072 done
Creating filesystem with 131072 4k blocks and 32768 inodes
Filesystem UUID: eaf40854-19ce-4587-8e23-b80b9762a785
Superblock backups stored on blocks:
32768, 98304
Allocating group tables: 0/4 done
Writing inode tables: 0/4 done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: 0/4 done作成されたext4ファイルシステムの内部構造やチューニングパラメータは、tune2fs -lコマンドで確認します。スーパーブロック内に記録されたinode総数、ブロック総数、予約ブロック数などが表示されます。
$ sudo tune2fs -l /dev/loop0 | head -n 22
tune2fs 1.46.5 (30-Dec-2021)
Filesystem volume name: myext4
Last mounted on: <not available>
Filesystem UUID: eaf40854-19ce-4587-8e23-b80b9762a785
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 32768
Block count: 131072
Reserved block count: 6553
Overhead clusters: 6347
Free blocks: 124719
Free inodes: 32757
First block: 0
Block size: 4096ext4では、rootユーザー用に一定のストレージ領域が「予約ブロック」として確保されています。デフォルトではディスク全体の5%が予約されますが、大容量ディスク（数TB〜数十TB）において5%の予約は過大となるため、tune2fs -mオプションで予約割合を1%などに引き下げることが実務上一般的です。
# 予約ブロック率を 1% に変更し、最大マウント回数を 30回 に設定
$ sudo tune2fs -m 1 -c 30 /dev/loop0
tune2fs 1.46.5 (30-Dec-2021)
Setting maximal mount count to 30
Setting reserved blocks percentage to 1% (1310 blocks)
# 変更結果の確認
$ sudo tune2fs -l /dev/loop0 | grep -E "Reserved block count|Maximum mount count|Reserved blocks percentage"
Reserved block count: 1310
Reserved blocks percentage: 1%
Maximum mount count: 30試験対策としては、以下のtune2fsオプションを確実に押さえておく必要があります。
| オプション | 設定項目 | 実務・試験での要点 |
|---|---|---|
-m <パーセント> |
予約ブロック率 | デフォルトは5%。大容量データ領域では1%程度へ縮小する |
-c <回数> |
最大マウント回数 | 指定回数マウントされると次回起動時にfsckが走る（0または-1で無効化） |
-i <日数> |
チェック間隔日数 | 最終チェックからの経過日数を指定（0で無効化、180dや6m等） |
-L <ラベル名> |
ボリュームラベル | e2label <device> <label>と同等 |
-U <UUID> |
UUID変更 | randomを指定するとランダムな新規UUIDを生成 |
-o <マウントオプション> |
デフォルトマウント設定 | aclやuser_xattrなどをファイルシステム自体に恒久設定可能 |
1.2 XFSファイルシステムの特性とxfs_admin・xfs_infoによる情報取得
XFSは大規模データや並列I/Oに最適化された64ビットファイルシステムです。内部がアロケーショングループ（AG: Allocation Group）と呼ばれる独立した論理領域に分割されており、複数のCPUコアが各AGに対してロック競合を起こさずに並列で割り当て処理を行える構造になっています。
# XFSファイルシステムの作成（ラベル名 myxfs）
$ sudo mkfs.xfs -f -L myxfs /dev/loop1
meta-data=/dev/loop1 isize=512 agcount=4, agsize=32768 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=1 inobtcount=1 nrext64=0
data = bsize=4096 blocks=131072, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =internal log bsize=4096 blocks=16384, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
# マウントして xfs_info を実行
$ sudo mkdir -p /mnt/test-xfs
$ sudo mount /dev/loop1 /mnt/test-xfs
$ sudo xfs_info /mnt/test-xfs
meta-data=/mnt/test-xfs isize=512 agcount=4, agsize=32768 blkstune2fs -lがアンマウント状態のブロックデバイス（例: /dev/loop0）に対して実行できるのに対し、xfs_infoは対象ファイルシステムがマウントされている状態（マウントポイントまたはマウント中デバイス）でなければ実行できません。アンマウント状態で実行するとエラーになります。
一方、アンマウント状態でラベルやUUIDを変更・確認する場合はxfs_adminを使用します。
# アンマウント後にラベルを変更
$ sudo umount /mnt/test-xfs
$ sudo xfs_admin -L "newlabel" /dev/loop1
writing all SBs
new label = "newlabel"
# ラベルの表示
$ sudo xfs_admin -l /dev/loop1
label = "newlabel"
# UUIDの再生成
$ sudo xfs_admin -U generate /dev/loop1
Clearing log and setting UUID
writing all SBs
new UUID = 5d7e6c38-8c54-4f81-a67b-1d70d2b86ea41.3 ファイルシステムチェックと修復（fsck と xfs_repair の注意点）
不正なシャットダウンやハードウェア異常によってファイルシステムに整合性エラーが生じた場合、修復ツールを実行します。ここでもファイルシステムごとに明確な使い分けが存在します。
| 対象ファイルシステム | 標準チェック・修復コマンド | 重要な制約・注意点 |
|---|---|---|
| ext4 / ext3 | fsck.ext4（または e2fsck） |
必ずアンマウント状態で実行する。クリーンと判定された場合でも強制チェックを行うには -f を付与する。対話修復には -y（全自動yes承諾）。 |
| XFS | xfs_repair |
fsck.xfsは起動時互換用ダミースクリプトであり修復を行わない。修復はxfs_repairを使用する。マウント中の実行は厳禁。ログが破損してマウント不能な場合の最終手段として -L（ログ強制消去）がある。 |
# ext4 の強制チェック（クリーン状態でも実行）
$ sudo fsck.ext4 -f /dev/loop0
e2fsck 1.46.5 (30-Dec-2021)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
myext4: 11/32768 files (0.0% non-contiguous), 6960/131072 blocks
# XFS のチェックと修復
$ sudo xfs_repair /dev/loop1
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
- scan filesystem freespace and inode maps...
Phase 3 - for each AG...
Phase 4 - check for duplicate blocks...
Phase 5 - check inode validity...
Phase 6 - check inode connectivity...
Phase 7 - verify and correct link counts...
done2. ソフトウェアRAID（mdadm）の構築と運用管理
ハードウェアRAIDカードを使用せず、LinuxカーネルのMD（Multiple Device）ドライバを利用して複数のストレージを仮想的なRAIDアレイとして束ねる技術がソフトウェアRAIDです。管理にはmdadmコマンドを使用します。
2.1 RAIDレベルの特徴とmdadmによるアレイ作成
LinuC試験では、主要なRAIDレベルの特徴と必要ディスク本数の把握が前提知識となります。
| RAIDレベル | 方式 | 最小ディスク数 | 許容障害数 | 実効容量 | 特徴 |
|---|---|---|---|---|---|
| RAID 0 | ストライピング | 2本 | 0本 | 全ディスク合計 | 高速だが耐障害性なし（1台故障で全損） |
| RAID 1 | ミラーリング | 2本 | 1本（2本構成時） | 1本分（最小ディスク容量） | 同一データを複製。耐障害性が高い |
| RAID 5 | パリティ分散 | 3本 | 1本 | (N – 1) × 最小容量 | データとパリティを均等分散。容量効率と耐障害性のバランス型 |
| RAID 6 | 二重パリティ分散 | 4本 | 2本 | (N – 2) × 最小容量 | 2台の同時故障に耐えられる高可用性構成 |
| RAID 10 | RAID 1+0 | 4本 | 各ミラーグループから1本 | 合計容量の50% | RAID 0の速度とRAID 1の冗長性を兼備 |
ここでは、実機環境で3つのブロックデバイス（/dev/loop2, /dev/loop3, /dev/loop4）を用い、「アクティブディスク2本＋スペアディスク1本」で構成されるRAID 1アレイ（/dev/md0）を構築します。
$ sudo mdadm --create /dev/md0 \
--level=1 \
--raid-devices=2 /dev/loop2 /dev/loop3 \
--spare-devices=1 /dev/loop4 --run
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.2.2 /proc/mdstatとmdadm –detailによる状態監視
構築されたアレイの稼働状況は、カーネル仮想ファイル/proc/mdstatで素早く確認できます。
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 loop4[2](S) loop3[1] loop2[0]
523264 blocks super 1.2 [2/2] [UU]
unused devices: <none>この出力には、試験で頻出する重要なステータス情報が集約されています。
| 表示項目 | 読み取り方と意味 |
|---|---|
loop4[2](S) |
(S)はスペア（Spare）デバイスを示します。loop2とloop3には記号がないためアクティブメンバーです。 |
[2/2] |
設定されたディスク本数に対する、現在アクティブなディスク本数（構成数 / 正常稼働数）。 |
[UU] |
各スロットの状態。UはUp（正常同期）。1台故障すると[_U]や[U_]となります。 |
より詳細な構成情報を確認するには、mdadm --detail（または -D）を実行します。
$ sudo mdadm --detail /dev/md0
/dev/md0:
Version : 1.2
Creation Time : Sun Sep 6 16:37:10 2026
Raid Level : raid1
Array Size : 523264 (511.00 MiB 535.82 MB)
Used Dev Size : 523264 (511.00 MiB 535.82 MB)
Raid Devices : 2
Total Devices : 3
Persistence : Superblock is persistent
State : clean
Active Devices : 2
Working Devices : 3
Failed Devices : 0
Spare Devices : 1
Name : linuc-node01:0 (local to host linuc-node01)
UUID : 625eddc9:cfe4911a:d79a5592:7dc3a8d5
Events : 0
Number Major Minor RaidDevice State
0 7 2 0 active sync /dev/loop2
1 7 3 1 active sync /dev/loop3
2 7 4 - spare /dev/loop42.3 ディスク障害発生のシミュレーションとスペア自動復旧
実機環境で障害試験を行う際は、mdadm --fail（または -f）コマンドを使用して、指定したディスクを意図的に故障状態（faulty）へ遷移させます。
# /dev/loop2 を意図的に故障状態に設定
$ sudo mdadm --fail /dev/md0 /dev/loop2
mdadm: set /dev/loop2 faulty in /dev/md0
# 即座に /proc/mdstat を確認
$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 loop4[2](S) loop3[1] loop2[0](F)
523264 blocks super 1.2 [2/1] [_U]
unused devices: <none>loop2[0](F)という表記で故障（Faulty）が記録され、ステータスは[2/1] [_U]へとデグレード（縮退）しています。これと同時に、待機していたスペアディスク（/dev/loop4）が自動的にアクティブスロットへと昇格し、データの再同期（リビルド）がバックグラウンドで開始されます。
$ sudo mdadm --detail /dev/md0
...
State : clean, degraded, recovering
Active Devices : 1
Working Devices : 2
Failed Devices : 1
Spare Devices : 1
Rebuild Status : 1% complete
Number Major Minor RaidDevice State
2 7 4 0 spare rebuilding /dev/loop4
1 7 3 1 active sync /dev/loop3
0 7 2 - faulty /dev/loop22.4 障害ディスクの切り離し・交換と設定永続化（/etc/mdadm.conf）
リビルド完了後、故障したディスクをアレイから物理的・論理的に取り除くにはmdadm --remove（または -r）を実行します。その後、新しいディスクを投入する場合はmdadm --add（または -a）でアレイに追加します。
# 故障ディスクの切り離し
$ sudo mdadm --remove /dev/md0 /dev/loop2
mdadm: hot removed /dev/loop2 from /dev/md0
# 交換用ディスクをスペアとして追加
$ sudo mdadm --add /dev/md0 /dev/loop2
mdadm: added /dev/loop2OS再起動時にRAIDアレイが正しく自動認識・組み立て（assemble）されるようにするには、設定ファイル/etc/mdadm.confを生成して保存しておく必要があります。これにはmdadm --detail --scanコマンドを用います。
# 現在のアレイ構成をスキャン
$ sudo mdadm --detail --scan
ARRAY /dev/md0 metadata=1.2 spares=1 UUID=625eddc9:cfe4911a:d79a5592:7dc3a8d5
# 設定ファイルへ追記して永続化
$ sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf3. LVM（Logical Volume Manager）の階層構造と構築手順
物理パーティションは一度作成すると容量の変更が困難ですが、LVM（論理ボリュームマネージャ）を導入することで、複数のディスクを束ねて柔軟なストレージプールを構成し、OS稼働中のまま容量を拡大したりスナップショットを取得したりできるようになります。
3.1 PV・VG・LVの概念と作成フロー
LVMは以下の3層アーキテクチャで構成されます。
- 物理ボリューム（PV: Physical Volume）:
実ディスクやRAIDデバイス、パーティションをLVM用として初期化したもの。コマンド:pvcreate - ボリュームグループ（VG: Volume Group）:
1つ以上のPVを束ねたストレージプール。内部はPE（Physical Extent、デフォルト4MB）と呼ばれる固定ブロック単位で管理される。コマンド:vgcreate - 論理ボリューム（LV: Logical Volume）:
VGから必要な容量（PEの集合）を切り出した論理デバイス。OSからは通常のディスクパーティションと同様に見える。コマンド:lvcreate
実機でこの3層を順番に構築していきます。
# 1. 物理ボリュームの作成
$ sudo pvcreate /dev/loop2 /dev/loop3
Physical volume "/dev/loop2" successfully created.
Physical volume "/dev/loop3" successfully created.
# 2. ボリュームグループの作成（まず /dev/loop2 のみで作成）
$ sudo vgcreate vg_test /dev/loop2
Volume group "vg_test" successfully created
# 3. 論理ボリュームの切り出し（容量256MB、名前 lv_data）
$ sudo lvcreate -n lv_data -L 256M vg_test
Logical volume "lv_data" created.
# 4. ファイルシステムの作成とマウント
$ sudo mkfs.xfs -f /dev/vg_test/lv_data
$ sudo mkdir -p /mnt/lvm-test
$ sudo mount /dev/vg_test/lv_data /mnt/lvm-test
$ df -h /mnt/lvm-test
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/vg_test-lv_data 251M 15M 236M 6% /mnt/lvm-test3.2 LVM状態表示コマンドの使い分け（*s と *display）
LVMの状態確認コマンドには、1行要約を表示する「末尾sコマンド（pvs, vgs, lvs）」と、詳細なプロパティを出力する「末尾displayコマンド（pvdisplay, vgdisplay, lvdisplay）」があります。
$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/loop2 vg_test lvm2 a-- 508.00m 252.00m
/dev/loop3 lvm2 a-- 512.00m 512.00m
$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vg_test 1 1 0 wz--n- 508.00m 252.00m
$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_data vg_test -wi-ao---- 256.00mvgsの出力から、ボリュームグループ全体の容量（VSize: 508MB）のうち、約半分（256MB）がLVに割り当てられ、残り（VFree: 252MB）が空き領域としてプールに残されていることが分かります。
4. LVMのオンライン容量拡張とファイルシステム拡張
ストレージ容量が逼迫した際、LVMであればOSや稼働中サービスを停止することなく（オンラインで）領域を拡張できます。容量拡張は「物理層（VG）の拡張」➔「論理層（LV）の拡張」➔「ファイルシステム層の拡張」という順序で行います。
4.1 VGの拡張（vgextend）とLVの拡張（lvextend）
まず、新しいストレージ領域（/dev/loop3）をVGに追加してプール全体の容量を拡大します。これにはvgextendコマンドを使用します。
$ sudo vgextend vg_test /dev/loop3
Volume group "vg_test" successfully extended
$ sudo vgs vg_test
VG #PV #LV #SN Attr VSize VFree
vg_test 2 1 0 wz--n- 1016.00m 760.00mプール容量が1016MBに拡大したため、論理ボリュームlv_dataの容量を拡張します。これにはlvextendを用います。容量の指定方法には以下のバリエーションがあります。
| 指定構文 | 意味 |
|---|---|
lvextend -L +200M /dev/vg_test/lv_data |
現在のサイズに200MBを加算して拡大する |
lvextend -L 500M /dev/vg_test/lv_data |
最終的なサイズが500MBになるように拡大する |
lvextend -l +100%FREE /dev/vg_test/lv_data |
VG内の空き領域（PE）をすべて割り当てて最大まで拡大する |
4.2 ファイルシステム拡張コマンドの差異（resize2fs と xfs_growfs）
論理ボリューム（LV）のサイズを広げただけでは、その上で稼働しているファイルシステムは広がりません。ファイルシステムを拡張するコマンドは、ファイルシステムの種類によって大きく異なります。試験において最も問われやすい最重要論点です。
| 項目 | ext4（resize2fs） | XFS（xfs_growfs） |
|---|---|---|
| 引数の指定方法 | ブロックデバイス名を指定 （例: resize2fs /dev/vg_test/lv_data） |
マウントポイントを指定 （例: xfs_growfs /mnt/lvm-test） |
| オンライン拡張 | 可能（マウントしたまま拡張可能） | 可能（マウント中のみ実行可能） |
| 容量縮小（Reduce） | 可能（ただしアンマウントが必須） | 縮小不可（ファイルシステムの仕様） |
現代のLVMでは、lvextendに-r（または --resizefs）オプションを付与することで、LVの拡張と同時に背後のファイルシステム（ext4またはXFS）を自動検出し、対応する拡張コマンドを自動実行してくれます。
$ sudo lvextend -L +200M -r /dev/vg_test/lv_data
Size of logical volume vg_test/lv_data changed from 256.00 MiB (64 extents) to 456.00 MiB (114 extents).
Extending file system xfs to 456.00 MiB (478150656 bytes) on vg_test/lv_data...
xfs_growfs /dev/vg_test/lv_data
meta-data=/dev/mapper/vg_test-lv_data isize=512 agcount=4, agsize=16384 blks
...
data blocks changed from 65536 to 116736
xfs_growfs done
Extended file system xfs on vg_test/lv_data.
Logical volume vg_test/lv_data successfully resized.
# 拡張結果の確認
$ df -h /mnt/lvm-test
ファイルシス サイズ 使用 残り 使用% マウント位置
/dev/mapper/vg_test-lv_data 451M 17M 435M 4% /mnt/lvm-testログから明らかなように、lvextend -rの内部で自動的にxfs_growfsが呼び出され、マウントを解除することなく451MBへと即座に拡張されています。
5. LVMスナップショットの作成とバックアップ運用
LVMのもう1つの強力な機能がスナップショット（Snapshot）です。データベースやファイルサーバーの整合性バックアップを取得する際、長時間のサービス停止を回避するために利用されます。
5.1 Copy-on-Write（CoW）の仕組みとスナップショット作成
LVMのスナップショットは、作成時点の全データを別領域へ丸ごと複製するわけではありません。Copy-on-Write（CoW: 書き込み時コピー）と呼ばれる仕組みを採用しています。
- スナップショット作成直後は、実質的なデータ複製は行われず、消費容量はほぼゼロです。
- 元ボリューム側のブロックが上書き変更される直前に、そのブロックの「変更前の古いデータ」だけがスナップショット領域へ退避・コピーされます。
- スナップショットを参照すると、「変更されたブロックは退避領域から、変更されていないブロックは元ボリュームから」データを読み出すことで、スナップショット作成瞬間の静止点データを完全に再現します。
スナップショットはlvcreate -sコマンドで作成します。実機でスナップショットを作成し、元ボリュームへデータを書き込んだ際の使用率変化を観察します。
# 基準ファイルの作成
$ echo "Initial Data 12345" | sudo tee /mnt/lvm-test/file1.txt
# 容量128MBのスナップショット（名前 lv_data_snap）を作成
$ sudo lvcreate -s -n lv_data_snap -L 128M /dev/vg_test/lv_data
Logical volume "lv_data_snap" created.
# 作成直後の状態確認（Data% は 0.00%）
$ sudo lvs vg_test
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_data vg_test owi-aos--- 456.00m
lv_data_snap vg_test swi-a-s--- 128.00m lv_data 0.00
# 元ボリュームへ30MBのダミーデータを書き込み
$ sudo dd if=/dev/urandom of=/mnt/lvm-test/largefile.bin bs=1M count=30
$ sync
# 書き込み後の状態確認（Data% が 23.54% へ増加）
$ sudo lvs vg_test
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
lv_data vg_test owi-aos--- 456.00m
lv_data_snap vg_test swi-a-s--- 128.00m lv_data 23.54 元ボリュームに新しいデータを書き込むことでブロックが更新され、変更前データがスナップショット領域へ退避された結果、Data%が23.54%に増加している様子が確認できます。
5.2 スナップショットのマージ（ロールバック）と監視
スナップショット作成時点の状態へボリューム全体を巻き戻したい（ロールバックしたい）場合は、lvconvert --mergeコマンドを使用します。
# アンマウント後にマージを実行
$ sudo umount /mnt/lvm-test
$ sudo lvconvert --merge /dev/vg_test/lv_data_snap
Merging of volume vg_test/lv_data_snap started.
vg_test/lv_data: Merged: 100.00%スナップショットに割り当てた容量（上記の例では128MB）を超えて元ボリュームが変更され、Data%が100%に達すると、スナップショットは無効化（Invalid）され二度と読み書き・復旧ができなくなります。スナップショットを長期運用する場合は、lvextendでスナップショット領域自体を拡張するか、バックアップ完了後に速やかにlvremoveで削除するのが運用の鉄則です。
6. LinuC 201試験（主題2.02）重要ポイント総整理
試験本番で迷いやすいコマンド構文、引数指定の差異、頻出オプションを対照表形式で整理します。
6.1 記述式（コマ問）頻出コマンド・オプション一覧
| コマンド | 主要オプション / 書式 | 役割・ポイント |
|---|---|---|
mkfs.ext4 |
-L <label>, -b <block-size> |
ext4ファイルシステムの作成 |
tune2fs |
-m <%>, -c <max>, -i <interval>, -l <dev> |
ext4パラメータの変更・スーパーブロック情報表示 |
mkfs.xfs |
-f（強制上書き）, -L <label> |
XFSファイルシステムの作成 |
xfs_info |
<mount-point> |
マウント中のXFSファイルシステム詳細情報表示 |
xfs_admin |
-L <label>, -U <uuid>, -l |
アンマウント状態のXFSラベル・UUID管理 |
xfs_repair |
-L（ログクリア強制） |
XFSファイルシステムの整合性検査・修復 |
mdadm |
--create, --level=, --raid-devices=, --spare-devices= |
ソフトウェアRAIDアレイの作成 |
mdadm |
--fail (-f), --remove (-r), --add (-a) |
ディスク障害シミュレーション、切り離し、追加 |
mdadm |
--detail (-D), --detail --scan |
アレイ詳細表示、/etc/mdadm.conf用構文スキャン |
pvcreate |
<device>... |
物理ボリューム（PV）の初期化 |
vgcreate |
-s <pe-size> <vg-name> <pv>... |
ボリュームグループ（VG）の作成（PEサイズ指定可） |
lvcreate |
-n <name> -L <size> <vg-name> |
論理ボリューム（LV）の切り出し |
lvcreate |
-s -n <snap-name> -L <size> <origin-lv> |
スナップショットの作成 |
lvextend |
-L +<size> -r <lv-path> |
LVの容量拡張（-rでファイルシステムも同時拡張） |
resize2fs |
<lv-path> |
ext4ファイルシステムのオンラインサイズ拡張 |
xfs_growfs |
<mount-point> |
XFSファイルシステムのオンラインサイズ拡張 |
6.2 引数やコマンドの取り違えやすい盲点
試験直前に見直すべき典型的な引数の取り違えパターンです。
- ファイルシステム拡張の引数指定:
resize2fs /dev/mapper/vg_test-lv_data➔ デバイスパスを指定する。xfs_growfs /mnt/data➔ マウントポイントを指定する。
- 実行時のマウント状態:
fsckやxfs_repair➔ アンマウント状態で実行する。マウント中に実行するとデータ破損の原因となる。xfs_info➔ マウント状態でなければ実行できない。
- RAIDアレイの操作オプション:
- 故障マーク:
--fail（短縮形:-f） - 切り離し:
--remove（短縮形:-r） - ディスク追加:
--add（短縮形:-a）
- 故障マーク:
7. まとめ：ストレージ運用の本質はレイヤー構造の把握にある
Linuxのストレージアーキテクチャは、物理デバイス（ディスク）、アレイ層（mdadm）、論理ボリューム層（LVM）、そして最上位のファイルシステム層（ext4 / XFS）という階層構造によって支えられています。
障害発生時の切り分けや容量逼迫への対応では、「現在どのレイヤーで問題が起きているのか」「どのレイヤーのコマンドを投入すべきか」を論理的に整理して判断することが不可欠です。本記事で取り上げた実機ログの手順を繰り返し自身の手で検証し、コマンド構文と出力の意味を体得してください。
次回（第4回）は、エンタープライズ環境で必須となる「高度なネットワーク設定・ボンディングと障害切り分け」（nmcli、ipコマンド、NICボンディング、VLAN設定、およびtcpdumpによるパケット解析）を取り上げます。
