dd if=/dev/random of=/dev/blog

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 petros@opensolaris:~$ pfexec mount -F tmpfs -o size=96m tmpfs /mnt/rdisk

You can even configure the /etc/vfstab to automount the tmpfs volume at bootup:

#device         device          mount           FS      fsck    mount   mount #to mount       to fsck         point           type    pass    at boot options # /devices        -               /devices        devfs   -       no      - /proc           -               /proc           proc    -       no      - ctfs            -               /system/contract ctfs   -       no      - objfs           -               /system/object  objfs   -       no      - sharefs         -               /etc/dfs/sharetab       sharefs -       no      - fd              -               /dev/fd         fd      -       no      - swap            -               /tmp            tmpfs   -       yes     - /dev/zvol/dsk/rpool/swap        -               -               swap    -       no      - swap            -               /mnt/rdisk      tmpfs   -       yes     size=96m

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 if [ $? -ne 0 ]; then exit 0; fi case "$1" in 'start') pfexec chmod 777 /mnt/rdisk ;; 'stop') ;; *) echo "Usage: $0 { start | stop }" exit 1 ;; esac exit 0

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 /dev/ramdisk/ramdisk1 petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk2 100m /dev/ramdisk/ramdisk2 petros@opensolaris:~$ pfexec zpool create rampool mirror /dev/ramdisk/ramdisk1 /dev/ramdisk/ramdisk2

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 pool: rampool state: ONLINE scrub: none requested config: NAME                       STATE     READ WRITE CKSUM rampool                    ONLINE       0     0     0 mirror                   ONLINE       0     0     0 /dev/ramdisk/ramdisk1  ONLINE       0     0     0 /dev/ramdisk/ramdisk2  ONLINE       0     0     0 errors: No known data errors

Listing the zfs device will provide the following information (note that I cropped out the unrelated material):

petros@opensolaris:~$ zfs list NAME                       USED  AVAIL  REFER  MOUNTPOINT rampool                   71.5K  63.4M    19K  /rampool

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 /dev/ramdisk/ramdisk1 petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk2 64m /dev/ramdisk/ramdisk2 petros@opensolaris:~$ pfexec ramdiskadm -a ramdisk3 64m /dev/ramdisk/ramdisk3 petros@opensolaris:~$ pfexec zpool create rampool raidz /dev/ramdisk/ramdisk1 /dev/ramdisk/ramdisk2

zpool status gives us:

pool: rampool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rampool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 /dev/ramdisk/ramdisk1 ONLINE 0 0 0 /dev/ramdisk/ramdisk2 ONLINE 0 0 0 errors: No known data errors

A zfs list will show:

petros@opensolaris:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT rampool 70K 27.4M 19K /rampool

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 petros@opensolaris:~$ zpool status pool: rampool state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM rampool ONLINE 0 0 0 raidz1 ONLINE 0 0 0 /dev/ramdisk/ramdisk1 ONLINE 0 0 0 /dev/ramdisk/ramdisk2 ONLINE 0 0 0 /dev/ramdisk/ramdisk3 ONLINE 0 0 0 errors: No known data errors petros@opensolaris:~$ zfs list NAME USED AVAIL REFER MOUNTPOINT rampool 73K 86.9M 19K /rampool

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.