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

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

[Swen Schillig]

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.

Signed-off-by: Christof Schmitt <schmichr@de.ibm.com>
Signed-off-by: Swen Schillig <swen@vnet.ibm.com>

---

 drivers/s390/scsi/zfcp_aux.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Index: linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
===================================================================
--- linux_jb_patched.orig/drivers/s390/scsi/zfcp_aux.c
+++ linux_jb_patched/drivers/s390/scsi/zfcp_aux.c
@@ -864,7 +864,8 @@ zfcp_unit_enqueue(struct zfcp_port *port
 
 	zfcp_unit_get(unit);
 
-	scsi_lun = 0;
+	/* Don't report LUN 0 to prevent the REPORT LUNS command from SCSI. */
+	scsi_lun = 1;
 	found = 0;
 	write_lock_irq(&zfcp_data.config_lock);
 	list_for_each_entry(tmp_unit, &port->unit_list_head, list) {

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

[James Bottomley]

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?

James

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

[Hannes Reinecke]

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

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Swen Schillig]

On Monday 18 June 2007 10:47, 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 ...
> 
> Cheers,
> 
> Hannes

Agree, we will provide a new patch covering this issue.
So dump this one, but please don't forget to apply the other patches we sent.

Cheers 
	
Swen

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

[Heiko Carstens]

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

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

[James Bottomley]

On Mon, 2007-06-18 at 15:56 +0200, Heiko Carstens wrote:
> One of my current disks has an FCP LUN of 0x401040ba00000000... That's just

That's correct and coped with ... SCSI LUNs are BE ... this is still
only a four byte lun ... it actually says Flat Space addressing, 2 level
LUN: 16-168

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

We've been around this several times, but no-one's ever seen a LUN that
goes beyond 2 levels (and our current scheme correctly copes with all 2
level LUNs)... to go beyond 2 level, it's a simple case of converting
the LUN to u64 and updating the accessors, but we still haven't found a
reason to do it yet.

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

The only broken bit about our approach is the fact that we print the
translated value (as you show) which doesn't correspond to the actual
hierarchy.  We could quietly update to use the correct number, but we'd
probably have to change our device ID. For only single level LUs, it's
easy, we still use

H:C:I:L

for flat space, I could see something like

H:C:I:L4-L3-L2-L1

Or we could just combine them into a single enumerated LUN.

For peripheral Encoding, perhaps something like:

H:C:I:B4,L4-B3,L3-B2,L2-B1,L1

Logical Unit addressing is starting to look really horrible: something
like:

H:C:I:T4,B4,L4-T3,B3,L3...

And obviously, there's no translation for the extended address method.

James