On 16/02, Chris Leech wrote: > Hi Gorka, > > Thanks for the detailed write-up here. > > It seems to me that we have a way to disable automatic kernel/driver > initiated scans (scsi_mod.scan=manual) for just these type of situations, but > with iSCSI we've already moved control to iscsid and are always doing > user-space initiated manual scanning. So it makes sense that we might want > to disable scans in iscsid, using it just for session management, in order to > let Cinder (or other similar storage managers) take over like they can for > say fiber channel. > > I'd really like it if we didn't need a transport specific configuration, but > I'm not sure how else that would work. iscsid checking the iscsi_mod.scan > setting and treating manual as none? That might be a bit too automatic. > > - Chris
Hi Chris, Thank you for looking into my proposal. So, if we consider the 4 available options to us: 1- Check scsi_mod.scan setting and treat sync/async as autoscan, and none/manual as no autoscans. Pros: No new configuration, good alignment with scsi configuration. Cons: No fine control over scans since you have to set all your SCSI connections to manual to affect your iSCSI connections, and you cannot disable scanning for only specific sessions. 2- Add a specific parameter to the kernel module, iscsi_tcp.scan, so we can have different configurations for scsi and iscsi. Pros: Finer grain control than option 1 over scan as we don't have to set all scsi connections. It's similar to scsi_mod configuration option. Cons: It's weird to set a parameter in the kernel module that is only going to be used by iscsid, we have to add a configuration option to iscsi_tcp, and we still cannot have per session control over the scans. 3- Add a global iscsid configuration option similar to safe_logout. Pros: Finer grain control than option 1 over scan as we don't have to set all scsi connections. Cons: We don't have per session control over the scans and we have to add a configuration option to iscsid. 4- Add a specific configuration option for the sessions to disable automatic scans, as proposed by the patch. Pros: Finer grain control than any other option since we have per session configuration. Cons: We have to add a configuration option to iscsid. I believe option 1 and 4 and the most reasonable. With option 1 favoring not having to add a configuration parameter over finer control of scans, and option 4 doing the opposite. I think that finer control of the scans is preferable (changing the parameter name in the patch to "scan", with acceptable values "auto" and "manual" instead) over using the scsi_mod configuration, but if adding another configuration option is not acceptable I am willing to modify the patch to use the other approach. Cheers, Gorka. > > ----- Original Message ----- > > Hi, > > > > 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. > > > > Cheers, > > Gorka. > > > > > > [1] https://gorka.eguileor.com/iscsi-multipath/ > > [2] https://github.com/open-iscsi/open-iscsi/pull/40 > > > > -- > > -- > 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. -- 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.
