Home > General Storage Devices, Linux, Red Hat, SCSI, SSD, Storage, Ubuntu > Announcement: RapidDisk (rxdsk) 1.0b Stable release

Announcement: RapidDisk (rxdsk) 1.0b Stable release

July 16th, 2011

I am writing to announce the release of my Linux RAM disk kernel module. Yes, the Linux kernel has the brd module already integrated into it, and also the zram module it the staging tree. And yes, you can instead utilize ramfs or tmpfs for RAM based file systems. But RapidDisk or rxdsk is a bit different.

Unlike brd or zram all attached RAM disk are populated on-the-fly with any user defined size and not during the module’s insertion (i.e. typically system bootup) with a fixed size. When you attach a new RAM disk, you can define sizes as little as 16 Mbytes and in theory as large as 1 TByte and possibly above and it is designed to allocate new kernel pages as needed; so it won’t steal all memory when the RAM disk is created.

Unlike ramfs or tmpfs, an rxdsk volume can easily be exported as a physical device across a SAN or simply allocated as a SWAP space which would become more ideal when the LZO compression is completed and stabilized.

This type of technology could be used for quick I/O storage (configured as a DRAM-based SSD with enabled syncing to persistent storage) and mounted as a block device labeled with a traditional file system and functioning as a traditional storage device; Application and/or database caching; File system meta-data caching; Virtualization (when data compression is developed and/or while running another data deduplication solution on top of the RAM disk); and as mention above, a CompCache replacement for enabling compressed swap space into RAM (again, when compression is developed).

For more details, please do not hesitate to visit the project’s wiki page. Here you will find details on how to check the source code out from the git repo, build & install it, among other things including performance numbers (writing 1 GByte sizes in 3 seconds!!!) to community involvement. The kernel module is licensed under the GPLv2 while the management utility is licensed under the GPLv3.

Note - So far this has only been tested and seen as fully functional on the 2.6.32 and 2.6.35 kernels.

  1. jason
    July 17th, 2011 at 09:00 | #1


  2. Piotr
    August 4th, 2011 at 09:01 | #2

    You should consider google’s snappy instead of lzo, snappy have only a bit worst ratio but is many times *faster* than lzo.

  3. pkoutoupis
    August 5th, 2011 at 10:13 | #3

    The reason why LZO was picked was because it is one of two compression (LZO and zlib) algorithms already supported within the kernel’s mainline. You can reference this in the /lib directory from the root of the Linux kernel source tree. Although thank you for the suggestion, I am intrigued to learn more about Google’s snappy (http://code.google.com/p/snappy/). I will be sure to keep it in mind if I ever need to rely on compression/decompression in user space.

  4. segoon
    August 8th, 2011 at 07:55 | #4

    Did/will you try to push it upstream?

  5. pkoutoupis
    August 9th, 2011 at 10:21 | #5

    I assume you mean to the mainline kernel. If so, then yes. That would be my eventual goal but after I get the compression among a couple other little features in and stabilize it.

Comments are closed.