You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(14) |
Jun
(46) |
Jul
(43) |
Aug
(199) |
Sep
(329) |
Oct
(214) |
Nov
(198) |
Dec
(236) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(316) |
Feb
(240) |
Mar
(230) |
Apr
(300) |
May
(339) |
Jun
(301) |
Jul
(284) |
Aug
(213) |
Sep
(197) |
Oct
(150) |
Nov
(216) |
Dec
(287) |
2006 |
Jan
(346) |
Feb
(189) |
Mar
(222) |
Apr
(260) |
May
(100) |
Jun
(184) |
Jul
(229) |
Aug
(102) |
Sep
(82) |
Oct
(216) |
Nov
(389) |
Dec
(466) |
2007 |
Jan
(512) |
Feb
(330) |
Mar
(322) |
Apr
(271) |
May
(301) |
Jun
(251) |
Jul
(302) |
Aug
(168) |
Sep
(134) |
Oct
(132) |
Nov
(223) |
Dec
(75) |
2008 |
Jan
(101) |
Feb
(115) |
Mar
(83) |
Apr
(111) |
May
(91) |
Jun
(180) |
Jul
(101) |
Aug
(75) |
Sep
(178) |
Oct
(104) |
Nov
(159) |
Dec
(131) |
2009 |
Jan
(135) |
Feb
(84) |
Mar
(84) |
Apr
(63) |
May
(44) |
Jun
(25) |
Jul
(68) |
Aug
(95) |
Sep
(183) |
Oct
(118) |
Nov
(61) |
Dec
(156) |
2010 |
Jan
(172) |
Feb
(186) |
Mar
(204) |
Apr
(449) |
May
(52) |
Jun
(136) |
Jul
(35) |
Aug
(19) |
Sep
(93) |
Oct
(89) |
Nov
(62) |
Dec
(29) |
2011 |
Jan
(91) |
Feb
(37) |
Mar
(97) |
Apr
(53) |
May
(50) |
Jun
(50) |
Jul
(44) |
Aug
(26) |
Sep
(52) |
Oct
(42) |
Nov
(28) |
Dec
(63) |
2012 |
Jan
(103) |
Feb
(40) |
Mar
(83) |
Apr
(66) |
May
(54) |
Jun
(35) |
Jul
(13) |
Aug
(2) |
Sep
(27) |
Oct
(47) |
Nov
(13) |
Dec
(17) |
2013 |
Jan
|
Feb
(12) |
Mar
(5) |
Apr
(10) |
May
(21) |
Jun
(4) |
Jul
(15) |
Aug
|
Sep
(37) |
Oct
(3) |
Nov
(1) |
Dec
|
2014 |
Jan
(8) |
Feb
(3) |
Mar
(5) |
Apr
(5) |
May
(6) |
Jun
(18) |
Jul
(7) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(3) |
Dec
(2) |
2015 |
Jan
(5) |
Feb
|
Mar
(4) |
Apr
(6) |
May
(15) |
Jun
(14) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
(9) |
Feb
(2) |
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(6) |
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Emmanuel F. <ef...@in...> - 2017-06-06 13:27:56
|
Le Fri, 2 Jun 2017 10:21:50 +0800 (HKT) Horace <ho...@hk...> écrivait: > I'm having a problem on compiling iscsi-scst from scst-3.2.0.7058 on > centos. Please help. Thanks. > Wrong list. SCST list is here: <scs...@li...> -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Horace <ho...@hk...> - 2017-06-02 02:21:59
|
Hi, I'm having a problem on compiling iscsi-scst from scst-3.2.0.7058 on centos. Please help. Thanks. OS: Centos 7.3 Kernel: 3.10.0-514.21.1.el7.x86_64 RPMs: kernel-3.10.0-514.21.1.el7.x86_64 kernel-tools-libs-3.10.0-514.21.1.el7.x86_64 kernel-headers-3.10.0-514.21.1.el7.x86_64 kernel-tools-3.10.0-514.21.1.el7.x86_64 kernel-devel-3.10.0-514.21.1.el7.x86_64 kernel-3.10.0-514.16.1.el7.x86_64 [root@iscsi02 iscsi-scst]# make all echo "/* Autogenerated, don't edit */" >include/iscsi_scst_itf_ver.h echo "" >>include/iscsi_scst_itf_ver.h echo -n "#define ISCSI_SCST_INTERFACE_VERSION " >>include/iscsi_scst_itf_ver.h echo -n "ISCSI_VERSION_STRING \"_" >>include/iscsi_scst_itf_ver.h echo "`sha1sum include/iscsi_scst.h|awk '{printf $1}'`\"" >>include/iscsi_scst_itf_ver.h make -C usr SCST_INC_DIR=/root/scst-3.2.x.7058/iscsi-scst/../scst/include make[1]: Entering directory `/root/scst-3.2.x.7058/iscsi-scst/usr' cc -M -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE iscsid.c iscsi_scstd.c conn.c session.c target.c message.c ctldev.c log.c chap.c event.c param.c config.c isns.c md5.c sha1.c misc.c >.depend_d cc -c -o iscsid.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE iscsid.c cc -c -o iscsi_scstd.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE iscsi_scstd.c cc -c -o conn.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE conn.c cc -c -o session.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE session.c cc -c -o target.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE target.c cc -c -o message.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE message.c cc -c -o ctldev.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE ctldev.c cc -c -o log.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE log.c cc -c -o chap.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE chap.c cc -c -o event.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE event.c cc -c -o param.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE param.c cc -c -o config.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE config.c cc -c -o isns.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE isns.c cc -c -o md5.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE md5.c cc -c -o sha1.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE sha1.c cc -c -o misc.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE misc.c cc iscsid.o iscsi_scstd.o conn.o session.o target.o message.o ctldev.o log.o chap.o event.o param.o config.o isns.o md5.o sha1.o misc.o -o iscsi-scstd cc -M -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE iscsi_adm.c param.c >.depend_adm cc -c -o iscsi_adm.o -O2 -Wall -Wextra -Wstrict-prototypes -Wno-sign-compare -Wimplicit-function-declaration -Wno-unused-parameter -Wno-missing-field-initializers -g -I../include -I/root/scst-3.2.x.7058/iscsi-scst/../scst/include -D_GNU_SOURCE iscsi_adm.c cc iscsi_adm.o param.o -o iscsi-scst-adm make[1]: Leaving directory `/root/scst-3.2.x.7058/iscsi-scst/usr' cp /root/scst-3.2.x.7058/iscsi-scst/../scst/src/Module.symvers kernel/ if true; then \ cp /root/scst-3.2.x.7058/iscsi-scst/../scst/src/Module.symvers kernel/isert-scst; \ fi make -C /lib/modules/3.10.0-514.21.1.el7.x86_64/build SCST_INC_DIR=/root/scst-3.2.x.7058/iscsi-scst/../scst/include SUBDIRS=/root/scst-3.2.x.7058/iscsi-scst/kernel modules make[1]: Entering directory `/usr/src/kernels/3.10.0-514.21.1.el7.x86_64' CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/iscsi.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/nthread.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/config.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/digest.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/conn.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/session.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/target.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/event.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/param.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/iscsit_transport.o LD [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/iscsi-scst.o Building modules, stage 2. MODPOST 1 modules CC /root/scst-3.2.x.7058/iscsi-scst/kernel/iscsi-scst.mod.o LD [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/iscsi-scst.ko make[1]: Leaving directory `/usr/src/kernels/3.10.0-514.21.1.el7.x86_64' echo "mods: INFINIBAND_ENABLED = true" mods: INFINIBAND_ENABLED = true if true; then \ echo " Building against in-tree InfiniBand kernel headers."; \ make -C /lib/modules/3.10.0-514.21.1.el7.x86_64/build SCST_INC_DIR=/root/scst-3.2.x.7058/iscsi-scst/../scst/include SUBDIRS=/root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst \ PRE_CFLAGS=" -DIB_CREATE_CQ_HAS_INIT_ATTR -DOFED_FLAVOR=in-tree" \ KBUILD_EXTRA_SYMBOLS=/root/scst-3.2.x.7058/iscsi-scst/kernel/Module.symvers modules; \ fi Building against in-tree InfiniBand kernel headers. make[1]: Entering directory `/usr/src/kernels/3.10.0-514.21.1.el7.x86_64' CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/isert.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/isert_login.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_datamover.o CC [M] /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.o /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c: In function âisert_device_createâ: /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:972:2: error: implicit declaration of function âib_query_deviceâ [-Werror=implicit-function-declaration] err = ib_query_device(ib_dev, &isert_dev->device_attr); ^ /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c: In function âisert_portal_createâ: /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:1795:11: warning: passing argument 1 of ârdma_create_idâ from incompatible pointer type [enabled by default] IB_QPT_RC); ^ In file included from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser.h:50:0, from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:44: include/rdma/rdma_cm.h:172:20: note: expected âstruct net *â but argument is of type âint (*)(struct rdma_cm_id *, struct rdma _cm_event *)â struct rdma_cm_id *rdma_create_id(struct net *net, ^ /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:1795:11: warning: passing argument 2 of ârdma_create_idâ from incompatible pointer type [enabled by default] IB_QPT_RC); ^ In file included from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser.h:50:0, from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:44: include/rdma/rdma_cm.h:172:20: note: expected ârdma_cm_event_handlerâ but argument is of type âstruct isert_portal *â struct rdma_cm_id *rdma_create_id(struct net *net, ^ /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:1795:11: warning: passing argument 3 of ârdma_create_idâ makes pointer from integer without a cast [enabled by default] IB_QPT_RC); ^ In file included from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser.h:50:0, from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:44: include/rdma/rdma_cm.h:172:20: note: expected âvoid *â but argument is of type âintâ struct rdma_cm_id *rdma_create_id(struct net *net, ^ /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:1795:11: error: too few arguments to function ârdma_create_idâ IB_QPT_RC); ^ In file included from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser.h:50:0, from /root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.c:44: include/rdma/rdma_cm.h:172:20: note: declared here struct rdma_cm_id *rdma_create_id(struct net *net, ^ cc1: some warnings being treated as errors make[2]: *** [/root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst/iser_rdma.o] Error 1 make[1]: *** [_module_/root/scst-3.2.x.7058/iscsi-scst/kernel/isert-scst] Error 2 make[1]: Leaving directory `/usr/src/kernels/3.10.0-514.21.1.el7.x86_64' make: *** [mods] Error 2 [root@iscsi02 iscsi-scst]# Regards, Horace Ng ISL E-Mail Disclaimer (http://www.hkisl.net/index.php?hkisl_page=emailDisclaimer) |
From: Chris S. <ck...@cs...> - 2016-12-28 23:26:14
|
> If I could somehow intercept the incoming data, that would be an > important milestone. Then I can focus on the content reconstruction. > Well, obviously block level transport is a new territory for > me. AFAIU, the "usr" folder in the sources is the user space part of > the server and I hope that would be the proper place to look into, > avoiding the even more complicated kernel space. I've already browsed > through some of the files there, but unfortunately I couldn't identify > what I was looking for. The user space component does not handle iSCSI data; it only configures the kernel components that do all the work. If you have to work with iSCSI as opposed to some other transport protocol, I strongly suggest that you find an iSCSI target implementation that is done entirely in user space. It's likely to be far easier to alter in ways that you want. (For that matter there are other, simpler block level protocols that are supported by Linux and have user-space target implementations, such as ATA-over-Ethernet.) > Thanks, Lars. I want to then stream the available reconstructed > content fragments, once available in the pipe. But I need the > available raw content fragments immediately they are received at > the server side and not wait for the whole file to be received, > reconstructed and made available via the fs. You may want to consider something other than iSCSI, such as NFS. I believe that there are user level NFS servers and they have the advantage that they explicitly deal with files at the protocol level; you do not have to reconstruct files from trying to understand the block data being sent to you (something that is sure to be fraught with all sorts of fun issues, especially if you wind up trying to do it at the kernel level). Basically, using iscsitarget for what you want to do appears to be picking one of the very hardest approaches possible. I suggest that you reconsider your goals and potential approaches from the ground up. - cks |
From: NavAil <som...@ya...> - 2016-12-28 22:52:29
|
Thanks, Lars. I want to then stream the available reconstructed content fragments, once available in the pipe. But I need the available raw content fragments immediately they are received at the server side and not wait for the whole file to be received, reconstructed and made available via the fs. If I could somehow intercept the incoming data, that would be an important milestone. Then I can focus on the content reconstruction. Well, obviously block level transport is a new territory for me. AFAIU, the "usr" folder in the sources is the user space part of the server and I hope that would be the proper place to look into, avoiding the even more complicated kernel space. I've already browsed through some of the files there, but unfortunately I couldn't identify what I was looking for. I'd appreciate if I could use some help on where in the code would the right place be to somehow take the incoming data. On 12/28/16 5:08 PM, Lars Ellenberg wrote: > On Tue, Dec 27, 2016 at 04:58:51PM +0100, NavAil wrote: >> Hello All, >> >> I need to use the server (on the server pc) in a special way, where I >> need to be intercepting and extracting in real timethe incoming (binary) >> file content of a big file (1-2GB or bigger) and concurrently writing it >> into a FIFO pipe for further processing. Only a single file at a time >> will be transferred to the server, at a known time. > What would be the purpose of that? > What would "further processing" be? > >> What would be the easiest way to do that? If that would be only possible >> by changing/adapting the source files, which files exactly should be >> changed? Could I perhaps get some directions on how to try to do that (I >> have no prior knowledge of this software)? > Are you aware of the difference between a "file", > "file system" and "block device"? > iSCSI is a block level transport, > so it does not see files. > It sees block IO requests to block offsets. > (and other things). > > So whatever your "pre/post processing" thingy was, > it would need to have internal knowlege of the file system in use > to be able to reliably re-construct the file-level requests from the > block-level requests. > > Whatever you are up to, > I don't think *this* angle will lead anywhere useful. > |
From: Lars E. <lar...@li...> - 2016-12-28 16:24:35
|
On Tue, Dec 27, 2016 at 04:58:51PM +0100, NavAil wrote: > Hello All, > > I need to use the server (on the server pc) in a special way, where I > need to be intercepting and extracting in real timethe incoming (binary) > file content of a big file (1-2GB or bigger) and concurrently writing it > into a FIFO pipe for further processing. Only a single file at a time > will be transferred to the server, at a known time. What would be the purpose of that? What would "further processing" be? > What would be the easiest way to do that? If that would be only possible > by changing/adapting the source files, which files exactly should be > changed? Could I perhaps get some directions on how to try to do that (I > have no prior knowledge of this software)? Are you aware of the difference between a "file", "file system" and "block device"? iSCSI is a block level transport, so it does not see files. It sees block IO requests to block offsets. (and other things). So whatever your "pre/post processing" thingy was, it would need to have internal knowlege of the file system in use to be able to reliably re-construct the file-level requests from the block-level requests. Whatever you are up to, I don't think *this* angle will lead anywhere useful. -- : Lars Ellenberg : LINBIT | Keeping the Digital World Running : DRBD -- Heartbeat -- Corosync -- Pacemaker : R&D, Integration, Ops, Consulting, Support DRBD® and LINBIT® are registered trademarks of LINBIT |
From: NavAil <som...@ya...> - 2016-12-27 14:58:57
|
Hello All, I need to use the server (on the server pc) in a special way, where I need to be intercepting and extracting in real timethe incoming (binary) file content of a big file (1-2GB or bigger) and concurrently writing it into a FIFO pipe for further processing. Only a single file at a time will be transferred to the server, at a known time. What would be the easiest way to do that? If that would be only possible by changing/adapting the source files, which files exactly should be changed? Could I perhaps get some directions on how to try to do that (I have no prior knowledge of this software)? Any help would be much appreciated! Thanks |
From: Steffen P. <swp...@am...> - 2016-12-20 14:54:26
|
Hi Matt, With ietd, the parameter -a is used to bind the server to a specific IP address. If you want to bind to multiple addresses, I just skip this parameter and let it bind to all addresses and use iptables to block off any unwanted TCP connections. Steffen _______________________________________________________________________________________________ Steffen Plotner Amherst College Tel (413) 542-2348 Systems/Network Administrator/Programmer PO BOX 5000 Fax (413) 542-2626 Systems & Networking Amherst, MA 01002-5000 swp...@am... From: Matt Lavergne [mailto:th...@gm...] Sent: Tuesday, December 20, 2016 9:14 AM To: isc...@li... Subject: [Iscsitarget-devel] bind so some IP addresses Hello all, I know by editing /etc/defaults/iscsitarget ISCSITARGET_OPTIONS="" I can bind iscsitarget to listen on a single IP what i would like to do is bind to 2 IP's of the 4-5 the machine has. Is there anyway to accomplish this? |
From: Matt L. <th...@gm...> - 2016-12-20 14:14:19
|
Hello all, I know by editing /etc/defaults/iscsitarget ISCSITARGET_OPTIONS="" I can bind iscsitarget to listen on a single IP what i would like to do is bind to 2 IP's of the 4-5 the machine has. Is there anyway to accomplish this? |
From: craigslist 4. <st...@um...> - 2016-06-10 21:31:31
|
Hey, Have you seen this before? That's something really nice, more info here <http://zosefywo.thedockloader.com/lnulslq> Kind regards, craigslist 4645995254 |
From: Carol U. <st...@um...> - 2016-05-30 03:46:27
|
Hi, You're not gonna believe what I've read yesterday, you've got to read it yourself at <http://cethucyspo.wegoat.com/lndgjwoo> Hugs, Carol Umbehocker |
From: Emmanuel F. <ef...@in...> - 2016-02-01 17:06:25
|
Le Mon, 1 Feb 2016 11:14:33 -0300 Felipe Gutierrez <fe...@us...> écrivait: > Hi, > I am developing MODE_SENSE_6 messages for jscsi.org, which is at > SPC3. I am basing my developing at the IET dump which I sow is at > SPC2. Is there a way to configure target to use SPC3? > I think there was some patches proposed, but it doesn't seem that it came to fruition. Have a look through the archive to be sure. -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Felipe G. <fe...@us...> - 2016-02-01 14:14:41
|
Hi, I am developing MODE_SENSE_6 messages for jscsi.org, which is at SPC3. I am basing my developing at the IET dump which I sow is at SPC2. Is there a way to configure target to use SPC3? Thanks, Felipe [image: Inline image 1] -- |
From: Felipe G. <fe...@us...> - 2016-01-26 13:00:59
|
Kernel 3.2. but I don't think it is the problem because I am using a Java implementation of iscsi target. http://jscsi.org/. I believe I need to implement some message that is missing at this target. 2016-01-26 5:25 GMT-02:00 José JORGE <jos...@cp...>: > Le 25/01/2016 23:09, Felipe Gutierrez a écrit : > >> >> I am trying to connect VMware ESX 3 to my iscsi target. >> > With which kernel version? Looks like the same problem we have with > kernels >3.x > > > > ***************************************************** > "Le contenu de ce courriel et ses eventuelles pièces jointes sont > confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si > cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et > afin de ne pas violer le secret des correspondances, vous ne devez pas le > transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à > l'émetteur et de le détruire. > > Attention : L'Organisme de l'émetteur du message ne pourra être tenu > responsable de l'altération du présent courriel. Il appartient au > destinataire de vérifier que les messages et pièces jointes reçus ne > contiennent pas de virus. Les opinions contenues dans ce courriel et ses > éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent > pas la position de l'Organisme sauf s'il en est disposé autrement dans le > présent courriel." > ****************************************************** > > > > ------------------------------------------------------------------------------ > Site24x7 APM Insight: Get Deep Visibility into Application Performance > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month > Monitor end-to-end web transactions and take corrective actions now > Troubleshoot faster and improve end-user experience. Signup Now! > http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140 > _______________________________________________ > Iscsitarget-devel mailing list > Isc...@li... > https://lists.sourceforge.net/lists/listinfo/iscsitarget-devel > > -- |
From: José J. <jos...@cp...> - 2016-01-26 07:26:04
|
Le 25/01/2016 23:09, Felipe Gutierrez a écrit : > > I am trying to connect VMware ESX 3 to my iscsi target. With which kernel version? Looks like the same problem we have with kernels >3.x ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ****************************************************** |
From: Felipe G. <fe...@us...> - 2016-01-25 22:40:43
|
Hi, I am trying to connect VMware ESX 3 to my iscsi target. Debuging my code I can see vmware is sending from wire dataDigest=None and headerDigest=None. So my target cant process anything and after that I can see a "Broken Pipe" on my target. I beliave the Broken Pipe is a request from the initiator to re establish the connection. But what cant I program on my target to accept VMware ESX3 initiator to connect on it? Thanks, Felipe ()2016-01-25 18:43:03 DEBUG [main] connection.TargetSenderWorker - Settings: Settings [settingsId=3, dataDigest=None, headerDigest=None, ifMarker=false, ifMarkInt=2048, maxRecvDataSegmentLength=131072, ofMarker=false, ofMarkInt=2048, targetName=iqn.2014-06.ustore-dev:disk1, dataPduInOrder=true, dataSequenceInOrder=true, defaultTime2Retain=0, defaultTime2Wait=2, errorRecoveryLevel=0, firstBurstLength=65536, immediateData=true, initialR2T=false, initiatorAlias=null, initiatorName=iqn.1998-01.com.vmware:coelhos-65f7dd86, maxBurstLength=262144, maxConnections=1, maxOutstandingR2T=1, sessionType=Normal] ()2016-01-25 18:43:03 DEBUG [main] connection.TargetSenderWorker - Receiving this PDU: ParserClass: null OpCode: LOGIN_REQUEST FinalFlag: false TotalAHSLength: 0x0 DataSegmentLength: 0x0 InitiatorTaskTag: 0x0 ()2016-01-25 18:43:03 DEBUG [main] connection.TargetSenderWorker - connection.getStatusSequenceNumber: 4973 ()2016-01-25 18:43:03 DEBUG [main] connection.Connection$TargetConnection - ****************************** Recieving System Time: 2016-01-25 18:43:03.274 ParserClass: null OpCode: LOGIN_REQUEST FinalFlag: false TotalAHSLength: 0x0 DataSegmentLength: 0x0 InitiatorTaskTag: 0x0 ****************************** ()2016-01-25 18:43:03 INFO [main] phase.TargetFullFeaturePhase - bhs.getOpCode() = LOGIN_REQUEST ()2016-01-25 18:43:03 ERROR [main] phase.TargetFullFeaturePhase - Recieved unsupported opcode for LOGIN_REQUEST ()2016-01-25 18:43:03 DEBUG [main] connection.TargetSenderWorker - Sending this PDU: ParserClass: SCSIResponseParser ImmediateFlag: false OpCode: 0x21 FinalFlag: true TotalAHSLength: 0x0 DataSegmentLength: 0x14 InitiatorTaskTag: 0x0 Response: 0x0 SNACK TAG: 0x0 StatusSequenceNumber: 0x136d ExpectedCommandSequenceNumber: 0xf00 MaximumCommandSequenceNumber: 0xf00 ExpDataSN: 0x0 BidirectionalReadResidualOverflow: false BidirectionalReadResidualUnderflow: false ResidualOverflow: true ResidualUnderflow: false ResidualCount: 0x13 Bidirectional Read Residual Count: 0x0 ()2016-01-25 18:43:03 ERROR [main] connection.Connection$TargetConnection - Exception throws () java.io.IOException: Pipe quebrado at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[?:1.8.0_60] at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) ~[?:1.8.0_60] at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) ~[?:1.8.0_60] at sun.nio.ch.IOUtil.write(IOUtil.java:65) ~[?:1.8.0_60] at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) ~[?:1.8.0_60] at org.jscsi.parser.ProtocolDataUnit.write(ProtocolDataUnit.java:364) ~[udrive.jar:?] at org.jscsi.target.connection.TargetSenderWorker.sendOverWire(TargetSenderWorker.java:246) ~[udrive.jar:?] at org.jscsi.target.connection.Connection$TargetConnection.sendPdu(Connection.java:209) ~[udrive.jar:?] at org.jscsi.target.connection.stage.fullfeature.UnsupportedOpCodeStage.execute(UnsupportedOpCodeStage.java:64) ~[udrive.jar:?] at org.jscsi.target.connection.phase.TargetFullFeaturePhase.execute(TargetFullFeaturePhase.java:185) ~[udrive.jar:?] at org.jscsi.target.connection.Connection$TargetConnection.call(Connection.java:235) ~[udrive.jar:?] at org.jscsi.target.connection.Connection$TargetConnection.call(Connection.java:64) ~[udrive.jar:?] at org.jscsi.target.TargetServer.call(TargetServer.java:326) ~[udrive.jar:?] at org.jscsi.target.TargetServer.main(TargetServer.java:773) ~[udrive.jar:?] 2016-01-25 18:43:03 DEBUG [main] connection.Connection$TargetConnection - closed connection ()2016-01-25 18:43:03 DEBUG [main] connection.TargetSenderWorker - Receiving this PDU: ParserClass: LoginRequestParser ImmediateFlag: true OpCode: 0x3 FinalFlag: true TotalAHSLength: 0x0 DataSegmentLength: 0xe2 InitiatorTaskTag: 0x0 Continue Flag: false CSG: 0x1 NSG: 0x3 minVersion: 0x0 maxVersion: 0x0 ISID: T: 0x0 A: 0x0 B: 0x23d C: 0x0 D: 0x0 TSIH: 0x0 CID: 0x0 CommandSequenceNumber: 0x1 ExpectedStatusSequenceNumber: 0x0 -- |
From: José J. <jos...@cp...> - 2016-01-22 16:57:21
|
Le 22/01/2016 16:32, Emmanuel Florac a écrit : > Le Mon, 14 Sep 2015 17:37:54 +0200 > José JORGE <jos...@cp...> écrivait: > >> hi, the module does not build anymore against 3.19 kernels. >> >> May I expect a patch? >> > Any luck lately with the patches I've posted? > I could not find time to test them, but as you said "Doesn't actually work yet unfortunately, need some work." for 4.3 kernel, I suppose I didn't miss anything while I tried against 4.1 kernel and got no luck. ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ****************************************************** |
From: Emmanuel F. <ef...@in...> - 2016-01-22 15:32:33
|
Le Mon, 14 Sep 2015 17:37:54 +0200 José JORGE <jos...@cp...> écrivait: > hi, the module does not build anymore against 3.19 kernels. > > May I expect a patch? > Any luck lately with the patches I've posted? -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Emmanuel F. <ef...@in...> - 2016-01-22 15:31:48
|
Le Tue, 5 Jan 2016 13:31:31 +0100 Emmanuel Florac <ef...@in...> écrivait: > Le Tue, 5 Jan 2016 12:50:31 +0100 > Emmanuel Florac <ef...@in...> écrivait: > > > > I'm joining the cleaned-up patches, they work fine with the current > > SVN release (503). > > And here is a patch that allows compilation with 4.3.x kernel (not yet > tested, but create a working module). Doesn't actually work yet unfortunately, need some work. -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Felipe G. <fe...@us...> - 2016-01-22 14:58:57
|
Hi, I have a doubt about the PDU of iscsi target protocol. Must them be process in order? Because on my iscsi target implementation I have a main thread that process all PDUs. But to increase the performance I would like to create different threads for read and write PDUs. thanks, Felipe -- |
From: Emmanuel F. <ef...@in...> - 2016-01-05 12:31:36
|
Le Tue, 5 Jan 2016 12:50:31 +0100 Emmanuel Florac <ef...@in...> écrivait: > > I'm joining the cleaned-up patches, they work fine with the current > SVN release (503). And here is a patch that allows compilation with 4.3.x kernel (not yet tested, but create a working module). -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Emmanuel F. <ef...@in...> - 2016-01-05 12:06:52
|
Le Fri, 6 Nov 2015 13:23:56 +0100 Emmanuel Florac <ef...@in...> écrivait: > Le Fri, 06 Nov 2015 08:29:26 +0100 > José JORGE <jos...@cp...> écrivait: > > > Le 05/11/2015 19:08, Emmanuel Florac a écrit : > > > Le Mon, 14 Sep 2015 17:37:54 +0200 > > > José JORGE <jos...@cp...> écrivait: > > > > > >> hi, the module does not build anymore against 3.19 kernels. > > >> > > >> May I expect a patch? > > > I hope to have some time next week to create patches for kernels > > > 3.19-4.3. Stay tuned. > > > > > In fact, I have found a patch : > > http://lists.openembedded.org/pipermail/openembedded-devel/2015-August/103052.html > > > > But it fails to work when I try to connect the iSCSI disks to an > > ESXi system. > > > > OK, I'll have a look at this patch. Please post to the list too, the > information may be useful to others too... These patches seem to work for me, up to kernel 4.3 where they break due to missing function bio_get_nr_vecs . I'm joining the cleaned-up patches, they work fine with the current SVN release (503). -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Emmanuel F. <ef...@in...> - 2015-11-06 12:24:01
|
Le Fri, 06 Nov 2015 08:29:26 +0100 José JORGE <jos...@cp...> écrivait: > Le 05/11/2015 19:08, Emmanuel Florac a écrit : > > Le Mon, 14 Sep 2015 17:37:54 +0200 > > José JORGE <jos...@cp...> écrivait: > > > >> hi, the module does not build anymore against 3.19 kernels. > >> > >> May I expect a patch? > > I hope to have some time next week to create patches for kernels > > 3.19-4.3. Stay tuned. > > > In fact, I have found a patch : > http://lists.openembedded.org/pipermail/openembedded-devel/2015-August/103052.html > > But it fails to work when I try to connect the iSCSI disks to an ESXi > system. > OK, I'll have a look at this patch. Please post to the list too, the information may be useful to others too... -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: Emmanuel F. <ef...@in...> - 2015-11-05 18:26:52
|
Le Mon, 14 Sep 2015 17:37:54 +0200 José JORGE <jos...@cp...> écrivait: > hi, the module does not build anymore against 3.19 kernels. > > May I expect a patch? I hope to have some time next week to create patches for kernels 3.19-4.3. Stay tuned. -- ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | <ef...@in...> | +33 1 78 94 84 02 ------------------------------------------------------------------------ |
From: José J. <jos...@cp...> - 2015-09-14 15:45:58
|
hi, the module does not build anymore against 3.19 kernels. May I expect a patch? Thanks ***************************************************** "Le contenu de ce courriel et ses eventuelles pièces jointes sont confidentiels. Ils s'adressent exclusivement à la personne destinataire. Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur, et afin de ne pas violer le secret des correspondances, vous ne devez pas le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer à l'émetteur et de le détruire. Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération du présent courriel. Il appartient au destinataire de vérifier que les messages et pièces jointes reçus ne contiennent pas de virus. Les opinions contenues dans ce courriel et ses éventuelles pièces jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme sauf s'il en est disposé autrement dans le présent courriel." ****************************************************** |
From: Felipe G. <fe...@us...> - 2015-07-09 13:35:59
|
open-iscsi http://www.open-iscsi.org/ On Thu, Jul 9, 2015 at 10:24 AM, Emmanuel Florac <ef...@in...> wrote: > Le Mon, 6 Jul 2015 11:18:06 -0300 > Felipe Gutierrez <fe...@us...> écrivait: > > > Hi, > > > > I am having these errors: ISCSI_ERR_BAD_ITT and 1011 - > > ISCSI_ERR_CONN_FAILED. After this the iscsi initiator disconnect. I > > search at the web and I found the problem is the target is sending > > PDU in order but the initiator received it in different order. So I > > want to change at the target DATA_PDU_IN_ORDER to FALSE as say at > > http://schemas.dmtf.org/wbem/cim-html/2/CIM_iSCSISession.html > > > > I wonder to know if I need to configure other properties at the > > initiator as well at the target. > > > > What initiator are you using? > > -- > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > | <ef...@in...> > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ > -- |