I’ve resized plenty of EC2 disks in my time, but the most recent one was a little different. Most of the disks I resize are on Ubuntu or CentOS, but the most recent one was a Redhat disk. Call me crazy but it’s strangely different.<\/p>\n
The disks layout looks like this (using the “lsblk” command):<\/p>\n
# lsblk\r\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\r\nnvme0n1 259:0 0 50G 0 disk\r\n\u251c\u2500nvme0n1p1 259:1 0 1M 0 part\r\n\u2514\u2500nvme0n1p2 259:2 0 50G 0 part \/\r\n<\/pre>\nAnd here’s the partition details (and type):<\/p>\n
# fdisk \/dev\/nvme0n1\r\n...\r\nDevice Boot Start End Blocks Id System\r\n\/dev\/nvme0n1p1 1 104857599 52428799+ ee GPT\r\n<\/pre>\nThe “ee \/ GPT” isn’t common in my experience. Having said that, most Linux servers I maintain are Ubuntu or CentOS. <\/p>\n
Hang on: Where’s the second (the root) disk? The one you see above it not it. And notice the partition type. “ee GPT”. That’s the part that got me. I would normally be “83 Linux”.<\/p>\n
At this point we’d go to the AWS console and resize\/grow the disk (volume). Then return here and continue on.<\/p>\n
Now we confirm the resize:<\/p>\n
# lsblk\r\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\r\nnvme0n1 259:0 0 75G 0 disk\r\n\u251c\u2500nvme0n1p1 259:1 0 1M 0 part\r\n\u2514\u2500nvme0n1p2 259:2 0 50G 0 part \/\r\n<\/pre>\nThe above looks good. The disk is now 75G in size but the partition is still the original size (50G).<\/p>\n
I decided not to use the normal method I’d use (delete and recreate the partition) because the partitions weren’t listing as I’d expect. So I went with the “growpart” method as documented here “https:\/\/aws.amazon.com\/premiumsupport\/knowledge-center\/ebs-volume-size-increase\/”. The following command lists a “2” next to the command. It specifies the partition to deal with. I know from the above output that the “\/” partition is the second partition.<\/p>\n
# growpart \/dev\/nvme0n1 2\r\nCHANGED: partition=2 start=4096 old: size=104853470 end=104857566 new: size=157282270 end=157286366\r\n<\/pre>\nConfirm the resized partition:<\/p>\n
# lsblk\r\nNAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT\r\nnvme0n1 259:0 0 75G 0 disk\r\n\u251c\u2500nvme0n1p1 259:1 0 1M 0 part\r\n\u2514\u2500nvme0n1p2 259:2 0 75G 0 part \/\r\n<\/pre>\nConfirm the filesystem type so we can use the right growth tool (xfs_grow or resize2fs) – Hint: it’s xfs:<\/p>\n
# mount | grep ' \/ '\r\n\/dev\/nvme0n1p2 on \/ type xfs (rw,relatime,seclabel,attr2,inode64,noquota)\r\n<\/pre>\nGrow the filesystem over the newly available space:<\/p>\n
# xfs_growfs \/\r\nmeta-data=\/dev\/nvme0n1p2 isize=512 agcount=34, agsize=393216 blks\r\n = sectsz=512 attr=2, projid32bit=1\r\n = crc=1 finobt=0 spinodes=0\r\ndata = bsize=4096 blocks=13106683, imaxpct=25\r\n = sunit=0 swidth=0 blks\r\nnaming =version 2 bsize=4096 ascii-ci=0 ftype=1\r\nlog =internal bsize=4096 blocks=2560, version=2\r\n = sectsz=512 sunit=0 blks, lazy-count=1\r\nrealtime =none extsz=4096 blocks=0, rtextents=0\r\ndata blocks changed from 13106683 to 19660283\r\n<\/pre>\nCheck the disk space allocation details to confirm it was successful:<\/p>\n
# df -h\r\nFilesystem Size Used Avail Use% Mounted on\r\ndevtmpfs 10G 0 10G 0% \/dev\r\ntmpfs 10G 4.0K 10G 1% \/dev\/shm\r\ntmpfs 10G 1.1G 8.9G 11% \/run\r\ntmpfs 10G 0 10G 0% \/sys\/fs\/cgroup\r\n\/dev\/nvme0n1p2 75G 41G 35G 54% \/\r\ntmpfs 2.0G 64K 2.0G 1% \/run\/user\/0\r\ntmpfs 2.0G 48K 2.0G 1% \/run\/user\/1003\r\ntmpfs 2.0G 0 2.0G 0% \/run\/user\/1001\r\n<\/pre>\nAnd we’re done.<\/p>\n","protected":false},"excerpt":{"rendered":"
I’ve resized plenty of EC2 disks in my time, but the most recent one was a little different. Most of the disks I resize are on Ubuntu or CentOS, but the most recent one was a Redhat disk. Call me crazy but it’s strangely different. The disks layout looks like<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[3,115,114],"tags":[],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/posts\/9767"}],"collection":[{"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/comments?post=9767"}],"version-history":[{"count":13,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/posts\/9767\/revisions"}],"predecessor-version":[{"id":9865,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/posts\/9767\/revisions\/9865"}],"wp:attachment":[{"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/media?parent=9767"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/categories?post=9767"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/agix.com.au\/wp-json\/wp\/v2\/tags?post=9767"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}