8

I want to create a fixed size Linux ramdisk which never swaps to disk. Note that my question is not "why" I want to do this (let say, for example, that it's for an educative purpose or for research): the question is how to do it.

As I understand ramfs cannot be limited in size, so it doesn't fit my requirement of having a fixed size ramdisk.

It also seems that tmpfs may be swapped to disk. So it doesn't fit my requirement of never swapping to disk.

How can you create a fixed size Linux ramdisk which does never swap to disk?

Is it possible, for example, to create tmpfs inside a ramfs (would such a solution fit both my requirements) and if so how?

Note that performances are not an issue and the ramdisk getting full and triggering "disk full" errors ain't an issue either.

  • I guess this answer your concern cyberciti.biz/faq/howto-create-linux-ram-disk-filesystem – Kiwy Jan 27 '14 at 14:57
  • possible duplicate of Creating a ram disk on Linux – Kiwy Jan 27 '14 at 15:02
  • To use an actual ramdisk (and not tmpfs or ramfs), you will need support built into your kernel, which some distro kernels may not do that anymore -- or else it is a module. See if you have any ram devices in dev. If not, try modprobe rd. – goldilocks Jan 27 '14 at 15:20
  • 1
    I don't think this question is a duplicate since none of the answers addresses the size restriction and the swapping. – Marco Jan 27 '14 at 16:14
  • 3
    When people ask you why you want to do something, it's because what you're asking sounds a little (or at lot) crazy to them. "Hmmm, he's asking for a really convoluted way to accomplish X, does he know about the do-X command?". Sometimes its also because there are multiple ways, and the right one depends on why you're doing it. E.g., if you ask how to delete a bunch of files, the way to do it depends on why—rm is great if you need to free disk space, but not so much if you need to blank a disk for disposal. So, in summary, I'm going to go ahead and ask... why? – derobert Jan 27 '14 at 20:57
5

This is just a thought and has more than one downside, but it might be usable enough anyway.

How about creating an image file and a filesystem inside it on top of ramfs, then mount the image as a loop device? That way you could limit the size of ramdisk by simply limiting the image file size. For example:

$ mkdir -p /ram/{ram,loop}
$ mount -t ramfs none /ram/ram
$ dd if=/dev/zero of=/ram/ram/image bs=2M count=1
1+0 records in
1+0 records out
2097152 bytes (2.1 MB) copied, 0.00372456 s, 563 MB/s
$ mke2fs /ram/ram/image
mke2fs 1.42 (29-Nov-2011)
/ram/ram/image is not a block special device.
Proceed anyway? (y,n) y
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
Stride=0 blocks, Stripe width=0 blocks
256 inodes, 2048 blocks
102 blocks (4.98%) reserved for the super user
First data block=1
Maximum filesystem blocks=2097152
1 block group
8192 blocks per group, 8192 fragments per group
256 inodes per group

Allocating group tables: done                            
Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done
$ mount -o loop /ram/ram/image /ram/loop
$ dd if=/dev/zero of=/ram/loop/test bs=1M count=5
dd: writing `/ram/loop/test': No space left on device
2+0 records in
1+0 records out
2027520 bytes (2.0 MB) copied, 0.00853692 s, 238 MB/s
$ ls -l /ram/loop
total 2001
drwx------ 2 root root   12288 Jan 27 17:12 lost+found
-rw-r--r-- 1 root root 2027520 Jan 27 17:13 test

In the (somewhat too long) example above the image file is created to be 2 megabytes and when trying to write more than 2 megabytes on it, write simply fails because the filesystem is full.

One obvious downsize for all this is of course that there is much added complexity, but at least for academic purposes this should suffice.

  • The loopback mounted file is subject to swapping... – vonbrand Jan 30 '14 at 14:24
1

The (dated!) book "Linux Device Drivers" by Corbet, Rubini and Kroah-Hartman has an example driver that just allocates a fixed memory area for fooling around. Not a file system, but...

-1

Cannot be done. All RAM is subject to paging by both CPU hardware design and Linux microkernel design. There are NO legitimate reasons for treating memory otherwise. ALL software algorithms CAN be adapted to use file caching scheme and paged memory. Virtual is ALWAYS better and more efficient.

RAM disks of limited size go counter to the foundation principles of the virtual world. You must assuming that only useful files requests are being made to the host file system and that all such requests have equal importance and priority in the virtual world (the only model that counts).

It has been mathematically proven that even Real time processes fit this rule. If you got a speed problem it CAN NEVER solved by using RAM as storage == the whole host system needs to operate faster from CPU to I/O bus to permanent storage device. All but artificial degenerate computing problems have sufficient branches and file I/O requirements that the average speed increase of RAM caching is the best you can do.

  • Cannot be done. All RAM is subject to paging by both CPU hardware design and Linux microkernel design. Wrong: "mlock(), mlock2(), and mlockall() lock part or all of the calling process's virtual address space into RAM, preventing that memory from being paged to the swap area." – Andrew Henle May 9 '18 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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