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.

  • 1
    You don't want to store data on instance base storage unless its replicated or can easily be recovered/recreated. What do you mean by 'standard amazon linux image'? To my knowledge there is no such thing. May 4 '11 at 15:47
  • There's a ec2 linux instance and is made by amazon themselfs. Its like the offical one I think. I thought the storage is persistent? I have termination protection so I don't shut down the box bymistake..but I'm pretty much using it as my mysql backend for my sites.
    – Lostsoul
    May 4 '11 at 18:21
  • EBS instances are persistent. Instance-store instances are ephemeral.
    – ceejayoz
    May 6 '11 at 3:37

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:

  • ami-id
  • (-n) number of instances to launch
  • (-t) instance type
  • (-z) availability zone
  • (-b) block device mapping
  • (-g) security group
  • (-k) key name


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


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!

  • Hey sorry it took so long I finally got around to doing this and it worked perfectly. Thank you for your great instructions.
    – Lostsoul
    May 29 '11 at 0:06
  • 1
    Note that for my Ubuntu instance, I needed to use /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 '13 at 3:08
  • I don't know if AlanZ's reference to /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).
    – mdahlman
    Aug 28 '13 at 16:32

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.

  • I used to have a instance that I setup an EBS mount but it costs alot because my database has alot of read/writes on it. I thought the storage we get with the instance is persistent also? I have termination protection against it and am basically using it to storage a very large database I'm hosting. When I look under /mnt its totally empty.
    – Lostsoul
    May 4 '11 at 18:24
  • @Lostsoul: /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.
    – dtoubelis
    May 4 '11 at 22:01
  • ok, I'll try to create a file and see how it goes but I just went to the folder and tried to use the df . command and it only shows my root partition (/dev/xvda1 8256952 1930904 6242164 24% /) I'll try it and let you know later tonight. Thanks so much Dmitri.
    – Lostsoul
    May 4 '11 at 23:09
  • @Lostsoul: Please check this link and go to "Instance Storage" section. The exact location of instance storage depends on instance type and you may need to mount it manually after all, so it is not always under /mnt.
    – dtoubelis
    May 5 '11 at 0:32

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.

  • (BTW I know this probably isn't the exact situation the OP was having, but it may be related.)
    – Tom
    Jul 6 '14 at 1:02

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.