[stgt] sg-based backing store

[Alexander Nezhinsky]

On Fri, Oct 3, 2008 at 6:47 AM, FUJITA Tomonori
<fujita.tomonori at lab.ntt.co.jp> wrote:
> On Thu, 02 Oct 2008 15:34:19 +0300
> Alexander Nezhinsky <nezhinsky at gmail.com> wrote:
>>
>> I have a question. Once there had been a backing-store implementation
>> based on the SG driver, which was subsequently removed from git.
>> I found only vague remarks that it was "broken".
>> Could you explain me what was wrong with it?
>
> See Arne and Ronnie's mails when Ronnie posted his sg code.

This is what Arne wrote:
> there used to be a passthrough handler - it was removed due to its
> "brokeness" (anything else besides the TMF and I_T nexus mapping
> issues?), but the commit message suggests that it [cs]hould serve as a
> starting point?
> http://git.kernel.org/?p=linux/kernel/git/tomo/tgt.git;a=commitdiff;h=59e4aee0796783b765e9cc5748b8f4c7efe934eb

And Ronnie echoed this when i asked him about the "passthrough" implementation:
> My approach may be broken in the same way as the one removed.
> I however only need it to do very basic passthough so I can expose the
> SCSI layer onto the network with iSCSI, take network traces...

I did not find actual explanation about brokenness neither in these
mails, nor in the files
pointed by the git link above.

Perhaps I should send a patch reflecting what i did to have a better
basis for discussion,
i'll do it asap, have to clean it up a bit, first.

But in general, my approach and motivation differ quite radically from
what Ronnie did
in his "passthrough" patch and slightly from the old removed sg-based code.
Passthrough code uses SG_IO ioctl which has its own limitations, and
it was intended
just to trace scsi sessions. The removed code used write() and read()
calls, came in
two flavors, one using sg4 and another sg3, defined both new device
and bs types.

I also used write-read(), went only for sg3 interface in order not to
be dependent on external
patches, implemented only a new bs, using sbc device-type. It seems
that the removed code
had a slight problem with direct IO handling, which i fixed, and did
some other stuff
slightly differently. Anyhow, these are rather small technical issues
(important as they could be),
and i can't see what is fundamentally broken here.

As for the motivation, i'm targeting  a situation, when you want to
export scsi devices
not for tracing only, and not just to allow some special scsi
commands, but for plain block access.
Thus sbc code suffices. The advantage is performance, the ability to
avoid using threads
by performing scsi commands asynchronously, to perform direct IO, and
potentially,
to submit multiple commands in a batch. Completions are received
through a file descriptor
which is in accord with the stgt architecture.
In short, all the stuff that AIO should have supplied, plus it works
and is available for older kernels :)

Do i miss anything here? Could you explain what was the problem, and
whether it still exists?
Again, i'm going to flow in a patch as soon as is it ready, in hope it
is relevant :)

Thanx,
Alexander Nezhinsky
--
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