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, 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
