Status of a patch to export built-in kernel module info to sysfs
Hi, lkml list. I'm from open-iscsi mailing list and want to know if somebody already worked on a patch to export module information of scsi_transport_iscsi module to sysfs when it is compiled and built in kernel. Digging through open-iscsi and lkml list, I found some discussions about this issue at http://groups.google.com/group/open-iscsi/browse_thread/thread/5d0fd37e7d6a606c/d42284704f3bdf95?lnk=gstq=Rusty#d42284704f3bdf95 It looks like someone already made a patch but, can't find the one. So, if you have any ideas about where I can find the patch, please point it to me. Otherwise, I will make the one by myself. Please include yangkook...@gmail.com or open-iscsi@googlegroups.com at CC in reply since I am not subscribing lkml list. Thanks, Kim -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Building iscsid with iscsi modules built into the kernel
Hi, all.
I want to know how to compile iscsid with iscsi modules already built
into the kernel.
I built a kernel with the following options selected in .config so that
iscsi_tcp, libiscsi and scsi_transport_iscsi are built into the kernel.
CONFIG_ISCSI_TCP=y
I compiled iscsid shipped with open-iscsi-2.0-871 and run it.
Then, I hit the following error and iscsid won't come up.
Mar 23 04:58:03 ubuntu iscsid: Missing or Invalid version from
/sys/module/scsi_transport_iscsi/version. Make sure a up to date
scsi_transport_iscsi module is loaded and a up todate version of
iscsid is running. Exiting...
I understand that the error is telling that it can't read version of
scsi_transport_iscsi from /sys/module directory.
But, since my scsi_transport_iscsi is built into the kernel,
there is no /sys/module/scsi_transport_iscsi direcotry.
So, I removed the piece of codes in iscsid.c to avoid checking
/sys/module/scsi_transport_iscsi/version to run iscsid.
if (iscsi_sysfs_check_class_version()) {
log_close(log_pid);
exit(1);
}
However, I don't think removing the codes is not a correct way
to build iscsid with iscsi modules already built into the kernel.
Can anybody tell the correct way to make iscsid when iscsi modules
are built into the kernel?
Thanks,
Kim
#
Here is my system information.
bash-3.2$ /sbin/iscsid -v
iscsid version 2.0-871
bash-3.2$ uname -a
Linux ubuntu 2.6.28.11-kgdb #1 SMP Sat Mar 20 13:57:02 PDT 2010 i686 GNU/Linux
bash-3.2$ cat open-iscsi-2.0-871/usr/Makefile
# This Makefile will work only with GNU make.
OSNAME=$(shell uname -s)
# allow users to override these
# eg to compile for a kernel that you aren't currently running
KERNELRELEASE ?= $(shell uname -r)
KSRC ?= /lib/modules/$(KERNELRELEASE)/build
KSUBLEVEL=$(shell cat $(KSRC)/Makefile | awk -F= '/^SUBLEVEL =/ {print $$2}' | \
sed 's/^[ \t]*//;s/[ \t]*$$//')
ifeq ($(OSNAME),Linux)
ifeq ($(KSUBLEVEL),11)
IPC_CFLAGS=-DNETLINK_ISCSI=12 -D_GNU_SOURCE
else
ifeq ($(KSUBLEVEL),12)
IPC_CFLAGS=-DNETLINK_ISCSI=12 -D_GNU_SOURCE
else
IPC_CFLAGS=-DNETLINK_ISCSI=8 -D_GNU_SOURCE
endif
endif
IPC_OBJ=netlink.o
else
ifeq ($(OSNAME),FreeBSD)
IPC_CFLAGS=
IPC_OBJ=ioctl.o
endif
endif
OPTFLAGS ?= -O2 -g
WARNFLAGS ?= -Wall -Wstrict-prototypes
CFLAGS += $(OPTFLAGS) $(WARNFLAGS) -I../include -I. -D$(OSNAME) $(IPC_CFLAGS)
PROGRAMS = iscsid iscsiadm iscsistart
# libc compat files
SYSDEPS_SRCS = $(wildcard ../utils/sysdeps/*.o)
# sources shared between iscsid, iscsiadm and iscsistart
ISCSI_LIB_SRCS = util.o io.o auth.o login.o log.o md5.o sha1.o iface.o
idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o $(SYSDEPS_SRCS)
# sources shared between iscsid and iscsiadm
COMMON_SRCS = $(ISCSI_LIB_SRCS)
# core initiator files
INITIATOR_SRCS = initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o isns.o \
cxgb3i.o transport.o
# fw boot files
FW_BOOT_SRCS = $(wildcard ../utils/fwparam_ibft/*.o)
all: $(PROGRAMS)
iscsid: $(COMMON_SRCS) $(IPC_OBJ) $(INITIATOR_SRCS) iscsid.o
$(CC) $(CFLAGS) $^ -o $@
iscsiadm: $(COMMON_SRCS) $(FW_BOOT_SRCS) strings.o discovery.o iscsiadm.o
$(CC) $(CFLAGS) $^ -o $@
iscsistart: $(IPC_OBJ) $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(FW_BOOT_SRCS) \
iscsistart.o statics.o
$(CC) $(CFLAGS) -static $^ -o $@
clean:
rm -f *.o $(PROGRAMS) .depend $(LIBSYS)
depend:
gcc $(CFLAGS) -M `ls *.c` .depend
-include .depend
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
Understanding iscsi kernel space codes
Hi, all. I'm now trying to study open-iscsi kernel space codes. Basically my goal is understanding how iscsi packet is created/sent/recieved in kernel space. Unlike user space codes, there is no main function, so not sure about where I should start from. There are four kernel codes files. iscsi_tcp.c libiscsi.c libiscsi_tcp.c scsi_transport_iscsi.c Can anybody tell me which file is a good start point to understand iscsi code flow in kernel space? Also, can anybody briefly tell me the main functions of each file above? Thanks, Kim -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: read only access on 1 LUN for multiple initiators
Remember that clients (especially Linux) doe cache blocks locally Doesn't kernel refresh the read cache for blocks at some intervals? If I make a new file on target locally, and waiting for sometime, hitting read command like ls on initiator side will read data from block device, not from stale cache, so that I can read updated data. I believed that this is how the file-system is supposed to work, but it is not? they do not invalidate that cache. Clients not invalidating cache means that they do not update their read cahce unless the volume is remounted? 2010/3/1, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de: On 27 Feb 2010 at 0:23, Kapetanakis Giannis wrote: Hi, This probably have been brought up before, but I couldn't find any info. I'd like to setup multiple initiators (web/ftp cluster) to access read-only the same iscsi target. I would prefer to do this without cluster fs (ie GFS) if possible. However I want to have right access on the target server locally. I managed to do this but I have the following problem: When I write something on the target (locally on the server) the updates are not propagated to the initiators. Naturally, read-only media don't propagate changes, because they don't change. Remember that clients (especially Linux) doe cache blocks locally, and they do not invalidate that cache. So you could even experience application crashes when accessing data structures that were partially cached while being changed on the original. If I unmount and mount again I can see the changes. Naturally, because unmount invalidates the cached blocks for the device. Regards, Ulrich I'm sharing /dev/vg01/iscsi which is an ext3 fs. It's locally mounted on server and also mounted (/dev/sde - /mnt) on clients. Server is centos 5.4 scsi-target-utils-0.0-6.20091205snap.el5_4.1 target iqn.2008-09.com.example:server.target2 backing-store /dev/vg01/iscsi incominguser user pass initiator-address 10.0.0.0/26 write-cache off /target client is Fedora 12 iscsi-initiator-utils-6.2.0.870-10.fc12.1.x86_64 scsi22 : iSCSI Initiator over TCP/IP scsi 22:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 scsi 22:0:0:0: Attached scsi generic sg5 type 12 scsi 22:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 sd 22:0:0:1: Attached scsi generic sg6 type 0 sd 22:0:0:1: [sde] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB) sd 22:0:0:1: [sde] Write Protect is off sd 22:0:0:1: [sde] Mode Sense: 79 00 00 08 sd 22:0:0:1: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sde: unknown partition table sd 22:0:0:1: [sde] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. so is GFS the only option? Giannis -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: read only access on 1 LUN for multiple initiators
Remember that clients (especially Linux) doe cache blocks locally Doesn't kernel refresh the read cache for blocks at some intervals? If I make a new file on target locally, and waiting for sometime, hitting read command like ls on initiator side will read data from block device, not from stale cache, so that I can read updated data. I believed that this is how the file-system is supposed to work, but it is not? they do not invalidate that cache. Clients not invalidating cache means that they do not update their read cahce unless the volume is remounted? Thanks. kim 2010/3/1, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de: On 27 Feb 2010 at 0:23, Kapetanakis Giannis wrote: Hi, This probably have been brought up before, but I couldn't find any info. I'd like to setup multiple initiators (web/ftp cluster) to access read-only the same iscsi target. I would prefer to do this without cluster fs (ie GFS) if possible. However I want to have right access on the target server locally. I managed to do this but I have the following problem: When I write something on the target (locally on the server) the updates are not propagated to the initiators. Naturally, read-only media don't propagate changes, because they don't change. Remember that clients (especially Linux) doe cache blocks locally, and they do not invalidate that cache. So you could even experience application crashes when accessing data structures that were partially cached while being changed on the original. If I unmount and mount again I can see the changes. Naturally, because unmount invalidates the cached blocks for the device. Regards, Ulrich I'm sharing /dev/vg01/iscsi which is an ext3 fs. It's locally mounted on server and also mounted (/dev/sde - /mnt) on clients. Server is centos 5.4 scsi-target-utils-0.0-6.20091205snap.el5_4.1 target iqn.2008-09.com.example:server.target2 backing-store /dev/vg01/iscsi incominguser user pass initiator-address 10.0.0.0/26 write-cache off /target client is Fedora 12 iscsi-initiator-utils-6.2.0.870-10.fc12.1.x86_64 scsi22 : iSCSI Initiator over TCP/IP scsi 22:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5 scsi 22:0:0:0: Attached scsi generic sg5 type 12 scsi 22:0:0:1: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 sd 22:0:0:1: Attached scsi generic sg6 type 0 sd 22:0:0:1: [sde] 16777216 512-byte logical blocks: (8.58 GB/8.00 GiB) sd 22:0:0:1: [sde] Write Protect is off sd 22:0:0:1: [sde] Mode Sense: 79 00 00 08 sd 22:0:0:1: [sde] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA sde: unknown partition table sd 22:0:0:1: [sde] Attached SCSI disk kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. so is GFS the only option? Giannis -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Question about /sys/class/iscsi_connection
Hi, Mike. Thank you for the reply. OK, now I see the history. P.S. I also thought that connectionXX:0 is misleading. XX is supposed to be where iscsi session number is put after binding connection and session. I did not get what you mean here. The XX is the session number. Probably I should have not to say misleading. Instead, I should have said it confused me. It seemed to me a bit strange to say like connectionXX:0 where XX is session number. I was wondering why you have to say session number to describe a connection... But, I now came to a reason by myself. It is said so probably because it is just useful to indentiy which connection you are talking about in one-word, and this is useful in logging. Or, is there any other reasons? However, I still think it is misleading to say connectionXX:0 before binding connection and session. In iscsid.c:session_conn_poll(), connectionXX:0 appears before binding. log_debug(3, created new iSCSI session sid %d host no %u, session-id, session-hostno); snip log_debug(3, created new iSCSI connection %d:%d, session-id, conn-id); snip log_debug(3, bound iSCSI connection %d:%d to session %d, session-id, conn-id, session-id); Does it fit you very natural? Is it only me to worry about it? 2010/1/7, Mike Christie micha...@cs.wisc.edu: On 01/02/2010 01:56 PM, Yangkook Kim wrote: Hi, Group, I am wondering why we have /sys/class/iscsi_connection for iscsi connection in sysfs filesystem. I understand that the one or more iscsi connection form a single iscsi session and, in this sense, iscsi connection subordinates to iscsi session. Then, it more makes sense if we have iscsi_connection/ under iscsi_session/. Ex. /sys/class/iscsi_session/iscsi_connection/connectionXX:0 Hey, Sorry for the late reply. We sort of have that. The reason we have /sys/class/iscsi_connection and then /sys/class/iscsi_session is due to how the kernel APIs work. For them we are using transport classes and classes (see the kernel file scsi_transport_iscsi.c), and this is just how they get laid out. We could have just made the iscsi_connection a struct with a kobject and then added that directly under the session, but at the time people did not like the idea of messing with kobjects directly. So if you look in the iscsi_session dir /sys/class/iscsi_session/session1 ls abort_tmo ifacenamepassword tpgt data_pdu_in_order immediate_data password_in uevent data_seq_in_order initial_r2t power username device initiatornamerecovery_tmo username_in erllu_reset_tmo state fast_abort max_burst_lensubsystem first_burst_lenmax_outstanding_r2t targetname there is a device dir/link. When you follow that you see ls [r...@max session1]# cd device/ [r...@max device]# ls connection1:0 iscsi_session power target6:0:0 uevent how the connection is below the session1. So sort of what you would expect but there is that device dir/link due to us using the classes/transport_classes which use device structs instead f kobjects directly. Can anybody give me an explanation? Thanks Kim, P.S. I also thought that connectionXX:0 is misleading. XX is supposed to be where iscsi session number is put after binding connection and session. I did not get what you mean here. The XX is the session number. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Question about /sys/class/iscsi_connection
Hi, Group, I am wondering why we have /sys/class/iscsi_connection for iscsi connection in sysfs filesystem. I understand that the one or more iscsi connection form a single iscsi session and, in this sense, iscsi connection subordinates to iscsi session. Then, it more makes sense if we have iscsi_connection/ under iscsi_session/. Ex. /sys/class/iscsi_session/iscsi_connection/connectionXX:0 Can anybody give me an explanation? Thanks Kim, P.S. I also thought that connectionXX:0 is misleading. XX is supposed to be where iscsi session number is put after binding connection and session. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
How to make a 2.6..*_compat.patch without sub-directory?
I posted similar message on other thread, but let me ask the same question with diffrent tittle. I want to make a kernel compat patch without kernel/ sub-directory. I used git diff to output the patch, but each header of outputted patch includes kernel/ sub-directory like below. e.g diff --git a/kernel/libiscsi.c b/kernel/libiscsi.c index 0b810b6..6ffb49c 100644 --- a/kernel/libiscsi.c +++ b/kernel/libiscsi.c git history shows me that other people have made a compat patch without kernel/ sub-directory in headers. Can anybody tell me how to do this? Thanks, Kim -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: Unable to apply kernel/2.6.26_compat.patch from git master branch
Hi, you are back. I think for your patch, you want to include open_iscsi_compat.h in it. I included open_iscsi_compat.h and created a patch. Please check it. I have a quetion about creating a patch agaist files in sub-directory. I used git diff to output the patch, but each hunk of outputted patch includes kernel/ sub-directory. e.g diff --git a/kernel/libiscsi.c b/kernel/libiscsi.c index 0b810b6..6ffb49c 100644 --- a/kernel/libiscsi.c +++ b/kernel/libiscsi.c However, kernel/ sub-directory in the compat patch will prevent you from making and your current compat patch is actually does't have kernel/ sub-directory. e.g diff --git a/libiscsi.c b/libiscsi.c index 149d5eb..467abbf 100644 --- a/libiscsi.c +++ b/libiscsi.c How do I make a patch without the sub-directory? Since I didn't know how to do it, I simply remove the sub-directory by,,, sed -i 's%a\/kernel%a%g' update_2.6.26_compat.patch2 sed -i 's%b\/kernel%b%g' update_2.6.26_compat.patch2 But, this obviously isn't the way to do it...It will be very appriciated if you tell me the right way to do it. Thanks. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en. update_2.6.26_compat.patch2 Description: Binary data
Unable to apply kernel/2.6.26_compat.patch from git master branch
Hi,
I just wanted to report a small problem applying kernel/2.6.26_compat.patch and
provide an updated patch to fix the problem.
If you try to compile the source from current git master branch for
kernel-2.6.26,
you will encounter patch error.
Here is what I did.
bash-3.2$ git clone
git://git.kernel.org/pub/scm/linux/kernel/git/mnc/open-iscsi.git
bash-3.2$ git log --summary | head -3
commit fb4f2d3072bee96606d01e3535c100dc99b8d331
Author: Mike Christie micha...@cs.wisc.edu
Date: Wed Nov 25 18:09:39 2009 -0600
bash-3.2$ uname -r
2.6.26.8-57.laphroaig.fc8
bash-3.2$ make KSRC=/home/hiro/rpmbuild/BUILD/kernel-2.6.26/linux-2.6.26.i686/
snip-
make -C kernel
make[1]: Entering directory `/home/hiro/programming/git/open-iscsi/kernel'
echo Patching source code for linux-2.6.26 ...
Patching source code for linux-2.6.26 ...
if [ -e cur_patched ]; then \
make -C . clean; \
fi
patch -p1 2.6.26_compat.patch
patching file libiscsi.c
patching file open_iscsi_compat.h
patching file scsi_transport_iscsi.c
Hunk #1 FAILED at 30.
Hunk #2 succeeded at 146 (offset 31 lines).
Hunk #4 succeeded at 1405 (offset 92 lines).
Hunk #6 succeeded at 1548 (offset 119 lines).
Hunk #8 succeeded at 2080 (offset 123 lines).
Hunk #10 succeeded at 2134 (offset 123 lines).
1 out of 10 hunks FAILED -- saving rejects to file scsi_transport_iscsi.c.rej
make[1]: *** [has_26_patch] Error 1
make[1]: Leaving directory `/home/hiro/programming/git/open-iscsi/kernel'
make: *** [kernel] Error 2
You can see that patchihg scsi_transport_iscsi.c failed.
The problematic hunk in 2.6.26_compat.patch is
#define ISCSI_SESSION_ATTRS 21. In the latest source file,
ISCSI_SESSION_ATTRS is 22, but that macro was left
to be 21 in the patch, so patch command fails since
it cannot find proper context.
bash-3.2$ cat kernel/2.6.26_compat.patch
snip
diff --git a/scsi_transport_iscsi.c b/scsi_transport_iscsi.c
index a49a92c..c07535e 100644
--- a/scsi_transport_iscsi.c
+++ b/scsi_transport_iscsi.c
@@ -30,6 +30,8 @@
#include scsi_transport_iscsi.h
#include iscsi_if.h
+#include open_iscsi_compat.h
+
#define ISCSI_SESSION_ATTRS 21
#define ISCSI_CONN_ATTRS 13
#define ISCSI_HOST_ATTRS 4
bash-3.2$ cat -n kernel/scsi_transport_iscsi.c | grep define
ISCSI_SESSION_ATTRS
33 #define ISCSI_SESSION_ATTRS 22
I attached the updated 2.6.26_compat.patch. Please check it.
Thanks.
Kim
--
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-is...@googlegroups.com.
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/open-iscsi?hl=en.
diff --git a/libiscsi.c b/libiscsi.c
index 0b810b6..6ffb49c 100644
--- a/libiscsi.c
+++ b/libiscsi.c
@@ -38,6 +38,8 @@
#include scsi_transport_iscsi.h
#include libiscsi.h
+#include open_iscsi_compat.h
+
static int iscsi_dbg_lib_conn;
module_param_named(debug_libiscsi_conn, iscsi_dbg_lib_conn, int,
S_IRUGO | S_IWUSR);
diff --git a/scsi_transport_iscsi.c b/scsi_transport_iscsi.c
index f64ffa7..c6eeae0 100644
--- a/scsi_transport_iscsi.c
+++ b/scsi_transport_iscsi.c
@@ -30,6 +30,8 @@
#include scsi_transport_iscsi.h
#include iscsi_if.h
+#include open_iscsi_compat.h
+
#define ISCSI_SESSION_ATTRS 22
#define ISCSI_CONN_ATTRS 13
#define ISCSI_HOST_ATTRS 4
@@ -144,6 +146,7 @@ static struct attribute_group iscsi_transport_group = {
.attrs = iscsi_transport_attrs,
};
+#if 0
/*
* iSCSI endpoint attrs
*/
@@ -267,6 +270,7 @@ struct iscsi_endpoint *iscsi_lookup_endpoint(u64 handle)
return ep;
}
EXPORT_SYMBOL_GPL(iscsi_lookup_endpoint);
+#endif
static int iscsi_setup_host(struct transport_container *tc, struct device *dev,
struct device *cdev)
@@ -1401,6 +1405,8 @@ static int
iscsi_if_transport_ep(struct iscsi_transport *transport,
struct iscsi_uevent *ev, int msg_type)
{
+ return -ENOSYS;
+#if 0
struct iscsi_endpoint *ep;
int rc = 0;
@@ -1432,6 +1438,8 @@ iscsi_if_transport_ep(struct iscsi_transport *transport,
break;
}
return rc;
+
+#endif
}
static int
@@ -1540,6 +1548,9 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
ev-u.c_session.queue_depth);
break;
case ISCSI_UEVENT_CREATE_BOUND_SESSION:
+ err = -ENOSYS;
+ break;
+#if 0
ep = iscsi_lookup_endpoint(ev-u.c_bound_session.ep_handle);
if (!ep) {
err = -EINVAL;
@@ -1551,6 +1562,7 @@ iscsi_if_recv_msg(struct sk_buff *skb, struct nlmsghdr *nlh, uint32_t *group)
ev-u.c_bound_session.cmds_max,
ev-u.c_bound_session.queue_depth);
break;
+#endif
case ISCSI_UEVENT_DESTROY_SESSION:
session = iscsi_session_lookup(ev-u.d_session.sid);
if (session)
@@ -2068,13 +2080,14 @@ static __init int iscsi_transport_init(void)
if (err)
return err;
+#if 0
err = class_register(iscsi_endpoint_class);
if (err)
goto
Re: [Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()
Thanks for your patch. I tested your patch and it worked fine. So, next you will upload this patch to the git tree and the patch will become the part of source code in the next release of open-iscsi. Is my understanding correct? I am asking this question because I just want to know the normal development process of this and other linux project. 2009/11/24, Mike Christie micha...@cs.wisc.edu: Mike Christie wrote: Yangkook Kim wrote: Hi, Mike. Thank you for your patch. I do not want to add a login log message to the iscsid_req_* functions because they are generic and could be used for any operation. Yes, that's perfectly right idea. That should be bettet than my patch. I tried your patch, but that still does not output login-success message when calling iscsid_req_by_rec. It seems that log_login_msg() would not be called in either login_portal() or iscsid_logout_reqs_wait() when iscsid_req_by_rec returns success. I probably missed something. I will look at it tomorrow again. Nope. You are right. Nice catch. I messed up. I was only concentrating on the error paths. I will fix up my patch and resend. Thanks. Here is a corrected patch. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=. -- You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
Re: iscsi diagnosis help
2) Are there plans in the future to have more than one connection per session? I dont't think so. If you want to know the reason, read the thread titled MC/S support in open-iscsi mailing list. Kim 2009/11/17, Pasi Kärkkäinen pa...@iki.fi: On Mon, Nov 16, 2009 at 09:39:00PM -0500, Hoot, Joseph wrote: On Nov 16, 2009, at 8:19 PM, Hoot, Joseph wrote: thanks. That helps. So I know that with the EqualLogic targets, there is a Group IP which, I believe, responds with an iscsi login_redirect. 1) Could the Login authentication failed message be the response because of a login redirect messages from the EQL redirect? and then my next question is more for curiosity sake: 2) Are there plans in the future to have more than one connection per session? and I guess in addition to that, would that mean multiple connections to a single volume over the same nic? Also Mike, I'm seeing one or two of these every 30-40 minutes if I slam our EqualLogic with roughly 7-15k IOPS (reads and writes) non stop on 3 volumes. In this type of scenario, would you expect to see timeouts like this once in awhile? If so, do you think increasing my NOOP timeouts would assist so we don't get these? maybe set it to 15 seconds instead of 10? Equallogic does active loadbalancing (redirects) during operation.. dunno about the errors though. -- Pasi On Nov 16, 2009, at 7:18 PM, Mike Christie wrote: Hoot, Joseph wrote: Hi all, I'm trying to understand what I'm seeing in my /var/log/messages. Here's what I have: Nov 13 10:49:47 oim6102506 kernel: connection5:0: ping timeout of 10 secs expired, last rx 191838122, last ping 191839372, now 191841872 Nov 13 10:49:47 oim6102506 kernel: connection5:0: detected conn error (1011) Nov 13 10:49:47 oim6102506 iscsid: Kernel reported iSCSI connection 5:0 error (1011) state (3) Nov 13 10:49:50 oim6102506 iscsid: Login authentication failed with target iqn.2001-05.com.equallogic:0-8a0906-e7d1dea02-786272c42554aef2-ovm-2-lun03 Nov 13 10:49:52 oim6102506 iscsid: connection5:0 is operational after recovery (1 attempts) the first line, what is connection5:0? is that referenced from iscsiadm somewhere? I only ask because I'm seeing iscsid messages and kernel messages. I also have dm-multipath running, which usually shows up as dm-multipath or something like that. I understand that iscsid is the process that is logging in and out. But is the kernel: message just an iscsi modules that is loaded into the kernel, which is why it is being logged as kernel:? It is the session id and connection id. connection$SESSION_ID:$CONNECTION_ID If you run iscsiadm -m session -P 1 or -P 3 You will see #iscsiadm -m session -P 1 Target: iqn.1992-08.com.netapp:sn.33615311 Current Portal: 10.15.85.19:3260,3 Persistent Portal: 10.15.85.19:3260,3 Iface Transport: tcp Iface IPaddress: 10.11.14.37 Iface HWaddress: default Iface Netdev: default SID: 7 iSCSI Connection State: LOGGED IN Internal iscsid Session State: NO CHANGE Session number is the SID value. If you run iscsiadm -m session tcp [2] 10.15.84.19:3260,2 iqn.1992-08.com.netapp:sn.33615311 the session number/SID is the value in brackets. If you run iscsiadm in session mode (iscsiadm -m session) then you can use the -R argument and pass in a SID to do an opertaion like iscsiadm -m session -R 2 --rescan would rescan that session. Connection number is currently always zero. For the second question, iscsid handles login and logout, and error handling, and the kernel basically passes iscsi packets around. Nov 13 10:49:47 oim6102506 kernel: connection5:0: ping timeout of 10 secs expired, last rx 191838122, last ping 191839372, now 191841872 so here the iscsi kernel code sends a iscsi ping/nop every noop_interval seconds, and if we do not get a response withing noop_timeout seconds it will fire off a connection error. Nov 13 10:49:47 oim6102506 kernel: connection5:0: detected conn error (1011) Here is the kernel code notifying userspace of the problem. Nov 13 10:49:47 oim6102506 iscsid: Kernel reported iSCSI connection 5:0 error (1011) state (3) And there iscsid is accepting the error (probably no need for the error to be logged twice). Nov 13 10:49:50 oim6102506 iscsid: Login authentication failed with target And then here iscsid handled the error by killing the tcp/ip connection, reconnection the tcp/ip connection, and then re-logging into the iscsi target. But for some reason we could not log back in right away. iqn.2001-05.com.equallogic:0-8a0906-e7d1dea02-786272c42554aef2-ovm-2-lun03 Nov 13 10:49:52 oim6102506 iscsid: connection5:0 is operational after recovery (1 attempts)
Re: [Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()
Are you hitting the non async code path? Did you hit the
iscsid_req_by_rec call? How many targets or portals were you logging into?
No, I never hit iscsid_req_by_rec call. I was just reading the codes
of iscsiadm and thought that there is less consideration when calling
iscsid_req_by_rec() than iscsid_req_by_rec_async().
If iscsid_req_by_rec fails, then won't we log an error here?
Sorry, my point was very unclear for you and my patch was also not good.
I basically have two points that I want to improve.
No1, checking the return value of iscisd_request() when calling
iscsid_req_by_rec().
No2, outputting login success message even when calling iscsid_req_by_rec().
In the origicanl code of login_portal() below,
if (async_req)
rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
rec, fd);
else
rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
/* we raced with another app or instance of iscsiadm */
if (rc == MGMT_IPC_ERR_EXISTS) {
if (async_req)
free(async_req);
return 0;
} else if (rc) {
iscsid_handle_error(rc);
if (async_req)
free(async_req);
return ENOTCONN;
}
the return value of iscsid_request() is checked when calling
iscsid_req_by_rec_async().
However, the same return value is not checked when calling iscsid_req_by_rec().
What you check here with rc = iscsid_req_by_rec() is not the return value of
iscsid_request(), but that of iscsid_req_wait() as you can see in the
codes below.
int iscsid_req_by_rec(iscsiadm_cmd_e cmd, node_rec_t *rec)
{
int err, fd;
err = iscsid_req_by_rec_async(cmd, rec, fd);
if (err)
return err;
return iscsid_req_wait(cmd, fd);
}
So, I check the return value of iscsid_request() inside iscsid_req_by_rec().
(I actually did not put the codes to achive this in the second patch of util.c.
and maybe that made you confused...
I will send a new patch of util.c that includes below codes.)
The code below will achive my point No1.
int iscsid_req_by_rec(iscsiadm_cmd_e cmd, node_rec_t *rec)
{
int err, fd;
err = iscsid_req_by_rec_async(cmd, rec, fd);
if (err == MGMT_IPC_ERR_EXISTS) {
return 0;
} else if (err) {
iscsid_handle_error(err);
return ENOTCONN;
}
I also check the return value of iscsid_req_wait() inside
iscsid_req_by_rec() and
outputting logs of login status. This will achive my point No2.
err = iscsid_req_wait(cmd, fd);
if (err) {
log_error(Could not login to [iface: %s, target: %s,
portal: %s,%d]: , rec-iface.name,
rec-name, rec-conn[0].address,
rec-conn[0].port);
} else
printf(Login to [iface: %s, target: %s, portal:
%s,%d]: successful\n, rec-iface.name,
rec-name, rec-conn[0].address,
rec-conn[0].port);
return err;
}
Since we checked the return value of iscsid_request() inside
iscsid_req_by_rec(),
what we need to check is only the return value of iscsid_req_wait() of
iscsid_req_by_rec().
So, patched login_portal() should be something like this now.
if (async_req) {
rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
rec, fd);
if (rc == MGMT_IPC_ERR_EXISTS) {
if (async_req)
free(async_req);
return 0;
} else if (rc) {
iscsid_handle_error(rc);
if (async_req)
free(async_req);
return ENOTCONN;
}
list_add_tail(async_req-list, list);
async_req-fd = fd;
async_req-data = rec;
return 0;
} else {
rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
if (rc) {
iscsid_handle_error(rc);
return ENOTCONN;
} else
return rc;
}
}
I know that iscsid_req_by_rec() is almost never called in the reality.
But, I just thought the codes looks little better if we take care of
iscsid_req_by_rec() more.
This patch unnecessary? Unclear? Give me your frank opinion, Mike.
Kim.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at
[Patch 1/2] iscsiadm: login_portal() misses outputting logs for iscsid_req_by_rec()
This patch tries to fix the lack of outputting logs when
iscsid_req_by_rec is used.
When using iscsid_req_by_rec, the current codes does not tell you whether you
are successfully logged in or hitting some errors because you cannot
get into the
loop of list_for_each_entry_safe() in iscsid_login_reqs_wait(). I
modify some codes
so that iscsid_req_by_rec will output logs.
Please give me a feedback if any.
-- Yangkook Kim
Signed-off-by: Yangkook Kim yangkook...@gmail.com
---
--- a/usr/iscsiadm.c2009-11-12 06:22:10.0 +0900
+++ b/usr/iscsiadm.c2009-11-12 06:23:01.0 +0900
@@ -597,29 +597,31 @@
INIT_LIST_HEAD(async_req-list);
}
- if (async_req)
- rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
-rec, fd);
- else
- rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
- /* we raced with another app or instance of iscsiadm */
- if (rc == MGMT_IPC_ERR_EXISTS) {
- if (async_req)
- free(async_req);
- return 0;
- } else if (rc) {
- iscsid_handle_error(rc);
- if (async_req)
- free(async_req);
- return ENOTCONN;
- }
-
if (async_req) {
+rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
+rec, fd);
+ if (rc == MGMT_IPC_ERR_EXISTS) {
+ if (async_req)
+ free(async_req);
+ return 0;
+ } else if (rc) {
+ iscsid_handle_error(rc);
+ if (async_req)
+ free(async_req);
+ return ENOTCONN;
+ }
list_add_tail(async_req-list, list);
async_req-fd = fd;
async_req-data = rec;
+ return 0;
+ } else {
+ rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
+ if (rc) {
+ iscsid_handle_error(rc);
+ return ENOTCONN;
+ } else
+ return rc;
}
- return 0;
}
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
--- a/usr/iscsiadm.c 2009-11-12 06:22:10.0 +0900
+++ b/usr/iscsiadm.c 2009-11-12 06:23:01.0 +0900
@@ -597,29 +597,31 @@
INIT_LIST_HEAD(async_req-list);
}
- if (async_req)
- rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
- rec, fd);
- else
- rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
- /* we raced with another app or instance of iscsiadm */
- if (rc == MGMT_IPC_ERR_EXISTS) {
- if (async_req)
- free(async_req);
- return 0;
- } else if (rc) {
- iscsid_handle_error(rc);
- if (async_req)
- free(async_req);
- return ENOTCONN;
- }
-
if (async_req) {
+rc = iscsid_req_by_rec_async(MGMT_IPC_SESSION_LOGIN,
+ rec, fd);
+ if (rc == MGMT_IPC_ERR_EXISTS) {
+ if (async_req)
+free(async_req);
+ return 0;
+ } else if (rc) {
+ iscsid_handle_error(rc);
+ if (async_req)
+free(async_req);
+ return ENOTCONN;
+ }
list_add_tail(async_req-list, list);
async_req-fd = fd;
async_req-data = rec;
+ return 0;
+ } else {
+ rc = iscsid_req_by_rec(MGMT_IPC_SESSION_LOGIN, rec);
+ if (rc) {
+ iscsid_handle_error(rc);
+ return ENOTCONN;
+ } else
+ return rc;
}
- return 0;
}
static int __login_portals(void *data, int *nr_found,
[Patch 2/2] iscsiadm: checking return value of iscsid_req_wait() in iscsid_req_by_rec()
This patch adds some codes to output logs to reflect the return value
of iscsid_req_wait() for outputting logging.
Please give me a feedback if any.
-- Yangkook Kim
Signed-off-by: Yangkook Kim yangkook...@gmail.com
---
--- a/usr/util.c2009-11-12 06:22:10.0 +0900
+++ b/usr/util.c2009-11-12 06:28:45.0 +0900
@@ -121,6 +121,34 @@
#define MAXSLEEP 128
+void iscsid_handle_error(mgmt_ipc_err_e err)
+{
+ static char *err_msgs[] = {
+ /* 0 */ ,
+ /* 1 */ unknown error,
+ /* 2 */ not found,
+ /* 3 */ no available memory,
+ /* 4 */ encountered connection failure,
+ /* 5 */ encountered iSCSI login failure,
+ /* 6 */ encountered iSCSI database failure,
+ /* 7 */ invalid parameter,
+ /* 8 */ connection timed out,
+ /* 9 */ internal error,
+ /* 10 */ encountered iSCSI logout failure,
+ /* 11 */ iSCSI PDU timed out,
+ /* 12 */ iSCSI driver not found. Please make sure it
is loaded, and retry the operation,
+ /* 13 */ daemon access denied,
+ /* 14 */ iSCSI driver does not support requested capability.,
+ /* 15 */ already exists,
+ /* 16 */ Unknown request,
+ /* 17 */ encountered iSNS failure,
+ /* 18 */ could not communicate to iscsid,
+ /* 19 */ encountered non-retryable iSCSI login failure,
+ /* 20 */ could not connect to iscsid,
+ };
+ log_error(initiator reported error (%d - %s), err, err_msgs[err]);
+}
+
static mgmt_ipc_err_e iscsid_connect(int *fd)
{
int nsec;
@@ -231,7 +259,18 @@
err = iscsid_req_by_rec_async(cmd, rec, fd);
if (err)
return err;
- return iscsid_req_wait(cmd, fd);
+ err = iscsid_req_wait(cmd, fd);
+ if (err) {
+ log_error(Could not login to [iface: %s, target: %s,
+ portal: %s,%d]: , rec-iface.name,
+ rec-name, rec-conn[0].address,
+ rec-conn[0].port);
+ } else
+ printf(Login to [iface: %s, target: %s, portal:
+ %s,%d]: successful\n, rec-iface.name,
+ rec-name, rec-conn[0].address,
+ rec-conn[0].port);
+ return err;
}
int iscsid_req_by_sid_async(iscsiadm_cmd_e cmd, int sid, int *fd)
@@ -312,34 +351,6 @@
iface_setup_defaults(rec-iface);
}
-void iscsid_handle_error(mgmt_ipc_err_e err)
-{
- static char *err_msgs[] = {
- /* 0 */ ,
- /* 1 */ unknown error,
- /* 2 */ not found,
- /* 3 */ no available memory,
- /* 4 */ encountered connection failure,
- /* 5 */ encountered iSCSI login failure,
- /* 6 */ encountered iSCSI database failure,
- /* 7 */ invalid parameter,
- /* 8 */ connection timed out,
- /* 9 */ internal error,
- /* 10 */ encountered iSCSI logout failure,
- /* 11 */ iSCSI PDU timed out,
- /* 12 */ iSCSI driver not found. Please make sure it
is loaded, and retry the operation,
- /* 13 */ daemon access denied,
- /* 14 */ iSCSI driver does not support requested capability.,
- /* 15 */ already exists,
- /* 16 */ Unknown request,
- /* 17 */ encountered iSNS failure,
- /* 18 */ could not communicate to iscsid,
- /* 19 */ encountered non-retryable iSCSI login failure,
- /* 20 */ could not connect to iscsid,
- };
- log_error(initiator reported error (%d - %s), err, err_msgs[err]);
-}
-
int __iscsi_match_session(node_rec_t *rec, char *targetname,
char *address, int port, struct iface_rec *iface)
{
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
--- a/usr/util.c 2009-11-12 06:22:10.0 +0900
+++ b/usr/util.c 2009-11-12 06:28:45.0 +0900
@@ -121,6 +121,34 @@
#define MAXSLEEP 128
+void iscsid_handle_error(mgmt_ipc_err_e err)
+{
+ static char *err_msgs[] = {
+ /* 0 */ ,
+ /* 1 */ unknown error,
+ /* 2 */ not found,
+ /* 3 */ no available memory,
+ /* 4 */ encountered connection failure,
+ /* 5 */ encountered iSCSI login failure,
+ /* 6 */ encountered iSCSI database failure,
+ /* 7 */ invalid parameter,
+ /* 8 */ connection timed out,
+ /* 9 */ internal error,
+ /* 10 */ encountered iSCSI logout
Question about struct idbm
Hi, I have a question about struct idbm. I want to know what the role of the structure in the codes of open- iscsi initiator is. While reading codes in iscsiadm.c, idbm.c, etc, I see that struct idbm is passed to many functions. However, I found that these functions do not use the structure very much, and only a few members of the structure are used by these functions. Guessing from the name, I understand that the structure would play central role in the idbm database, but don't see where the role played. Can anybody explain to me what the role of the structure and the relationship with idbm database briefly? Thanks, Kim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
Question about struct idbm
Hi, I have a question about struct idbm. I want to know what the role of the structure in the codes of open-iscsi initiator. While reading codes of iscsiadm.c, idbm.c, etc, I see that struct idbm is passed to many functions. However, I found that these functions do not use the structure very much, and only a few members of the structure are used by these functions. Guessing from the name, I understand that the structure would play central role in the idbm database, but don't see where the role played. Can anybody explain to me what the role of the structure and the relationship with idbm database briefly? Thanks, Kim --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
