On 14/02, Bart Van Assche wrote: > On 02/13/17 07:07, Gorka Eguileor wrote: > > While working on Cinder, the block storage service in OpenStack, I > > noticed that the autoscan mechanism in iscsid is creating issues for us > > and I would like to popose a mechanism to make it optional. > > > > The problem for OpenStack deployment comes from the automatic scan of > > targets at startup, login, and AEN/AER reception. > > > > These are clearly great for normal use cases, but in our situation we > > may have very lively targets that are constantly changing exposed LUNs, > > and the autoscan mechanism is just polluting our systems with paths that > > are being removed, because we have multiple systems accessing different > > LUNs in the same target while they are being removed. More details of > > the issues can be found in this post . > > > > My proposal is adding a new configuration option to the sessions, called > > "autoscan_en", that allows us to disable the autoscan mechanism. > > > > I have submitted the patch via pull request , and I don't know if > > this is an acceptable approach in the eyes of the community, so any > > guidance will be greatly appreciated. > > Why to make the iSCSI autoscan mechanism optional? That will make the iSCSI > initiator more complicated. Recent kernel versions generate uevents upon > reception of a SCSI sense code. How about using that mechanism as a trigger > for a rescan for users who want automatic rescanning of LUNs? > > Bart. >
Hi Bart, Thank you for taking the time to think about my proposal, and there might have been a misunderstanding, apologies for not being clearer in my original email, I'll try to present a proper picture this time. The automatic scan mechanism is already present in iscsid, so users who want to have it enabled don't need to do anything, since this is the current, and only possible, behavior. The issue comes when you don't want to have this behavior, since the code doesn't allow you to prevent iscsid from doing the scans. Because the scanning feature is already there, we cannot make a breaking change and remove the AEN/AER package treatment in iscsid to let them be treated through uevent triggers (I didn't know the sense code treatment was there). But even if it was acceptable to make this non backward compatible change, we would still have an issue with iscsid scans that are automatically done at program start and on logins, and in my opinion it would be an inferior solution, since you would have to disable the triggers globally even when you only wanted them disabled for some specific sessions. I believe proposed change is more flexible at the cost of a tiny increase in code complexity, as we are just adding a new configuration option and doing a couple of simple checks. It also has the added benefit of being easily backported. Cheers, Gorka. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to open-iscsi+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.