Running Linux from ramdisk

English Install/Boot/Login
1

I recently bought 8GB RAM for my laptop and thought it might be interesting to try and get Linux running entirely from a ramdisk. I modified the initrd (/boot/83-mount.sh and /boot/84-remount.sh) to mount a 6GB ramdisk to /root, mounted the local harddisk to another directory and then simply copied everything with ‘cp -rxa --no-preserve=timestamps’ (the ‘–no-preserve=timestamps’ was necessary since otherwise the lxdm window manager would not start; dunno why) from the local harddisk to the ramdisk. Then I unmounted the local harddisk and modified the fstab accordingly.

Everything went fine (besides that strange behavior with the timestamps), however compared to running Linux from the local harddisk, which is a Kingston V+100 SSD, the entire desktop environment runs much less snappy. For example starting Firefox takes about 3.0sec when running from SSD while from ramdisk it takes over 5.0sec; starting Gimp takes about 4.0sec with SSD and 6.5sec from ramdisk. Also, the start of lxdm login screen and then the desktop screen after login is much much slower when running from ramdisk.

To simulate the loading of the window manager and applications and check if this slow behavior of the ramdisk might be due to a bandwidth bottleneck I created a 2GB file filled with /dev/urandom on the SSD. Copying this test file from the SSD to a ramdisk takes 3.6sec (simulating the loading from SSD), while copying this file from one ramdisk to another ramdisk (simulating the loading from the ramdisk) takes 3.5sec. So, the slow startup when running from the ramdisk does not seem to be due to a bottleneck of the bandwidth.

I am running openSUSE 11.3 with 2.6.37 kernel on a ThinkPad Edge 13" with Intel Core 2 Duo SU7300 processor and 2x 4GB Kingston Value RAM DDR3-1333 CL9.

Any ideas?

2

I don’t have a solution to your problem, I’m just curious.
Did you physically alter the initial install or did you create a new bootloader entry that booted openSuse into a ramdisk? Ideally, you could create a boot entry that was meant to save battery life that booted into RAM similar to Puppy Linux while still having a nice physical environment.

Did you perform a RAM test to make sure Linux indeed recognizes 8 GB and not just 4 GB? It should be in sysinfo.

3

Hi,

I tried a different approach and it seems to work ok. Sorry this does not help you directly either.

On booting the laptop, pressing one of the F-keys (F12?), allows selection of boot device.

Hence a new install of openSUSE11.3 could be implemented to the USB-stick.

Afterward mounting of internal HDD to access data was easy via Dolphin.

No change to installed OS was necessary and a normal start could be achieved with the HDD afterward if required.

No significant speed difference has been observed.

Michael

4

I simply boot with the modified initrd.

The 8GB are recognized properly.

5

Let me see if I get this right: You have a complete install of openSUSE on an USB stick including bootloader; you boot from the USB stick, create a ramdisk, copy the OS from the USB stick to the ramdisk and then run Linux from the ramdisk?

When you say that there is no speed difference, do you have a magnetic HD or SSD?

6

Hi Ezekeel,

The basic openSUSE11.3_32bit is on the USB device. Ramdisk, /, and /home partitions.

Initially I booted into a CD for a network install and installed to the USB.

On an HP laptop at boot time I have to hit one of the F-keys, its specified in the boot splash screen. This allows selection of the boot device.
Here it allows selection of either the internal HDD or the USB device.

The USB device also works on PCs but there the bios needs to be altered for boot device selection. If the bios is set to CD, USB, HDD. Then if its plugged in its used.

It can be used on machines which have ATI displays supported by the open drivers. The displays are set for auto detected. The PCs have two monitors set up as one large screen.
The PCs are setup under one user profile.
The HP laptop is setup under another user profile. For this it was necessary to give the DVI screen priority in case no external monitor was plugged in.
The user profile for the HP laptop also works on a Toshiba Satellite with an external CRT but here the DVI screen only shows white. I only tried this once as its my wife’s win7 machine. The machine was useable from the CRT interface.

The USB is a magnetic HD.

7

Hi Ezekeel,

wrt speed
– the HP laptop has SLED11-SP1 installed! Hence booting openSUSE11.3_32bit from the USB device the performance is faster.
– on a 64bit machine, booting openSUSE11.3_32bit from the USB device the performance is slower.
– on a 32bit machine, booting openSUSE11.3_32bit from the USB device the performance is about the same.

Michael

8

On 02/04/2011 11:36 PM, Ezekeel wrote:
>
> I recently bought 8GB RAM for my laptop and thought it might be
> interesting to try and get Linux running entirely from a ramdisk.

there is a long tradition of experimentation and inquisitiveness among
Linux users, enthusiast, converts, developers, hackers, and
n00bs…PLEASE take nothing i say as either fact or useful to
you–and, most important: Do not let this chill your quest for speed:

RAMDISKs have been around a long time…they gave an AMAZING speed
boost back in the days of 33MHZ processors, 4MB ram, slow rotating
50MB hard drives (if you could afford one that ‘HUGE’) and full MS-DOS
operating systems (and others) sold on five or six 1.44MB floppy
disks…WITH printed manuals (OS/2 was about 15 or 20 floppies but it
FAR exceeded the capability of MS-DOS and was full 32 bit…)

anyway: back then you could turn 1MB into a ramdisk, load it right and
you machine was like “simply FLY”…of course, back then RAM was
about a gillion times faster than that clunky hard drive…so, it
RAMDISK was really really GOOD !

ok, so zoom to today: unlike back then where DOS (and still Win today)
did everything it could to clean out RAM as fast as it
could–REQUIRING reloading app/system code into RAM often, often,
often, often…today on linux you are using a system which tries to
KEEP as much in RAM as possible to avoid reloading reloading
reloading…so the counterintutive observation made that the speed is
about the same (or even SLOWER) by stuffing stuff in a RAMDISK might
come from the decrease in RAM available to the system to use as IT
sees best…

and, consider the case when the size of the RAMDISK takes away enough
ram from system use that it FORCES the system to use the much slower
swap on hard disk (mag or not, it a megazillion times slower)…and,
think about managing the movement of bit back and forth between system
memory and ramdisk…ALL of that transiting must go through the same
‘pipes’ back and forth, back and forth, back and forth…whereas if
you just let the system keep it ALL in one place (system RAM) you
decrease total system load and management overhead tremendously…

see?

ps: there is a very highly likely i have no idea what i’m talking
about…so, go forth and experiment–prove me wrong, please!

but, do read some google finds on the use of RAM in linux/unix vs
whatever else you might have used before. :wink: and, ymmv!

–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.0.11, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

9

Yeah. I once played around with a ramdisk on my 386DX40. Put a copy of Xenon2 on it and it practically eliminated all the loading time. Not very useful in practise for me though since all the decent games needed the 4MB RAM for extended memory and games essentially was all I was interested in back in the days.

I know Linux uses some RAM for caching however I only used about 5GB of the available 6GB capacity of the ramdisk and since the tmpfs should be flexible and only use as much RAM as it really needs, this means I am still left with 3GB of free RAM. Even if you substract some RAM used for the internal GPU, there should be still enough left for running Linux with the very slim LXDE.

I was not using swap.

I also thought about that. When you store the OS on a ramdisk, for example on an application launch the program data has to be transfered from RAM to the CPU and then back into the RAM while with SSD the data goes from the SSD to the CPU and then into RAM. Thus the memory bandwidth used is doubled when using a ramdisk. This is the reason why I did that test with the 2GB file described in the initial post. And according to the results the memory bandwidth does not seem to be the bottleneck here. Maybe that test of sequentially transferring a large file is not a good simulation for the I/O which takes place when launching an application - it might be more random.

Believe me, I tried to find something about running Linux from a ramdisk, but there does not seem to that much out there especially when it comes to the actual performance.

10

There is a lot of calculations going on to emulate a disk in memory. In essence you need to make a model of a disk controller then map the disk sectors to the real memory locations all the while running the foreground apps and processes. For the SSD this is all done in hardware and though the SSD memory is not as fast as RAM all the controller functions are at hardware speeds and not constrained by time slices of the OS on the CPU. Also the default kernel may be a bit better because of smaller time slices optimized for servers. But that is a pure guess. :slight_smile:

11

On 02/06/2011 12:36 AM, Ezekeel wrote:
> Believe me, I tried to find something about running Linux from a
> ramdisk, but there does not seem to that much out there especially when
> it comes to the actual performance.

i think the reason for that is: there is not much to be gained (in
terms of speed or efficiency) by running a RAMDISK on a modern system…

and, you can’t easily find that info because it that was learned, and
discussed in detail, sometime last century…since google
concentrates on the web of TODAY you may need to look FAR back in the
search results to find what you see…

search old mail list archives (the SuSE archives go far back i think),
kernel archives, etc etc etc

as far as i know it is not possible to force google to search for all
hits before (say) the year 2000, only…but, if you learn how, please
tell me.

–
DenverD
CAVEAT: http://is.gd/bpoMD
[NNTP posted w/openSUSE 11.3, KDE4.5.5, Thunderbird3.0.11, nVidia
173.14.28 3D, Athlon 64 3000+]
“It is far easier to read, understand and follow the instructions than
to undo the problems caused by not.” DD 23 Jan 11

12

I found the thread looking around to see if any documented system/procedure for a full-RAM OS was described, other then mine.
I stretched down a comprehensive detailed explanation of how my system can work this way; scripts, modifications to initrd, and eventually ready-to-use filesystem image are all published in this post at linuxquestions forum.
However, it’s not a step-by-step guide and some skills and autonomy are required.

13

hello!

It is some time ago that you wrote this last entries on this thread, but fundamental technical information is no matter of time.

A lot of statements are definitly incorrect. You might have started to copy your system to ramdisk, but when having a look to your measurements i can tell you, that you had your system NOT running independent from your harddisk – without having analyzed any details.

IF your system would run independent in RAM and only in RAM i can tell you that even compared to fastest SSD it will be even another 10 to 100 times faster, dependent on the age of your system :smiley: (you should have at least 2GB of physical RAM available)
Also embedded systems must run from Ramdisk per default, without any harddisk in system.

You easily can see and feel the difference between running system from harddisk compared to running from RamDisk, when starting f.e. any Ubuntu live CD with option toram (option can be added by pressing F6 before starting CD)

THERE YOU ARE WITH REEEEEEEEEEEEAAAAAAAAAAALY FAST SYSTEM !!! :smiley:

for example starting libre office takes on first start about 15s to come up from a standard harddisk … from Ramdisk much less than a second

I am sorry - i don’t know how to do with suse live cd’s and if it is implemented there, but i am currently only too lazy to search for this information

… i am with you and hope to find some time to proceed with thinking about your way of trying to solve to run YOUR OWN system from RAM, because that’s what i like to have too … yeah! :slight_smile:

… ok - then it needs some syncing from time to time to keep the origin system updated

another example to see performance difference:
Currently i am upgrading which takes around an hour, because of millions of harddisk accesses … from RAM this would last less than a minute (apart from some user interactions) … sync the system back to origin (of course in background so it is not disturbing the user experience) would take even on slowest harddisks only 30 seconds. (time difference ~ 100 : 1 !!!)

AND !!! most important: if you are running a SSD: this is living much much longer, because only written to on sync approaches and those are not ramdom, they are sequential.
life time: also magnetic harddisks will live longer when not treated as hell all the time :smiley:

… so i must say: it would be a great benefit also on top modern systems
btw: there are currently cloud solutions in development EXLUSIVLY running in RAM and only there.

14

i found a good link, which describes to build a solution being able to boot either to standard system to maintain or to speedy Ramdisk system selectable with grub bootloader:

HOW-TO: Boot OS into RAM for speed and silence

15

btw: the solution on the beginning of the page is the fastest at all, because in comparison to liveCD ‘toram’ this is uncompressed taking also no time for uncompression.
… but needs of course also much more RAM to build (no problem any more on nowadays systems with 8GB and even much more RAM)

16

Do you <really> want to know why you’re not seeing any performance boost running in RAM?
The following applies to openSUSE 12.2 and later.

Run df and note all the runtime mounts that are configured for tmpfs, they’re already running in RAM instead of disk

df

The mountpoints that remain on disk are primarily read only (very little writing if at all) or persistent data like /home.

If you’d still like to analyze your bootup and where your bootup bottlenecks might be install the following

zypper in systemd-analyze

Run with the -blame and -plot switches to list and graphically plot the bootup components by the time they take to load.

Enjoy,
TSU

17

Please before you post you should read what others are writing. It is definitly incorrect, that there should not be a performance boost when running whole system ALREADY in RAM.
With mounts that you described there is not already your libraries and code already loaded there. Therefore it takes the time it needs to load from Harddisk.
Therefore first load of everything takes lets say kind of ages. Starting Google-chrome without preloading it takes on fast harddisk system 10 seconds. Close it and start it again and it will take less than a second, because it is cached in RAM.
THIS is the big difference !!!
If the whole system would already be loaded on startup to RAM, then EVERY first start of EVERYTHING is extremely fast. Best would be to have a battery buffered Ramdisk also being able to boot such a system REALLY very fast (nearly instant on). As i gave as example - even an upgrade of a system would take besides the time to download just a few minutes intead of hours and more.
This is no performance boost? Are you kidding?
Some “Gurus” are getting “high” when just gaining a few percent performance boost. I am talking about THOUSANDS of such percents !!! This is a fact.
But this example of doing this which is explained in this thread in the beginning is dealing with a compressed system. This compression algorithm is not as good performing than squashfs does (used in live CDs). THIS is the reason of his “low” gains.
BUT i was talking about an UNCOMPRESSED system copied to RAM 1:1
THIS is the system i like to have and i think i can achieve this goal myself – as partly explained above.

kind regards
Josef