Home > General Storage Devices, Linux, Red Hat, Storage, System, Ubuntu, Virtual Memory > Announcement: RapidDisk (rxdsk) 1.2b Stable release

Announcement: RapidDisk (rxdsk) 1.2b Stable release

August 27th, 2011

I am writing to announce the update release of my Linux RAM disk kernel module RapidDisk (rxdsk). It is currently at a stable 1.2b release with optimizations to the configuring of the request queue of each rxd block device and also with added checks for the module to build from kernels 2.6.32 all the way to the latest (currently 3.0.3); this includes the addressing of the deprecated command blk_queue_ordered() found in 2.6.37 and later. More information can be found at http://rxdsk.petroskoutoupis.com.

  1. simon
    August 28th, 2011 at 10:12 | #1

    Another release so soon, it’s a good job the seasons are changing in favour of cooler times as you are on fire.

    Suggestion:
    The user passes a parameter to system referable location at disk attachment, and the RAM disk matches that in size as a readable location. An administrator could just dump what they like in the store and it would be readily available.

    For example:
    sudo rxadm –mirror 192.168.100.0/24(r) –target /home/mymirror/

    In my humble (and hypothetical) opinion, it would make thin desktops quite a bit swifter in terms of operation after the initial boot. Just an idea from a follower.

  2. simon
    August 28th, 2011 at 11:49 | #2

    I would please have it be known when i specified location, I didn’t just mean a network address. Poor use of English there, apologies.

    At simplest, it could be:

    - Initiate RAMDisk
    - Check location disk usage (Another example = /home/username/folder/)
    - Adjust RAMDisk size
    - After use, try to write changes back to original location, if specified

    Positives :

    + Faster every day computing in terms of IO
    + Easy to set up a disposable computing environment

  3. pkoutoupis
    August 29th, 2011 at 07:29 | #3

    @simon
    I think you offer some excellent suggestion and procedure. I will need to do some research (for instance) with the mirroring concept and see if there is any benefit to rewrite the logic as opposed to utilizing rsync. Having the logic built into rxdsk may make the sync’ing to the mirror location a lot more elegant. I would just need to figure out appropriate moments to ensure that the latest of rxdsk data is written to disk. I would imagine that the majority of functionality would reside in userspace with the possibility of some hooks in the rxdsk module code to handle some “extra functionality.” Again, thank you.

  4. Matt
    September 26th, 2011 at 09:54 | #4

    Hi Petros,

    This module sounds very interesting! Thanks for your hard work. I have an idea/question:

    I am interested in using a ramdisk of some type to hold log files (to minimise disk wear on an SSD-based system). At the moment you can do this quite easily with startup scripts, but the result is quite brittle and distro-dependent.

    I would be very interested if rxdsk would allow me to mount a ramdisk at some mountpoint (/var/log in this case), but optionally copy all of the existing files under that mount point into the ramdisk so they can be modified by the system logger.
    Then, at detach time, rxdsk would copy all of the files in its volume back into the mount point’s underlying storage. Perhaps there could be a “sync” option added to rxadm to manually do this – which could possibly be put in cron job.

    Bonus points if you are able to perform the attach/detach process transparently while the logger is adding to them! (no idea if this is possible)

    Do you think this is possible? Of course, it might be well outside the scope of what you think rxdsk should do. However, for what it’s worth, I would love to see this feature.

    Thanks a lot :)

    • pkoutoupis
      September 27th, 2011 at 14:49 | #5

      Matt,

      Thank you very much for your interest. It has been suggested earlier by someone else to add support for mirroring (archiving)/restoring to/from persistent storage. This would potentially be the same thing, at least how I view it; that is (not necessarily in this order), create the ramdisk, mount it, copy data from other path to it and when time comes to unmount the device, you can then do some sort of copy back (or rsync, etc.) to the original persistent location. The problem in this scenario would be, that you would have to first mount it to a temporary location, copy /var/log contents to it, umount the rxdsk from the temporary location and then mount it to /var/log. In turn, to copy the new data back to the persistent location, it would need to copy that data to a temp location and then umount the device before taking the data from the temp and copying it to the original.

      I don’t think there is a real easy way to do this in realtime, specifically because while all of this is happening, syslog is adding these umount/mount entries into a messages file and anything else in-between, and vital could be missed. It does require some thinking and if I come up with anything I will be sure to let you know.

      Also, if you have anything else to add, feel free to contact me at devel@petroskoutoupis.com.

    • pkoutoupis
      September 28th, 2011 at 12:17 | #6

      Although a second thought came to me…
      It would be possible to limit the amount of syslog writes into your /var/log path and reconfigure syslog-ng (or whatever logger you use) to write the more critical levels of messages to /var/log and in the meantime, using rxdsk or tmpfs mount a new volume to /var/tmplog (or whatever), and have it write the more informative and lesser critical messages to that. And when complete and gracefully shutting the system down, use logrotate to then archive those back into /var/log. In every scenario that I can think of, you will always run the risk of not preserving all messages which can cause headaches down the road. I will still spend some more time thinking about this unique setup.

      If you wish to optimize other portions of your OS (especially to limit the writes to an SSD), check out one of my earlier postings (also read through the readers’ comments): http://blog.petroskoutoupis.com/?p=245. You will find a lot of useful info.

Comments are closed.