On Wed, 10 Jan 2001, Prasenjit Sarkar wrote:
>
>
>
> I am aware of the 64-bit LUN specification, but can you clarify what you
> meant by 'id'?
SCSI ID
> If you meant the WWN-type identifier in FCP,
Seems, that FCP-2 [ftp://ftp.t10.org/t10/drafts/fcp2/fcp2r04.pdf]
maps FCP term "address identifier of target port" (should be D_ID) to
SCSI term "target identifier" (SCSI ID, I think) - see Annex A.1.
Since D_IDs are volatile, I think it would be nice to use the WW(P)N of
targets for device discovery (see FCP-2, annex F.1).
>then I think it should not be
> part of the scan
> procedure (as it is currently: 0 to max_id) and not something the SCSI
> upper layer
> should be concerned with until you implement multipathing.
to find alternate paths by means of WWN? Yes.
> However, if id
> represents
> a bus [virtual bus for FCP] and is used for scanning, then the current 32
> bit value is fine.
32bit would be enough for D_DID (24 bit).
> REPORT LUNS would be a good start to make the current architecture more
> network
> friendly [I was a bit suprised not to see it defined in scsi/scsi.h]
>
> This is a stretch, but any possibility of introducing NT-style filter
> drivers?
don't know much about it
>
>--------------------------------------------------------------------------------------------------------------
> further proposals:
>
> - broaden ID and LUN to 64bit to follow SCSI-3 (or associated interfaces,
> such as FCP)
>
> - enhance scsi_scan.c to make use of REPORT LUNS (useful for large but
> sparsely populated LUN address spaces (i.e. 64bit FCP_LUN)
>
> - remove the LUN < 8 restriction from scsi_scan.c finally
> (only valid for parallel SCSI but not i.e. for FCP ;)
> max. SCSI LUN should be provided by the HBA
> drivers - as it is currently - and respected by scsi_scan.c - as it is not
> currently)
>
>
>
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
