Playing with RAM disks on OpenSolaris 2009.06
After writing my article on The Linux RAM Disk for Linux+ Magazine and also after writing a very generic Linux RAM disk block device module, I decided to play around with the concept of RAM disks on OpenSolaris 2009.06. I must admit that this was actually a very great learning experience. One that I wish to share with the reader. Note that this post will be separated into two section: (2) tmpfs and (3) ramdiskadm.
TMPFS
While the tmpfs module exists across multiple operating systems, including Linux, the Solaris/OpenSolaris version does differ quite a bit its Linux counterpart. It is also not as flexible as the one found in Linux. For instance, on the Linux version you have the following supported user-defined module parameters (for more details, please reference the Documentation/filesystems/tmpfs.txt file in the Linux kernel source tree):
- size - limit of allocated bytes for the size of the volume
- mode - volume permission (once mounted)
- nr_blocks - same as in size, but in blocks
- nr_inodes - maximum number of inodes
The Solaris/OpenSolaris version only defines size and when you list the mounted device with the df command, it labels it as a swap. When it comes to volume permissions, you can always work around this (read below). In all cases, the advantages to utilizing tmpfs lie in the fact that it works off of virtual memory and can swap to disk when necessary. It runs like a normal file system, but when the power goes out or when the mounted volume is unmounted, all data contents disappear; as is the case with any RAM disk and no method of synchronization employed. By default, a normal installation of Solaris/OpenSolaris will use tmpfs for various computing needs such as mounting the /tmp directory with a tmpfs volume. This module can also be used to help ease a user’s computing experience and security, for example by optimizing Firefox and instead of having cache all data contents to the physical hard drive, create and have it write all necessary content to a tmpfs mounted device. The file system can also serve well in an area where constant database queries or other web services are being cached and routinely accessed. These are a few of many scenarios in which this can be used in.
Despite the few differences between each operating system, the tmpfs module is still easy to work with. Once a directory for the mount point is created, you can then mount the tmpfs RAM-based volume:
petros@opensolaris:~$ pfexec mkdir /mnt/rdisk |
You can even configure the /etc/vfstab to automount the tmpfs volume at bootup:
#device device mount FS fsck mount mount |
The only major drawback is that at this point only root or someone with superuser permissions (i.e. sudo/pfexec) can work with the volume or change the mount point permissions so that other users can access it. If you desire have these permissions altered at bootup, it may be advantageous to automate it in a startup script. If it doesn’t already exist, you can create it. I am referring to the /etc/rc3.d/S99local file. Some, if not all of you may already be familiar with the concept of run levels and if you are coming from a Linux environment, you may realize that the run levels are not the same between Linux and Solaris. But, this is a topic for another day. Notice under the field of startup, how I use pfexec (similar to sudo) to change the permission of the tmpfs mount. Also note that you can skip the vfstab step shown earlier and just mount the file system within the same script file.
#!/bin/bash |
As can be seen, tmpfs is very easy to work with and can be applied to many things to bring forth many advantages and additional securities (a result of having the contents disappear at power down of the system). If one wanted to employ some basic method of synchronization, a script can be called during scheduled periods to perform an rsync to another mount point.
RAMDISKADM
I find this module to be an excellent tool, capable of being utilized in both production use or for teaching purposes. To utilize the ramdisk module you need to invoke the ramdiskadm command on the command line. For example, let us say I want to create a memory-based volume 100 MB in size, I would type:
petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk1 100m |
A device node would be created at /dev/ramdisk/ramdisk1. You can format this node with a file system and mount it locally to even exporting it as an NFS share; or configure it as an iSCSI target.
To destroy the RAM disk, you would need to type:
petros@opensolaris:~$ pfexec ramdiskadm -d ramdisk1 |
If you are interested, you can even create multiple ramdisks and pool them in a ZFS volume. An advantage to utilizing this approach comes from the checksum feature to prevent data corruption of contents stored in volatile memory and also the ability to grow the volume and add it to the RAM-based pool.
petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk1 100m |
I now have a zfs pool mirroring two 100 MB ramdisks. Obviously there are no real advantages to mirroring two RAM disks but this just serves as an example. I can check the status of the rampool device with the following command:
petros@opensolaris:~$ zpool status |
Listing the zfs device will provide the following information (note that I cropped out the unrelated material):
petros@opensolaris:~$ zfs list |
To destroy the rampool I can invoke the following on the command line:
pfexec zpool destroy rampool |
Let us create a RAIDZ volume:
petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk1 64m |
zpool status gives us:
pool: rampool |
A zfs list will show:
petros@opensolaris:~$ zfs list |
I now want to add another device to the rampool. Notice the differences when I list the zpool status and list the zfs device.
petros@opensolaris:~$ pfexec zpool add -f rampool /dev/ramdisk/ramdisk3 |
CONCLUSION
As one can see, working with RAM disks on Solaris/OpenSolaris is fairly simple and can be configured in just a couple of steps. Who knows, you may find situations in your current environment which may benefit from the use of a RAM disk. Note - Do not forget to destroy the zpool and the RAM disks when not in use. The last thing you want to do is waste much needed memory.
Nice post.
Comment by morisbecon — 9. February 2010 @ 06:05