/etc/rc.d/ramdisk script for review

From: Wes Peters <wes_at_softweyr.com>
Date: Tue, 30 Mar 2004 05:44:59 -0000
A question came up on the mimedefang-users mailing list today.  One 
user who has recently converted from 4.8 to 5.2.1 was lamenting the 
fact there is no way to control ownership and permission of memory 
disks in 5.x.  The MIMEdefang spool area, often placed on a ramdisk 
for speed, needs to be owned by the MIMEdefang user and group.

I poked around at mdmfs, aka mount_mfs, and thought there should be 
a more 5.x-ish way to create ramdisks early enough in the boot process 
to just put them in /etc/fstab directly.  Here's what I came up with.

This is configured from /etc/rc.conf, as in:

ramdisk_units="10 11 12"
ramdisk_10_config="-t swap -s 128m"
ramdisk_10_owner="wes:staff"
ramdisk_10_perms="1755"
ramdisk_11_config="-t malloc -s 32m"
ramdisk_11_newfs="-b 4096 -f 1024"

This results in /dev/md10 (with ownership and permissions as specified) 
and /dev/md11 (with default ownership and permissions, 4K/1K block/frag
size), but not a /dev/md12 as its type has not been specified.

Here is the script:

---- ramdisk

#!/bin/sh -
#
# Copyright (c) 2004  The FreeBSD Project
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#    notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#    notice, this list of conditions and the following disclaimer in the
#    documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
#
# $FreeBSD$
#

# PROVIDE: ramdisk
# REQUIRE: localswap
# BEFORE: mountcritlocal
# KEYWORD: FreeBSD

. /etc/rc.subr

name="ramdisk"
stop_cmd="ramdisk_stop"
start_cmd="ramdisk_start"

ramdisk_start()
{
	for unit in $ramdisk_units
	do
		eval mdoptions=\$ramdisk_${unit}_config
		if [ "$mdoptions" = "${mdoptions##-t}" ]
		then
			echo "Type not specified for md$unit"
			continue
		fi
		eval fsoptions=\$ramdisk_${unit}_newfs
		eval owner=\$ramdisk_${unit}_owner
		eval perms=\$ramdisk_${unit}_perms

		echo Configuring ramdisk /dev/md$unit

		mdconfig -a $mdoptions -u $unit
		newfs $fsoptions /dev/md$unit
		[ "X$owner" != "X" ] && chown $owner /dev/md$unit
		[ "X$perms" != "X" ] && chmod $perms /dev/md$unit
	done
}

ramdisk_stop()
{
	for unit in $ramdisk_units
	do
		if [ -c /dev/md$unit ] ; then
			umount -f /dev/md$unit > /dev/null 2>&1
			mdconfig -d -u $unit
			echo Recovered ramdisk /dev/md$unit
		fi
	done
}

load_rc_config $name
run_rc_command "$1"

---- ramdisk

Gordon Tetlow suggested creating a mount_md program instead, which 
would probably be a hackup of mdmfs.  To some extent, just linking
/sbin/mount_md to /sbin/mdmfs would allow all of the options in mdmfs
to be used in /etc/fstab.  Does anyone have strong preferences for 
one approach vs. the other?

-- 

        Where am I, and what am I doing in this handbasket?

Wes Peters                                               wes_at_softweyr.com
Received on Mon Mar 29 2004 - 19:44:58 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:49 UTC