[stgt] sg-based backing store

[FUJITA Tomonori]

On Fri, 3 Oct 2008 10:20:48 +0300
"Alexander Nezhinsky" <nezhinsky at gmail.com> wrote:

> 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,

If you don't do passthough, it would be fine. That is, all you want to
do is doing READ/WRITE faster with sg rather than with read/write
system calls.
--
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