SSD のスワップ領域を削除した

VM ホスト環境のスワップ領域を削除し、ルートファイルシステムに統合した。

前提と環境

Debian 13 を稼働させている物理ホストの構成を見直した。このホストは以下の通りである。

目的: ファイルサーバーおよび VMware Workstation 17 Pro による複数 VM の同時稼働
デスクトップ環境: Xfce
システムストレージ: SSD (ADATA SP600, 128GB)
データストレージ: HDD 複数本 (LUKS 暗号化 /mnt/disk1, /mnt/disk2)
物理メモリ: 32GB
OS: Debian 13

この環境では、LVM 上に約 6GB のスワップ領域を確保していた。しかし運用状況を観測すると、メモリの空きが常に大きく、スワップの使用量は常に 0B であった。そこでスワップ領域を削除し、その領域をルートファイルシステムに統合することにした。本記事はその判断と作業手順の記録である。

判断の整理

スワップ領域を削除するかどうかはケースバイケースであり、単純に正しい／間違いとは言えない。本ホストでは次の観点から削除を妥当と判断した。

観点	このホストの状況	判断根拠
物理メモリ余裕	Mem: 31Gi 中 used 10Gi / available 20Gi / swap 使用 0B	32GB の RAM があり、平常時は 10GB 程度しか使わず、swap は常時 0B で推移している。free -h の結果で確認済みであり、実ワークロードでスワップに逃がす必要が発生していない。
運用目的	ファイルサーバーと複数 VM の同時稼働	VM やキャッシュ用途でメモリは使うが、32GB 内で収まっている。スワップを前提に逼迫を吸収する設計ではない。
可用性要件	即時復旧は不要	停止した場合でも復旧手順で戻せる。RTO はゼロではなく許容幅がある。したがって「スワップで踏ん張ってサービス継続する」価値は小さい。
データ保全	重要データは単一ディスク依存ではない	どの物理ディスクが壊れても唯一無二のデータは存在しない。復旧は交換と再構築でよいという設計になっている。
ストレージ構成	SSD 128GB 上で / と swap_1 を LVM で分割	スワップを削除すれば、その分を / に統合できる。限られた SSD 容量を有効に使える。
SSD への書き込み	スワップは SSD 上	無駄な swap 書き込みは SSD の書き換え量を増やす。用途が OS とサービス起動中心である以上、削減できる書き込みは削減する方針と合致する。
S.M.A.R.T. 状態	S.M.A.R.T. overall-health: PASSED / 再配置セクタ 0 / 保留セクタ 0 / 訂正不能 0	ADATA SP600 は古い SSD だが、Reallocated_Sector_Ct=0, Current_Pending_Sector=0, Offline_Uncorrectable=0 であり、自己テストも Completed without error と記録されている。明確な物理エラー兆候は出ていない。
監視体制	定期的に smartctl を確認できる	障害時はディスク交換とリストアで対応する前提運用になっているため、スワップで延命するより壊れたら復旧する設計のほうが合理的である。

上記の結果として、本ホストでは「スワップ領域を維持し続ける価値」より「スワップ領域を / に統合してシステムを単純化し、SSD の限られた容量を有効活用する価値」が上回ると判断した。

S.M.A.R.T. 情報の確認

スワップ領域を削除し、その領域を / に統合するということは、その SSD を今後もシステムディスクとして信用するという判断でもある。よって事前に S.M.A.R.T. の内容を確認している。

重要な指標は次である。

S.M.A.R.T. overall-health self-assessment test result: PASSED
デバイスの自己診断上は正常である。
Reallocated_Sector_Ct = 0
不良ブロックが代替領域にリマップされた記録がない。不良ブロックが顕在化していない。
Current_Pending_Sector = 0
「今は読めないが後で再試行する」保留セクタがない。読めない領域の発生兆候はない。
Offline_Uncorrectable = 0
オフライン自己テストで訂正不能だったセクタがない。
Self-test log: Extended offline Completed without error
過去のロングセルフテストがエラーなしで完了している。
通電時間は 65535h と表示されており、これはこの SSD のカウンタ上限に張り付いている。デバイスが古いことは事実である。ただしこれは「すぐ壊れる」という意味ではなく、単に通電時間が長いという事実を示すだけである。

重要なのは、S.M.A.R.T. の結果は「いつ壊れるか」を保証するものではないという点である。新品でも突然壊れることはある。逆に通電 5 万時間を超えた HDD がまだ動き続けることもある。よって本ホストでは、ディスクが壊れることそのものを避けようとするのではなく、壊れた時に復旧できるかどうかを重視している。これは運用として、RTO をどこまで許容できるかという話に置き換わる。

作業手順

以下に実際に行った手順を示す。コマンドと確認出力を対にし、再現と検証ができる形にしている。

1. メモリとスワップの現状確認

まずシステムが実際にスワップを使っていないか確認する。

$ free -h
total used free shared buff/cache available
Mem: 31Gi 10Gi 1.1Gi 8.6Gi 28Gi 20Gi
Swap: 6.0Gi 0B 6.0Gi

物理メモリ 31Gi 中 10Gi 程度しか使っておらず、available が 20Gi ある。Swap は 6.0Gi 確保されているが使用量は 0B である。

スワップがどこに割り当てられているか確認する。

$ swapon --show
NAME TYPE SIZE USED PRIO
/dev/dm-2 partition 6G 0B -2

/dev/dm-2 がスワップデバイスであることが分かる。この環境ではこれは LVM の LV (ray-vg/swap_1) に相当する。

2. スワップを停止する

稼働中のままスワップを無効化する。

$ sudo swapoff -a

停止後に確認する。

$ swapon --show

出力が空であり、現在のカーネルはスワップを一切使っていない状態になった。

3. /etc/fstab の更新

再起動時に再びスワップを有効化されないよう、/etc/fstab の該当行をコメントアウトする。

# Swap (LVM)
#/dev/mapper/ray--vg-swap_1 none swap sw 0 0

これで次回のブートでもスワップは設定されない。

4. LVM の状態確認 (削除前)

スワップ用の LV がどのように割り当てられているか確認する。

$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root ray-vg -wi-ao---- 111.32g
swap_1 ray-vg -wi-a----- 5.99g

$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
ray-vg 1 2 0 wz--n- <117.32g 0

ray-vg という VG に root と swap_1 の 2 本の LV があり、空き領域は 0GiB と報告されている。つまり swap_1 を削除すれば、その分が丸ごと空く。

5. スワップ LV の削除

LVM から swap_1 を削除する。

$ sudo lvremove /dev/ray-vg/swap_1
Do you really want to remove active logical volume ray-vg/swap_1? [y/n]: y
Logical volume "swap_1" successfully removed.

これで LVM 上からスワップ用 LV が消え、その容量が VG 内の未割り当て領域として解放された。

6. ルート LV の拡張

空いた領域を root LV にすべて割り当てる。

$ sudo lvextend -l +100%FREE /dev/ray-vg/root
Size of logical volume ray-vg/root changed from 111.32 GiB (28499 extents) to <117.32 GiB (30033 extents).
Logical volume ray-vg/root successfully resized.

LV 自体は拡張されたが、ファイルシステムはまだ古いサイズのままである。ext4 はオンラインで拡張できるので、そのまま拡張する。

$ sudo resize2fs /dev/ray-vg/root
resize2fs 1.47.2 (1-Jan-2025)
Filesystem at /dev/ray-vg/root is mounted on /; on-line resizing required
old_desc_blocks = 14, new_desc_blocks = 15
The filesystem on /dev/ray-vg/root is now 30753792 (4k) blocks long.

7. 拡張結果の確認

ルートファイルシステムのサイズを確認する。

$ df -h /
ファイルシスサイズ使用残り使用% マウント位置
/dev/mapper/ray--vg-root 115G 25G 85G 23% /

作業前は約 110G だった / が、約 115G に拡張されていることを確認できる。これは旧スワップ領域だった 6G 弱が / に統合されたことを意味する。

最終確認として、スワップが無効なままであることを再度確認する。

$ swapon --show

出力が空であることから、再起動後もスワップは利用されないことが保証される。fstab のコメントアウト済み状態と合わせて、スワップ領域は論理的にも物理的にもシステムから消えた。

結果と考察

今回の変更により、以下が達成された。

スワップ領域を完全に削除した。
スワップ用に確保していた LVM の LV を削除し、その容量を root LV に統合した。
オンラインでファイルシステムを拡張し、/ の利用可能容量が拡大した。
fstab を修正したことで、再起動後にもスワップは復活しない構成になった。
SSD 上での無駄なスワップ書き込みは今後発生しない。
システムは 32GB の物理メモリだけで安定稼働していることを確認できている。

このホストでは、ディスク故障は「いつか必ず起きること」として扱っている。つまり故障そのものを避けるのではなく、故障後に復旧できるようにしておくという運用思想である。可用性要件が「即時復旧必須」ではないため、この方針は妥当である。今回のスワップ削除と領域統合は、その思想と整合する。

結論

十分な物理メモリ (32GB) を搭載し、swap が実際には消費されていない Debian 13 環境では、SSD 上のスワップ領域は必須ではない。むしろ、スワップ領域を削除し、その領域を / に統合することで、SSD の限られた容量を有効に使えるようになる。

S.M.A.R.T. の結果が示すように、ストレージは古くても明確な物理障害兆候が出ていない限り、運用継続は可能である。ただし、ハードウェアはいつでも壊れうるため、前提は「壊れたら復旧する」ことであり、これはバックアップと復旧手順の整備で担保される。

まとめると、このホストではスワップを削除し、LVM の空き領域をルートファイルシステムに統合することが合理的であった。これは単なる容量の最適化ではなく、運用モデルそのものの整理でもある。