From: Mike Christie <michaelc@cs.wisc.edu>
To: open-iscsi@googlegroups.com, Lee Duncan <lduncan@suse.com>,
linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Use ida_simple for SCSI iSCSI transport session id
Date: Fri, 12 Feb 2016 16:13:41 -0600 [thread overview]
Message-ID: <56BE5915.9070308@cs.wisc.edu> (raw)
In-Reply-To: <1455299691.2396.45.camel@HansenPartnership.com>
On 02/12/2016 11:54 AM, 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?
I think it is if we do it by the iscsi rfc. We have two issues.
1. For iSCSI's iSID we need a 24 bit id. The iSID + initiator name is
the SCSI initiator port ID, so targets want the iSID to be reused for
things like persistent reservation tracking.
There are a couple red hat bugzillas. I am not sure if they are open
though. Here is a KB
https://access.redhat.com/solutions/66861
for more info.
We have been lazy and did not implement this and were just reusing part
of the session->sid.
2. For the kobject/sysfs name we want a unique name/id. Linux boxes stay
up a long time and some users login and logout of sessions a lot. We
roll over and have collisions.
Lee's patch was only meant to fix this. The reuse part was not meant to
fix #1, and so it does not handle every case like you suspect.
To fix everything how about this:
- Use Lee's patch to fix #2. We do not need the iSID to match the sysfs
name. Userspace does not do any type of iSCSI iSID <-> kernel session id
matching.
- For #1, in the userespace node db code we can implement some iSID
allocation/management code that follows the spec. We can also add a
blacklist there in case we find broken targets.
next prev parent reply other threads:[~2016-02-12 22:13 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-12 17:38 Lee Duncan
2016-02-12 17:54 ` James Bottomley
2016-02-12 22:13 ` Mike Christie [this message]
2016-02-15 18:26 ` Chris Leech
2016-02-16 18:40 ` Mike Christie
2016-02-17 22:37 ` Chris Leech
2016-03-08 1:02 ` Lee Duncan
2016-03-08 2:15 ` Martin K. Petersen
2016-03-08 17:21 ` Chris Leech
2016-03-09 8:43 ` Johannes Thumshirn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56BE5915.9070308@cs.wisc.edu \
--to=michaelc@cs.wisc.edu \
--cc=lduncan@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=open-iscsi@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®