[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: [dm-devel] Round Robin vs Active/Passive



All is Beautiful now. Not logging any errors to messages so looks like "
mpath_prio_hds_modular" is getting called correctly. 

Multipath -ll
asm14 (1HITACHI_730600240013) dm-55 HITACHI,DF600F
[size=64G][features=0][hwhandler=0]
\_ round-robin 0 [prio=2][active]
 \_ 1:0:0:13 sdcp 69:208  [active][ready]
 \_ 0:0:0:13 sdn  8:208   [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 0:0:1:13 sdbb 67:80   [active][ready]
 \_ 1:0:1:13 sded 128:80  [active][ready]

Thanks,
Craig




-----Original Message-----
From: Craig Simpson 
Sent: Wednesday, May 21, 2008 2:49 PM
To: device-mapper development
Cc: Michael Denney; Geoff Quan; Kevin Koplar; Craig Simpson
Subject: RE: [dm-devel] Round Robin vs Active/Passive




OK, I did notice that my Multipath Tools are a little old

[root wpe02 sbin]# rpm -qa |grep -i multipath
device-mapper-multipath-0.4.7-12.el5_1.3

Running Oracle Linux 5. Which in truth is:

[root wpe02 sbin]# cat /etc/redhat-release
Enterprise Linux Enterprise Linux Server release 5.1 (Carthage)

Guess I could grab the latest multipath tools from RedHat for ES 5.1.


Looks like I am on track now. 

I looked in
/usr/share/doc/device-mapper-multipath-0.4.7/multipath.conf.defaults 
And see the below. I guess that is what multipath is trying to use.
#       device {
#               vendor                  "HITACHI"
#               product                 "DF.*"
#               getuid_callout          "/sbin/scsi_id -g -u -s
/block/%n"
#               prio_callout            "/sbin/mpath_prio_hds_modular
%d"
#               features                "0"
#               hardware_handler        "0"
#               path_grouping_policy    group_by_prio
#               failback                immediate
#               rr_weight               uniform
#               rr_min_io               1000
#               path_checker            readsector0
#       }

Created my own version of defaults in /etc/multipath.conf from that:
defaults {
        udev_dir                /dev
        polling_interval        10
        selector                "round-robin 0"
        path_grouping_policy    group_by_prio
        getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
        prio_callout            "/sbin/mpath_prio_hds_modular /dev/%n"
        path_checker            readsector0
        rr_min_io               1000
        rr_weight               uniform
        failback                immediate
        no_path_retry           fail
        user_friendly_name      yes
}



Then for an alias I use this:
        multipath {
                wwid                    1HITACHI_D60090910032
                alias                   asm01
        }


Output from multipath -ll
asm01 (1HITACHI_D60090910032) dm-6 HITACHI,DF600F
[size=32G][features=0][hwhandler=0]
\_ round-robin 0 [prio=1][active]
 \_ 0:0:1:32 sdm 8:192 [active][ready]
\_ round-robin 0 [prio=0][enabled]
 \_ 0:0:0:32 sdb 8:16  [active][ready]



>From a multipathd -k, "show config"
        device {
                vendor HITACHI
                product DF.*
                prio_callout mpath_prio_hds_modular %d
        }

So looks like maybe it is incorrect there? 
Usually if that is messing up, it shows in /var/log/messages. 


THANKS THANKS THANKS Tore!!!!!!!! Would be lost without the help!

Craig



-----Original Message-----
From: dm-devel-bounces redhat com [mailto:dm-devel-bounces redhat com]
On Behalf Of Tore Anderson
Sent: Wednesday, May 21, 2008 2:01 PM
To: device-mapper development
Cc: Michael Denney
Subject: Re: [dm-devel] Round Robin vs Active/Passive

Hi,

* Craig Simpson

> Amazing Info, thanks!

Glad I could help.

> Changed my Defaults to this:
> 
> defaults {
>         udev_dir                /dev
>         polling_interval        10
>         selector                "round-robin 0"
>         path_grouping_policy    group_by_prio
>         getuid_callout          "/sbin/scsi_id -g -u -s /block/%n"
>         prio_callout            /sbin/mpath_prio_hds_modular
>         path_checker            readsector0
>         rr_min_io               100
>         rr_weight               priorities
>         failback                immediate
>         no_path_retry           fail
>         user_friendly_name      yes
> }

You need

  prio_callout "/sbin/mpath_prio_hds_modular /dev/%n"

for the priority to be determined correctly.

Anyway I'm a bit surprised that you need to specify these things, the
AMS series do have a entry in hwtable.c in multipath-tools 0.4.8 at
least.  Running an old version maybe?  They don't differ much from what
you have there, though.

> So figure I don't need to include anything in my aliases, since the
> defaults are set.

You figure correctly.

> Did a multipathd -k
> And a reconfigure

You also need to actually reload the multipath maps in the kernel, by
invoking e.g. "multipath -v2".

> But when doing a multipath -l Not sure if it looks correct:
> 
> asm01 (1HITACHI_D60090910032) dm-6 HITACHI,DF600F
> [size=32G][features=0][hwhandler=0]
> \_ round-robin 0 [prio=0][enabled]
>  \_ 0:0:1:32 sdm 8:192 [active][undef]
> \_ round-robin 0 [prio=0][enabled]
>  \_ 0:0:0:32 sdb 8:16  [active][undef]

You need to use "multipath -ll" (two l's) for it to show you the
priority, but it looks like multipathd have everything figured out:

> Also a multipathd> show topology
> 
> reload: asm01  (1HITACHI_D60090910032) dm-6  HITACHI,DF600F
> [size=32G ][features=0       ][hwhandler=0        ]
> \_ round-robin 0 [prio=1][enabled]
>  \_ 0:0:1:32 sdm 8:192 [active][ready]
> \_ round-robin 0 [prio=0][enabled]
>  \_ 0:0:0:32 sdb 8:16  [active][ready]

It's a bit strange that it actually is able to determine the priority,
considering that you have the prio_callout set incorrectly in your
defaults section.

I suspect that the default values from hwtable.c comes into play and
overrides your settings anyway.  You can check this by running "show
config" from inside "multipathd -k" - if you have a device section for
your vendor HITACHI, product DF.* there that might be what's going on.

> Looks like I have [enabled] [enabled] ...
> But it should be [active] [enabled]

Have you sent any I/O to the device after the configuration change?  The
PG doesn't transition from enabled to active before some regular I/O has
been sent there.  Just reading some data from it should suffice.

Regards,
-- 
Tore Anderson

--
dm-devel mailing list
dm-devel redhat com
https://www.redhat.com/mailman/listinfo/dm-devel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]