[dm-devel] Question about EMC Clariion trespass in multipath

[Chandra Seetharaman]

Hi Martin,

This is the general sequence of events that happen w.r.t pg_init(). I do
not know exactly what happens in the EMC handler (from pg_init() to
pg_init_complete()) :)...

- dm-multipath chooses a path group with highest priority to be the
  active path group.
- dm-multipath sends IO to paths in this path group in a round-robin
  fashion.
- When one of the paths in this "active" path group fail, dm-multipath 
  stops sending IO on that path, but continues to use the other paths 
  in that path group.
- All along, path checker will be checking for path's state and when the
  path comes back, it will be added to the round-robin logic.
- When all paths in a path group fail, dm-multipath will send a 
  pg_init(). The underlying handler is supposed to do the needful to 
  enable that path group (like EMC doing a trespass).
- On Success, pg_init_complete() will be called with success by the 
  handler and dm-multipath will make that path group the "active"
  path group and start sending IOs to the paths in that path group.
- On Failure, pg_init_complete() will be called with failure by the 
  handler and dm-multipath will fail that path group too, and depending 
  on the value set for queue_if_no_path the IO will be either failed
  of held on a queue or tried specified # of times.
- When the high priority path group comes back alive ( path checker
  keeps polling and finds it out), pg_init() will be sent to that 
  path group and dm-multipath will try to make that path group active
  again.

In effect, trespass happens only when a failover or failback happens,
not for each IOs.

Hopefully it is clear.

If you are not following the terminologies, see my Wiki at
http://sources.redhat.com/lvm2/wiki/MultipathUsageGuide

regards,

chandra
On Thu, 2009-10-22 at 13:07 -0700, McGreal, Martin (EHQ) wrote:
> I've been told that dm multipath does not support trespassing LUNs on
> Clariion, but after looking through the hardware handler for EMC
> Clariion devices, I believe it does.  However, I'm confused about how it
> determines when to issue the trespass command.
> 
> Since we are using RHEL 5.3, I am looking at the 2.6.18.8 version of the
> hardware handler, dm-emc.c
> (http://lxr.linux.no/#linux+v2.6.18.8/drivers/md/dm-emc.c).
> 
> Looking at emc_pg_init(), which, according to the documentation, is
> called "when a Priority Group is selected for use, but before any I/O is
> sent to it" (http://lwn.net/Articles/123134), it looks like the only way
> out of this function is by either failing the path via
> dm_pg_init_complete(), or issuing a switch-over command.  So either a
> path is failed or a trespass occurs every time that a priority group is
> selected?  What am I missing here?
> 
> Any guidance would be appreciated.
> 
> Thanks!
> Martin
> 
> 
>  192static void emc_pg_init(struct hw_handler *hwh, unsigned bypassed,
>  193                        struct path *path)
>  194{
>  195        struct request *rq;
>  196        struct request_queue *q = bdev_get_queue(path->dev->bdev);
>  197
>  198        /*
>  199         * We can either blindly init the pg (then look at the
> sense),
>  200         * or we can send some commands to get the state here (then
>  201         * possibly send the fo cmnd), or we can also have the
>  202         * initial state passed into us and then get an update here.
>  203         */
>  204        if (!q) {
>  205                DMINFO("emc_pg_init: no queue");
>  206                goto fail_path;
>  207        }
>  208
>  209        /* FIXME: The request should be pre-allocated. */
>  210        rq = emc_trespass_get(hwh->context, path);
>  211        if (!rq) {
>  212                DMERR("emc_pg_init: no rq");
>  213                goto fail_path;
>  214        }
>  215
>  216        DMINFO("emc_pg_init: sending switch-over command");
>  217        elv_add_request(q, rq, ELEVATOR_INSERT_FRONT, 1);
>  218        return;
>  219
>  220fail_path:
>  221        dm_pg_init_complete(path, MP_FAIL_PATH);
>  222}
> 
> 
> 
> 
> 
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel