Re: do discovery through SW transports too
On 6/9/13 9:54 AM, Or Gerlitz wrote: usr]# make Hey, Did you figure this out? Support for that changed. You need to do make from the top level dir, because of dependencies on other stuff. Once that stuff is built you can do make from the usr dir to build just the usr stuff. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai w...@broadcom.com Date: Wednesday 5 June 2013 7:00 AM To: shyam_i...@dell.com shyam_i...@dell.com Cc: open-iscsi@googlegroups.com open-iscsi@googlegroups.com, Vikas vikas.chaudh...@qlogic.com, Lalit Chandivade lalit.chandiv...@qlogic.com, Ravi Anand ravi.an...@qlogic.com, Poornima Vonti poornima.vo...@qlogic.com, Manish Rangankar manish.rangan...@qlogic.com, Adheer Chandravanshi adheer.chandravan...@qlogic.com Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs entries correctly. Although we have not proposed this via the netdev ML yet, however, the current suggestion to only add ethtool extension to support this is gaining traction. As far as latency goes, a simple for_each_netdev loop to probe each netdev's ethtool_ops for these new extensions (like get/set_flash_node) shouldn't incur
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai w...@broadcom.com Date: Wednesday 5 June 2013 7:00 AM To: shyam_i...@dell.com shyam_i...@dell.com Cc: open-iscsi@googlegroups.com open-iscsi@googlegroups.com, Vikas vikas.chaudh...@qlogic.com, Lalit Chandivade lalit.chandiv...@qlogic.com, Ravi Anand ravi.an...@qlogic.com, Poornima Vonti poornima.vo...@qlogic.com, Manish Rangankar manish.rangan...@qlogic.com, Adheer Chandravanshi adheer.chandravan...@qlogic.com Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs entries correctly. Although we have not proposed this via the netdev ML yet, however, the
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On 06/11/2013 12:43 PM, Eddie Wai wrote: On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai w...@broadcom.com Date: Wednesday 5 June 2013 7:00 AM To: shyam_i...@dell.com shyam_i...@dell.com Cc: open-iscsi@googlegroups.com open-iscsi@googlegroups.com, Vikas vikas.chaudh...@qlogic.com, Lalit Chandivade lalit.chandiv...@qlogic.com, Ravi Anand ravi.an...@qlogic.com, Poornima Vonti poornima.vo...@qlogic.com, Manish Rangankar manish.rangan...@qlogic.com, Adheer Chandravanshi adheer.chandravan...@qlogic.com Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs entries correctly. Although we have not proposed this via the netdev ML yet, however, the current suggestion to only add ethtool extension to support this is gaining traction. As far
Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support
On Tue, 2013-06-11 at 13:26 -0500, Mike Christie wrote: On 06/11/2013 12:43 PM, Eddie Wai wrote: On Tue, 2013-06-11 at 12:25 -0500, Mike Christie wrote: On 6/10/13 10:47 PM, Vikas Chaudhary wrote: -Original Message- From: Eddie Wai w...@broadcom.com Date: Wednesday 5 June 2013 7:00 AM To: shyam_i...@dell.com shyam_i...@dell.com Cc: open-iscsi@googlegroups.com open-iscsi@googlegroups.com, Vikas vikas.chaudh...@qlogic.com, Lalit Chandivade lalit.chandiv...@qlogic.com, Ravi Anand ravi.an...@qlogic.com, Poornima Vonti poornima.vo...@qlogic.com, Manish Rangankar manish.rangan...@qlogic.com, Adheer Chandravanshi adheer.chandravan...@qlogic.com Subject: RE: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On Wed, 2013-05-29 at 14:37 -0700, shyam_i...@dell.com wrote: -Original Message- From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On Behalf Of Mike Christie Sent: Wednesday, May 29, 2013 1:30 PM To: open-iscsi@googlegroups.com Cc: Eddie Wai; vikas.chaudh...@qlogic.com; lalit.chandiv...@qlogic.com; ravi.an...@qlogic.com; poornima.vo...@qlogic.com; manish.rangan...@qlogic.com; Adheer Chandravanshi Subject: Re: [RFC_V5 PATCH 1/3] scsi_transport_iscsi: Add flash node mgmt support On 05/29/2013 12:23 PM, Eddie Wai wrote: On Wed, 2013-05-29 at 10:26 -0500, Mike Christie wrote: On 05/28/2013 07:35 PM, Eddie Wai wrote: Hello Mike, Vikas, and all, Thanks for the great work in creating the flash node mechanism! To extend the conversation we had to add support for software and other offload solutions that requires iscsid/iscsiadm to create the sessions, the following needs to be further discussed: 1. Flash node creation. The current solution relies on the transport driver to initiate the flash node sysfs creation upon iscsi_host allocation. This presents a fundamental problem for software iSCSI as new iscsi_host instance won't get created until there's a session initiation. Per our conversation, I think it makes sense to move the flash node initiation code altogether to a separate module like how its done for ibft. The new module shall cycle through each existing iSCSI host and query the corresponding transport to fill the flash node sysfs entries specific to that host. Perhaps via a new transport callback or so. Agree. Since there won't be any pre-existing host created for software iSCSI, this needs to be handled differently. Instead, the new module will also need to cycle through each network interfaces present and query for the flash node content separately. To accomplish this, each network interface will need to be made aware of flash nodes and also provide a way for the new module to read out the flash node content. Per our conversation, this can be done via an extension of the ethtool utility. For unsupported network drivers, this I do not remember that discussion. Has it been discussed with the netdev people already? This has only been discussed internally so far, but we believe adding a new ethtool extension for this flash memory access is one logical way that the netdev community can accept. Why does the new module need to cycle through each net device? Can't a net driver that knows it supports this just call into the new module to register itself when it is loaded? When it registers it can create any sysfs/netlink stuff needed so userspace can detect it and access it. That would work too, but our proposal essentially is tailored toward minimizing any storage specific code in the network drivers. Note that our proposal is to add an ethtool extension which will provide read/write access directly to the flash memory. It will not do any sysfs creation or parameter qualification. It only provides a gateway to the flash memory, that's it. It will be up to the new module to initiate, create, and manage over those sysfs parameters. Sounds ok to me. Perhaps we can add some minor initiation code in the network driver to perhaps 'register' some flag so the new module will only have to cycle through a list of supported network interfaces only. It is ok. I was just thinking along the lines of either ethtool or iscsi mod only. I cannot think of a major issue to probe with ethtool from userspace like you suggested before. The only issue might be if we have to do some sort of probing and checking if this is supported takes a while (like if we have to do some fw command that takes several to 10-15 seconds each time). For that case we do not want to have to probe every device during boot or the boot/distro people will not be happy. Second that.. One alternative is that the network driver registers to the new module. I would prefer that the new module is loaded already so it can enumerate the /sysfs
Re: do discovery through SW transports too
On 06/06/2013 18:01, Mike Christie wrote: However, above I am not talking about that or doing discovery over a normal session in general. I was just trying to get clarification for what you wanted. I was not sure if there was some new iser spec stuff that I missed and you wanted to implement. Hi Mike, Its not new spec stuff, its just environments where plain TCP services might be out of hand for either of the sides and we don't want that to be an obstacle to deploy iser. Or. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: do discovery through SW transports too
On 06/06/2013 18:01, Mike Christie wrote: I think everything should be there. I thought I worked on iser when doing the work too. You need the attached kernel patch. In the other mails I think I said you need a change to the userspace iser code, but ignore that. In the common iscsi code I did a hack for all drivers. Apply the patch and then run iscsiadm -m discovery -t st -p ip -I iser -d 8 In the userspace discovery.c:iscsi_create_leading_conn() you will want to check that the code path with this debug log statement is being hit: log_debug(2, %s discovery ep connect\n, __FUNCTION__); and that it is the correct callout for your driver. Mike, I had some troubles building the user space part of the initiator from the latest git, FWYI - for utils/open-isns./configure --without-securityworks OK, but the default (which is --with-security) seems to be broken (see below). Also once, I passed that, I failed to get the usr directory utils to get built as of missing strlcpy/strlcat -- probably my glibc is too old and doesn't contain these folks... do you know of the latest initiator is buildable on RHEL 6.x nodes (e.g with glibc-2.12-1.47.el6.x86_64) ? auth.o: In function `acl_set_chap_alg_key': /open-iscsi/usr/auth.c:743: undefined reference to `strlcpy' /open-iscsi/usr/auth.c:746: undefined reference to `strlcat' another failure I see there is for the fw_xxx functions, any idea what should I build to make that work? discovery.o: In function `discovery_fw': /open-iscsi/usr/discovery.c:391: undefined reference to `fw_get_targets' /open-iscsi/usr/discovery.c:419: undefined reference to `fw_free_targets' Or. checking openssl/crypto.h usability... yes checking openssl/crypto.h presence... yes checking for openssl/crypto.h... yes checking for EVP_PKEY_new in -lcrypto... yes checking slp.h usability... no checking slp.h presence... no checking for slp.h... no checking for SLPOpen in -lslp... no configure: creating ./config.status config.status: creating Makefile config.status: WARNING: 'Makefile.in' seems to ignore the --datarootdir setting config.status: creating config.h config.status: config.h is unchanged [root@vsa3 open-isns]# make gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o server.o server.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o client.o client.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o objects.o objects.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o callback.o callback.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o timer.o timer.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o vendor.o vendor.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o db.o db.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o db-file.o db-file.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o db-policy.o db-policy.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o relation.o relation.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o scope.o scope.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o message.o message.c gcc -Wall -fno-strict-aliasing -g -O2 -I. -D_GNU_SOURCE -c -o security.o security.c security.c: In function ?isns_create_principal?: security.c:40: warning: dereferencing ?void *? pointer security.c:40: error: request for member ?type? in something not a structure or union security.c:41: error: ?EVP_PKEY_DSA? undeclared (first use in this function) security.c:41: error: (Each undeclared identifier is reported only once security.c:41: error: for each function it appears in.) security.c:42: error: ?EVP_PKEY_RSA? undeclared (first use in this function) security.c:47: warning: implicit declaration of function ?EVP_PKEY_bits? security.c: In function ?isns_principal_set_key?: security.c:61: warning: implicit declaration of function ?EVP_PKEY_free? make: *** [security.o] Error 1 usr]# make cc -O2 -g -Wall -Wstrict-prototypes -I../include -I. -I../utils/open-isns -DLinux -DNETLINK_ISCSI=8 -D_GNU_SOURCE iscsi_util.o io.o auth.o iscsi_timer.o login.o log.o md5.o sha1.o iface.o idbm.o sysfs.o host.o session_info.o iscsi_sysfs.o iscsi_net_util.o iscsid_req.o transport.o iser.o cxgbi.o be2iscsi.o initiator_common.o iscsi_err.o flashnode.o uip_mgmt_ipc.o netlink.o initiator.o scsi.o actor.o event_poll.o mgmt_ipc.o kern_err_table.o strings.o discovery.o iscsid.o session_mgmt.o discoveryd.o -o iscsid -L../utils/open-isns -lisns io.o: In function `bind_conn_to_iface': /mnt/sdb1/ogerlitz/open-iscsi/usr/io.c:237: undefined reference to `strlcpy' auth.o: In function `acl_set_key_value': /mnt/sdb1/ogerlitz/open-iscsi/usr/auth.c:547: undefined reference to `strlcpy' auth.o: In function `acl_set_user_name': /mnt/sdb1/ogerlitz/open-iscsi/usr/auth.c:1890: undefined reference to `strlcpy' auth.o: In function `acl_send_key_val': /mnt/sdb1/ogerlitz/open-iscsi/usr/auth.c:1520:
iscsi initiaor, obsolete volumes remain zombie
Hi, I am new to iscsi. The iscsi in normal environment works fine. Both target and initiators are running on ubuntu. When a new lun is added to a target, it automatically appears on the initiators. But when a lun is removed on the target side, it is remain a zombie, on the initiator. Is there a way to remove a specific lun on the initiator side. The only way i found is to logout of the target, and login again. This disrupts healthy lun as well. I am using iscsiadm. version 2.0-871 I am using Ubuntu with open-iscsi 2.0.871-0 Preparing to replace open-iscsi 2.0.871-0ubuntu9.12.04.1 (using .../open-iscsi_2.0.871-0ubuntu9.12.04.2_amd64.deb) . 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
rhel6.3 - iscsid's ability to reconnect after server restart, or service restart (open-iscsi 2.0-872.41)
Hi! rhel6.3 (unpatched) iscsistart version 2.0-872.41.el6 iscsid version 2.0-872.41.el6 iscsi-initiator-utils-6.2.0.872-41.el6.x86_64 We use rhel6.3 as diskless clients (iscsi) against our NetApp. Connecting through iBFT with iPXE at BIOS level. Adjusting node.session.timeo.replacement_timeout in /etc/iscsi/iscsid.con to a large number (3 days in seconds), does the timeout I want to have (and, we do not get any I/O errors). If our network goes down for maintenance 2-3 days (network/switches) etc, our diskless iscsi clients will survive. But, when I test this, I just pull out the network cable from my computer. What happends if the server goes down, or iscsi-service is restarted (iscsi sessions gets disconnected, server side)? Does iscsid on the client reconnect the same way if session gets disconnected, as when I just pull out the network cable from the computer? Regards, Torgeir -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
do the undoable - survive network disconnections under heavy load
Hey, I've a system which uses open-iscsi and mpp driver, to connect an external storage. The system reads data from all disks, and writes to some of them. Kernel is 2.6.27, but latest open-iscsi and mpp. When the storage is down, the system cannot umount some of the disks, and the application is stalled. Only reboot can save the situation. I tried to minimize the iscsi timeouts, as well as the mpp timeouts, which resulted in a better results, but not enough. I also tried to make the iscsi timeout long and the mpp short, and vice versa. It seems that the kernel is just not designed to such cases. At least not with a heavy i/o. I also tried close the open file-descriptors, tried to logoff the iscsi and remove the disks using echo 1 /sys/block/sdx/device/delete, changed the elevator to noop, but nothing helped. At the moment I can't upgrade the kernel, but I'll do that in the near future. Any ideas how to handle such case, except of monitor it and reboot the system? Thanks! -- Uri -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
iSCSI and multipath failover
Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator would send the commands. Appreciate any help you can offer. What value you would suggest if I what multipath to take over as soon as iSCSI target fails. Kind regards, Bubuli -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
do discovery through SW transports too
Hi Mike, There are iser environments where we might need to do iscsi discovery over rdma connection, that is establish iser connection and then carry the discovery session over it. I was a bit away for the developments in the initiator over the last months so would need some crash help here. Looking on the user space code, I see that if a transport advertizes SENDTARGETS_OFFLOAD capability there's possibility for them to provide -sendtargets entry through which discovery can be done. I also see in usr/netlink.c framework to go into the kernel for sendtargets. I understand this was build for HW iscsi transports where the card offloads things like discovery, but I hope we can reuse this code if the user wants to (say) conduct discovery through any transport (e.g iser) and not through tcp from user space, any heads up will be cool. Or. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
iSCSI and multipath failover
Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator would send the commands. Appreciate any help you can offer. What value you would suggest if I what multipath to take over as soon as iSCSI target fails. Kind regards, Bubuli -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: iSCSI and multipath failover
On 06/07/2013 12:55 AM, Bubuli Nayak wrote: Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator would send the commands. It depends on the iscsi tools and kernel version you have. If in iscsid.conf you see the chunk about if the value is 0 it will be failed immediately and you have a recent kernel like 3.0 or newer or distro like RHEL 6 or SLES 11 then if you set it to 0 then it there will be no delay and IO will be failed as soon as we detect a error. # To specify the length of time to wait for session re-establishment # before failing SCSI commands back to the application when running # the Linux SCSI Layer error handler, edit the line. # The value is in seconds and the default is 120 seconds. # Special values: # - If the value is 0, IO will be failed immediately. # - If the value is less than 0, IO will remain queued until the session # is logged back in, or until the user runs the logout command. Appreciate any help you can offer. What value you would suggest if I what multipath to take over as soon as iSCSI target fails. Kind regards, Bubuli -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[PATCH] iscsid: fix order of setting uid/gid and drop supplementary groups
If using the user and group ID settings together the existing order of
calling setuid first will almost always cause the setgid call to fail,
assuming the new effective user id does not have the CAP_SETGID
capability. The effective group ID needs to change first.
While we're at it, if iscsid is started as root it should drop any
inherited supplementary group permissions.
And if anyone is actually using this to try and isolate capabilities,
they probably care enough to want to known that it is failing. Make
iscsid startup fail instead of just calling perror.
Signed-off-by: Chris Leech cle...@redhat.com
---
usr/iscsid.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/usr/iscsid.c b/usr/iscsid.c
index b4bb65b..c0ea6fa 100644
--- a/usr/iscsid.c
+++ b/usr/iscsid.c
@@ -27,6 +27,7 @@
#include unistd.h
#include string.h
#include signal.h
+#include grp.h
#include sys/mman.h
#include sys/utsname.h
#include sys/types.h
@@ -477,11 +478,25 @@ int main(int argc, char *argv[])
}
}
- if (uid setuid(uid) 0)
- perror(setuid\n);
+ if (gid setgid(gid) 0) {
+ log_error(Unable to setgid to %d\n, gid);
+ log_close(log_pid);
+ exit(ISCSI_ERR);
+ }
- if (gid setgid(gid) 0)
- perror(setgid\n);
+ if ((geteuid() == 0) (getgroups(0, NULL))) {
+ if (setgroups(0, NULL) != 0) {
+ log_error(Unable to drop supplementary group ids\n);
+ log_close(log_pid);
+ exit(ISCSI_ERR);
+ }
+ }
+
+ if (uid setuid(uid) 0) {
+ log_error(Unable to setuid to %d\n, uid);
+ log_close(log_pid);
+ exit(ISCSI_ERR);
+ }
memset(daemon_config, 0, sizeof (daemon_config));
daemon_config.pid_file = pid_file;
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: iSCSI and multipath failover
Thanks Mike. I have few follow-up question please. Why is this default replacement timeout so high. If I understand correctly in a multipath environment it is perfectly alright to set it to 0 without any side effect. The other question is, how early iSCSI can detect session error , be it with transport or target. What if I set nop-out values as low as 1sec? In that case my paths shall be failed over in 2sec? Any optimized value for a virtual environment, where machines booted from iSCSI luns and our requirement is to achieve failover like fiber channel does, almost immediately? Without instant failover virtual machines just hangs as long as the path comes back or failover to alternate path. Kind regards, Bubuli On Wed, Jun 12, 2013 at 2:24 AM, Mike Christie micha...@cs.wisc.edu wrote: On 06/07/2013 12:55 AM, Bubuli Nayak wrote: Hello experts, I have learnt from MIke and others comment that multipath failover would be driven by nop timout + nop interval + replacement_timeout seconds. My question is what is the impact I set replacement_timeout to 0. I know if NOPOUT interval is low , more frequently iSCSI initiator would send the commands. It depends on the iscsi tools and kernel version you have. If in iscsid.conf you see the chunk about if the value is 0 it will be failed immediately and you have a recent kernel like 3.0 or newer or distro like RHEL 6 or SLES 11 then if you set it to 0 then it there will be no delay and IO will be failed as soon as we detect a error. # To specify the length of time to wait for session re-establishment # before failing SCSI commands back to the application when running # the Linux SCSI Layer error handler, edit the line. # The value is in seconds and the default is 120 seconds. # Special values: # - If the value is 0, IO will be failed immediately. # - If the value is less than 0, IO will remain queued until the session # is logged back in, or until the user runs the logout command. Appreciate any help you can offer. What value you would suggest if I what multipath to take over as soon as iSCSI target fails. Kind regards, Bubuli -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 2/7] actor: simplify actor_check
From: Adam Jackson a...@redhat.com
Now that it's static we know it can't ever be called when
poll_in_progress is true.
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/usr/actor.c b/usr/actor.c
index 880bf81..fb90924 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -221,17 +221,10 @@ actor_check(uint64_t current_time)
(long)thread, thread-scheduled_at, thread-ttschedule,
current_time, pend_list.next, pend_list);
- if (poll_in_progress) {
- thread-state = ACTOR_POLL_WAITING;
- list_add_tail(thread-list, poll_list);
- log_debug(7, thread %08lx now in poll_list,
- (long)thread);
- } else {
- thread-state = ACTOR_SCHEDULED;
- list_add_tail(thread-list, actor_list);
- log_debug(7, thread %08lx now in actor_list,
- (long)thread);
- }
+ thread-state = ACTOR_SCHEDULED;
+ list_add_tail(thread-list, actor_list);
+ log_debug(7, thread %08lx now in actor_list,
+ (long)thread);
}
}
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 4/7] actor: Remove ACTOR_TICKS_10MS()
From: Adam Jackson a...@redhat.com
Again, just obfuscation.
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/usr/actor.c b/usr/actor.c
index 9c2f449..e4e8a24 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -38,7 +38,6 @@ static volatile uint64_t actor_jiffies = 0;
__ret; \
})
-#define ACTOR_TICKS_10MS(_a) (_a)
#define ACTOR_MS_TO_TICKS(_a) ((_a)/ACTOR_RESOLUTION)
static uint64_t
@@ -246,8 +245,7 @@ actor_poll(void)
current_time = actor_jiffies;
scheduler_loops = 0;
/* checking whether we are in the same tick... */
- if ( ACTOR_TICKS_10MS(current_time) !=
-ACTOR_TICKS_10MS(previous_time)) {
+ if (current_time != previous_time) {
previous_time = current_time;
actor_check(current_time);
}
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
iscsid: stop 250ms actor poll when idle
iscsid doesn't need to wake up every 250ms, we can drive the polling of the actor callbacks only when they are needed. Passing on the prep patches as they were sent to me by Adam Jackson, but I've reworked the final event loop changes to keep the time keeping for scheduled actors from falling apart. -- 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+unsubscr...@googlegroups.com. To post to this group, send email to open-iscsi@googlegroups.com. Visit this group at http://groups.google.com/group/open-iscsi?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 3/7] actor: s/ACTOR_TICKS/actor_jiffies/
From: Adam Jackson a...@redhat.com
No reason to obscure this.
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/usr/actor.c b/usr/actor.c
index fb90924..9c2f449 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -38,7 +38,6 @@ static volatile uint64_t actor_jiffies = 0;
__ret; \
})
-#define ACTOR_TICKSactor_jiffies
#define ACTOR_TICKS_10MS(_a) (_a)
#define ACTOR_MS_TO_TICKS(_a) ((_a)/ACTOR_RESOLUTION)
@@ -96,7 +95,7 @@ actor_schedule_private(actor_t *thread, uint32_t ttschedule,
int head)
actor_t *next_thread;
delay_time = ACTOR_MS_TO_TICKS(ttschedule);
- current_time = ACTOR_TICKS;
+ current_time = actor_jiffies;
log_debug(7, thread %p schedule: delay % PRIu64 state %d,
thread, delay_time, thread-state);
@@ -244,7 +243,7 @@ actor_poll(void)
* if new time is not same as old time */
if (scheduler_loops++ ACTOR_MAX_LOOPS) {
/* try coming in about every 100 msecs */
- current_time = ACTOR_TICKS;
+ current_time = actor_jiffies;
scheduler_loops = 0;
/* checking whether we are in the same tick... */
if ( ACTOR_TICKS_10MS(current_time) !=
@@ -285,5 +284,5 @@ actor_poll(void)
(long)thread);
}
- ACTOR_TICKS++;
+ actor_jiffies++;
}
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 6/7] actor: Simplify actor_poll a little
From: Adam Jackson a...@redhat.com
Finally, a functionality change. Having expanded ACTOR_MAX_LOOPS it's
now obvious that we were basically only doing actor_check() on every
other call. Also, the commentary is just wrong on many levels, we'd
only get called about every 250ms anyway.
Just call actor_check every time, might as well.
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 20 ++--
1 file changed, 2 insertions(+), 18 deletions(-)
diff --git a/usr/actor.c b/usr/actor.c
index c084176..7f93e76 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -24,8 +24,6 @@
static LIST_HEAD(pend_list);
static LIST_HEAD(poll_list);
static LIST_HEAD(actor_list);
-static volatile uint64_t previous_time;
-static volatile uint32_t scheduler_loops;
static volatile int poll_in_progress;
static volatile uint64_t actor_jiffies = 0;
@@ -56,8 +54,6 @@ void
actor_init(void)
{
poll_in_progress = 0;
- previous_time = 0;
- scheduler_loops = 0;
}
void
@@ -229,7 +225,6 @@ actor_check(uint64_t current_time)
void
actor_poll(void)
{
- uint64_t current_time;
struct actor *thread;
/* check that there are no any concurrency */
@@ -237,19 +232,8 @@ actor_poll(void)
log_error(concurrent actor_poll() is not allowed);
}
- /* don't check wait list every single poll.
-* get new time. Shift it to make 10s of msecs approx
-* if new time is not same as old time */
- if (scheduler_loops++ 1) {
- /* try coming in about every 100 msecs */
- current_time = actor_jiffies;
- scheduler_loops = 0;
- /* checking whether we are in the same tick... */
- if (current_time != previous_time) {
- previous_time = current_time;
- actor_check(current_time);
- }
- }
+ /* check the wait list */
+ actor_check(actor_jiffies);
/* the following code to check in the main data path */
poll_in_progress = 1;
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 7/7] actor: Don't wake up poll() on a timeout if we don't need to
Have actor_poll take an indication from the outer event loop of how many
ticks of ACTOR_RESOLUTION have passed, and return how many ticks into
the future it would like to be called again.
Then in event_loop, try and keep the poll timeouts as long as possible
without delaying actors or screwing up their timeouts too badly.
First draft sent to me by Adam Jackson, but I've reworked everything
except the actor_check changes considerably so blame me.
Bugzilla: https://bugzilla.redhat.com/458213
Cc: Adam Jackson a...@redhat.com
Signed-off-by: Chris Leech cle...@redhat.com
---
usr/Makefile | 4 ++--
usr/actor.c | 23 ---
usr/actor.h | 2 +-
usr/event_poll.c | 42 ++
4 files changed, 57 insertions(+), 14 deletions(-)
diff --git a/usr/Makefile b/usr/Makefile
index 3d8ee22..550fdff 100644
--- a/usr/Makefile
+++ b/usr/Makefile
@@ -55,14 +55,14 @@ all: $(PROGRAMS)
iscsid: $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(DISCOVERY_SRCS) \
iscsid.o session_mgmt.o discoveryd.o
- $(CC) $(CFLAGS) $^ -o $@ -L../utils/open-isns -lisns
+ $(CC) $(CFLAGS) $^ -o $@ -L../utils/open-isns -lisns -lrt
iscsiadm: $(ISCSI_LIB_SRCS) $(DISCOVERY_SRCS) iscsiadm.o session_mgmt.o
$(CC) $(CFLAGS) $^ -o $@ -L../utils/open-isns -lisns
iscsistart: $(ISCSI_LIB_SRCS) $(INITIATOR_SRCS) $(FW_BOOT_SRCS) \
iscsistart.o statics.o
- $(CC) $(CFLAGS) -static $^ -o $@
+ $(CC) $(CFLAGS) -static $^ -o $@ -lrt
clean:
rm -f *.o $(PROGRAMS) .depend $(LIBSYS)
diff --git a/usr/actor.c b/usr/actor.c
index 7f93e76..3685a41 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -193,17 +193,18 @@ actor_timer_mod(actor_t *thread, uint32_t timeout, void
*data)
return 0;
}
-static void
+static uint64_t
actor_check(uint64_t current_time)
{
struct actor *thread, *tmp;
+ uint64_t ret;
list_for_each_entry_safe(thread, tmp, pend_list, list) {
- if (actor_diff_time(thread, current_time)) {
+ if ((ret = actor_diff_time(thread, current_time))) {
log_debug(7, thread %08lx wait some more,
(long)thread);
/* wait some more */
- break;
+ return ret;
}
/* it is time to schedule this entry */
@@ -220,12 +221,17 @@ actor_check(uint64_t current_time)
log_debug(7, thread %08lx now in actor_list,
(long)thread);
}
+
+ return -1LL;
}
-void
-actor_poll(void)
+uint64_t
+actor_poll(uint64_t ticks_expired)
{
struct actor *thread;
+ uint64_t ticks_to_wait;
+
+ actor_jiffies += ticks_expired;
/* check that there are no any concurrency */
if (poll_in_progress) {
@@ -233,7 +239,7 @@ actor_poll(void)
}
/* check the wait list */
- actor_check(actor_jiffies);
+ ticks_to_wait = actor_check(actor_jiffies);
/* the following code to check in the main data path */
poll_in_progress = 1;
@@ -252,6 +258,9 @@ actor_poll(void)
}
poll_in_progress = 0;
+ if (!list_empty(poll_list))
+ ticks_to_wait = 1;
+
while (!list_empty(poll_list)) {
thread = list_entry(poll_list.next, struct actor, list);
list_del_init(thread-list);
@@ -266,5 +275,5 @@ actor_poll(void)
(long)thread);
}
- actor_jiffies++;
+ return ticks_to_wait;
}
diff --git a/usr/actor.h b/usr/actor.h
index 4c1ae60..eb624ed 100644
--- a/usr/actor.h
+++ b/usr/actor.h
@@ -48,7 +48,7 @@ extern void actor_schedule(actor_t *thread);
extern void actor_timer(actor_t *thread, uint32_t timeout,
void (*callback)(void *), void *data);
extern int actor_timer_mod(actor_t *thread, uint32_t new_timeout, void *data);
-extern void actor_poll(void);
+extern uint64_t actor_poll(uint64_t ticks_expired);
extern void actor_init(void);
#endif /* ACTOR_H */
diff --git a/usr/event_poll.c b/usr/event_poll.c
index f36fec1..dcbb79a 100644
--- a/usr/event_poll.c
+++ b/usr/event_poll.c
@@ -121,17 +121,37 @@ static int shutdown_wait_pids(void)
static int event_loop_stop;
static queue_task_t *shutdown_qtask;
-
void event_loop_exit(queue_task_t *qtask)
{
shutdown_qtask = qtask;
event_loop_stop = 1;
}
+#include time.h
+
+uint64_t elapsed_ticks(struct timespec *start, struct timespec *end)
+{
+ struct timespec elapsed;
+
+ if ((end-tv_nsec - start-tv_nsec) 0) {
+ elapsed.tv_sec = end-tv_sec - start-tv_sec - 1;
+ elapsed.tv_nsec = 10 + end-tv_nsec - start-tv_nsec;
+ } else{
+ elapsed.tv_sec = end-tv_sec - start-tv_sec;
+ elapsed.tv_nsec = end-tv_nsec - start-tv_nsec;
+ }
+ return (elapsed.tv_sec * (1000 / ACTOR_RESOLUTION))
[PATCH 5/7] actor: Unobfuscate ACTOR_MAX_LOOPS
From: Adam Jackson a...@redhat.com
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 2 +-
usr/actor.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/usr/actor.c b/usr/actor.c
index e4e8a24..c084176 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -240,7 +240,7 @@ actor_poll(void)
/* don't check wait list every single poll.
* get new time. Shift it to make 10s of msecs approx
* if new time is not same as old time */
- if (scheduler_loops++ ACTOR_MAX_LOOPS) {
+ if (scheduler_loops++ 1) {
/* try coming in about every 100 msecs */
current_time = actor_jiffies;
scheduler_loops = 0;
diff --git a/usr/actor.h b/usr/actor.h
index 704224d..4c1ae60 100644
--- a/usr/actor.h
+++ b/usr/actor.h
@@ -23,7 +23,6 @@
#include list.h
#define ACTOR_RESOLUTION 250 /* in millis */
-#define ACTOR_MAX_LOOPS1
typedef enum actor_state_e {
ACTOR_INVALID,
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
[PATCH 1/7] actor: Mark actor_check static
From: Adam Jackson a...@redhat.com
Signed-off-by: Adam Jackson a...@redhat.com
---
usr/actor.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/usr/actor.c b/usr/actor.c
index b8f8e61..880bf81 100644
--- a/usr/actor.c
+++ b/usr/actor.c
@@ -199,7 +199,7 @@ actor_timer_mod(actor_t *thread, uint32_t timeout, void
*data)
return 0;
}
-void
+static void
actor_check(uint64_t current_time)
{
struct actor *thread, *tmp;
--
1.8.1.4
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
