Making Ubuntu Fast using RAM (updated and simplified)

[terminator14]

Hmmm so I tried your script out, but at some point it was asking me to choose between 3 options - where to store the home folder. So I entered a 2, which would be for choosing a disk manually, but when I entered 2 the scripts started doing all kinds of things and at one point I saw it copying my home folder to somewhere (?) and then I saw it was trying to copy all my VM disks and I canceled the script . I ran the un-installer and it says it's un-installed but when I run the script again, it says the only option is to un-uninstall !

Thanks for your feedback. I'll take a look. A few things could help me out though, if you don't mind:

1. What OS did you run this script on? 10.04? 10.10?
2. What is the layout of your filesystems on the OS you ran it on? Is your /home on the same partition as your '/'?
3. How far did the script get in asking you questions before it started to copy your /home after you chose to enter the device manually? Normally, after you choose 2, it will ask which device you want to use for /home. It will then verify that the device is valid, make sure it's empty (or ask you to empty it if it finds files on it), it will format it, and it will copy your current /home to that device. So copying the files you have in your old /home to the new device is done by design in order for you to have access to your old /home in the RAM Session. There would be a problem with the script if it somehow jumped the gun and as soon as you hit option 2, it started to copy your /home to a device you haven't chosen yet. Are you saying this is what happened? If so, where did the files get copied to?


As for the uninstall not working, that is incredibly strange. The way the script determines if it ran before is a file called /Original_OS. When the script runs normally, it makes sure the file doesn't exist before it continues. If it doesn't, the script keeps running and this file is created. When the script is launched again, it checks for the file again, but this time when it finds it, it tells you that the script ran before, and asks if you want to uninstall. The uninstall function removes the /Original_OS file (along with anything else the script may have done). The uninstall function is one of the simplest functions within the entire script, and looking at it now, I don't see where I could have messed it up. Does the /Original_OS file exist on your original OS? If it does, run "RAM_booster.sh --uninstall" and check again. Is it not being removed? The line within the uninstall function that removes that file is "sudo rm -f /Original_OS", which means it's removing it as root. That means it should pretty much never fail. Are you sure you didn't just run the script as "RAM_booster.sh --uninstall" again?

[Slim Odds]

Good point. I think this is the basic idea behind preload, but I never could get preload to function properly. I wonder if something as simple as that (reading files in rc.local at boot) would end up with the exact same results in terms of speed of opening apps and speed of the OS itself as this script provides. If so, that would make the issue this script addresses be solved by something 100x simpler, which is always a good thing.

The only potential problem I see with simply reading a file in rc.local (not running it but simply reading it) is that any libraries the file needs when it runs will not be read into RAM. This won't cause any problems - it simply means when the app is launched by the user, the main file will already be in RAM but the libraries it needs will still need to be copied from the HDD to RAM before they can be used. I'm not a programmer, and having limited knowledge of exactly how libraries are linked to apps, I may be wrong about this, but I'm pretty sure this is the case.

I didn't go into that much detail, but yes, I was also thinking that you would want to read the libs as well. The 'ldd' program will tell you what libs an application references.

Like you said, it would be far simpler and also not impact the existing system in any way.

[terminator14]

I didn't go into that much detail, but yes, I was also thinking that you would want to read the libs as well. The 'ldd' program will tell you what libs an application references.

Like you said, it would be far simpler and also not impact the existing system in any way.

Definitely sounds like an idea that might work. I wonder if anyone has tried such a solution before. I whipped up a simple script to demo the theory. Here's the code:

#!/bin/bash
while read LINE; do
	if [[ -r "$LINE" ]]
	then
		#Read file
		dd if=$LINE of=/dev/null

		#Read its library dependencies
		LIBS=$(ldd /bin/grep | grep -o '/.*[ ]')

		#Check if each file exists and read it
		IFS=$'\n'
		for LIBRARY in $(echo "$LIBS")
		do
			if [[ -e "$LIBRARY" ]]
			then
				dd if=$LIBRARY of=/dev/null
			fi
		done
	else
		#File not readable. Find out why
		if [[ ! -e "$LINE" ]]
		then
			echo "$LINE does not exist!"
		else
			echo "You do not have permission to read $LINE"
		fi
	fi
done < /filename/to/read/from

replace "/filename/to/read/from" with path to a file that contains programs you want to be preloaded into RAM. Each program needs to be on its own line and have its full path. Ex:

/usr/bin/firefox
/usr/bin/evolution
/usr/bin/vmware

If anyone wants to give it a go and post some results, that would be great. My SSD would make it hard to tell if it was working or not since either way is fast.

Anyone who wants to test this: to test this, you'd basically need to see how long an app takes to launch after a reboot normally, then reboot again so the app is not in RAM anymore, run the script above and run the same app again. Here are the steps in point form so they are a little more clear:

1. Reboot
2. Start app (like firefox) and note how long it took to open
3. Close the app and reboot
4. Run above script
5. Start same app and note how long it took to open this time
6. Did the script make a difference?

This should show if it improved the load speed any. To make it permanent, just call the script above from rc.local, making it run at boot.

If you can, use larger apps, or ones that normally take the longest to load to make the difference more apparent.

Note: This is just a quick thing I wrote so I never bothered to save and run this. For all I know, there's a bracket missing somewhere (though I would have probably picked up on that). If it won't run, let me know. Also, if there's a better way to read a file so it's stored into RAM (not that there's anything wrong with the dd way AFAIK) let me know too.

If this works and gives good results, it will be funny how a script that I whipped up in 10 min in gedit, and that I never even bothered to save as I was working on it can accomplish the same thing as a script that took me a week to write, and had at least 5 different versions (save files at different stages of completion).

[jim_deadlock]

My installation went smoothly on 10.10 (32-bit) with a separate /home partition. I ended up with a 1.2G image so I need to delete some stuff to fit into my paltry 1G RAM but I'm unclear about this:

"If saving space on that partition is your goal, you can also remove the old /home files which are still in the same place they used to be, they just get hidden by the new /home partition."

Does this mean that if I delete some files in my original /home directory that will shrink my ramboost image so I can run it? Or do I need to delete stuff in /var/squashfs ?

[nolag]

Will it make a write back after issuing a shutdown? Otherwise all updates will go away with a simple reboot, and that would suck.

[terminator14]

My installation went smoothly on 10.10 (32-bit) with a separate /home partition. I ended up with a 1.2G image so I need to delete some stuff to fit into my paltry 1G RAM but I'm unclear about this:

Does this mean that if I delete some files in my original /home directory that will shrink my ramboost image so I can run it? Or do I need to delete stuff in /var/squashfs ?

"With a separate /home partition"? Did you already have that /home partition before you ran the script or did you give the script a device to copy your /home partition to?

That note means this:

If you gave the script a device to be your new /home partition, what it does is copy your existing files from /home to the new device. In then mounts the device as your /home in BOTH your original OS and the RAM Session. What happens on the original OS is that the original files at /home do NOT get deleted. When the device gets mounted at /home, it gets mounted OVERTOP of your old /home. That means there are still files there, you just don't see them unless you unmount your new device from /home.

The only use of seeing the old files is a) cleanup - to make sure old junk isn't just lying around or b) to delete the files and shrink the partition your original OS was installed on.

NEITHER reasons affect the RAM Session in any way. Finding and deleting your old /home files will NOT make the squashfs image smaller because these files are NOT copied over to the RAM Session.

What you are looking for is deleting files from /var/squashfs that you don't need, and then rerunning the squashfs recreation commands (see inside of script for commands needed - search for 'mksquashfs'). The easier way to accomplish this (the way that doesn't require you to recreate the squashfs image manually) is to just remove (uninstall) packages from your Original OS that you don't need and that take up tons of space. After you do that, rerun the script (you may need to tell the script to uninstall first to remove the image you already created) so that it can make a new, smaller image.

The thing is though, with 1GB RAM, not only will you need to remove enough packages from your OS to fit the image into RAM, but you will need extra RAM for the OS to use (every program you run makes variables and stores stuff in RAM). That means you either need to remove somewhere close to 500MB of stuff so that the 1.2GB image would now be about 700MB, giving you 300MB of RAM, or the more practical alternative, is buy a little more RAM.

In your case, the following won't help you but if anyone still wants to find their old /home files, you will need to not be using the /home before you unmount it. Since your desktop uses /home, you need need to shut down your entire GUI and drop down to the terminal. To do this, make sure no applications are running, open terminal and type:

sudo service gdm stop

which will take you out to the console. After that, you may need to hit Alt + <- (left arrow) or Alt + -> (right arrow) to get a console you can log into. Login, make sure you cd out of /home by running:

cd /

unmount the device from your /home with:

sudo umount /home

and restart the GUI with

sudo service gdm start

Your desktop, and the rest of your /home folder is now the old version of them. You can delete these files since you have a backup of them on the device that gets mounted at boot to your /home. To remount the device as your /home again, just reboot and fstab will do this for you.

As an alternative for people who know their way around fstab, you can also comment out the line in fstab that mounts /home, reboot, deal with your old files, restore fstab, and reboot again. Make sure to fix fstab when you're done or your RAM Session's /home and your Original OS's /home will not be synced.

[terminator14]

Will it make a write back after issuing a shutdown? Otherwise all updates will go away with a simple reboot, and that would suck.

It will NOT make a write during a shutdown. And you are absolutely right in that all regular updates will be undone after a reboot. This is why I wrote the rupdate script, which does not update the RAM Session you are running but instead runs updates on the /var/squashfs from which the squashfs image is created. It then automatically recreates that image, and replaces your old image with it. That means the squashfs image will get the updates, and after you reboot, your updates will stick. rupdate is easy to use and basically does everything for you to update your squashfs image.

Do NOT using the regular Ubuntu updater unless you want temporary updates that last until the next reboot. Use rupdate (which gets copied to your path so you can run it from anywhere using the terminal) instead. Try "rupdate --help" to see all the different options it comes with.

[jim_deadlock]

The first time I attempted an install with my original /home but that created a hopelessly large 13G image, so I uninstalled and then used Gparted to create a new partition and used it for the "separate /home" option during the install - I also did some cleaning with ubuntu-tweak before I started. Unfortunately my old computer is maxed out at 1G RAM but I think I may be able to clear out 500M worth of packages, it'll be a good spring cleaning exercise for me anyway.

[terminator14]

The first time I attempted an install with my original /home but that created a hopelessly large 13G image, so I uninstalled and then used Gparted to create a new partition and used it for the "separate /home" option during the install - I also did some cleaning with ubuntu-tweak before I started. Unfortunately my old computer is maxed out at 1G RAM but I think I may be able to clear out 500M worth of packages, it'll be a good spring cleaning exercise for me anyway.

Sounds like a plan. If you actually accomplish this, I'd be interested to know what packages you removed to clear up 500M.

[Slim Odds]

Sorry to say, but the original "solution" is overcomplicated to simply give the appearance of a faster system. The system is not really any faster since reading the applications and libraries must be read from disk at some point. And it is prone to too many potential problems.

I don't think that we are going to outsmart the linux file caching.

I actually liked the "preloading" the file cache idea. That one is much more natural, simple and does not have any side-effects.