On Tue, Feb 8, 2011 at 12:06 AM, <Shyam_Iyer@xxxxxxxx> wrote: >> -----Original Message----- >> From: Richard Sharpe [mailto:realrichardsharpe@xxxxxxxxx] [snip] >> >> So, I wonder if adding just the ability for SCSI upper drivers (sd, >> st, etc) to register interest in different UNIT ATTENTIONS is all that >> interesting and whether vendors would rather have the ability to tell >> drivers (via an ioctl, say) the UNIT ATTENTIONS they are interested >> in, and how they should be mapped. >> > > An ioctl implementation would not be elegant. I was only suggesting an ioctl for informing the driver of the ASC/ASCQ pairs of interest. To get the stream of UAs out of the kernel a different mechanism would be used, like, say, the relayfs. > Even if registering for UAs per vendor was envisioned there are scenarios that can cause a flurry of UAs too.. > (I initially opined to have a vendor specific implementation of logging scsi_netlink events from the scsi_device handler, > it was gloriously shot down ;-)) > > Consider this scenario.. > > Above water mark.. --> Unit Attention > Discard to free up space > Below water mark ... -> Unit Attention > > Consider a ripple scenario where this repeats.. > (Although this can not happen too often it is very much akin to a thrashing scenario) > > The UA should be hints for the filesystem to optimize online. Here is where the thin profile can reduce the UAs. > > Also, you delete a file - select a good age time to discard the associated blocks(debatable and worth any good algorithm writer's salt). > Now I am not sure if the filesystem should run an inkernel thread to do this profile management.. > >> It might be more useful to allow user-land utilities to perform the re- >> scanning. >> >> I would imagine that you will get unit attentions saying that REPORTED >> LUNS DATA HAS CHANGED, but what other UNIT ATTENTIONS would you get? >> If you add storage to a LUN, then perhaps CAPACITY DATA HAS CHANGED. >> >> Perhaps there is also a need to say things like, for these ASC/ASCQ >> values, take the device off line, and all the rest are just advisory >> but pass them all to user land as well. >> > > This is a kind of policy that needs to go into the thin profile although Storage Arrays do take the device offline on reaching > certain hard limits there is nothing like mounting a filesystem read-only ;-) Well, yes, but Ext3/4 and XFS tend to remount the fs RO when writes to the journal fail as well because the SCSI stack takes the device offline :-( If the device has lied in its response to a READ_CAPACITY or READ_CAPACITY16 that is hard to prevent unless the file system has the concept of a lying reserve ... -- Regards, Richard Sharpe -- 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
