The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

gmultipath (8)
  • >> gmultipath (8) ( FreeBSD man: Команды системного администрирования )

  • BSD mandoc
     

    NAME

    
    
    gmultipath
    
     - disk multipath control utility
    
     
    

    SYNOPSIS

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

    DESCRIPTION

    The 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 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 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.conf5, camcontrol(8), geom(8), mount(8), newfs(8), sysctl(8)  

    BUGS

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

    AUTHOR

    An Matthew Jacob Aq [email protected]


     

    Index

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


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру