[stgt] [PATCH 15/15] Remove dummy RAID controller from LUN 0

[FUJITA Tomonori]

On Wed, 25 Nov 2009 17:42:04 +0200
Boaz Harrosh <bharrosh at panasas.com> 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.


> >> (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 at googlemail.com>
> > 
> 
> 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.


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