I have an Ubuntu server running on EC2 with an EBS volume mounted on /. I resized the EBS volume to 16TB before realizing that using it as the root volume implies partitioning, and that I might need a specific partitioning scheme in order to increase the size.

$ df -hT
Filesystem Type Size Used Avail Use% Mounted on
udev devtmpfs 7.4G 0 7.4G 0% /dev
tmpfs tmpfs 1.5G 840K 1.5G 1% /run
/dev/xvda1 ext4 2.0T 1.8T 200G 90% /
tmpfs tmpfs 7.4G 0 7.4G 0% /dev/shm
tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup
/dev/loop1 squashfs 56M 56M 0 100% /snap/core18/1932
/dev/loop3 squashfs 29M 29M 0 100% /snap/amazon-ssm-agent/2333
/dev/loop4 squashfs 33M 33M 0 100% /snap/amazon-ssm-agent/2996
tmpfs tmpfs 1.5G 0 1.5G 0% /run/user/1000
/dev/loop5 squashfs 56M 56M 0 100% /snap/core18/1944
/dev/loop6 squashfs 98M 98M 0 100% /snap/core/10577
/dev/loop2 squashfs 98M 98M 0 100% /snap/core/10583

Running fdisk -l, I see that /dev/xvda is 15.6TiB, but that I'm only utilizing part of that on /dev/xvda1:

Disk /dev/xvda: 15.6 TiB, 17179869184000 bytes, 33554432000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb32e823c
Device Boot Start End Sectors Size Id Type
/dev/xvda1 * 2048 4294967294 4294965247 2T 83 Linux

Upon attempting to growpart /dev/xvda 1, I found out that:

WARNING: MBR/dos partitioned disk is larger than 2TB. Additional space will go unused.
NOCHANGE: partition 1 could only be grown by 1 [fudge=2048]

After googling, it became clear that I need to repartition with GPT and possibly enable GPT in the Ubuntu kernel (?) if I want to mount a larger root partition. I don't actually care if the EBS volume is mounted as the root volume, really my only goals are to (1) have a 16TB EBS volume mounted, somewhere, and (2) preserve the data from a specific directory on the current volume.

I have almost no experience with this sort of thing; what's the easiest thing to do here?

1. Can I just create a new, partition-less 16TB EBS volume, mount it on the same EC2 instance (not as the root volume), and then copy over data from the root volume to the new, larger volume?
2. Am I going to be able to mount an EBS volume of that size by default if it's not the root volume?

1 Answer

After a bit of experimentation, I can say that the answers to (1) and (2) are "yes" and "yes" — the only real problem is trying to use a large EBS volume as the root volume.

You can indeed mount a 16TB EBS volume without partitions, and Ubuntu 18.04 handles it without problems. Therefore, the easiest thing to do is to create a new, 16TB EBS volume, mount it on the EC2 instance, and copy over the data that you need.

First, you'll want to back up any data that you have on your current volume, just in case. To do this, you'll need to stop the EC2 instance (this is only necessary when snapshotting the root volume). Then, go to the Elastic Block Store Volumes page of the EC2 console, and choose "create snapshot" under "actions". Once finished, restart the EC2 instance. More details here.

1. Create an EBS volume in the AWS console, configure it with the size and type that you require (gpt3 is good for the specifications in the question, but see "Amazon EBS Volume Types" for more information), and attach it to your running instance. There's no need to stop the instance or touch its configuration at this point.

2. SSH into the EC2 instance and check that the volume is attached but not mounted:

   ubuntu:~$ lsblk
   NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
   loop1 7:1 0 55.4M 1 loop /snap/core18/1932
   loop2 7:2 0 97.9M 1 loop /snap/core/10583
   loop3 7:3 0 28.1M 1 loop /snap/amazon-ssm-agent/2333
   loop4 7:4 0 32.3M 1 loop /snap/amazon-ssm-agent/2996
   loop5 7:5 0 55.4M 1 loop /snap/core18/1944
   loop6 7:6 0 97.9M 1 loop /snap/core/10577
   xvda 202:0 0 15.6T 0 disk
   └─xvda1 202:1 0 2T 0 part /
   xvdf 202:80 0 16T 0 disk 

   Notice that xvda (the root volume) has a partition underneath it (xvda1) and is mounted at /, whereas the new xvdf volume has neither partition nor mount point.

3. Fresh EBS volumes have no filesystem, so you need to create one: sudo mkfs -t xfs /dev/xvdf. Take care to reference the proper volume, otherwise you will overwrite data if you attempt to create a new filesystem on a volume which already contains one.

4. Create a place to mount the volume, I'll call it 'data': sudo mkdir /data.

5. Mount the volume, and you'll see it appear in the output of df. Optionally, update the fstab file to mount the volume automatically after reboot, as described here.

   ubuntu:~$ sudo mount /dev/xvdf /data
   ubuntu:~$ df -hT
   Filesystem Type Size Used Avail Use% Mounted on
   udev devtmpfs 7.4G 0 7.4G 0% /dev
   tmpfs tmpfs 1.5G 828K 1.5G 1% /run
   /dev/xvda1 ext4 2.0T 1.8T 180G 91% /
   tmpfs tmpfs 7.4G 0 7.4G 0% /dev/shm
   tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock
   tmpfs tmpfs 7.4G 0 7.4G 0% /sys/fs/cgroup
   /dev/loop1 squashfs 56M 56M 0 100% /snap/core18/1932
   /dev/loop3 squashfs 29M 29M 0 100% /snap/amazon-ssm-agent/2333
   /dev/loop4 squashfs 33M 33M 0 100% /snap/amazon-ssm-agent/2996
   tmpfs tmpfs 1.5G 0 1.5G 0% /run/user/1000
   /dev/loop5 squashfs 56M 56M 0 100% /snap/core18/1944
   /dev/loop6 squashfs 98M 98M 0 100% /snap/core/10577
   /dev/loop2 squashfs 98M 98M 0 100% /snap/core/10583
   /dev/xvdf xfs 16T 17G 16T 1% /data

6. Finally, set the file permissions you need for /data and copy over any files that you would like on the new drive. Consider using rsync here as a less brittle alternative to cp.

1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

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