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.comReceived 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