Mounting an EBS Volume to an Instance and Soft Linking a Growing Directory to it

We were having a crisis on our project the other day. The VPS on which we were running our application had some issues with kernel and Tomcat, for that matter, any java process was running unpredictably. Tomcat would explode the WAR file once in a while and even if it did, it would just pause at “Deploying app.war” forever. After spending some time troubleshooting (we didn’t know that it was an issue with the kernel), we decided to move our infrastructure to Amazon EC2. We picked up an EBS based large instance, running Ubuntu and copied the setup from our production server to this new machine. The setup was a breeze, thanks to the scripts we already had in place for migrating our production setup to our QA machines for testing purposes.

However, we realized that Image Magick, which was being used from our application was not working as expected. In fact, it wasn’t working at all. We noticed that we were able to perform it as root, but not as any other user. The error which showed up was that there was lack of disk space. Static documents generated by our application were stored on the file system and it was meant to be an ever expanding directory. The EBS instance we had chosen had a capacity of just 8GB and about 6 GB of that was being occupied by the OS and the rest of our infrastructure. We decided to move this particular directory to a new EBS volume.

This could be accomplished smoothly, thanks to the ease of attaching a new EBS volume to an instance. We added a new volume and then, performed the following steps to move this particular expanding directory.

[java]

mke2fs -F -j /dev/sdh #This is to create an ext3 file system for the device attached at /dev/sdh

mkdir /path_to_new_file_system

mount /dev/sdh /path_to_new_file_system #mount the new file system at this directory

cp -r static_documents_location /path_to_new_file_system #Copy the files from the existing directory to the new directory

mv static_documents_location static_documents_location_backup #Backup the existing documents, just in case anything goes wrong

ln -s /path_to_new_file_system/static_documents_location static_documents_location #Create a soft link to refer to the new file location with the same name as the previous one

[/java]

With these steps, we were good to go on the Amazon machine without even requiring a Server restart. We were expecting a downtime of at least 10 minutes but this happened so flawlessly.

Hope this helps someone.