The Lee-Man | 23 Jun 19:22 2016
Picon
Gravatar

open-isns has moved under the github open-iscsi organization

Hi All:

I have moved the open-isns project, previously under my home projects, to the open-iscsi project, where we are consolidating several iscsi-related projects.

The new home is now: https://github.com/open-iscsi/open-isns

As before, we will share the open-iscsi mailing list (this list) for announcements and/or reports, since the volume of such emails are so low.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
electric0209 | 22 Jun 05:38 2016
Picon

login fails

Hi everybody.

I have the question....

log :
iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not log into all portals

Could you tell me the reason?

thanks for your help.
 

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
陳德安 | 22 Jun 10:07 2016
Picon

login fail


Hi,

I have the question at login of iSCSI

console:

iscsiadm: initiator reported error (13 - daemon access denied)
iscsiadm: Could not log into all portals

Could anyone tell me the reason?

Thanks for your help.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
asubra | 19 Jun 23:36 2016
Picon

sysfs compatibility during logouts and could not read session info errors

Hi All,

We have a large number of iscsi logins and logouts in our setup. During the logouts we see the following messages. Eventually the logouts succeed after retries but does this point to some more fundamental mismatch which should be corrected or can these be ignored?

2016-06-19 13:55:12 INFO miutils.py:2255 Executed: sudo iscsiadm --m node --logout --target iqn.2010-06.com.xyz:7b1652d2-4185-4b01-97cd-8add64a97c37-tgt0

2016-06-19 13:55:12 INFO minutils.py:2259 stderr: iscsiadm: Could not lookup devpath for session174. Possible sysfs incompatibility.


iscsiadm: Could not lookup devpath for session176. Possible sysfs incompatibility.


We are using open-iscsi-2.0-872-rc4-bnx2i on CentOS with Linux version 3.10.0-229.26.2.el6


Based on past ML posts, I have checked "whereis iscsid" and iscsiadm and they all seem to be of the same bitness (x86_64).


We do a fairly large number of logins and logouts and one of the things to try out for improving performance would be Chris' patches from another recent thread. Will give it a shot based on our open-iscsi versions for the patch and see how that goes.


But the above messages during logouts are seen as well as some other messages during logins


2016-06-19 13:56:18 INFO minutils.py:2255 Executed: sudo iscsiadm --m node --targetname=iqn.2010-06.com.xyz:de49c23b-76c2-422d-8659-74ad8a47e864-tgt3 --login --portal 10.4.81.16

2016-06-19 13:56:18 INFO minutils.py:2259 stderr: iscsiadm: could not read session targetname: 5

iscsiadm: could not find session info for session17


TIA for any pointers/inputs.


Regards,

Anand

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 19 Jun 19:44 2016
Picon
Gravatar

open-isns updated to version v0.96

Several updates have been recently to open-isns
(many thanks to Christian Seiler), and as a result
I've updated the version to v0.96.

Available at https://github.com/gonzoleeman/open-isns/releases/tag/v0.96.

Note: It is my plan "some time soon" to move open-isns from
being a "personal" project on github to being under the
"open-iscsi" group. As with the open-iscsi change,
it will just mean a different URL, but the code and
process will remain the same.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Syed Mushtaq | 7 Jun 21:24 2016
Picon
Gravatar

Performance issues when logging into a large number of targets

Hi,

We run a small public cloud in Canada and were testing out a VDI-per-LUN type of storage where each virtual disk is mapped to a LUN on the storage array. We have been seeing delays when an iscsi login is made. We use open-iscsi 2.0-873 in our production. I compiled that with profiling support to figure out where the delay is. I would love if someone could help me figure out the performance bottlenecks.


I currently have the following sessions:

[root <at> ucs-xen1 ~]# iscsiadm -m session | wc -l
798
[root <at> ucs-xen1 ~]#

If I attach a new LUN the time taken is about 9.3 seconds

[root <at> ucs-xen1 ~]# time ./iscsiadm -m node -p 172.31.255.160 -T  iqn.2010-01.com.solidfire:giwd.sr-198.3588 -l
Logging in to [iface: default, target: iqn.2010-01.com.solidfire:giwd.sr-198.3588, portal: 172.31.255.160,3260] (multiple)
Login to [iface: default, target: iqn.2010-01.com.solidfire:giwd.sr-198.3588, portal: 172.31.255.160,3260] successful.
Number of recs found 1


real    
0m9.312s
user    
0m0.088s
sys    
0m0.120s
[root <at> ucs-xen1 ~]#


I am attaching the gmon output here

-Syed

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Attachment (gmon_txt): application/octet-stream, 34 KiB
Christian Seiler | 2 Jun 01:46 2016
Picon

Re: iscsistart takeover vs iface names

Hi,

On 06/01/2016 11:35 PM, Mike Christie wrote:
> Ccing Christian and dropping list to make sure the mail does not get
> lost in his open-iscsi filters.

It's actually the other way around: I get emails from the list just
fine, but in the end I resorted to creating a gmail account to be able
to post to the list, because emails from my real email address were
just rejected by the list for no apparent reason. (cc'ing the list
again.)

> How does debian implement iscsi boot?
> 
> Does it:
> 1. Run iscsistart for the root sessions/targets in the initramfs and
> then start iscsid during the normal startup procedure and run iscsiadm
> at that time for other non boot/root related sessions?

Yes. You can find the current code used by Debian (and by extension
Ubuntu) in the initramfs here:
http://sources.debian.net/src/open-iscsi/2.0.873%2Bgit0.3b4b4500-15/debian/extra/initramfs.local-top/

Basically, there are 3 ways you can boot from iSCSI at the moment in
Debian (via the officially supported hook to initramfs-tools):

1. You create a special file /etc/iscsi/iscsi.initramfs (source by the
shell in the initramfs) with a couple of settings (ISCSI_TARGET_IP=...,
ISCSI_USERNAME=..., etc.). That file is copied into the initramfs
image, which then calls iscsistart. If you install Debian on iSCSI via
the official installer, it will create this file with the corresponding
settings.

2. You create the file /etc/iscsi/iscsi.initramfs with the setting
ISCSI_AUTO=true, then the initramfs will use iscsistart -f to auto-
configure the iSCSI sessions. (And also iscsistart -N to configure the
the network interfaces, if required.)

3. This has been added very recently: root=iscsi:... (RFC 4173 syntax)
is now also supported, there you don't need to create any special file,
just have the package installed. In that case, also iscsistart will be
used.

In no case is the iSCSI database or iscsid used in the initramfs at
the moment. (That means that you can use the iscsi.initramfs file to
configure a session separate from the iscsi database btw.)

(Note that dracut is available as an alternative in Debian, and it
brings its own iSCSI support. I haven't gotten around to testing that
so far, though; but I'm pretty sure it won't work, because dracut does
start iscsid in the initramfs since fall of last year IIRC, but due to
Debian policies we install the iSCSI database directly in /etc/iscsi
instead of /var/lib/..., whereas IIRC the dracut code tries to copy the
database from the official upstream location. Making sure dracut also
works in Debian with iSCSI is on my TODO list for Debian 9.)

The system startup code (once the root file system is mounted) is
independent of the initramfs and boils down to basically the following
two steps:

1. start iscsid
2. iscisadm -m node --loginall=automatic

If a session is configured both in the database as well as the
iscsi.initramfs file, iscsiadm will display a warning and return exit
code 15 (already logged in), but we use SuccessExitStatus in our
systemd service file, so it's not treated as an error.

(The shutdown logic is more involved, because we try to detect which
sessions are used for the root and /usr filesystems, if any, and only
shut down all the _other_ sessions. But we also allow the admins to
override that and not shutdown any session at all, in case they have a
storage configuration that we don't properly detect.)

> 2. Run iscsiadm and iscsid in the initramfs, stop iscsid, and then
> restart it and maybe run iscsiadm again for non root/boot related
> sessions/targets during the normal startup procedures?

We have a low-priority TODO item to think about maybe (perhaps
optionally) supporting using iscsid in the initramfs, but haven't
gotten around to that so far.

Hope that answers your question.

That all said, we're not married to the internals of the current
approach, so if there were to be good reasons to do something
differently, so for example if you decided to drop iscsistart upstream
and say the only supported way is to have iscsid running in the
initramfs, we'd be open to that, as long as we can support all the
potential previous use cases with it.

Regards,
Christian

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

The Lee-Man | 13 May 18:58 2016
Picon
Gravatar

Using all 24-bits of the ISID

When we made the most recent changes to open-iscsi:

  "make use of all 24 bits of ISID qualifier space"

we agreed it would be a "good thing" to modify the kernel
to use the "id" routines instead of an atomic int.

I created a set of patches and submitted them, and they
got comments, but the current version has sat for a month
without comment.

I'd really like to either get these changes into the kernel
if we want them there.

Can anyone on the list review them, please, if they get a chance?

On LKML or linux-scsi, the subject is:

  "Re: [PATCHv3 0/2] target: make location of /var/targets configurable"

Thank you.
--
Lee Duncan

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Zhengyuan Liu | 12 May 05:29 2016
Picon

open-iscsi Ping timeout error.

Hi everyone:
I create a target using fileio as the backend storage on ARM64 server. The initiator reported some errors showed bellow  while perform iozone test.

[178444.145679]  connection14:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4339462894, last ping 4339464146, now 4339465400
[178444.145706]  connection14:0: detected conn error (1011)
[178469.674313]  connection14:0: detected conn error (1020)
[178504.420979]  connection14:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4339477953, last ping 4339479204, now 4339480456
[178504.421001]  connection14:0: detected conn error (1011)
[178532.064262]  connection14:0: detected conn error (1020)
[178564.584087]  connection14:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4339492980, last ping 4339494232, now 4339495484
..............................

I try to trace the function call of target iscsi. Then, I found the  receiving  thread of target iscsi blocked at fd_execute_sync_cache -> vfs_fsync_range. Further, vfs_fsync_range may takes more than 10 seconds to return,while initiator Ping timeout would happened after 5 seconds.   vfs_fsync_range was call with the form vfs_fsync_range(fd_dev->fd_file, 0, LLONG_MAX, 1) every times  which means sync all device cache. 
So, is this a bug?
How  does Initiator send sync_cache scsi command? 
Does it need to sync all device cache at once?
Any reply would be thankful.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
whls.jing | 9 May 17:32 2016
Picon

Question: Where are scsi commands encapsulated?

Hi,

I am recently looking into the process of iSCSI initiator. I wonder where the source codes are that receive the scsi commands and encapsulate them into iscsi format. I have walked through the interaction between iscsiadm and iscsid, but I did find that. I thought it may be written in qtask structure, but it seems the payload_len is never set within the code.

Could anyone help answer this question?

Thanks.

--
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+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
To post to this group, send email to open-iscsi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Mike Christie | 22 Apr 20:28 2016
Picon

[ANNOUNCE] new open-iscsi maintainers

Hi open-iscsi list,

I am very happy to announce that Chris Leech and Lee Duncan will be
taking over open-iscsi maintainership.

They have created a new github organization:

https://github.com/open-iscsi

that will host the userspace code.

Send all userspace patches to the list and to Chris Leech
(cleech@...) and Lee Duncan (lduncan@...).

Send kernel patches to this list, myself, and also to Lee and Chris. In
the hopefully near future, they will be comfortable with taking over the
kernel code as well.

Thanks to Lee and Chris for taking this over!

--

-- 
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+unsubscribe@...
To post to this group, send email to open-iscsi@...
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Gmane