5min: Extending EC2 storage
Quick steps for anyone facing “not enough storage” error
Problem Statement
download failed: [Errno 28] No space left on deviceThis a common error faced by folks possessing smaller volumes [speak “storage”] but utilizing larger files.
tldr;
sudo growpart /dev/xvda 1
sudo resize2fs /dev/xvda1Long story
Elastic Cloud Compute [EC2] instances provide users ability to choose their storage via Elastic Block Store [EBS] volumes.
Taking a leaf out of the Bible on accessibility & control, AWS allows users to shrink or blow the storage space. This comes in handy once you have instance running & development environment setup but hit the obstacle of “limited storage”.
Step 0: Identify the volume [via AWS Console]
Navigate to EC2 console, click the desired instance & out comes the information about the volume that is “attached” to your instance. Clicking on the hyperlink of the device shows the EBS ID. Clicking on the hyperlink of the EBS ID takes you to the EBS volume tab.
Step 1: Resize the volume [via AWS Console]
The volume that’s attached to the instance is pre-selected. Navigate to Actions followed by Modify Volume.
Volume State should transfer from in-use to optimizing(0%). It will continue optimizing for certain time [depending on the storage space to be optimized for]. After optimizations are complete, it will transfer to complete.
Alternative: Steps 0 & 1 can be done via AWS CLI. [1]
Step 2+: Recognize the expanded volume [Linux]
All steps here onward require you to connect to the instance via ssh.
Step 2: Partition Extension
2a. Identify the file system for a volume
File system can either be based on Nitro system or T2 instance.
Nitro instance has boot volume = XFS and additional volume with XFS.
T2 instance has boot volume = ext4 and additional volume with XFS.
$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
/dev/xvda1 ext4 485G 368G 117G 76% /In my case, I had T2 instance.
2b. List volumes
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 1000G 0 disk
└─xvda1 202:1 0 500G 0 part /Here in lies the issue.
The size of the volume doesn’t match the partition size.
Root volume /dev/xvda [1000G] has a partition /dev/xvda1 [500G]. This needs to be fixed by extending the partition to match the size of the volume.
2c. Grow the partition
growpart allows to grow/extend the partition. First parameter is volume name and second parameter is the partition number [in this case 1]
$ sudo growpart /dev/xvda 1
CHANGED: partition=1 start=2048 old: size=1048573919 end=1048575967 new: size=2097149919,end=20971519672d. Verify the extended partition
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 1000G 0 disk
└─xvda1 202:1 0 1000G 0 part /This verifies the partition has been successfully extended.
Step 3: File System Extension
3a. Check the file system size
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 485G 368G 117G 76% /3b. Extend the file system by volume
resize2fs command allows to resize [grow/shrink] filesystem on any volume. Note the difference between growpart and resize2fs.
$ sudo resize2fs /dev/xvda1
resize2fs 1.44.1 (24-Mar-2018)
Filesystem at /dev/xvda1 is mounted on /; on-line resizing required
old_desc_blocks = 63, new_desc_blocks = 125
The filesystem on /dev/xvda1 is now 262143739 (4k) blocks long.3c. Verify the updated file system
$ df -h .
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 970G 371G 599G 39% /There you go! File system has been extended and suddenly you’ve 500+ gigs at your disposal.
The more important question left is : What do you do with the extra Gigs?
