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@xxxxxxxxxx> > >> > >> 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... - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
