On 02/15/2016 12:26 PM, Chris Leech wrote: > On Fri, Feb 12, 2016 at 09:54:51AM -0800, James Bottomley wrote: >> On Fri, 2016-02-12 at 09:38 -0800, Lee Duncan wrote: >>> The scsi_transport_iscsi module already uses the ida_simple >>> routines for managing the target ID, if requested to do >>> so. This change replaces an ever-increasing atomic integer >>> that tracks the session ID itself with the ida_simple >>> family of routines. This means that the session ID >>> will be reclaimed and can be reused when the session >>> is freed. >> >> Is reusing session ID's really a good idea? For sequential sessions it >> means that the ID of the next session will be re-used, i.e. the same as >> the previous sessions, which could lead to target confusion. I think >> local uniqueness of session IDs is more important than wrap around >> because sessions are short lived entities and the chances of the same >> session being alive by the time we've wrapped is pretty tiny. > > I've got a few complaints about target resources being tied up because > we don't reuse session IDs. The ISID becomes a component in the > I_T nexus identifier, so changing it invalidates persistent reservations. > >> If you can demostrate a multi-target problem, perhaps we should rather >> fix this by making the next session id a target local quantity? > > Mike's got a good point that we don't really need to base the ISID off > of our local session identifier (kobject name). I think getting reuse > right may be a bit trickier than being a target local value, because it > needs to be unique across target portal groups. Which probably furthers > the argument that we should deal with that in the userspace tools. > > If we plan to split the protocol ISID cleanly from the kobject name, > I guess the question is if aggressive reuse of the local identifier is > better than dealing with the unlikely collision on rollover?
I thought Lee's patch to convert the host_no from a atomic_t to ida based was merged in Martin's tree. If that is going upstream, then I thought you would want to fix the session id too. Is the concern similar to /dev/sdX reuse and bad apps? In this case, some app might do a logout and login, but not update the sysfs mapping. You could then hit corruption due to the sysfs session id now mapping to a different target. -- 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.
