Re: [PATCH 3/3] tcm ibmvscsis driver

[Brian King <brking@linux.vnet.ibm.com>]

On 03/23/2011 03:34 PM, Nicholas A. Bellinger wrote:
> On Wed, 2011-03-23 at 10:19 -0500, Brian King wrote:
>> On 03/22/2011 05:06 PM, Nicholas A. Bellinger wrote:
>>>>>> I'm also seeing disktest complain on the client about commands taking longer than 120 seconds
>>>>>> on occasion, which may play into the performance issue I mentioned in my previous mail.
>>>>>>
>>>>>
>>>>> Mmmm, please verify with RAMDISK_MCP backends as well, as by default
>>>>> FILEIO has O_SYNC enabled..  This does seem strange for LTP disktest
>>>>> however..
>>
>> With RAMDISK_MCP I don't see any of the problems seen with RAMDISK_DR. Additionally,
>> disktest is running much snappier. I'm seeing between 30 and 60 MB/sec on the read workload
>> and between 100 and 300 MB/sec on the writes. 
>>
> 
> Thanks for the update Brian!  I am glad to hear we have a stable
> baseline for large block throughput with RAMDISK_MCP.
> 
> I would also be interested to see how small block performance looks with
> RAMDISK_MCP, and for IBLOCK/FILEIO/PSCSI export on top of some fast
> physical storage as well.  :)

Not too good. I've tried both FILEIO and IBLOCK and am seeing in the neighborhood
of 1 MB/sec read throughput and 5 MB/sec write throughput. I also continue
to see warnings from disktest indicating I/O's are taking longer than 120 seconds.
This is all with data integrity testing enabled, but I would still expect to see
much better numbers... Not sure where the bottleneck is at this point. If I run with
both a ramdisk LUN and an iblock LUN, I am seeing the ramdisk performance significantly
reduced to be on par with the iblock performance.

>> I'm having some trouble with multiple LUNs, however. Perhaps this is more
>> configuration issues, but if I create a lun_1 directory and link to a second
>> device, the client just sees two devices which seems to be both mapped to
>> the device mapped at lun_0.
>>
> 
> Mmmm, this sounds like some a bug in incoming LUN unpack or outgoing LUN
> pack issue.  From a quick look it appears we are missing a
> scsi_lun_to_int() call for transport_get_lun_for_cmd which is currently
> expecting an unpacked LUN.
> 
> @@ -880,7 +901,7 @@ static int tcm_queuecommand(struct ibmvscsis_adapter *adapter,
>                               srp_cmd_direction(cmd),
>                               attr, vsc->sense_buf);
> 
> -       ret = transport_get_lun_for_cmd(se_cmd, cmd->lun);
> +       ret = transport_get_lun_for_cmd(se_cmd, scsi_lun_to_int(cmd->lun));
>         if (ret) {
>                 printk(KERN_ERR "invalid lun %u\n", GETLUN(cmd->lun));
>                 transport_send_check_condition_and_sense(se_cmd,

This worked. I had to move the scsi_lun_to_int function further up the file in order
to be able to build it, but once I did this multiple LUNs seems to be working.

Thanks,

Brian

-- 
Brian King
Linux on Power Virtualization
IBM Linux Technology Center