[stgt] [PATCH] sg-based backing store

[Mark Harvey]

On Fri, Oct 17, 2008 at 1:49 AM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Thu, Oct 16, 2008 at 1:53 AM, ronnie sahlberg
> <ronniesahlberg at gmail.com> wrote:
>> OFF TOPIC :
>>
>> On Wed, Oct 8, 2008 at 5:14 PM, FUJITA Tomonori
>> <fujita.tomonori at lab.ntt.co.jp> wrote:
>>>
>>> My point is that the performance of read-world workload benchmark like
>>> dbench are relevant for the users than the performances of sequential
>>> accesses.
>>
>>
>> Funny you should mention DBENCH ( http://dbench.samba.org ).
>> I recently added a NFS backend so that dbench can generate raw NFS
>> traffic using "nfs-style" loadfiles. With the ability to take a NFS
>> network trace and convert into one such loadfile automatically.
>>
>> I also recently added a SCSI backend to dbench (though it only handles
>> READ10 and TESTUNITREADY commands so far) with the intent of being
>> able to trace from a kernel the set of all SCSI operations perfromed
>> durign some operation and then use "dbench -B scsi" to replay the
>> exact same set of commands.
>> My vision is that this could then be used to compare different devices
>> how they operate on specific kinds of workloads.
>> Maybe one "loadfile" that records and replays all SCSI i/o that goes
>> to a device while one is recompiling a kernel,    while operating on a
>> very large picture in GIMP, reading a very large document into
>> openoffice, etc etc.
>
> Hmmm, it struck me recently that one could write a simple filter SCSI
> LLD that interposes itself between a real LLD and the SCSI ML and
> captures all CDBs and some of the data on the way through and makes it
> available for a capture program in the same way as the packet capture
> stuff works.

I can think of many instances during trouble-shooting where a function
like this would be useful. As long as you could pin-point the actual
SCSI target under scrutiny and ignore all other targets.

Enabling SCSI ML debugging generates so much data for all SCSI devices
making the work of extracting the data for one device (or device type)
not worth the effort in all but extreme cases.

Nice to have options:
- Limit to one target
- Limit to one device type (e.g. Tape) and ignore all other device types.
- Capture response codes and optionally data blocks.

Ability to 'or' the above options - So we could capture tape or medium
changer data and leave disk traffic alone.

>
> In some ways, this would be more convenient than using iSCSI ...
>
> --
> Regards,
> Richard Sharpe
> --
> To unsubscribe from this list: send the line "unsubscribe stgt" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html