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 [1].
> >
> > 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 [2], 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 open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to