I have a machine with 62GB of RAM, and a trunk that's only 7GB, so I thought I would create a RAM disk and compile there. I am not a Linux expert. I found instructions on the internet to create the RAM disk:

mkfs -q /dev/ram1 8192

but I changed the 8192 to 16777216 in an attempt to allocate 16GB of ram disk.

Did you try tmpfs? It is a filesystem in RAM, no need for ext2. mount -o size=16G -t tmpfs none /mnt/tmpfs
– t-8chFeb 27 '13 at 18:17

That worked! Thanks! But so far, not much speed-up: I think the tools I'm using to build are still using the regular disk. I'll put more stuff on the ram disk.
– FrankFeb 27 '13 at 18:24

3

Putting the tools themselves on the ramdisk shouldn't make much difference as the kernel will cache them anyways in ram.
– t-8chFeb 27 '13 at 18:28

1

@goldilocks It's anecdotal evidence, but when compiling our Java projects with Maven, there is a significant speedup when using a ramdisk. I would guess though that this is more because of seek time than read time.
– SpellingDFeb 27 '13 at 18:54

on my system, with nothing at all in /mnt, it says: ls: cannot access /mnt/tmpfs: No such file or directory mount: mount point /mnt/tmpfs does not exist. Is that something to worry about? If I simply mkdir /mnt/tmpfs, does that defeat the purpose (by creating tmpfs on the regular disk - please no flames, I'm a beginner here).
– FrankFeb 27 '13 at 19:23

9

You need a mountpoint (directory) as target, so after you created this directory (you can use any directory, existing contents are shadowed) you can mount it with the command from the answer.
– t-8chFeb 27 '13 at 19:26

1

tmpfs may use swap, which you probably do not want in a pure RAM disk.
– palswimAug 17 '17 at 17:55

2

@RomanSusi tmpfs is the filetype (passed after -t). "none" is the backing device ("disk") which does not exist for tmpfs
– t-8chApr 29 '18 at 21:24

1

It may be worth noting that specifying the size is optional. It defaults to half of RAM. There's no overhead from specifying a higher size, all it does is set a cap, to protect yourself from accidentally using all your RAM and killing the system.
– sourcejediSep 22 '18 at 12:54

Linux is very efficient in using RAM. There is little surprise that you see little if any speedup with tmpfs. The largest pieces to read into memory (and thus able to slow the process down) are the tools (compiler, assembler, linker), and in a longish make they will be loaded into memory at startup and never leave it. What is left is reading in source (the writing out of the results won't slow you down, unless severely memory constrained). Again, comon header files will stay around, only the user's source will require reading. And that is unlikely to be more than a few megabytes. Creating a large RAMdisk (or even much use of tmpfs) can very well slow things down (by making the build memory constrained, the files on RAMdisk or on tmpfscan not be used directly from there).

@Kazark, to handle executables in memory special data structures are used. As RAMdisks and tmpfs aren't in common use to store executables (RAMdisks are a remnant from the good old days of excruciatingly slow floppy disks and such, tmpfs is for stricty temporary data), nobody has considered it important enough to add the required ugly hacks.
– vonbrandFeb 28 '13 at 16:39

8

I have tried running my rails code from a tmpfs (RAM) filesystem, and I did not see any difference at all. I was really hoping for a noticeable difference but I was disappointed by how awesome linux is.
– Khaja MinhajuddinMar 4 '13 at 19:25

The problem is that the maximum size of a ramdisk, more specifically of size of memory that can be accessed via the ramdisk driver is configured at compiletime, can be overwritten at boottime, but remains fixed once the kernel is loaded into memory. The default value is probably measured in Megabytes. If I recall correctly the memory for a ramdisk is reserved right when the driver is loaded, all ramdisks are the same size and there is are some 16 ramdisks by default. So not even you want a ramdisk size of 16G :-)

As stated in the other answer, tmpfs is what you want to use. Further, you won't win a lot by having your entire OS in a ramdisk/tmpfs. Just copy your builddir to a tmpfs and do your compiling then. You may have to ensure that all temporary results are written to a location thats in the tmpfs as well.

They don't actually use any memory until you write things to them. The boot time limit is just the limit. Even after filling one you can free the memory back up with blockdev --flushbufs.
– psusiFeb 28 '13 at 13:57

@psusi: can you give us more information on that? I can only find statements mentioning that once claimed by the ramdisk memory is never reclaimed, e.g. in Documentation/blockdev/ramdisk.txt in the kernel sources. And on my answer: that file also says the ramdisk grows as memory is consumed so it is not all allocated at once.
– BananguinMar 1 '13 at 14:46

What sort of information? You run the command and it frees the ram, assuming you don't still have it mounted anyhow.
– psusiMar 1 '13 at 15:13

How do you know that the command does what you say it does? Its man page doesn't confirm that and the documentation in the kernel source tree can be understood to contradict your information.
– BananguinMar 1 '13 at 20:40

6

I read the source code, and verified it by trying it.
– psusiMar 1 '13 at 20:50

Using brd kernel module (/dev/ram0)

The rd_nr parameter specifies how many RAM disks to create (by default, it creates 16, i.e. /dev/ram0 through /dev/ram15). The rd_size parameter is size in kilobytes. The $(( ... )) syntax lets you do arithmetic in the shell.

To deallocate the RAM disk, unmount it and remove the brd kernel module:

The truncate command creates an empty file of a given size such that it is initialized (i.e. consumes memory) on-demand.

To deallocate the RAM disk, umount it and delete the disk image:

umount /ramdisk
rm /ramdisk-storage/ramdisk.img

Comparison with tmpfs and ramfs

Although tmpfs and ramfs are more efficient than using a block device, below are some of their downsides.

tmpfs may swap to disk. This is more efficient, but there may be times you want a pure RAM disk:

The files you are working with are sensitive (e.g. files from an encrypted partition).

You are doing performance testing and you don't want disk I/O to be a factor (SSD write times can vary a lot).

You are unpacking a large file and you don't want to wear out your SSD.

ramfs is easy to set up, reclaims space once you delete files, and uses RAM more efficiently (the system does not buffer the files because it knows they are in RAM). But it has its own downsides and surprises:

There is no size limit parameter. If you put too much in the ramdisk, your system will hang.

Sparse files can become unsparse when you least expect it. This morning, I copied a VM image (150G, but 49G used on disk) to ramfs (I have 128G of RAM). That worked. But when I copied from the ramfs to the destination, my system became unresponsive. The cp utility apparently filled the holes on read, but not on write.

Both tmpfs and ramfs may behave differently than a real ext4 filesystem. Creating a block device in RAM and initializing it with ext4 avoids this.

You can mount a ramfs filesystem, copy your project into it and work from there. This guarantees your input files are loaded in to RAM, and they will not be re-read from the much slower disk drive. However as you discovered, this is generally not a useful strategy. You already get the exact same benefit.

Ramfs is a very simple filesystem that exports Linux's disk caching
mechanisms (the page cache and dentry cache) as a dynamically resizable
RAM-based filesystem.

If you run tests of a program that involves fsync(), running these in a filesystem like ramfs may speed them up. Another strategy is to try and disable fsync() with eatmydata / nosync.so.

Some other operating systems might have specific limitations, that can be bypassed using a ramdisk. At one end, the lack of any file caching is why ramdisks were popular on DOS.

tmpfs

tmpfs works the same as ramfs, except that it can use swap space if you have one. I.e. if you need RAM for something else, the Least Recently Used algorithms may select data blocks from tmpfs and swap them to disk.

Most people stick with tmpfs, because it also lets you limit the total size, and shows the space used correctly e.g. in the df command. I'm not sure why this difference exists. The size limit in tmpfs protects you from accidentally filling your entire RAM and basically killing your system. It defaults to half of your RAM.

Other reasons why writes can slow down

The above is a simplification tailored to your case. The writes to files in your case should not need to wait for the disk. However there are some cases of writes that do. See the excellent blog post Why buffered writes are sometimes stalled. The most surprising case is a recent change to Linux called "stable page writes".