Subject: Re: 64-bit LUN support
To: Bill Studenmund <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 01/06/2005 17:21:36
In message <20050107010314.GB12668@netbsd.org>,
Bill Studenmund writes:
>Content-Type: text/plain; charset=us-ascii
>So what should we do to add 64-bit LUN support to our SCSI layer?
>The other part of the question is what to do about devices that don't=20
>support REPORT_LUNS. I think some sort of fall-back to the old-style "max=
>LUNs" method would be best.
Its been years time since I checked the T10/T11 drafts, but as best I
recall, there's some SCSI level (SCSI-3? The last ANSI level?) where
any device claiming that level is required(?) to implement
I've also seen devices just below that level which just won't talk
happily to an initiator unless the initiator sends them a REPORT_LUNS.
(The Compaq RA4000 RAID array was infamous for that. IIRC, the Linux
driver for the recommended Compaq/Aglient controller sent a REPORT
LUNs from inside the driver, then remapped the native LUNs to 8-bit
LUNS for upper layers; or something equally distaseful.)
So (though it may well be what you planned) I suggest something like:
1. Sending REPORT LUNS to any devices which report themselves as SCSI-3
2. Add a quirk table for SCSI-2 devices which reallyh want a REPORT_LUNS;
3. Fall back to the linear probe for all other devices not covered by 1 and 2,
which don't have the quirk that they're a single-LUn device that
incorrectly reports itself present on all LUNs.
Havent thought about the storage issues, tho.