----- Original Message -----
From: "Robert Frey" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "Mark Veteikis" <[EMAIL PROTECTED]>; "Eric Youngdale" <[EMAIL PROTECTED]>;
"casler heather" <[EMAIL PROTECTED]>; "'linux-scsi'"
<[EMAIL PROTECTED]>
Sent: Monday, January 31, 2000 8:01 PM
Subject: Re: Skipping LUN 0?
> REPORT LUNS is only required to be supported by multi-LUN devices for LUN
0. It
> is optional for multi-LUN device LUN > 0 as well as single-LUN devices,
cf.
> t10.org SPC-2. Also a SCSI device must always at a minimum have a LUN 0 -
it's
> unlikely this will ever change because LUN 0 has other specific
characteristics
> defined in the SCSI standards.
>
> Eric I know you're busy but here's a future change that would be an
improvement
> to Linux's SCSI device detection and I think would help the situation in
the
> future with multi-LUN devices. The first command sent to a SCSI device for
a
> SCSI bus scan should always be an INQUIRY. The last time I checked
> (actuallyobserved with a SCSI analyzer) it is a TEST UNIT READY which
doesn't
> make sense in all cases like for scanners and CD-ROM changers. After the
LUN 0
> INQUIRY the device should be passed to the Upper Layer driver to complete
> initialization for the device that makes sense for that class of device.
A couple of points.
As things stand currently, the mid-layer by and large treats individual
luns of a multi-lun device as separate devices. The upper level drivers
don't know the difference between two disks that have different SCSI ids,
and two disks that have the same ID but different luns. I have wondered
over the years whether we should rearrange the datastructures again to
essentially stratify devices/luns. The major place that I know of where
this screws us up is in the treatment of changer types of devices, as we
have some hack code to serialize the access to a single lun at one time.
During the bus scan, we enumerate every target/lun combination that
currently is on the system. As devices are detected, they are offered to
all of the upper level drivers to see whether they want to drive them or
not.
Originally when I first added support for logical units, we only did the
INQUIRY we had problems with devices which falsely indicated the presence of
devices on all logical units. I suppose it was mainly because I failed to
read the standards closely that this behavior surprised me. The addition of
the TEST UNIT READY was really more a way of probing to see if any sort of
actual device exists at that logical unit. We don't insist that the thing
actually succeed - if it comes back and says it isn't ready because there is
no media (or for any other reason, for that matter), that is still good
enough to pass the test, for example.
I should add that it has probably been about 5 or 6 years now since we
did that, and the realities of today's devices are undoubtedly different, so
some of the assumptions that went into that code could certainly be
re-examined.
One thing that existed 5 years ago were fan-out "devices" which allowed
you to attach multiple normal single lun devices in clusters, and each of
the physical devices was mapped to a different lun. At least I gather this
is what they did - someone explained it to me once, but I never actually saw
one. The point is that this sort of monstrosity destroyed the symmetry
that theoretically should exist where each logical unit is in theory a sort
of clone of the other logical units for that device. Do these sorts of
things still exist any more?
Anyways, my long-winded answer is that I gather from what you are saying
above that we should first do an INQUIRY, and if the INQUIRY succeeds, then
we perform a scan on all luns for the device in question.
> Note the INQUIRY data for SPC-2 devices does indicate whether a device
supports
> REPORT LUNS with the HiSup bit. An Upper Layer driver could detect this
bit set
> and decide to use the REPORT LUNS command.
There is also a bit in there that indicates that the device is a changer
which we could make use of if we wanted to. Mainly to toggle the single-lun
behavior.
One thing I should mention in passing. I get lots of comments and ideas
from people as to future enhancements, and I basically need to keep a list
in order to make sure I don't forget good ideas. I have a relatively
recent version of my todo list in http://www.andante.org/scsi_todo.html.
Feel free to make comments, send additions, etc. Some of the simple things
towards the top are already in the works. Some of them are pipe dreams.
Some are easy, some are hard. Some of the ideas I have in there are half
baked, so don't get your knickers in a twist about the proposed solutions to
some of them :-).
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
