Thank you very much for the suggestions. I will see what I can do with the features you are asking for.

I do apologize for the late reply but regarding your comment on testing it on your netbook, I wanted to share with you that in my development of all releases, my netbook and also a VirtualBox guest on that same netbook were used. Although, nothing would compare to utilizing the power of a 64-bit server…

My reason for such a suggestion would be that a location will never be just an integer, so whether returning an error or location, it would be very simple to differentiate between the two

rxadm returns a zero exit status if no error occurs during operation. A non- zero value is returned on error.

Instead of returning a zero, might I suggest returning the location of the rxdsk device. This would allow piping for any further operations outside of the program scope. Admittedly, this entails checking that what gets returned isn’t an error through current modus operandi, but that’s not so much a problem.

For the case where errors do occur, initial speculation presents two methods to make this work:

- Return a 0 on failure. User can call “rxadm –errors” for feedback
- Have an index of error codes:
0 – success
1 – Operation failed due to permissions
2 – Operation failed due to insufficient space
3 – Mounting archive failed due to read problems

Just some food for thought. Kudos

- LAMP stack with multimedia deliverables
- Virtualbox deployment

I am currently away from a big rig but will be able to test it out using my netbook and would happily provide some feedback. I wonder if using such a resource constrained device will make a bigger difference.

Again, thank you for your great work

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.

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.

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

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

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.