linuxscsi.in

linux集群服务器软件代码包

#!/bin/sh
#
# $Id: LinuxSCSI.in,v 1.1 2004/08/27 09:34:14 lars Exp $
# 
# LinuxSCSI
#
# Description:	Enables/Disables SCSI devices to protect them from being
#		used by mistake
#
#
# Author:	Alan Robertson
#		Support: [e-mail]
# License:	GNU Lesser General Public License (LGPL)
# Copyright:	(C) 2002 IBM
#
# CAVEATS:	See the usage message for some important warnings
#
# usage: ./LinuxSCSI <host>:<channel>:<target>[:<lun>] (start|stop|status)
#
#<adapter>:	Adapter number of the SCSI device to query
#<target>:	Target ID of the SCSI device under consideration
#<lun>:		LUN of the SCSI device under consideration
#			(optional)
#
#
# An example usage in /etc/ha.d/haresources: 
#       node1  10.0.0.170 LinuxSCSI:0:0:11 
#
unset LC_ALL; export LC_ALL
unset LANGUAGE; export LANGUAGE

usage() {
  cat <<-! >&1
	usage: $0 <host>:<channel>:<target>[:<lun>] (start|stop|status)

	$0 manages the availability of a SCSI device from the point
	of view of the linux kernel.  It make Linux believe the
	device has gone away, and it can make it come back again.

	The purpose of this resource script is to keep admins from
	accidentally messing with a shared disk that is managed by the
	HA subsystem and is currently owned by the other side.

	To get maximum benefit from this feature, you should (manually)
	disable the resources on boot, and let your HA software enable
	them when it wants to acquire the disk.
	
	The kernel code says this is potentially dangerous.  DO NOT USE
	IT ON AN ACTIVE DEVICE.  If the device is inactive, this script
	will make it stay inactive, when given "off".  If you inactivate
	the wrong device, you may have to reboot your machine, and your
	data may take a hit.

	On the other hand, at least one RAID controller requires the
	use of this technique for it to work correctly in a failover
	environment - so it is believed that it is more stable in this
	usage than the comments in the code imply.

	Here are the warnings from the kernel source about the "stop"
	operation as of 2.4.10:

	------------------------------
	Consider this feature pre-BETA.
	    CAUTION: This is not for hotplugging your peripherals. As
	    SCSI was not designed for this, you could damage your
	    hardware and thoroughly confuse the SCSI subsystem.

	Similar warnings apply to the "start" operation...

	 Consider this feature BETA.
	     CAUTION: This is not for hotplugging your peripherals.
	     As SCSI was not designed for this you could damage your
	     hardware !
	However perhaps it is legal to switch on an already connected
	device. It is perhaps not guaranteed this device doesn't corrupt
	an ongoing data transfer.
	-------------------------

	So, Caveat Emptor, and test this feature thoroughly on
	your kernel and your configuration with real load on the SCSI
	bus before using it in production!

	Another potential trouble spot...
	The order in which you bring up LinuxSCSI resources determines which
	SCSI device they show up as on Linux.  If you have two SCSI devices
	in different resource groups they will be brought up asyncronously
	resulting in indeterminate device name assignments.  This usually
	happens in an active-active configuration.
	
	To solve this you probably should use LVM or EVMS to manage these
	volumes.  LVM and EVMS solve this problem for you by labels they
	keep in the volumes.  If you don't use a reasonable volume manager,
	then you'll have to mount by UUID.

	$Id: LinuxSCSI.in,v 1.1 2004/08/27 09:34:14 lars Exp $
	!
  exit 1
}

zeropat="[ 0]0"

prefix=@prefix@
exec_prefix=@exec_prefix@
#. @sysconfdir@/ha.d/shellfuncs

PROCSCSI=/proc/scsi/scsi

scsi_methods() {
  cat <<-!
	start
	stop
	status
	methods
	!
}


parseinst() {
  lun=0
  case "$1" in
	
    [0-9*]:[0-9]*:[0-9]*);;

    [0-9*]:[0-9]*:[0-9]*:[0-9]*)
	lun=`echo "$1" | cut -d: -f4`;;

    *)	host=error
	channel=error
	target=error
	lun=error
	echo "Invalid SCSI instance $1" >&2
  esac
  host=`echo "$1" | cut -d: -f1`
  channel=`echo "$1" | cut -d: -f2`
  target=`echo "$1" | cut -d: -f3`
}


#
# start: Enable the given SCSI device in the kernel
#
scsi_start() {
  parseinst "$1"
  [ $target = error ] && exit 1
  echo "scsi-add-single-device $host $channel $target $lun" >>$PROCSCSI
  if
    scsi_status "$1"
  then
    return 0
  else
    echo "ERROR: SCSI device $1 not active!"
    return 1
  fi
}


#
# stop: Disable the given SCSI device in the kernel
#
scsi_stop() {
  parseinst "$1"
  [ $target = error ] && exit 1
  echo "scsi-remove-single-device $host $channel $target $lun" >>$PROCSCSI
  if
    scsi_status "$1"
  then
    echo "ERROR: SCSI device $1 still active!"
    return 1
  else
    return 0
  fi
}


#
# status: is the given device now available?
#
scsi_status() {
  parseinst "$1"
  [ $target = error ] && exit 1
  [ $channel -eq 0 ]	&& channel=$zeropat
  [ $target -eq 0 ]	&& target=$zeropat
  [ $lun -eq 0 ]	&& lun=$zeropat
  greppat="Host: *scsi$host *Channel: *$channel *Id: *$target *Lun: *$lun"
  grep -i "$greppat" $PROCSCSI >/dev/null
}

if
  [ $# -eq 1 -a "X$1" = "Xmethods" ]
then
  scsi_methods
  exit #?
fi

instance=$1
# Look for the start, stop, status, or methods calls...
case "$2" in
  stop)
	scsi_stop $instance
	exit $?;;
  start)
	scsi_start $instance
	exit $?;;
  status) 
	if
	  scsi_status $instance
	then
	  echo SCSI device $instance is running
	  exit 0
	else
	  echo SCSI device $instance is stopped
	  exit 1
	 fi
	exit $?;;


#
# methods: What methods do we support?
#
  methods) 
	scsi_methods
	exit $?;;

*)
    usage
    exit 1;;

esac

exit 1