Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1335721

Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id

From Mike Christie <michaelc@cs.wisc.edu>
Newsgroups linux.kernel
Subject Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id
Date 2016-02-16 19:50 +0100
Message-ID <r2SRc-3dV-1@gated-at.bofh.it> (permalink)
References <r1q0W-1Ii-31@gated-at.bofh.it> <r1qaB-1Lx-1@gated-at.bofh.it> <r2w4i-4N8-11@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] Use ida_simple for SCSI iSCSI transport session id Lee Duncan <lduncan@suse.com> - 2016-02-12 18:50 +0100
  Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id James Bottomley <James.Bottomley@HansenPartnership.com> - 2016-02-12 19:00 +0100
    Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id Mike Christie <michaelc@cs.wisc.edu> - 2016-02-12 23:20 +0100
    Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id Chris Leech <cleech@redhat.com> - 2016-02-15 19:30 +0100
      Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id Mike Christie <michaelc@cs.wisc.edu> - 2016-02-16 19:50 +0100
        Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id Chris Leech <cleech@redhat.com> - 2016-02-17 23:40 +0100

csiph-web