On Fri, 3 Oct 2008 10:20:48 +0300 "Alexander Nezhinsky" <nezhinsky@xxxxxxxxx> wrote: > On Fri, Oct 3, 2008 at 6:47 AM, FUJITA Tomonori > <fujita.tomonori@xxxxxxxxxxxxx> wrote: > > On Thu, 02 Oct 2008 15:34:19 +0300 > > Alexander Nezhinsky <nezhinsky@xxxxxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
