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
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
