Greg KH | 14 Dec 21:16 2014

Linux kernel development reports for the 3.17 release

Hi,

I'm trying to keep track of the different companies that people are
working for, or if people are just doing this as a hobby, or being paid
as a consultant for future articles on lwn.net about who is doing the
work on the Linux kernel.

Jonathan Corbet has also been writing articles at lwn.net about this
topic, and we share the same set of scripts, as well as we write a
yearly article for the Linux Foundation about Linux kernel
contributions.  An example of this can be found at:
	http://www.linuxfoundation.org/publications/whowriteslinux.pdf

Your email address shows up in the changelog for the 3.16 kernel
release as a contributor, but I can't seem to place it with a company.
If you don't mind, could you let me know what company you work for?  Or
if no company, do you want to be classified in any of these other
categories instead:
	- Amateur/Hobbyist/Unaffiliated/None
	  - this category is for people who are doing kernel work, but
	    not getting paid by any corporation to do it.
	- Consultant
	  - this category is for people who are consultants working on
	    the kernel and getting paid by other companies (not your
	    own) to do the work
	- Academia
	  - this category is for people working for Universities and
	    doing kernel work as part of their research or other
	    responsibilities related to school work.
	- Unknown
(Continue reading)

The Lee-Man | 11 Dec 20:53 2014
Picon

Problem setting host net params via iscsiuio on first try: bad error message

Hi Mike:

I have started working more with iscsiuio.

I have discovered what I consider a bug in an error message printed during normal operation of iscsiadm that makes it seem like something bad happened.

As you know, when performing discovery via the bnx2i transport and the iscsiuio daemon, the iscsiadm command tries to set up host parameters when a target is discovered. The iscsiadm command does this by sending a message to the iscsiuio daemon, who actually does the work in this case and then normally returns that information.

But it looks like the design of iscsiuio is that it does not even try to set up the NIC it is using very first time its called. Instead, it initializes the NIC only when the first attempt to use it is received, while it returns EAGAIN to the caller. The protocol evidently is that the caller knows to retry. In this case, the iscsiadm code retries several times no matter what error is returned. In fact, the iscsiadm code being used translates all errors received from this attempt to talk to iscsiuio into an "INTERNAL_ERROR", and the communication is retried anyway.

This translation is the only problem, IMHO, and resulted in these messages from iscsiadm, which are misleading (and poorly formatted):

 iscsiadm: Could not set host net params (err 29)

 iscsiadm: Connection to discovery portal 10.125.128.120 failed: internal error
 ...

which becomes, with my patches:

 iscsiadm: Could not set host net params (err 29)
 iscsiadm: Connection to discovery portal 192.168.30.1 failed: operation failed but retry may succeed
 ...

The "fix" is simple: in the case where iscsiuio returns EAGAIN, let it through. (And fix the error message printing so we don't core dump, of course.)

I thought about a more aggressive fix, i.e. letting all return values from the communications attempt through, but I worried about fixing something that is not really broken and perhaps breaking something else. So, in the spirit of fixing just what is broken, I submit two patches:

0001-Supply-strings-for-newly-added-error-numbers.patch: This patch is needed by the second patch, though it stands alone. This patch fixes the problem that a couple of new error codes have been added to the open-iscsi package but the array of error strings used to convert those errors into printed messages has not kept pace. So two missing error messages are added.

0002-Allow-setting-host-params-to-return-EAGAIN-errors.patch - This is the simple patch that allows EAGAIN errors through when trying to talk to iscsiuio. If you want the more aggressive version please let me know.

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Picon

CentOS7 and systemd ordering when shutting down results in unclean unmount

Setup iSCSI on CentOS7. Mounted a iSCSI disk and am running a small MySQL instance on the disk. The iSCSI disk and MySQL instance all come online fine with booting but when shutting down things seem to get very upset and the drive does not get unmounted cleanly.

Does not look like I'm the only one having the issue. Another report that is very similar was posted here:

https://www.centos.org/forums/viewtopic.php?f=47&t=49337

This might be a systemd issue but figured I'd post here first to see if anyone else has had this issue and has any suggestions.

Relevant version info:

CentOS Linux release 7.0.1406 (Core)
systemd-208-11.el7_0.4.x86_64
iscsi-initiator-utils-6.2.0.873-21.el7.x86_64

Systemd unit file for MySQL server:

[Unit]
Description=MySQL Server
After=nss-lookup.target network.target remote-fs.target time-sync.target
Wants=nss-lookup.target network.target remote-fs.target time-sync.target

Logs from journalctl:

Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): __ext4_get_inode_loc:4039: inode #58989720: block 235930089: comm mysqld: unable to read itable block
Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1) in ext4_reserve_inode_write:4962: IO failure
Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logging out of session [sid: 1, target: example.target, portal: 192.168.1.30,3260]
Dec 09 09:27:03 example.server.com iscsiadm[3906]: Logout of [sid: 1, target: example.target, portal: 192.168.1.30,3260] successful.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped Login and scanning of iSCSI devices.
Dec 09 09:27:03 example.server.com systemd[1]: Stopping Open-iSCSI...
Dec 09 09:27:03 example.server.com systemd[1]: Stopped Open-iSCSI.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped MySQL database.
Dec 09 09:27:03 example.server.com systemd[1]: Stopping System Time Synchronized.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped target System Time Synchronized.
Dec 09 09:27:03 example.server.com systemd[1]: Stopping Remote File Systems.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Remote File Systems.
Dec 09 09:27:03 example.server.com systemd[1]: Unmounting /iscsi-disk...
Dec 09 09:27:03 example.server.com systemd[1]: Stopping Host and Network Name Lookups.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Host and Network Name Lookups.
Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device sdb1, logical block 40960
Dec 09 09:27:03 example.server.com iscsid[853]: Connection1:0 to [target: example.target, portal: 192.168.1.30,3260] through [iface: default] 
Dec 09 09:27:03 example.server.com iscsid[853]: iscsid shutting down.
Dec 09 09:27:03 example.server.com mysqld_safe[1694]: 141209 09:27:03 mysqld_safe mysqld from pid file /backup/mysql-bacula/data/mysqld.pid ended
Dec 09 09:27:03 example.server.com kernel: EXT4-fs warning (device sdb1): ext4_end_bio:287: I/O error writing to inode 58989720 (offset 0 size 4096 starting block 40960)
Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): ext4_find_entry:1309: inode #58982448: comm mysqld_safe: reading directory lblock 0
Dec 09 09:27:03 example.server.com kernel: Aborting journal on device sdb1-8.
Dec 09 09:27:03 example.server.com kernel: Buffer I/O error on device sdb1, logical block 133726208
Dec 09 09:27:03 example.server.com kernel: lost page write due to I/O error on sdb1
Dec 09 09:27:03 example.server.com kernel: JBD2: Error -5 detected when updating journal superblock for sdb1-8.
Dec 09 09:27:03 example.server.com kernel: EXT4-fs error (device sdb1): ext4_put_super:789: Couldn't clean up the journal
Dec 09 09:27:03 example.server.com kernel: EXT4-fs (sdb1): Remounting filesystem read-only
Dec 09 09:27:03 example.server.com systemd[1]: Unmounted /iscsi-disk.
Dec 09 09:27:03 example.server.com systemd[1]: Stopping Network is Online.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Network is Online.
Dec 09 09:27:03 example.server.com systemd[1]: Stopping Network.
Dec 09 09:27:03 example.server.com systemd[1]: Stopped target Network.

Any help would be greatly appreciated.

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
pillar1986 | 3 Dec 03:59 2014
Picon

new comer questions on tgt,lio-utils and iscsitarget

hi
I am new to iscsi ,have some questions in learning,quite appreciate for your help and time

1 \ both lio-utils and tgt are pure user space program? Both of them are using the kernel iscsi module ? So ,what is the difference between them?
2 \ Are there any guide documents on how to setup a iscsi target using both tgt and lio-utils?

Thanks a lot for your help and time !

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
stefjeot | 2 Dec 15:06 2014
Picon

Slow dir / Performance.

We have 2 Equallogic Systems, And a Dell Servers.

We have every server give a block device home dir , so the user data are on the home dir this is working great its format on xfs filesystem, and running iscsiadm version 2.0-870 with linux kernel 3.10.57

But when we logging on the server, the first time we do a dir command on the home dir, its take a long time when we get feedback on the dir , the next time is fast when we do a dir.
Now we have users on this systems and this problem give not good performance on sql and websites an e-mail we are running on the server.

Are the some information how i can fix ore maybe get this problem better under control ?

I hope so that somebody can help me, i am searching for more than 3 weeks now.

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Stefan B | 2 Dec 15:22 2014
Picon

Slow / Performance problem.

We have 2 Equallogic Systems, And a Dell Servers.

We have every server give a block device home dir , so the user data are on the home dir this is working great its format on xfs filesystem, and running iscsiadm version 2.0-870 with linux kernel 3.10.57

But when we logging on the server, the first time we do a dir command on the home dir, its take a long time when we get feedback on the dir , the next time is fast when we do a dir.
Now we have users on this systems and this problem give not good performance on sql and websites an e-mail we are running on the server.

Are the some information how i can fix ore maybe get this problem better under control ?

I hope so that somebody can help me, i am searching for more than 3 weeks now.

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 26 Nov 01:58 2014
Picon

Current Portal vs Persistent Portal Question

Hi Mike:

I am dealing with a problem in Equallogic, and it looks like the Current Portal and Persistent Portal are different.

As this is something I haven't seen before, I was hoping you could explain what it is.

I see in the README:

...
        Current Portal: portal currently logged into
        Persistent Portal: portal we would fall back to if we had got redirected during login

Is this related to Equallogic's iSCSI login redirect?

It sounds like the Persistent Portal is the one that we initially try to log into, and the Current Portal is the one we get redirected to. Or is that backwards?

What happens if we discover the main (group virtual) portal, and our Node record reflects that, then we get redirected? It seems like the Portal is going to differ between the Node record and the Session record, which might explain what I'm seeing.

In this particular case, the problem occurs when Yast tries to step through the Session records, doing an "iscsiadm -m node -I default -T <iqn> -p <ip:port> -P1" for each session, but IPs does not match.

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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 25 Nov 02:25 2014
Picon

[PATCH] open-isns: Fix isns server PG registration

Allow the isns server to accept legal registration
sequence, including portal group information.
---
 simple.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/simple.c b/simple.c
index e560d63288ac..8972a0c858bc 100644
--- a/simple.c
+++ b/simple.c
<at> <at> -587,7 +587,7 <at> <at> isns_attr_list_scanner_get_pg(struct isns_attr_list_scanner *st)
                 && isns_object_get_string(base,
                                        ISNS_TAG_ISCSI_NAME,
                                        &st->pgt_iscsi_name)) {
-                       st->pgt_next_attr = ISNS_TAG_PORTAL_IP_ADDRESS;
+                       st->pgt_next_attr = ISNS_TAG_PG_PORTAL_IP_ADDR;
                } else {
                        return ISNS_INTERNAL_ERROR;
                }
<at> <at> -619,7 +619,7 <at> <at> isns_attr_list_scanner_get_pg(struct isns_attr_list_scanner *st)
                        return ISNS_INVALID_REGISTRATION;
 
                next = st->orig_attrs.ial_data[st->pos++];
-               if (next->ia_tag_id != ISNS_TAG_PORTAL_TCP_UDP_PORT)
+               if (next->ia_tag_id != ISNS_TAG_PG_PORTAL_TCP_UDP_PORT)
                        return ISNS_INVALID_REGISTRATION;
 
                isns_attr_list_append_string(&st->keys,
-- 
2.1.2

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
The Lee-Man | 22 Nov 01:52 2014
Picon

open-isns repository moving, under new stewardship

Hi All:

Mike has generously been carrying the open-isns code under the utils directory in open-iscsi for a while now.

As one of the main users of this code, Mike asked if I wanted to take ownership and I agreed.

The new repository will be hosted at https://github.com/gonzoleeman/open-isns.git.

For now, since iSNS gets so little use, I would like to just continue piggy-backing on open-iscsi for issues discovered, discussion, etc. So no new/extra mailing list needs to be subscribed to or maintained.

To start things off, after forking Mike's copy, I've added the following changes:

84905a025c7c Support install of systemd files
5702d6d2ce9e Use DESTDIR instead of INSTALL_ROOT in Makefile
213c0157185c Ignoring dot-o files
997d219eff07 fixing configure warning: not using datarootdir
b511e38470c3 Using INSTALL Macro in Makefile
af60e767adf1 open-isns: systemd integration
024925c372e5 open-isns: Read source name from /etc/iscsi/initiatorname.iscsi
ea0e553fad81 open-isns: Implement 'IQNPrefix' configuration setting
27a260b7cab6 open-isns: Make default IQN prefix configurable
7e0288220b96 isnsadm: Allow server to be specified
e30341671480 open-isns: add 'all' as valid option for debugging
d931d111654b Remove unused variable 'type' in insnsadm
f9717c82af21 open-isns: move config.h include

These reflect the set of 11 patches I recently submitted to this mailing list, with a couple of Makefile-cleanup patches added in.

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.
Anish Bhatt | 21 Nov 01:46 2014

boot support for offload transports

Hello,

         I was trying to figure out the current state of all the code tagged with “#ifdef OFFLOAD_BOOT_SUPPORTED”. The recent ibft patches don’t seem to touch any of this at all, and I was wondering what the roadmap for this is ? A couple of distros seem to enable this, but the default compile for open-iscsi does not.

-Anish

 

One socket to bind them all.

 

--
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 http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Lee Duncan | 18 Nov 22:35 2014
Picon

[PATCH 00] iscsid compute bound when bouncing many targets, one LUN per target

The following patch fixes a problem where the CPU becomes compute bound
when rediscovering targets, when there are hundreds of sessions.

When his occurs, most of the time is spent in the function
iscsi_sysfs_for_each_session(). This function does a scandir(),
sorted alphabetically, to get a list of sessions, then scans
that list looking for a match. When there are hundreds of sesions
this can take forever.

This patch saves the current session and then ensures that this
session sorted to the front of the list. Testing shows that
CPU usage goes from near 100% to near 0% when running cable
plug tests with hundreds of sessions.

Signed-off-by: Lee Duncan <leeman.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@...
To post to this group, send email to open-iscsi@...
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Gmane