had to resize my EBS on AWS. i followed amazon's instructions which basically had me mount the EBS/HD on a second machine (as a secondary disk) and use 'gdisk' to resize the partition. Then they say to mount the EBS/HD back onto the original machine (restart it) and do 'resize2fs'.

However, after launching the original instance, 'df' showed the "available" and "use %" as being aware of the size I added using gdisk (on the other machine). I did not have to use resize2fs at all.

So, my question is: how did my system automatically resize the filesystem? As far as I'm aware, all i did was resize the partition, but not the filesystem? Amazon's documentation makes it seem like this is 2 different things. Do I still need to do the resize2fs? Will I run into complications later on if i don't? I'm afraid i'm running in some purgatory state even though everything seems fine (and i can save new files whereas previously the HD was 100% full before this).

The format is ext4 (GPT with protective MBR) if that helps.


  • in cloud or not, don't store application data in root partition, and use lvm where posible, on aws store the app data on seperate volume and manage the volume with lvm inside the ec2 instance, in this way you can attach other volume when you spice is gone and resize the fs with lvm. – c4f4t0r Nov 8 '17 at 21:08

It is a common feature for Linux images in EC2 to automatically call resize2fs on their root filesystem when they "wake up" with unused space available there. This is done by cloud-unit. There may be a log file of this action at /var/log/resizerrootfs.log or evidence of it elsewhere in /var/log.

It is because of this facility that you can initially launch an instance with a larger root volume than what was on the 8GB AMI, and are able to use all of the space without changing anything -- before the first boot, your new instance actually has an 8GB root filesystem, cloned byte-for-byte from the AMI snapshot.

The instructions are likely designed with safety and universality in mind. It's technically possible to modify the partition table and do the whole thing from a single running instance, but it's obviously a delicate operation if attempted.

  • wow! you are right! i checked /var/log/cloud-init.log and sure enough the following was in there "Nov 08 16:59:22 cloud-init[2538]: util.py[DEBUG]: Running command ('resize2fs', '/dev/xvda1') with allowed return codes [0] (shell=False, capture=True)". thanks for the detailed explanation! completely makes sense on your example about the 8GB -> larger instance launch too. Much appreciated all around! – user3249281 Nov 10 '17 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.