On 11/26/2009 10:13 AM, FUJITA Tomonori wrote: > On Wed, 25 Nov 2009 17:42:04 +0200 > Boaz Harrosh <bharrosh@xxxxxxxxxxx> wrote: > >>>> The dummy RAID controller serves 2 purposes: >>>> (1) commands that are addressed to an inexistent LUN are redirected to it > > My purpose is redirecting appropriate commands (INQUIRY, REPORT_LUNS, > anything else?). I'm lazy so tgt redirects all. I'm happy to accept a > patch to fix it. > Sure, but it is the same as today, No? > >>>> (2) it provides a LUN 0 by default which is required by the SCSI spec >>>> . >>>> >>>> (1) is obviously wrong because instead of "wrong lun" "invalid cdb" is returned >>>> to the initiator. A "shadow LUN" of type NO_LUN is now used for this purpose. >>>> This LU uses bs_null as backingstore, so there are no idle threads spawned for >>>> it (in contrast to the previous dummy raid controller at LUN 0). >>>> >>>> (2) confuses some OSes / users (Windows prompts for drivers, >>>> Solaris repeatedly tries to online the LU, but does not succeed). > > I just tried OpenSolaris and it works (though it complains about lun > 0). Maybe it finally learned the proper way? > > >>>> It's now the user's responsibility to attach a LU to LUN 0 to adhere to the >>>> SCSI spec (Solaris / WinXP don't insist, Linux does!). >>>> >>>> Signed-off-by: Arne Redlich <arne.redlich@xxxxxxxxxxxxxx> >>> >> >> What was the final disposition on this patch. I've never seen an argument against it, > > I think that 'shadow lun' is hacky and I don't like to use that trick > for poor OSes. > The hack is already there today. Only this patch tries not to publish the hack to the outside world. "Haa, that extra, do-nothing, good-for-nothing, LUN0", "Yes this is tgt target". "Other wise it is very good I recommend it". It has become a characteristic of tgt that LUN0 thing. And no, "poor" is tgt that needs an extra LUN0 that has no purpose to the outside world. Surly that was not what the scsi standard meant when they said mandatory LUN0. What they meant is that if you don't have any LUNs to serve don't identify and don't take any address space, you are good for nothing. Out of all the scsi-targets out there in the world tgt is the only one who took that LUN0 rule to mean: "lets stick a no-op LUN0 to comply" > >> but it was never submitted either. Why not? >> >> The way I see it. It should be accepted. Since we have a configuration file arrangement >> in place, which is the recommended way to work now days. And since we have "service" >> scripts for major distros. > > Since when the configuration file is the recommended way? It's one > option but not the recommended way. Configuration by hand should work > well too. OK, the recommendation is besides the point. If one is using "configuration file" then we can cover is ass. If one is doing Configuration by hand then it is up to him to also configure a LUN. Lets try and find an acceptable solution. What if we refuse any connections until we have the first LUN configured. I know how to do it in iscsi, is there a way to do it in a general way? Boaz -- 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
