[dm-devel] device mapper / multipath

Adarsh adarshanto at gmail.com
Fri Apr 27 08:13:29 UTC 2012


Hello,

Please note that when I remove a LUN, I will follow the "Clean Device
Removal"

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Online_Storage_Reconfiguration_Guide/removing_devices.html

However, sometimes people won't  follow those steps.
I want to handle such scenarios gracefully.

regards,
Adarsh.


On 27 April 2012 12:58, Adarsh <adarshanto at gmail.com> wrote:

> Hello,
>
> I am trying to setup a RH Linux multipath setup with 256 LUNs.
> I am facing an issue.
>
> After deleting a LUN, I am invoking "multipath" command to immediately
> update the MPIO database.
> However, it takes 30-40 minutes mostly.
> Kindly advice how I can reduce the time taken to a few minutes at the max.
>
> Also, how often does multipathd update the MPIO database.
> Basically, I am trying to remove the stale LUN as soon as possible from
> the database (say 5-8 seconds)
> Is there any way to ensure/force that.
>
> Any help will be really appreciated.
>
> regards,
> Adarsh.
>
>
> Setup:
> =====
> RHEL 5.6 (Linux x336-207-59 2.6.18-238.9.1.el5)
> Multipath tools: 0.4.7
>
> multipath.conf:
> ============
> defaults {
>         user_friendly_names     no
>         max_fds                max
>         queue_without_daemon   no
>         pg_prio_calc           avg
>         flush_on_last_del      yes
> }
>
> blacklist {
>         wwid                   SIBM-ESXSMAW3073NC_FDAR9P6402P4G
>         wwid                   SIBM-ESXSMAW3073NC_FDAR9P6402PU9
>         devnode                "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
>         devnode                "^hd[a-z]"
>         devnode                "^cciss.*"
> }
>
> devices {
>         device {
>                 vendor "NETAPP"
>                 product "LUN"
>                 getuid_callout "/sbin/scsi_id -g -u -s /block/%n"
>                 prio_callout "/sbin/mpath_prio_alua /dev/%n"
>                 hardware_handler "0"
>                 failback immediate
>                 flush_on_last_del yes
>         }
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20120427/86eb3b87/attachment.htm>


More information about the dm-devel mailing list