Re: [PATCH 3/3] zfcp: Don't report device as LUN 0 to SCSI stack

[Heiko Carstens <heiko.carstens@de.ibm.com>]

On Mon, Jun 18, 2007 at 10:47:28AM +0200, Hannes Reinecke wrote:
> James Bottomley wrote:
> > On Tue, 2007-05-29 at 15:29 +0200, Swen Schillig wrote: 
> >> From: Christof Schmitt <schmichr@de.ibm.com>
> >>
> >> zfcp reported units to the SCSI stack starting
> >> with number 0. LUN 0 reported to the SCSI stack is usually 
> >> not the FCP LUN 0. When scanning for devices, 
> >> the SCSI stack tried to issue a REPORT LUN command to LUN 0. 
> >> The current design for zfcp does not want the SCSI stack to scan
> >> for devices, since they are configured explicitly via sysfs.
> >> This patch changes the numbering to always start with LUN 1 and therefore
> >> prevent the SCSI stack sending REPORT LUN command.
> > 
> > As a general principle, this does sound to be wrong (at least shifting
> > the LUNs).  Wouldn't something like the existing blacklist preventing
> > the REPORT LUN command from being sent be more appropriate?
> > 
> IMO the zfcp driver should export the FCP LUNs and not building their
> own internal SCSI LUN to FCP LUN mapping table.
> That would avoid this issue, too. And would make the zfcp driver more in
> line with everyone else ...

One of my current disks has an FCP LUN of 0x401040ba00000000... That's just
the limit that scsilun_to_int() (four bytes that is) still works with.
Just wondering if there are patches around that make the SCSI stack work
with eight byte LUNs?
Otherwise this looks like replacing a broken approach with a different but
at least incomplete approach. The above LUN would be translated to a SCSI
stack internal LUN of 1085947920. Hmm...