Re: [PATCH 1/1] Remove LUNs that no longer exist when we scan a target with REPORT LUNS.

From: Richard Sharpe <realrichardsharpe@gmail.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: linux-scsi@vger.kernel.org
Subject: Re: [PATCH 1/1] Remove LUNs that no longer exist when we scan a target with REPORT LUNS.
Date: Thu, 19 Aug 2010 19:59:21 -0700	[thread overview]
Message-ID: <AANLkTikz21mH1dKxD-d6qm6Y-GeEfu6pC2ORob-=JnNt@mail.gmail.com> (raw)
In-Reply-To: <1282144397.3035.32.camel@mulgrave.site>

On Wed, Aug 18, 2010 at 8:13 AM, James Bottomley
<James.Bottomley@suse.de> wrote:
> On Wed, 2010-08-18 at 08:10 -0700, Richard Sharpe wrote:
>> On Sun, Aug 15, 2010 at 5:08 PM,  <realrichardsharpe@gmail.com> wrote:
>> > From: Richard Sharpe <realrichardsharpe@gmail.com>
>> >
>> > If the target returns logical_unit_not_supported when we send REPORT LUNS
>> > it means that it supports REPORT LUNS but there really are no LUNs there.
>> > Delete LUN 0 in that case.
>> >
>> > Also, when parsing the LUNs reported, remove any LUNs that used to exist
>> > in the gaps, and remove LUNs beyond the end of those reported. They no
>> > longer exist.
>> >
>> > Also don't scan a target where the ID is too large or the channel is
>> > too large.
>> >
>> > Tested by adding four LUNs with scst_local and then deleting them in
>> > various combinations, including deleting from LUN 0, deleting from last
>> > LUN and deleting in the middle out.
>>
>> Hmmm, before James responds, it turns out that I did not test as
>> carefully as I thought, and deleting LUNs in the order 0, 2, ... does
>> not produce the results I expected, so I will have to rework this.
>
> OK, so I think what I'd really like is an AEN notification
> infrastructure based on the unit attentions that bubbles this up to user
> space for a decision.  That way if user space does the removal, we're
> not going to get into locking or other problems.

Having looked at this some more, I think that I chose the wrong way to
go about this. What I think should happen is that the target (in my
case scst_local, which is both a SCSI LLD and a SCSI target driver
that hooks into SCST) should establish a UNIT ATTENTION condition with
an ASC of REPORTED LUNS DATA HAS CHANGED (ASC = 3Fh ASCQ = 0Eh).

This should be detected by the SCSI stack which should then do a
REPORT LUNS scan and do the appropriate things (like cancel any
submitted requests for LUNs that no longer exist.

Does this sound reasonable?

-- 
Regards,
Richard Sharpe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html