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@xxxxxxxxxx> > > > > > > > > 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
