Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

My Ubuntu server has 24GB of RAM. I want to automatically create a ramdisk on boot and load files from the /home/user1/ramdisk folder. When the system shuts down, I need to load files from ramdisk back to that directory.

How can I achieve this?

share|improve this question
    
@user, this question is fine here, but just so you know, the people who run Super User also have a site just for Ubuntu questions: askubuntu.com. –  Pops Mar 2 '11 at 22:12
    
Do not do this without an uninterruptable power supply. That being said, they're relatively inexpensive (a sub-$100 one would be more than enough for this purpose), and I'm pretty sure you can just edit your fstab file and add in a new entry, with the path of your choice, and the filesystem set to ramfs or tmpfs, the latter being preferred so you don't have any size limits (see this entry in the Arch Linux Wiki for more details). –  Breakthrough Dec 11 '12 at 17:43
add comment

2 Answers

Even though upstart can be used to do things like this, this can only be recommended under the premise that the user is aware that the data is volatile and may get lost.

Consider the case where power is lost. There is no possible way the machine can react to that and quickly move your data from the ramdisk to your other storage.

That means: it won't be safe for the data.

Given that you want to mount it, you need super user privileges, which means you can also store the volatile data directly in /dev/shm which is created at system start.

share|improve this answer
    
I understand about data loss issue. I plan to have following setup. Install ubuntu OS on Intel 80GB SSD, Have two 1tb hard drives in raid 1 for backups and storage. Then I want the application to automatically load and unload from storage to RAMDISK. I can't figure out how to do that manually. P.S. Application writes and reads data a lot. I don't want to wear my SSD with those reads –  user68740 Mar 2 '11 at 21:07
    
@user68740: a read has no effect on an SSD, and a decent modern SSD is no more likely to fail due to the wear of normal activity than a spinning-disk based drive. –  David Spillett Mar 2 '11 at 21:17
    
I am concerned about write. Application does a lot of writes. As far as I know SSD has limited amount of writes. –  user68740 Mar 2 '11 at 21:19
    
Improved flash cell design/construction (increasing the write limit considerably) and wear-levelling algorithms (which stop writes being as unevenly distributed as the would otherwise be) mean a decent modern SSD is no more likely to fail due to the wear of normal activity than a spinning-disk based drive. There is likely to be some write performance degradation over time which can be minimised with TRIM support. If your kernel is not recent enough (2.6.33+ IIRC) to support TRIM directly there are tools that can be scheduled to send the relevant commands at appropriate intervals. –  David Spillett Mar 2 '11 at 21:31
    
Don't be too quick to dismiss concerns about excess write operations wearing out an SSD. I support the OP's concerns regarding an application that writes a lot. Older SSD's had NAND that was good for 10,000 write cycles. Now 34nm MLC NAND is good for 5,000 write cycles, while 25nm MLC NAND lasts for only 3,000 write cycles. –  MountainX Dec 10 '11 at 6:34
show 1 more comment

As status_access_denied points out in his answer, this is not safe for the data as it will be lost should a power0out or other uncontrolled shutdown occur.

Also, you are often better of letting the OS decide what to hold in RAM. If you devote a chunk of ram to specific files like this then it can not use it for other things like caching other files, VM memory, databases, and what-ever else your server is doing.

If you want to make sure the data is in cache on boot (where it will stay if the memory genuinely isn't ever needed for anything else, you could run something like:

find /path/to/directory -type f | xargs cat > /dev/null

on boot. The above command will result in all the files being read and therefore passed through the caching sub-system. Debian and Ubuntu (and probably other distros) run the script /etc/rc.local at the end of the boot process, so that is probably the simplest place to put the command. If the amount of data being loaded is large and/or spread over many large files you might want to limit the rate at which is it read so that this does not interfere with anything else that is going on (i.e. if you are logging in directly after booting, or other services are still starting up) with something like:

find /path/to/directory -type f | xargs pv --rate-limit 1M --quiet > /dev/null

You'll find pv in the standard repositories. the --rate-limit option does what it says on the tin (in this case limiting the rate to 1Mbyte/sec) and --quiet tells it not to bother with the progress bar and other display.

You could chuck the command in a cron job if you want the server to occasionally reread the files to reseed them in cache in case they have been pushed out by something else.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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