Re: [PATCH] scsi: Add "missing" sysfs attribute to scsi_device structure

[Ewan Milne <emilne@redhat.com>]

On Mon, 2013-11-18 at 10:15 -0800, James Bottomley wrote:
> On Mon, 2013-11-18 at 12:59 -0500, Ewan Milne wrote:
> > On Mon, 2013-11-18 at 09:45 -0800, James Bottomley wrote:
> > > On Mon, 2013-11-18 at 12:10 -0500, Ewan D. Milne wrote:
> > > > From: "Ewan D. Milne" <emilne@redhat.com>
> > > > 
> > > > This change adds a "missing" sysfs attribute to scsi_device
> > > > which is set when a previously scanned device no longer appears
> > > > in the REPORT LUNS inventory.
> > > 
> > > A sysfs parameter with time and external input dependent semantics
> > > really doesn't look like a good idea.  What is it you're trying to
> > > achieve that you can't achieve from userspace by watching for the
> > > events?
> > > 
> > > James
> > > 
> > > 
> > 
> > Ideally, one would like to remove SCSI LUNs that are no longer being
> > presented by the device.  The information about which LUNs are no
> > longer there could, I suppose, be obtained from userspace by sending
> > a REPORT LUNS command, but that is somewhat redundant because the
> > kernel will issue one anyway when it is instructed to scan the target
> > for new LUNs.  This patch just makes the information visible.
> 
> But that's the problem, it doesn't.  missing gets reset on every REPORT
> LUN, that makes the information potentially inaccurate, particularly if
> the device triggers multiple change events.
> 
> > Yes, the information is only valid at a point in time, but that is
> > true of REPORT LUNS any time it is used.  If the LUN inventory changes
> > again, there will be a new event generated that can be processed.
> > 
> > A udev event handler tell the kernel to scan for new LUNs, and then
> > potentially tell the kernel to delete scsi_devices that are now missing.
> 
> I don't see what's wrong with sending REPORT LUNS from user space and
> pruning devices that no longer exist.  You should probably do that
> before you trigger a REPORT LUN scan; that way anything that reappeared
> gets put back, so there's no chance of losing a LUN.

Well, yes, except that deleting it first and then (potentially)
re-adding it would leave a period of time when the LUN isn't there.
But, that's exactly what the target reported, so I guess that's OK.

I appreciate the feedback, I'll look at issuing REPORT LUNS from
userspace.

-Ewan

> 
> James
> 
>