I am using a large EC2 instance but just realized that I don't have the space promised. I only get 8 gigs when it says I should have 850 GB.
From what I understand two extra 420 gb drives should be avail for me to format/mount to setup, but I can't seem to find it. If I look in the dev directory its not there. I tried to enter "df -h " and it didn't show up either.
Is there something I need to do to get access to the drives?
if it helps, I'm using the standard amazon linux image.
To access the ephemeral (instance-store) storage Amazon includes with an EC2 instance, you need to define it when you launch an instance. Using the EC2 command line tools all you need to do is include the -b or --block-device-mapping option flag.
For example, this command would launch a single m1.large instance in us-east-1a, with ephemeral0 and ephemeral1 mapped to sdb1 and sdb2 respectively and the following options:
-
ec2-run-instances ami-id -n 1 -t m1.large -z us-east-1a -b "/dev/sdb1=ephemeral0" -b "/dev/sdb2=ephemeral1" -g security_group -k key_name
Then you can format and mount the devices. (repeat each command once for each device)
sudo mkfs /dev/sdb[1..n]
sudo mkdir -p /media/ephemeral[0...n]
You can then either add the following two lines to your /etc/fstab (feel free to adjust your mount options, file system, etc.)
/dev/sdb1 /media/ephemeral0 auto defaults,comment=cloudconfig 0 2
/dev/sdb2 /media/ephemeral1 auto defaults,comment=cloudconfig 0 2
And mount the devices
sudo mount /media/ephemeral0
sudo mount /media/ephemeral1
Or, just mount the devices without adding these devices to the fstab file
sudo mount -t ext3 /dev/sdb1 /media/ephemeral0
sudo mount -t ext3 /dev/sdb2 /media/ephemeral1
Verify
df -h
Sample Output:
[ec2-user@ip-10-251-159-223 media]$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 883M 7.0G 12% /
tmpfs 3.7G 48K 3.7G 1% /dev/shm
/dev/xvdb1 414G 199M 393G 1% /media/ephemeral0
/dev/xvdb2 414G 199M 393G 1% /media/ephemeral1
[ec2-user@ip-10-251-159-223 media]$
By the way, once you customize your instance. Create your own AMI based on this instance and whenever you launch an instance from the resulting AMI the ephemeral storage will already be configured.
Also, take a look at the documentation provided on the AWS website.
Amazon Command Line Tools Documentation
Good Luck!
/dev/sdb and /dev/sdc, NOT /dev/sdb1 and /dev/sdb2 (otherwise, the state immediately becomes "terminated" due to a system startup error).
Mar 31, 2013 at 3:08
/dev/scb1 and /dev/sdb2 is formerly correct or not, but it's not currently correct. I'm hesitant to edit his answer which is otherwise great. But @DanNissenbaum's comment is correct (and important).
The additional space should be mounted under /mnt. However keep in mind, that everything on it will go away if you terminate your instance, so if you want to persist your data you need to go through extra steps. For example, you may want to create additional EBS volume, mount it every time you boot the instance and keep all your persistent data on it. I personally use space from /mnt for temporary files only.
/mnt supposed to be empty, just go there and do df . you should see all your storage. Also keep in mind, that this storage is "thin provisioned", i.e. it gets physically allocated on first use, so you may experience slow performance when you initially load your database. You could speed it up by creating and then deleting a large file of approximate size of your database.
May 4, 2011 at 22:01
If you're specifically seeing this on the root volume, one thing to watch out for is that some AMIs don't seem to have their cloud-init scripts set up properly to expand your root FS to fill the available space. For instance, the AMI was initially created with an 8 GiB root volume, you change it to a larger size when creating a new instance, but when you run df -h it's still only showing 8 GiB.
I've seen this happen on a few CentOS AMIs in particular, but I haven't used it in a while so not sure if it's still a common issue.
In these cases a manual online resize usually does the trick for me.
First, check whether your root FS is using the whole disk (/dev/xvda), or on a partition (/dev/xvda1):
mount -l|grep 'on / '
Assuming it's used the whole disk (xvda), you can attempt an online resize: resize2fs /dev/xvda ... then try df -h again and high-five the nearest colleague/family member.
In the other situation... I don't think I've seen this happen when the setup process has actually partitioned the disk. There'd be no harm in trying resize2fs /dev/xvda1, but I suspect you would need to extend the size of the partition first in order for it to do anything. Your best bet there would be something like parted.
