[dm-devel] dm-emc: switchover fails when devices is reserved

[Eddie Williams]

The dm-emc module does not seem to be able to switchover a path on an
EMC CX array when the device is reserved (I am reserving the device
using SCSI-3 persistent reservations).  I believe the problem is due to
the default behavior of the dm-emc module to not honor reservations:
   /* Whether or not to honor SCSI reservations when initiating a
    * switch-over. Default: Don't. */

With the default setting I get the following errors:
Apr 26 11:08:14 titan kernel: device-mapper: dm-multipath: 67:48
(#715918): IO error - error: -5 - bi_rw: 8 - bi_flags: 10000018 -
bi_error: 02020403
Apr 26 11:08:14 titan kernel: device-mapper: dm-emc: emc_err: 715918: LU
Not Ready, bypassing PG
Apr 26 11:08:14 titan kernel: device-mapper: dm-multipath: bypass_pg: 2
Apr 26 11:08:14 titan kernel: device-mapper: dm-multipath: 67:48
(#715902): Requeued sector as #90
Apr 26 11:08:14 titan kernel: device-mapper: dm-emc: emc_pg_init:
sending switch-over command
Apr 26 11:08:14 titan kernel: scsi2 (0,0,6) : reservation conflict
Apr 26 11:08:14 titan kernel: SCSI error : <2 0 0 6> return code = 0x18
Apr 26 11:08:14 titan kernel: device-mapper: dm-emc: emc_endio: pg_init
error -5

The switchover is not successful.  If I release the reservation the
switch-over works.

I recompiled dm-emc so that the default behavior is to honor
reservations.  When I cause the same scenario as above I now get:
Apr 27 12:15:39 titan kernel: device-mapper: dm-multipath: 68:240 (#8):
IO error - error: -5 - bi_rw: 8 - bi_flags: 18 - bi_error: 01000005
Apr 27 12:15:39 titan kernel: device-mapper: dm-multipath: Failing path
68:240
Apr 27 12:15:39 titan kernel: device-mapper: dm-multipath: 68:240 (#0):
Requeued sector as #1
Apr 27 12:15:39 titan kernel: device-mapper: dm-emc: emc_pg_init:
sending switch-over command

At that point the path is activated and IO's continue.

Is there a reason for the default behavior to be not to honor
reservations?  Is there an easier way to change the default behavior of
the hardware handler other than rebuilding it?

Thanks

Eddie Williams
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20060427/b0bc8698/attachment.htm>