So you want to mount / in RAM for a super-speedy system?
Here's what you need to make your gentoo FLY

/usr must be on it's own partition
/home must be on it's own partition if it's large or you use it for storage
/root must be on it's own partition if you're putting anything big in it
/var on it's own partition (so we don't fill up the RAM drive with logs/portage cache)
an empty directory called /newroot
You must have a partition to store the tarballs on (I use the same partition that ends up being /root) and it can't be /usr.
Maybe use the partition that was / during the install
computer must have a spare 176MB of RAM or so.
(Depends how much you want to load into RAM)
You need to have ramdisk, initial ramdisk, loopback device support in the kernel, not as modules.
These choices can be found under block devices, which is under device drivers.

The amount of performance boost in order of magnitude, by which is loaded into RAM seems to be
/usr/lib
/lib
/usr/bin
/bin
/usr/sbin & /sbin

Step 1
Install as normal

Step 2
generate the tarballs that will populate our RAM drives
put this in /sbin so you can run it should you update your system (make sure STORE is mounted first if applicable!):

nice howto, thank you!
I´ll test it anyway, but do you notice some performance-boost? I´ve tried to put some files and libs on a ramdisk before, but it wasn´t faster than it was without..._________________Join the adopt an unanswered post initiative today

/usr must be on it's own partition
/home must be on it's own partition if it's large or you use it for storage
/root must be on it's own partition if you're putting anything big in it
/var on it's own partition (so we don't fill up the RAM drive with logs/portage cache)
an empty directory called /newroot
You must have a partition to store the tarballs on (I use the same partition that ends up being /root) and it can't be /usr.
Maybe use the partition that was / during the install
computer must have a spare 176MB of RAM or so.
(Depends how much you want to load into RAM)

Do you mean I should create more partitions and update my /etc/fstab, or is it okay to let these on my root-partition? Do I generally have to edit my fstab file?

Joined: 23 Dec 2004Posts: 790Location: under a car or on top of a keyboard

Posted: Tue Feb 22, 2005 12:52 pm Post subject:

paperp wrote:

Just an info for a non geek ; if i move lib e usr/lib on ram , usual apps like firefox , evolution and maybe X itself take a big advantage in term of speed??

Apps open instantly, but they don't run any faster. What this does is eliminate the bottleneck of loading the applications and their dependent libraries into RAM off the HD. Also, RAM seeks WAY faster than a HD, so if multiple instances of an app are called, the system doesn't sit and chug for 10 minutes while the hard-drive tries to do 100 things at once.

I set this up on an LTSP server with 1GB of RAM and it was quite fast with 4 clients connected. I then powered up the other 30 workstations and it ran out of RAM (because they have KDE on the silly thing) and ran horribly because it was swapping. 30 KDE desktops sure use a lot of RAM (about 40MB a piece). The RAMdisk was 512MB and had /bin, /sbin, /lib, openoffice firefox, AND most of /usr/lib on it.

Joined: 23 Dec 2004Posts: 790Location: under a car or on top of a keyboard

Posted: Wed Feb 23, 2005 5:18 am Post subject:

Hmm, you guys are missing a big plus to this. By putting critical things on a RAM drive and umounting the partition that holds the tarballs and the update script, you are preventing changes to those files except when you run the script to do so. If someone were to h@><0r your b0><0r, they'd be changing things in a RAM drive that is flushed as soon as you reboot! This is also awesome fun for a honey pot running SSH with a typical password or a service with a well known vulnerability. You can see how people go about exploiting these boxes by simply diffing the filesystems and learn how to better secure your _real_ servers (which are also packing a root RAM drive for security).

To those of you with large /usr/libs: did you look to see what was using the space? I'm just curious. If you use rox-filer, there's a nice count feature that tells you the total folder size for multiple selected folders. You can get a nice idea of where your disk-space is going.

Also, you can easily make a folder in /usr called preload (or whatever) and mount that in a RAM drive, link things back to /usr/lib and the silly symlinks that rely on .. to point to /usr will still work The lets you pick and choose what is loaded and what isn't loaded into RAM very eaily and could be automated with a simple bash script.

odegard:

My buddy Cory is working on one of these right now that takes the binary name as an argument and copies it and all it's dependent libraries to a tmpfs mount and links back to the original after renaming the originals .whatever. The script will soon have start and stop functions and take a config file. Might make an interesting addition to some people's init scripts.

Also, btw, I have shown this to a hard core winblowz user who swore he'd never convert to using linux on his desktop because it appears slower (even though his HTPC I made him runs KDE on gentoo on a dual AMD 1800+ box ) He was jealous.

People like me are working towards making linux easier for the windows transition crowd. Having apps startup fast is a big thing for those people (especially if they've spent a ton of $$ on a computer already so it will have acceptable performance under windows). Other projects this particular gentooer is working on include a GUI based livecd and various lightweight stage4 tarballs that can be rebuilt with -e world transparently after install, to allow people to install a working gentoo OS with under 5 minutes of interactivity (and that in a gui) along with post-stages that will add functionality in different areas as binaries and then be easily recompiled/optimized later. All use ebuild and portage. Look out for more howtos

I love Gentoo.

Last edited by thebigslide on Wed Feb 23, 2005 5:27 am; edited 3 times in total

Joined: 23 Dec 2004Posts: 790Location: under a car or on top of a keyboard

Posted: Wed Feb 23, 2005 5:22 am Post subject:

failcase wrote:

Hey there,

nice guide, but some parts are hard to understand I think.

Quote:

/usr must be on it's own partition
/home must be on it's own partition if it's large or you use it for storage
/root must be on it's own partition if you're putting anything big in it
/var on it's own partition (so we don't fill up the RAM drive with logs/portage cache)
an empty directory called /newroot
You must have a partition to store the tarballs on (I use the same partition that ends up being /root) and it can't be /usr.
Maybe use the partition that was / during the install
computer must have a spare 176MB of RAM or so.
(Depends how much you want to load into RAM)

Do you mean I should create more partitions and update my /etc/fstab, or is it okay to let these on my root-partition? Do I generally have to edit my fstab file?

Sorry if some of those questions sound stupid to you, but I'm really lookin forward to try it out

Sorry I missed your post earlier.
You must have any large folder on it's own physical partition on the disk.
You will have to edit fstab if you'd like the partitions mounted by gentoo automatically.
/var especially must be on it's own partition or someone can DoS your logger and maybe other things by making it fill up the RAM drive.

nah, i´ve tried to try it, but i´ve failed with the common "kernel panic: unable to find init. Try passing init= at the kernel line".
Initrd is found, kernel boots fine, then this error. But:
-i HAVE linuxrc
-i HAVE passed the option

dunno. I remember having this probling when i built my own stage4-livedvd, and i fixed it, but i can´t remember how.
And i´ve read almost any post on this forum that´s related to this.
K, some description:
-linuxrc is on / in my initrd
-line from grub:

Code:

kernel /bzImage root=/dev/ram0 rw init=/linuxrc ramdisk=32768

-i also changed the init= to every path i could think of and copied the file everywhere, no go.

hi,
@thebigslide:
linuxrc is executable, works if i start it by hand, and if i set init=/bin/bash i get a shell and can do my job.
Only if i call linuxrc it doesn´t work, even if i copy it to /bin and call init=/bin/linuxrc from grub. Dunno.

Thanks for the help, maybe s/o has another answer for me

Another one:
if i call "pivot_root . newroot" it tells me "no such device...". It only works for me if i set newroot to some available directory.

Now a tip from me:
I don´t use your tar-solution for /bin, /sbin etc. Instead i use my old root-partition which i mount in /store. Then i copy over /bin, /etc, /sbin, ... to my root-ramdrive (~50mb), unmount /store and proceed. So i don´t need to modify localmount and don´t need to untar (takes too much time for me)

you need to mkdir /newroot on your root filesystem before tarring it up Wink /newroot is the path that the initrd will reside at following the pivotroot so it must exist for the command to be executed.

yeah, i noticed this

Anyway, ´til now there´s no great speed gain. Not that i would notice it, at least. I´ll try moving some of the "most-wanted" libs to the ramdisk, maybe things´ll change then. All of ´em won´t work since my /lib is 1.5G...
Any ideas what else could help speeding things up? I´ve got ~550mb ram free _________________Join the adopt an unanswered post initiative today