

EC2のルートボリューム使用率が94%だったのでgrowpartとxfs_growfsで拡張した
この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。
状況
df -h で見たらルートボリュームの使用率が94%だった。
$ df -hファイルシス サイズ 使用 残り 使用% マウント位置/dev/xvda1 8.0G 7.5G 534M 94% /lsblk で確認すると、ディスク(xvda)自体は32GBあるのに、パーティション(xvda1)は8GBしか切られていなかった。
$ lsblkNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTxvda 202:0 0 32G 0 disk└─xvda1 202:1 0 8G 0 part /つまりEBSボリューム自体は既に32GBに拡張済みで、パーティションとファイルシステムが追従してない状態だった。
手順
流れとしてはこう。
flowchart TD
A[df -h で使用率確認] --> B[lsblk でパーティション構成確認]
B --> C[growpart でパーティションテーブル拡張]
C --> D{ファイルシステムの種類}
D -->|ext4 / Amazon Linux 1・CentOS6系| E[resize2fs]
D -->|XFS / Amazon Linux 2・CentOS7系| F[xfs_growfs -d /]
E --> G[df -h で結果確認]
F --> G
パーティションテーブルの拡張
growpart <disk> <partition> でパーティションテーブル上のサイズをディスクの実サイズまで拡張する。
$ sudo growpart /dev/xvda 1CHANGED: partition=1 start=4096 old: size=16773087 end=16777183 new: size=67104735 end=67108831ファイルシステムの拡張
ここはファイルシステムの種類で分かれる。
Amazon Linux 1 / CentOS6系(ext4)の場合:
$ sudo resize2fs /dev/xvda1Amazon Linux 2 / CentOS7系(XFS)の場合:
$ sudo xfs_growfs -d /xfs_growfs はデバイスパスじゃなくマウントポイント指定な点がresize2fsと違う。
今回は以下のような出力になった。
$ sudo xfs_growfs -d /meta-data=/dev/xvda1 isize=512 agcount=4, agsize=524159 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1 spinodes=0data = bsize=4096 blocks=2096635, imaxpct=25 = sunit=0 swidth=0 blksnaming =version 2 bsize=4096 ascii-ci=0 ftype=1log =internal bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1realtime =none extsz=4096 blocks=0, rtextents=0data blocks changed from 2096635 to 8388091結果
df -h で32GBに拡張されているのを確認できた。
$ df -hファイルシス サイズ 使用 残り 使用% マウント位置/dev/xvda1 32G 7.5G 25G 24% /使用率も94%から24%まで下がった。
補足
growpartもresize2fs/xfs_growfsもオンライン実行可能。アンマウントもリブートも不要だった- 前提としてEBSボリューム自体のサイズ拡張(コンソールかCLI)を先に済ませておく必要がある。この手順はあくまでパーティションとファイルシステムをEBSの実サイズに追従させる部分
- Amazon Linux 1系はext4、Amazon Linux 2系はXFSがデフォルトなのでこの分岐になっているが、AMIの選び方によっては違う組み合わせもあり得る。実行前に
lsblk -fかdf -Tでファイルシステム種別を確認しておいた方が安全