Date: Tue, 18 May 2010 17:05:51 -0700 From: Matthew Jacob <mj@feral.com> To: Scott Long <scottl@samsco.org> Cc: freebsd-scsi@freebsd.org Subject: Re: going rogue: incorporating REPORT_LUNS into the SCSI probe sequence Message-ID: <4BF32B5F.30809@feral.com> In-Reply-To: <76ECB3BB-6862-4DCE-8CC9-35ED1BC70BD2@samsco.org> References: <4BF19453.8090801@feral.com> <76ECB3BB-6862-4DCE-8CC9-35ED1BC70BD2@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 5/18/2010 4:59 PM, Scott Long wrote: > On May 17, 2010, at 1:09 PM, Matthew Jacob wrote: > > >> This one is a bit rougher than the others, but I'd like to encourage some discussion about this. >> >> The problems presented by not using REPORT LUNS have been getting uglier and uglier. Any kind of sparse lun arrangement for large JBODs or RAID units just makes life very painful. >> >> These changes manage REPORT LUNS for devices> SPC2, and even manage changes in the list. These changes do *not* address the edge case of having no attached LUN 0 (which has been known to happen- it's not illegal). >> > Under what circumstance is it not illegal? I thought that in SPI it was always illegal. Granted, FC and other protocols might be different, hence my curiosity. > AFAICT there is a difference of opinion on t10 about this. There's a lot of verbiage about things being attached to well known luns. From a practical point of view, it happens a lot. The LSI Santricity stack will create this run 100MB lun 0, but then most people just delete it after creating others, leaving nothing attached to lun 0. The main point here also is that luns that aren't "connected" (e.g., 0x7f types) should still respond to inquiry, request sense and REPORT LUNS. The code in scsi_xpt.c is something I'm going to have to make a little trickier to handle the case I'm referring to.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BF32B5F.30809>