On Tue, Jun 19, 2001 at 11:08:40AM -0700, Poul Petersen wrote:
> > This way, the device at LUN 0 is found to start the scan, and
> > then later
>
> On a more general question - in order to work around the
> Zzyzx problem, I have moved the call to get_device_flags
> as before and added (I also removed all traces of BLIST_FORCESCAN)
>
> bflags = get_device_flags (scsi_result);
>
> if (bflags & BLIST_SPARSELUN) {*sparse_lun = 1;}
>
> if (SRpnt->sr_result) {
> scsi_release_request(SRpnt);
> return 0; /* assume no peripheral if any sort of error
> */
> }
>
> ...
The above is a good idea, but the get/check of the flags should
happen after the sr_result.
>
> This way, even though the peripheral qualifier check exits, the
> sparse_lun parameter gets set first so scanning can continue on the
> Zzyzx device.
>
> BTW, what should the peripheral qualifier be returned as
> when scanning LUN 0 of a multiple LUN capable device which has no devices;
> for example if the RocketStor had no LUN mappings? If it should return
> 011b in this case, then the above modification would scan all the LUNs,
> while the original code would not. If it still returns 001b, then there
> won't be any difference...
A peripheral qualifier (PQ) of 011b should not halt the scan for a sparse
LUN device - current behaviour without your change above is to halt all
scans if LUN 0 has 011b, but for sparse LUN devices, if LUN 0 is "found",
other LUNs with 011b would not halt the scan.
I think the SCSI spec is a little vague on what a PQ of 011b means, it says
(SPC-2 R19, ftp://ftp.t10.org/t10/drafts/spc2/spc2r19.pdf) for PQ values
of 001b and 011b:
001b
The device server is capable of supporting the specified peripheral device
type on this logical unit. However, the physical device is not currently
connected to this logical unit.
011b
The device server is not capable of supporting a physical device on this
logical unit. For this peripheral qualifier the peripheral device type
shall be set to 1Fh to provide compatibility with previous versions of
SCSI. All other peripheral device type values are reserved for this
peripheral qualifier.
"not capable" seems somewhat ambiguous for cases where the device does not
currently have a LUN mapped - the device is currently "not capable" of
handling the LUN; 001b seems more appropriate, even though the device
will not ever be "connected".
For linux, returning a 001b can be bad, as it will allocate a Scsi_Device,
and use up an sd entry (and you can never access the device). Doug Ledford
posted a patch to skip these (apparently it is included in the redhat
7.1 2.4.2-2 kernel).
You might want to check the specs, and see if you can modify the PQ value
returned - some array devices can be configured to return different PQ
values, since different operating systems behave differently based on
the PQ.
-- Patrick Mansfield
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
