The traditional Linux RAM disk can only be statically loaded at boot time with a fixed size for all volumes; no more than 16 MB each. This Megabyte value can be adjusted but the result is still the same. You can reference the brd code of the Linux kernel for more details on this. Low capacities and not very manageable. I was primarily inspired by the Solaris implementation of their ramdisk module and the user land tool to accompany it, ramdiskadm. I was also partly inspired by the FreeBSD implementation called md or Memory Disk. My Linux module allows for dynamic creation and removal of RAM-based block devices for high performance computing at sizes varying from 16 MB to as high as 1 TB and larger. Plus it incorporates more up-to-date features and functionality.

Also, all other Linux implementations of RAM disks exist as file systems in memory. These include tmpfs and ramfs. These file systems are not always the most ideal solution to achieving high performance.

Achieving high performance played a big role but it was also a combination of a project that Petros Koutoupis started as a result of writing an article for a Linux publication about the Linux RAM Disk and the Solaris implementation of their ramdisk module.

Aside from increasing productivity with little to no bottlenecks in accessing data, there is also the opportunity to save costs in cooling. For instance, if a lot of frequently accessed data is moved to a stable and redundant RAM disk, there is less need to access mechanical Hard Disk Drives which contain a lot of movable parts and in turn use a lot more power while generating significant amounts of heat. Data centers around the world invest a lot of money in cooling, to keep their equipment operational in moderately cool and stable temperatures.

As much as you see fit to do the job. So long as you do not exceeds the system's limitations. We are not responsible for misuse or miscalculations and are not responsible for managing that for the user. As the user, you will need to determine how much the operating system will need to manage everything else and how much it can afford to use for our RAM disks.

If and when this project matures, I will begin to provide binary (rpm & dpkg) packages to some of the major distributions. For now, the only way to get the code is to clone it from the git repository and build it from source.

As mentioned above, to build the rxadm management utility, you will need to have the zlib libraries and zlib development files installed on your host system. As of 1.3, the build links to zlib for compressed archiving and decompressed restoration of rxdsk volumes. The idea is to take an existing volume and compress up to the last allocated sector which the module keeps track of (sent to rxadm via an ioctl() call) to a local file. This concept will save storage space for both the archives and the restored volumes. The latter of which is determined by the the last allocated sector prior to archiving. Note - It is advised to unmount the rxdsk volume before archiving.

I do not know the reason behind this but if you are using an rxdsk block device (alongside a physical block partition or a file configured as a loopback device) in an md RAID 1 mirror, fsync's sent to the md volume will fail the rxdsk block device. This has been observed with mdadm version 3.1.3-0 (Fedora 14) and 3.1.4 (Ubuntu 11.10) but does not occur on the older releases of Red Hat/ CentOS 5.x with mdadm version 2.6.9-x. This problem is not unique to rxdsk but will also occur with the kernel's already integrated brd RAM disk module (i.e. /dev/ram0, etc.) and seems to be more related to the md module. Again, this only occurs with a RAID 1 mirror. I also tested RAID levels 0 and 5, both of which do not exhibit the same problems with fsync. Sending an fsync to the rxdsk volume while it is not in an md RAID 1 array will not exhibit any problems. I submitted a bug report for this to the kernel team here.

Another thing to note is that on Fedora 14, when configured in the md RAID 1 array, any and all ioctl commands sent to the rxdsk block device will result in the following messages to appear in the kernel log:

I cannot explain this either. For whatever reason, even when you disable the md RAID, the ioctl errors still continue to the RAM disk, at least until you detach and re-attach it. These are the only known and documented issues while using an rxdsk volume in an md RAID.

Update - A fix for this has been addressed in version 2.4. The core issue was that the MD RAID 1 array was routinely sending an I/O command of 0 bytes which would cause a return value (initialized to EIO) to fall through the I/O handling routine and return back to the calling process with an error. Thanks go to Dmitry Trikoz of Stratus Technologies for finding this and providing a solution.

The best part of this solution is that it is free. It will only cost you a bit of time to learn, test and configure the solution. And if you need help, I offer support and consultation services and nobody knows my code better than me. For more information, please visit the Support page.