Skip site navigation (1)Skip section navigation (2)

FreeBSD Man Pages

Man Page or Keyword Search:
Man Architecture
Apropos Keyword Search (all sections) Output format
home | help
GMULTIPATH(8)		FreeBSD	System Manager's Manual		 GMULTIPATH(8)

NAME
     gmultipath	-- disk	multipath control utility

SYNOPSIS
     gmultipath	label [-hv] name prov ...
     gmultipath	clear [-v] prov	...
     gmultipath	list
     gmultipath	status
     gmultipath	load
     gmultipath	unload

DESCRIPTION
     The gmultipath utility is used for	device multipath configuration.

     Only automatic configuration is supported at the present time via the
     label command.  This operation writes a label on the last sector of the
     underlying	disk device with a contained name and UUID.  The UUID guaran-
     tees uniqueness in	a shared storage environment but is in general too
     cumbersome	to use.	 The name is what is exported via the device inter-
     face.

     The first argument	to gmultipath indicates	an action to be	performed:

     label    Label the	given underlying device	with the specified name.  The
	      kernel module geom_multipath.ko will be loaded if	it is not
	      loaded already.

     clear    Clear metadata on	the given device.

     list     See geom(8).

     status   See geom(8).

     load     See geom(8).

     unload   See geom(8).

SYSCTL VARIABLES
     The following sysctl(8) variable can be used to control the behavior of
     the MULTIPATH GEOM	class.

     kern.geom.multipath.debug:	0
	     Debug level of the	MULTIPATH GEOM class.  This can	be set to 0
	     (default) or 1 to disable or enable various forms of chattiness.

EXIT STATUS
     Exit status is 0 on success, and 1	if the command fails.

MULTIPATH ARCHITECTURE
     This is an	active/passive multiple	path architecture with no device
     knowledge or presumptions other than size matching	built in.  Therefore
     the user must exercise some care in selecting providers that do indeed
     represent multiple	paths to the same underlying disk device.  The reason
     for this is that there are	several	criteria across	multiple underlying
     transport types that can indicate identity, but in	all respects such
     identity can rarely be considered definitive.

     For example, if you use the World Word Port Name of a Fibre Channel disk
     object you	might believe that two disks that have the same	WWPN on	dif-
     ferent paths (or even disjoint fabrics) might be considered the same
     disk.  Nearly always this would be	a safe assumption, until you realize
     that a WWPN, like an Ethernet MAC address,	is a soft programmable entity,
     and that a	misconfigured Director Class switch could lead you to believe
     incorrectly that you have found multiple paths to the same	device.	 This
     is	an extreme and theoretical case, but it	is possible enough to indicate
     that the policy for deciding which	of multiple pathnames refer to the
     same device should	be left	to the system operator who will	use tools and
     knowledge of their	own storage subsystem to make the correct configura-
     tion selection.

     As	an active/passive architecture,	only one path has I/O moving on	it at
     any point in time.	 This I/O continues until an I/O is returned with a
     generic I/O error or a "Nonexistent Device" error.	 When this occurs, the
     active device is kicked out of the	MULTIPATH GEOM class and the next in a
     list is selected, the failed I/O reissued and the system proceeds.

     When new devices are added	to the system the MULTIPATH GEOM class is
     given an opportunity to taste these new devices.  If a new	device has a
     MULTIPATH label, the device is used to either create a new	MULTIPATH
     GEOM, or to attach	to the end of the list of devices for an existing
     MULTIPATH GEOM.

     It	is this	mechanism that works reasonably	with isp(4) and	mpt(4) based
     Fibre Channel disk	devices.  For these devices, when a device disappears
     (due e.g.,	to a cable pull	or power failure to a switch), the device is
     proactively marked	as gone	and I/O	to it failed.  This causes the
     MULTIPATH failure event just described.

     When Fibre	Channel	events inform either isp(4) or mpt(4) host bus
     adapters that new devices may have	arrived	(e.g., the arrival of an RSCN
     event from	the Fabric Domain Controller), they can	cause a	rescan to
     occur and cause the attachment and	configuration of any (now) new devices
     to	occur, causing the taste event described above.

     This means	that this active/passive architecture is not a one-shot	path
     failover, but can be considered to	be steady state	as long	as failed
     paths are repaired	(automatically or otherwise).

     Automatic rescanning is not a requirement.	 Nor is	Fibre Channel.	The
     same failover mechanisms work equally well	for traditional	"Parallel"
     SCSI but require manual intervention with camcontrol(8) to	cause the
     reattachment of repaired device links.

EXAMPLES
     The following example shows how to	use camcontrol(8) to find possible
     multiple path devices and to create a MULTIPATH GEOM class	for them.

	   mysys# camcontrol devlist
	   <ECNCTX @WESTVILLE >	  at scbus0 target 0 lun 0 (da0,pass0)
	   <ECNCTX @WESTVILLE >	  at scbus0 target 0 lun 1 (da1,pass1)
	   <ECNCTX @WESTVILLE >	  at scbus1 target 0 lun 0 (da2,pass2)
	   <ECNCTX @WESTVILLE >	  at scbus1 target 0 lun 1 (da3,pass3)
	   mysys# camcontrol inquiry da0 -S
	   ECNTX0LUN000000SER10ac0d01
	   mysys# camcontrol inquiry da2 -S
	   ECNTX0LUN000000SER10ac0d01

     Now that you have used the	Serial Number to compare two disk paths	it is
     not entirely unreasonable to conclude that	these are multiple paths to
     the same device.  However,	only the user who is familiar with their stor-
     age is qualified to make this judgement.

     You can then use the gmultipath command to	label and create a MULTIPATH
     GEOM provider named FRED.

	   gmultipath label -v FRED /dev/da0 /dev/da2
	   disklabel -Brw /dev/multipath/FRED auto
	   newfs /dev/multipath/FREDa
	   mount /dev/multipath/FREDa /mnt....

     The resultant console output looks	something like:

	   GEOM_MULTIPATH: adding da0 to Fred/b631385f-c61c-11db-b884-0011116ae789
	   GEOM_MULTIPATH: da0 now active path in Fred
	   GEOM_MULTIPATH: adding da2 to Fred/b631385f-c61c-11db-b884-0011116ae789

SEE ALSO
     geom(4), isp(4), mpt(4), loader.conf(5), camcontrol(8), geom(8),
     mount(8), newfs(8), sysctl(8)

BUGS
     The gmultipath should allow for a manual method of	pairing	disks.

     There is currently	no way for geom_multipath.ko to	distinguish between
     various label instances of	the same provider.  That is devices such as
     da0 and da0c can be tasted	and instantiated as multiple paths for the
     same device.  Technically,	this is	correct, but pretty useless.  This
     will be fixed soon	(I hope), but to avoid this it is a good idea to
     destroy any label on the disk object prior	to labelling it	with
     gmultipath.

AUTHOR
     Matthew Jacob <mjacob@FreeBSD.org>

FreeBSD	9.3		       February	26, 2007		   FreeBSD 9.3

NAME | SYNOPSIS | DESCRIPTION | SYSCTL VARIABLES | EXIT STATUS | MULTIPATH ARCHITECTURE | EXAMPLES | SEE ALSO | BUGS | AUTHOR

Want to link to this manual page? Use this URL:
<http://www.freebsd.org/cgi/man.cgi?query=gmultipath&sektion=8&manpath=FreeBSD+7.4-RELEASE>

home | help