NAME¶
gmultipath —
disk multipath control
utility
SYNOPSIS¶
gmultipath |
label [-hv]
name prov ... |
gmultipath |
clear [-v]
prov ... |
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
guarantees uniqueness in a shared storage environment but is in general too
cumbersome to use. The name is what is exported via the device interface.
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 different 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 configuration 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 storage 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⟩