Re: [PATCH 4/7] scsi_dh: add EMC Clariion device handler

[Mike Christie <michaelc@cs.wisc.edu>]

Mike Christie wrote:
> Chandra Seetharaman wrote:
>> On Thu, 2008-04-17 at 12:14 -0500, Mike Christie wrote:
>>> Chandra Seetharaman wrote:
>>>> On Wed, 2008-04-16 at 11:29 -0500, Mike Christie wrote:
>>>>> Chandra Seetharaman wrote:
>>>>>> +
>>>>>> +static int send_cmd(struct scsi_device *sdev, int cmd)
>>>>>> +{
>>>>>> +    struct request *rq = get_req(sdev, cmd);
>>>>>> +
>>>>>> +    if (!rq)
>>>>>> +        return SCSI_DH_RES_TEMP_UNAVAIL;
>>>>>> +
>>>>>> +    return blk_execute_rq(sdev->request_queue, NULL, rq, 1);
>>>>>> +}
>>>>>> +
>>>>> My only concerns are:
>>>>>
>>>>> 1. EMC and HP need to send a command to every device to transition 
>>>>> them. Because we do blk_execute_rq from the dm multipath workqueue 
>>>>> we can now only failover/failback for a couple devices at a time.
>>>>>
>>>>> I am not sure if this is a big deal, because this the error handler 
>>>>> path so it is going to be slower than the normal path. But it seems 
>>>>> like 
>>>> Yes. But...
>>>>
>>>> pg_init() due to failover/failback will be sent only when I/O is
>>>> sent/resent to a multipath device, isn't it ? and we don't expect I/Os
>>>> to be sent to all the devices at the same time (all the time), do we ?
>>>>
>>> I am not sure what you mean by all the time, because I am talking about 
>>
>> What I meant was that we do not expect I/Os to be sent to all the
>> devices at all the times (pg_init will be sent only when I/Os fails on a
>> path, right ?).
>>
>> Sorry for not being clear.
>>
> 
> No problem.
> 
> 
>>> failover times above. And for failover I think I said yes in the 
>>> previous mail. For EMC we are currently sending failover commands to 
>>> all the devices at the same time, because EMC does not do the 
>>> controller failover RDAC does.
>>
>> RDAC doesn't do controller failover. It also does per lun failover.
>>
> 
> Oh yeah, I forgot.
> 
> 
>>>> So, as you pointed, is it a big deal ? :)
>>>>
>>> In the previous mail I specifically said users might care, because 
>>> they are picky about failover times, real    3m39.728s
>> user    0m4.135s
>> sys     0m14.536s
>>
>>> so the answer is to your question is what I said before, maybe :) I 
>>> said I am not sure, because I do not have any numbers for the 
>>> failover times.
>>
>> Since RDAC also does the failover per device (as is the case with EMC),
>> I ran tests on about 49 luns. I ran disktest on all the disks at the
> 
> Thanks.
> 
>> same time and disabled/enabled the port to the preferred path to
>> generate failover and failback.
>>
>> Let me know what do you think.
>>
>> Here are the results:
>> Tests run in an idle system. With 49 luns and the following script:
>> ******************************************************
>> for i in `ls -1 /dev/mapper/mpath*`
>> do
>>     disktest $i -L 4000 -t 100 -P X &
>>     sleep 1
>> done
>>
>> wait
>> ******************************************************
>> Simple Run:
>>
>> with patchset:        2.6.25-mm1:
>> real    3m30.122s    real    3m29.746s
>> user    0m4.069s    user    0m4.099s
>> sys     0m14.876s    sys     0m14.535s
>> -----------------------------------------------
> 
> Is this just a boot up test or a test just running IO but no 
> failback/failover?
> 
>>
>> Failover Run:
>>
>> with patchset:        2.6.25-mm1:
>> real    5m18.875s    real    5m31.741s
>> user    0m4.069s    user    0m3.883s
>> sys     0m14.838s    sys     0m13.822s
> 
> Ehh, I have no idea if this is good or bad. Does it mean it is talking 
> 13 more seconds to complete?
> 

Oops, I read that wrong. With the new code it is 13 seconds faster. I 
have no concerns about that.