zfcp: Don't report device as LUN 0 to SCSI stack
Subsystems (3)
PATCH 3/3 zfcp: Don't report device as LUN 0 to SCSI stack
From: Christof Schmitt <[email protected]>
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.
---
drivers/s390/scsi/zfcp_aux.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
drivers/s390/scsi/zfcp_aux.c +2 -1
@@ -864,7 +864,8 @@ zfcp_unit_enqueue(struct zfcp_port *portzfcp_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) {
Quoted 10 lines · Swen Schillig
From: Christof Schmitt <[email protected]>
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
Quoted 12 lines · James Bottomley
Quoted 10 lines · Swen Schillig
From: Christof Schmitt <[email protected]>
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.
Quoted 4 lines
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
Signature · 8 lines
Dr. Hannes Reinecke zSeries & Storage [email protected] +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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 17 lines · Hannes Reinecke
Quoted 12 lines · James Bottomley
Quoted 10 lines · Swen Schillig
From: Christof Schmitt <[email protected]>
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.Quoted 4 lines
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?
Quoted 8 lines
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
Quoted 13 lines · Hannes Reinecke
Quoted 12 lines · James Bottomley
Quoted 10 lines · Swen Schillig
From: Christof Schmitt <[email protected]>
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.
Quoted 8 lines
Quoted 4 lines
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...
Quoted 1 line · Heiko Carstens
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
Quoted 3 lines
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.
Quoted 3 lines
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