Re: [PATCH] scsi: iscsi: fix stop connection cocurrency issue

[michael . christie]

On 7/4/23 6:15 AM, lihongweizz wrote:
> From: Rock Li 
> 
> We met a crash issue when iscsi connection was not stable:
> [ 5581.778976]  connection929:0: detected conn error (1020)
> [ 5592.539182] scsi host17: iSCSI Initiator over TCP/IP
> [ 5592.548847]  connection930:0: detected conn error (1020)
> [ 5592.548890] BUG: unable to handle kernel NULL pointer dereference at 
> 0020
> [ 5592.548935] PGD 0
> [ 5592.548947] Oops:  [#1] SNP NOPTI
> [ 5592.548966] CPU: 51 PID: 912890 Comm: kworker/u161:2 Kdump: loaded 
> Tainted: G OE - xx #1
> [ 5592.549022] Hardware name: xx
> [ 5592.549053] Workqueue: iscsi_conn_cleanup 
> scsi_cleanup_conn_work_fn[scsi_transport_iscsi]
> [ 5592.549098] RIP: 0010:iscsi_sw_tcp_release_conn+0x54/0x110[iscsi_tcp]
> [ 5592.549130] Code: fb be 02 00 00 00 48 89 0f e8 88 65 8b c9 48 8b 45 20 f0 
> ff 80 80 00 00 00 0f 88 e3 06 00 00 48 8b 43 08 4c 8b 70 08 49 8b 06 <48> 8b 
> 58 20 4c 8d bb 30 02 00 00 4c 89 ff e8 49 75 as c9 4c 89 ff
> [ 5592.549209] RSP: 0018:ff6937f4283e7e00 EFLAGS: 00010202
> [ 5592.549233] RAX:  RBX: ff347b03a4a4b478 RCX: 
> 
> [ 5592.549265] RDX:  RSI: fe0l RDI: 
> 8a2bc977
> [ 5592.549296] RBP: ff347b063d49d600 R08: ff347b20bffeb878 R09: 
> 03e8
> [ 5592.549327] R10:  R11: ff347b20bffe9b44 R12: 
> ff347b03a4a4b7a8
> [ 5592.549358] R13: ff347b03a4a4e610 R14: ff347b03a4a4b7a8 R15: 
> ff347b03a4a4b068
> [ 5592.549389] FS: () Gs:ff347b20bffc() 
> knlGs:
> [ 5592.549424] CS: 0010 DS:  ES:  CR0: 80050033
> [ 5592.549446] CR2: 0020 CR3: 003a22610005 CR4: 
> 00773ee0
> [ 5592.549469] DR0:  DR1:  DR2: 
> 
> [ 5592.549491] DR3:  DR6: fffe0ff0 DR7: 
> 0400
> [ 5592.549510] PKRU: 5554
> [ 5592.549518] Call Trace:
> [ 5592.549528]  iscsi_sw_tcp_conn_stop+0x5d/0x80 [iscsi_tcp]
> [ 5592.549546]  iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi]
> [ 5592.549568]  iscsi_cleanup_conn_workin+0x6e/0xbe [scsi_transport_iscsi]
> 
> After digging the vmcore file, a concurrency scenario was found:
>   
> iscsi_if_rx iscsi_sw_tcp_state_change
>   iscsi_if_recv_msg   iscsi_sw_sk_state_check
> iscsi_if_stop_conn  iscsi_conn_failure
>   cancel_work_sync(iscsi_conn_error_event
> >cleanup_work)
>  queue_work(
>>cleanup_work)
>   iscsi_stop_conn<- Excute cocurrenty -->  iscsi_stop_conn
> 
> iscsi_stop_conn will be excuted cocurrently in different paths.
> Fix this issue by leveraging ep_mutex to protect iscsi_stop_conn.
> 
> Signed-off-by: Rock Li 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index b9b97300e3b3..1da1083509b6 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -2307,7 +2307,16 @@ static int iscsi_if_stop_conn(struct iscsi_cls_conn 
> *conn, int flag)
>*/
>   if (flag == STOP_CONN_TERM) {
>   cancel_work_sync(>cleanup_work);
> +
> + /* There is a race window between cancel clean_work and
> +  * connection stopped. Socket down event may queue clean up
> +  * work again before connection stopped which will result
> +  * stop connection cocurrency issue. Avoid this issue
> +  * by leveraging ep_mutex
> +  */
> + mutex_lock(>ep_mutex);
>   iscsi_stop_conn(conn, flag);
> + mutex_unlock(>ep_mutex);
>   } else {
>   /*
>* Figure out if it was the kernel or userspace initiating this.


Thanks for the patch and nice debugging.

The patch will avoid the crash, but if we are calling iscsi_if_stop_conn to 
terminate
the connection (flag == STOP_CONN_TERM) then we don't want to leave the work 
queued
because it will overwrite the state we just set. Later it could cause problems 
because
we should be in a terminated state, but think we are in recovery so we might go 
down
different paths and not clean everything up.

How about the patch below?

diff --git a/drivers/scsi/scsi_transport_iscsi.c 
b/drivers/scsi/scsi_transport_iscsi.c
index e527ece12453..960af1cba267 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -2290,6 +2290,8 @@ static void iscsi_if_disconnect_bound_ep(struct 
iscsi_cls_conn *conn,
 
 static int iscsi_if_stop_conn(struct iscsi_cls_conn *conn, int flag)
 {
+   bool do_stop;
+
ISCSI_DBG_TRANS_CONN(conn, "iscsi if conn stop.\n");
/*
 * For offload, iscsid may not know about the ep like when iscsid is
@@ 

Re: [PATCH 11/11] iscsi: force destroy sesions when a network namespace exits

[michael . christie]

On 5/10/23 1:09 PM, michael.chris...@oracle.com wrote:
> On 5/6/23 4:29 PM, Chris Leech wrote:
>> The namespace is gone, so there is no userspace to clean up.
>> Force close all the sessions.
>>
>> This should be enough for software transports, there's no implementation
>> of migrating physical iSCSI hosts between network namespaces currently.
>>
>> Reviewed-by: Hannes Reinecke 
>> Signed-off-by: Chris Leech 
>> ---
>>  drivers/scsi/scsi_transport_iscsi.c | 16 
>>  1 file changed, 16 insertions(+)
>>
>> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
>> b/drivers/scsi/scsi_transport_iscsi.c
>> index 15d28186996d..10e9414844d8 100644
>> --- a/drivers/scsi/scsi_transport_iscsi.c
>> +++ b/drivers/scsi/scsi_transport_iscsi.c
>> @@ -5235,9 +5235,25 @@ static int __net_init iscsi_net_init(struct net *net)
>>  
>>  static void __net_exit iscsi_net_exit(struct net *net)
>>  {
>> +struct iscsi_cls_session *session, *tmp;
>>  struct iscsi_net *isn;
>> +unsigned long flags;
>> +LIST_HEAD(sessions);
>>  
>>  isn = net_generic(net, iscsi_net_id);
>> +
>> +spin_lock_irqsave(>sesslock, flags);
>> +list_replace_init(>sesslist, );
>> +spin_unlock_irqrestore(>sesslock, flags);
>> +
>> +/* force session destruction, there is no userspace anymore */
>> +list_for_each_entry_safe(session, tmp, , sess_list) {
>> +device_for_each_child(>dev, NULL,
>> +  iscsi_iter_force_destroy_conn_fn);
>> +flush_work(>destroy_work);
> 
> I think if this flush_work actually flushed, then we would be doing a use
> after free because the running work would free the session from under us.
> 
> We should never have a running destroy_work and be ale to see it on the 
> sesslist
> right? Maybe a WARN_ON or something else so it doesn't look like a possible
> bug.

Maybe not a WARN_ON. What happens if there is running destroy_works for this
namespace and we return from this function?

> 
> 
>> +__iscsi_destroy_session(>destroy_work);
>> +}
>> +
>>  netlink_kernel_release(isn->nls);
>>  isn->nls = NULL;
>>  }
> 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/2059dc74-a00b-fd53-f5ce-3dd41bfbf4f1%40oracle.com.

Re: [PATCH 11/11] iscsi: force destroy sesions when a network namespace exits

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> The namespace is gone, so there is no userspace to clean up.
> Force close all the sessions.
> 
> This should be enough for software transports, there's no implementation
> of migrating physical iSCSI hosts between network namespaces currently.
> 
> Reviewed-by: Hannes Reinecke 
> Signed-off-by: Chris Leech 
> ---
>  drivers/scsi/scsi_transport_iscsi.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index 15d28186996d..10e9414844d8 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -5235,9 +5235,25 @@ static int __net_init iscsi_net_init(struct net *net)
>  
>  static void __net_exit iscsi_net_exit(struct net *net)
>  {
> + struct iscsi_cls_session *session, *tmp;
>   struct iscsi_net *isn;
> + unsigned long flags;
> + LIST_HEAD(sessions);
>  
>   isn = net_generic(net, iscsi_net_id);
> +
> + spin_lock_irqsave(>sesslock, flags);
> + list_replace_init(>sesslist, );
> + spin_unlock_irqrestore(>sesslock, flags);
> +
> + /* force session destruction, there is no userspace anymore */
> + list_for_each_entry_safe(session, tmp, , sess_list) {
> + device_for_each_child(>dev, NULL,
> +   iscsi_iter_force_destroy_conn_fn);
> + flush_work(>destroy_work);

I think if this flush_work actually flushed, then we would be doing a use
after free because the running work would free the session from under us.

We should never have a running destroy_work and be ale to see it on the sesslist
right? Maybe a WARN_ON or something else so it doesn't look like a possible
bug.


> + __iscsi_destroy_session(>destroy_work);
> + }
> +
>   netlink_kernel_release(isn->nls);
>   isn->nls = NULL;
>  }

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/6ea35c03-09b9-425d-ddcd-8cdbf99f4fe8%40oracle.com.

Re: [PATCH v2 00/11] Make iscsid-kernel communications namespace-aware

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> Note that with iscsi_tcp, the connected socket will keep the network
> namespace alive after container exit. The namespace will exit once the

What happens for iser? Is it the same?

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/02b582ed-8450-4352-d1b5-a68cde26ba80%40oracle.com.

Re: [PATCH 03/11] iscsi: sysfs filtering by network namespace

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> +#define DECLARE_TRANSPORT_CLASS_NS(cls, nm, su, rm, cfg, ns, nslookup)   
> \
> +struct transport_class cls = {   
> \
> + .class = {  \
> + .name = nm, \
> + .ns_type = ns,  \
> + .namespace = nslookup,  \
> + },  \
> + .setup = su,\
> + .remove = rm,   \
> + .configure = cfg,   \
> +}

I think this would be in the transport class for others to use in the future
and or you want to name it differently so it doesn't clash with the future
transport class naming. Same as other places in the patch.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/3604c700-3106-dfc6-d39b-5583775be029%40oracle.com.

Re: [PATCH 04/11] iscsi: make all iSCSI netlink multicast namespace aware

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> @@ -2857,11 +2859,17 @@ void iscsi_post_host_event(uint32_t host_no, struct 
> iscsi_transport *transport,
>  enum iscsi_host_event_code code, uint32_t data_size,
>  uint8_t *data)
>  {
> + struct Scsi_Host *shost;
> + struct net *net;
>   struct nlmsghdr *nlh;
>   struct sk_buff *skb;
>   struct iscsi_uevent *ev;
>   int len = nlmsg_total_size(sizeof(*ev) + data_size);
>  
> + shost = scsi_host_lookup(host_no);
> + if (!shost)
> + return;
> +
>   skb = alloc_skb(len, GFP_NOIO);
>   if (!skb) {

Need scsi_host_put. Maybe just grab the net and do the put before the alloc_skb.


>   printk(KERN_ERR "gracefully ignored host event (%d):%d OOM\n",
> @@ -2880,7 +2888,9 @@ void iscsi_post_host_event(uint32_t host_no, struct 
> iscsi_transport *transport,
>   if (data_size)
>   memcpy((char *)ev + sizeof(*ev), data, data_size);
>  
> - iscsi_multicast_skb(skb, ISCSI_NL_GRP_ISCSID, GFP_NOIO);
> + net = iscsi_host_net(shost->shost_data);
> + scsi_host_put(shost);
> + iscsi_multicast_skb(net, skb, ISCSI_NL_GRP_ISCSID, GFP_NOIO);
>  }
>  EXPORT_SYMBOL_GPL(iscsi_post_host_event);
>  
> @@ -2888,11 +2898,17 @@ void iscsi_ping_comp_event(uint32_t host_no, struct 
> iscsi_transport *transport,
>  uint32_t status, uint32_t pid, uint32_t data_size,
>  uint8_t *data)
>  {
> + struct Scsi_Host *shost;
> + struct net *net;
>   struct nlmsghdr *nlh;
>   struct sk_buff *skb;
>   struct iscsi_uevent *ev;
>   int len = nlmsg_total_size(sizeof(*ev) + data_size);
>  
> + shost = scsi_host_lookup(host_no);
> + if (!shost)
> + return;
> +
>   skb = alloc_skb(len, GFP_NOIO);
>   if (!skb) {

Same as above.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/56fad7cf-1bf4-82a1-2acc-53a5fc7f9c70%40oracle.com.

Re: [PATCH 06/11] iscsi: set netns for tcp and iser hosts

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> @@ -656,6 +646,8 @@ iscsi_iser_session_create(struct iscsi_endpoint *ep,
>   if (!(ib_dev->attrs.kernel_cap_flags & IBK_SG_GAPS_REG))
>   shost->virt_boundary_mask = SZ_4K - 1;
>  
> + iscsi_host_set_netns(shost, ep->netns);
> +
>   if (iscsi_host_add(shost, ib_dev->dev.parent)) {
>   mutex_unlock(_conn->state_mutex);
>   goto free_host;
> @@ -663,6 +655,7 @@ iscsi_iser_session_create(struct iscsi_endpoint *ep,
>   mutex_unlock(_conn->state_mutex);
>   } else {
>   shost->can_queue = min_t(u16, cmds_max, ISER_DEF_XMIT_CMDS_MAX);
> + iscsi_host_set_netns(shost, net);

Just a nit, but use a consistent coding style. Do you like newlines before/after
like above or not like here.

>   if (iscsi_host_add(shost, NULL))
>   goto free_host;
>   }
> @@ -694,6 +687,34 @@ iscsi_iser_session_create(struct iscsi_endpoint *ep,
>   return NULL;
>  }
>  
> +/**
> + * iscsi_iser_session_create() - create an iscsi-iser session
> + * @ep: iscsi end-point handle
> + * @cmds_max:   maximum commands in this session
> + * @qdepth: session command queue depth
> + * @initial_cmdsn:  initiator command sequnce number
> + *
> + * Allocates and adds a scsi host, expose DIF support if
> + * exists, and sets up an iscsi session.

Maybe you want these comments for __iscsi_iser_session_create so you can
describe the ep vs a net args. Or it's just odd to have it for only the
ep function.


> @@ -3106,14 +3128,21 @@ static int
>  iscsi_if_create_session(struct iscsi_internal *priv, struct iscsi_endpoint 
> *ep,
>   struct iscsi_uevent *ev, pid_t pid,
>   uint32_t initial_cmdsn, uint16_t cmds_max,
> - uint16_t queue_depth)
> + uint16_t queue_depth, struct net *net)
>  {
>   struct iscsi_transport *transport = priv->iscsi_transport;
>   struct iscsi_cls_session *session;
>   struct Scsi_Host *shost;
>  
> - session = transport->create_session(ep, cmds_max, queue_depth,
> - initial_cmdsn);
> + if (ep) {
> + session = transport->create_session(ep, cmds_max, queue_depth,
> + initial_cmdsn);
> + } else {
> + session = transport->create_session_net(net, cmds_max,
> + queue_depth,
> + initial_cmdsn);
> + }


No {}s are neede here and above. It will also match the other code you
adding.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/29152592-ac41-546d-aeb6-867c6de2c860%40oracle.com.

Re: [PATCH 07/11] iscsi: convert flashnode devices from bus to class

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> From: Lee Duncan 
> 
> The flashnode session and connection devices should be filtered by net
> namespace along with the iscsi_host, but we can't do that with a bus
> device.  As these don't use any of the bus matching functionality, they
> make more sense as a class device anyway.
> 

Will offload always use the default namespace? If so, there's no need to
touch this code right?

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/2a771482-b582-246f-6921-afa1832d7dc0%40oracle.com.

Re: [PATCH 10/11] iscsi: make session and connection lists per-net

[michael . christie]

On 5/6/23 4:29 PM, Chris Leech wrote:
> diff --git a/drivers/scsi/scsi_transport_iscsi.c 
> b/drivers/scsi/scsi_transport_iscsi.c
> index cd3228293a64..15d28186996d 100644
> --- a/drivers/scsi/scsi_transport_iscsi.c
> +++ b/drivers/scsi/scsi_transport_iscsi.c
> @@ -1755,17 +1755,16 @@ static 
> DECLARE_TRANSPORT_CLASS_NS(iscsi_connection_class,
>  
>  struct iscsi_net {
>   struct sock *nls;
> + spinlock_t sesslock;
> + struct list_head sesslist;
> + spinlock_t connlock;
> + struct list_head connlist;

Instead of lists use an xarray. That was actually one of the TODO items from
Lee's talk last year on lots of sessions. You can kill that and do iscsi ns at
the same time :)


> + struct list_head connlist_err;
>  };

connlist_err is not used so you can kill it.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/7435f1b2-a5d6-4189-6153-0c18889e9440%40oracle.com.

Re: [PATCH] recovery: remove onlining of devices via sysfs

[michael . christie]

On 8/29/22 9:21 PM, michael.chris...@oracle.com wrote:
> On 8/29/22 4:51 PM, Uday Shankar wrote:
>>> So we could just add a CAP_SCSI_EH_TRANSPORT OFFLINE flag to
>>> the iscsi_transport->caps struct. When userspace sees that then
>>> it knows the kernel will now do the right thing.
>>>
>>> The drawback is that we have to patch userspace and then also
>>> get the the new CAP_SCSI_EH_TRANSPORT_OFFLINE patch in the stable
>>> kernels.
>>
>> Another drawback of this approach is that we are covering up a bug in
>> the kernel, which is still possible to hit if someone/something besides

Oh yeah, I don't think the list of programs that can hit this problem
is very long. It's a iscsi only problem right? So there's open-iscsi,
some boot tool in go, and google's tools that we know of. I think only
open-iscsi will have the problem too.

You won't hit it in other transports because only iscsid tries to online
the device from userspace from the same thread that is needed to relogin
and unblock a device. FC/SAS/SRP don't have the same problem since they
do the block and unblock from kernel workqueues which will run independently
from some userspace thread writing to sysfs.

Or, is there other ways to hit this that you are seeing? If there are
then forget what I wrote in the last mail :)

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/e5f7ba9f-8268-c0bd-7a60-f702157ab6a7%40oracle.com.

Re: [PATCH] recovery: remove onlining of devices via sysfs

[michael . christie]

On 8/29/22 4:51 PM, Uday Shankar wrote:
>> So we could just add a CAP_SCSI_EH_TRANSPORT OFFLINE flag to
>> the iscsi_transport->caps struct. When userspace sees that then
>> it knows the kernel will now do the right thing.
>>
>> The drawback is that we have to patch userspace and then also
>> get the the new CAP_SCSI_EH_TRANSPORT_OFFLINE patch in the stable
>> kernels.
> 
> Another drawback of this approach is that we are covering up a bug in
> the kernel, which is still possible to hit if someone/something besides

I'm still not sure if it's a bug in the kernel or not. I've been thinking
it's not a kernel bug.

Maybe it depends on if you feel there was a guarantee that writing to
that file was non-blocking. If so, then yeah I think it's a kernel bug
that we now do all this new work from that call. I don't think there is
anything that documents the behavior for that sysfs file though.

If there was no guarantee, then I think it's an issue with our design
where we assumed it was non-blocking from reading the kernel code and
thinking that was always going to be the case. If writing to that file
is allowed to block, then our design is wrong since we can't be sleeping
in that main thread.


> iscsid decides to write to the sysfs state field at the unlucky timing.
> Not sure how much we care about this. If it's considered a non-issue,
> then I'll put together the change you described and send it to
> linux-scsi as well.
> 
> Thanks,
> Uday

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/9c5a4232-5933-35c7-ac5d-745138de49a9%40oracle.com.

Re: [PATCH] recovery: remove onlining of devices via sysfs

[Michael Christie]

The kernel's call to unblock devices is only for setting devices to online if 
they are in the transport-offline state. It doesn't do anything if the scsi-eh 
set them to offline. The user space online code in your patch handles the 
scsi-eh case.

I hit the hang below and it should be fixed in this set:

https://lore.kernel.org/all/20211105221048.6541-1-michael.chris...@oracle.com/




From: Uday Shankar 
Sent: Tuesday, August 23, 2022 2:32 PM
To: open-iscsi@googlegroups.com 
Cc: Lee Duncan ; Chris Leech ; Michael 
Christie 
Subject: Re: [PATCH] recovery: remove onlining of devices via sysfs

Bump and CC maintainers.

On Thu, Aug 11, 2022 at 05:40:30PM -0600, Uday Shankar wrote:
> In setup_full_feature_phase, iscsid calls into the kernel via
> start_conn, then sets all the relevant device states to "running" via
> session_online_devs. This second step is redundant since start_conn will
> set the device states to running. Moreover, it can cause tasks to hang
> forever: between start_conn and session_online_devs, the kernel could
> detect another conn error and block the session again, which quiesces
> the device queues. Setting the device state to "running" via sysfs kicks
> off a rescan, and if the device queue is quiesced, the rescan will hang.
> The iscsid kernel stacktrace looks like the following:
>
> [<0>] blk_execute_rq+0x11c/0x170
> [<0>] __scsi_execute+0x108/0x270
> [<0>] scsi_vpd_inquiry+0x6d/0xc0
> [<0>] scsi_get_vpd_size+0x33/0x70
> [<0>] scsi_get_vpd_buf+0x25/0xb0
> [<0>] scsi_attach_vpd+0x33/0x1a0
> [<0>] scsi_rescan_device+0x2a/0x90
> [<0>] store_state_field+0x1b0/0x250
> [<0>] kernfs_fop_write_iter+0x130/0x1c0
> [<0>] new_sync_write+0x10c/0x190
> [<0>] vfs_write+0x218/0x2a0
> [<0>] ksys_write+0x59/0xd0
> [<0>] do_syscall_64+0x3a/0x80
> [<0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
>
> Since iscsid is responsible for recovery from the second conn error but
> it is stuck, the relevant device queues will remain quiesced forever.
> Tasks attempting I/O on these queues will thus also get stuck.
>
> For these two reasons, remove the call to session_online_devs in
> setup_full_feature_phase.
>
> Signed-off-by: Uday Shankar 
> ---
>  usr/initiator.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/usr/initiator.c b/usr/initiator.c
> index 56bf38b..6cbdcba 100644
> --- a/usr/initiator.c
> +++ b/usr/initiator.c
> @@ -1068,7 +1068,6 @@ setup_full_feature_phase(iscsi_conn_t *conn)
>} else {
>session->notify_qtask = NULL;
>
> - session_online_devs(session->hostno, session->id);
>mgmt_ipc_write_rsp(c->qtask, ISCSI_SUCCESS);
>log_warning("connection%d:%d is operational after recovery "
>"(%d attempts)", session->id, conn->id,
> --
> 2.25.1
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/DM5PR10MB14666AEF8ED8B55B35310917F1739%40DM5PR10MB1466.namprd10.prod.outlook.com.

Re: [PATCH] drivers: scsi: Directly use ida_alloc()/free()

[michael . christie]

On 5/27/22 3:30 AM, keliu wrote:
> Use ida_alloc()/ida_free() instead of deprecated
> ida_simple_get()/ida_simple_remove() .
> 
> Signed-off-by: keliu 
> ---
>  drivers/scsi/hosts.c| 4 ++--
>  drivers/scsi/scsi_transport_iscsi.c | 6 +++---
>  2 files changed, 5 insertions(+), 5 deletions(-)
> 

Reviewed-by: Mike Christie 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/d115fd35-55fd-598f-1fd7-0e3d16da4301%40oracle.com.

Re: Question about iscsi session block

[michael . christie]

On 2/15/22 7:28 PM, Zhengyuan Liu wrote:
> On Wed, Feb 16, 2022 at 12:31 AM Mike Christie
>  wrote:
>>
>> On 2/15/22 9:49 AM, Zhengyuan Liu wrote:
>>> Hi, all
>>>
>>> We have an online server which uses multipath + iscsi to attach storage
>>> from Storage Server. There are two NICs on the server and for each it
>>> carries about 20 iscsi sessions and for each session it includes about 50
>>>  iscsi devices (yes, there are totally about 2*20*50=2000 iscsi block 
>>> devices
>>>  on the server). The problem is: once a NIC gets faulted, it will take too 
>>> long
>>> (nearly 80s) for multipath to switch to another good NIC link, because it
>>> needs to block all iscsi devices over that faulted NIC firstly. The 
>>> callstack is
>>>  shown below:
>>>
>>> void iscsi_block_session(struct iscsi_cls_session *session)
>>> {
>>> queue_work(iscsi_eh_timer_workq, >block_work);
>>> }
>>>
>>>  __iscsi_block_session() -> scsi_target_block() -> target_block() ->
>>>   device_block() ->  scsi_internal_device_block() -> scsi_stop_queue() ->
>>>  blk_mq_quiesce_queue()>synchronize_rcu()
>>>
>>> For all sessions and all devices, it was processed sequentially, and we have
>>> traced that for each synchronize_rcu() call it takes about 80ms, so
>>> the total cost
>>> is about 80s (80ms * 20 * 50). It's so long that the application can't
>>> tolerate and
>>> may interrupt service.
>>>
>>> So my question is that can we optimize the procedure to reduce the time 
>>> cost on
>>> blocking all iscsi devices?  I'm not sure if it is a good idea to increase 
>>> the
>>> workqueue's max_active of iscsi_eh_timer_workq to improve concurrency.
>>
>> We need a patch, so the unblock call waits/cancels/flushes the block call or
>> they could be running in parallel.
>>
>> I'll send a patchset later today so you can test it.
> 
> I'm glad to test once you push the patchset.
> 
> Thank you, Mike.

I forgot I did this recently :)

commit 7ce9fc5ecde0d8bd64c29baee6c5e3ce7074ec9a
Author: Mike Christie 
Date:   Tue May 25 13:18:09 2021 -0500

scsi: iscsi: Flush block work before unblock

We set the max_active iSCSI EH works to 1, so all work is going to execute
in order by default. However, userspace can now override this in sysfs. If
max_active > 1, we can end up with the block_work on CPU1 and
iscsi_unblock_session running the unblock_work on CPU2 and the session and
target/device state will end up out of sync with each other.

This adds a flush of the block_work in iscsi_unblock_session.


It was merged in 5.14.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/be26ef80-c3cf-713d-2a9f-4fb73cec7e17%40oracle.com.

Re: [PATCH] iscsi_tcp: fix the NULL pointer dereference

[michael . christie]

On 10/10/21 2:19 AM, Li Feng wrote:
>  drivers/scsi/iscsi_tcp.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 1bc37593c88f..2ec1405d272d 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -724,6 +724,8 @@ static int iscsi_sw_tcp_conn_set_param(struct 
> iscsi_cls_conn *cls_conn,
>   break;
>   case ISCSI_PARAM_DATADGST_EN:
>   iscsi_set_param(cls_conn, param, buf, buflen);
> + if (!tcp_sw_conn || !tcp_sw_conn->sock)
> + return -ENOTCONN;
>   tcp_sw_conn->sendpage = conn->datadgst_en ?
>   sock_no_sendpage : tcp_sw_conn->sock->ops->sendpage;
>   break;
> 

Hi,

Thanks for the patch. This was supposed to be fixed in:

commit 9e67600ed6b8565da4b85698ec659b5879a6c1c6
Author: Gulam Mohamed 
Date:   Thu Mar 25 09:32:48 2021 +

scsi: iscsi: Fix race condition between login and sync thread

because it was not supposed to allow set_param to be called on
an unbound connection. However, it looks like there was a mistake in
the patch:

err = transport->set_param(conn, ev->u.set_param.param,
   data, ev->u.set_param.len);
+   if ((conn->state == ISCSI_CONN_BOUND) ||
+   (conn->state == ISCSI_CONN_UP)) {
+   err = transport->set_param(conn, ev->u.set_param.param,
+   data, ev->u.set_param.len);
+   } else {
+   return -ENOTCONN;
+   }


and that first set_param call was supposed to be deleted and
replaced with the one that was added in the conn->state check.

We should just need a patch to remove that first set_param call.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/95db5f3d-99dd-ddbb-ea44-8cd37d92ce0f%40oracle.com.

Re: [PATCH V2] scsi: iscsi_tcp: Fix use-after-free when do get_host_param

[michael . christie]

On 3/21/21 1:47 AM, Wu Bo wrote:
> From: Wu Bo 
> 
> iscsid(cpu1): Logout of iscsi session, will do destroy session, 
> tcp_sw_host->session is not set to NULL before release the iscsi session.
> in the iscsi_sw_tcp_session_destroy(). 
> 
> iscsadm(cpu2): Get host parameters access to tcp_sw_host->session in the
> iscsi_sw_tcp_host_get_param(), tcp_sw_host->session is not NULL, 
> but pointed to a freed space.
> 
> Add ihost->lock and kref to protect the session,
> between get host parameters and destroy iscsi session. 
> 
> [29844.848044] sd 2:0:0:1: [sdj] Synchronizing SCSI cache
> [29844.923745] scsi 2:0:0:1: alua: Detached
> [29844.927840] 
> ==
> [29844.927861] BUG: KASAN: use-after-free in 
> iscsi_sw_tcp_host_get_param+0xf4/0x218 [iscsi_tcp]
> [29844.927864] Read of size 8 at addr 80002c0b8f68 by task iscsiadm/523945
> [29844.927871] CPU: 1 PID: 523945 Comm: iscsiadm Kdump: loaded Not tainted 
> 4.19.90.kasan.aarch64
> [29844.927873] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
> [29844.927875] Call trace:
> [29844.927884]  dump_backtrace+0x0/0x270
> [29844.927886]  show_stack+0x24/0x30
> [29844.927895]  dump_stack+0xc4/0x120
> [29844.927902]  print_address_description+0x68/0x278
> [29844.927904]  kasan_report+0x20c/0x338
> [29844.927906]  __asan_load8+0x88/0xb0
> [29844.927910]  iscsi_sw_tcp_host_get_param+0xf4/0x218 [iscsi_tcp]
> [29844.927932]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0x84/0xa0 
> [scsi_transport_iscsi]
> [29844.927938]  dev_attr_show+0x48/0x90
> [29844.927943]  sysfs_kf_seq_show+0x100/0x1e0
> [29844.927946]  kernfs_seq_show+0x88/0xa0
> [29844.927949]  seq_read+0x164/0x748
> [29844.927951]  kernfs_fop_read+0x204/0x308
> [29844.927956]  __vfs_read+0xd4/0x2d8
> [29844.927958]  vfs_read+0xa8/0x198
> [29844.927960]  ksys_read+0xd0/0x180
> [29844.927962]  __arm64_sys_read+0x4c/0x60
> [29844.927966]  el0_svc_common+0xa8/0x230
> [29844.927969]  el0_svc_handler+0xdc/0x138
> [29844.927971]  el0_svc+0x10/0x218
> 
> [29844.928063] Freed by task 53358:
> [29844.928066]  __kasan_slab_free+0x120/0x228
> [29844.928068]  kasan_slab_free+0x10/0x18
> [29844.928069]  kfree+0x98/0x278
> [29844.928083]  iscsi_session_release+0x84/0xa0 [scsi_transport_iscsi]
> [29844.928085]  device_release+0x4c/0x100
> [29844.928089]  kobject_put+0xc4/0x288
> [29844.928091]  put_device+0x24/0x30
> [29844.928105]  iscsi_free_session+0x60/0x70 [scsi_transport_iscsi]
> [29844.928112]  iscsi_session_teardown+0x134/0x158 [libiscsi]
> [29844.928116]  iscsi_sw_tcp_session_destroy+0x7c/0xd8 [iscsi_tcp]
> [29844.928129]  iscsi_if_rx+0x1538/0x1f00 [scsi_transport_iscsi]
> [29844.928131]  netlink_unicast+0x338/0x3c8
> [29844.928133]  netlink_sendmsg+0x51c/0x588
> [29844.928135]  sock_sendmsg+0x74/0x98
> [29844.928137]  ___sys_sendmsg+0x434/0x470
> [29844.928139]  __sys_sendmsg+0xd4/0x148
> [29844.928141]  __arm64_sys_sendmsg+0x50/0x60
> [29844.928143]  el0_svc_common+0xa8/0x230
> [29844.928146]  el0_svc_handler+0xdc/0x138
> [29844.928147]  el0_svc+0x10/0x218
> [29844.928148]
> [29844.928150] The buggy address belongs to the object at 
> 80002c0b8880#012 which belongs to the cache kmalloc-2048 of size 2048
> [29844.928153] The buggy address is located 1768 bytes inside of#012 
> 2048-byte region [80002c0b8880, 80002c0b9080)
> [29844.928154] The buggy address belongs to the page:
> [29844.928158] page:7eb02e00 count:1 mapcount:0 
> mapping:8000d8402600 index:0x0 compound_mapcount: 0
> [29844.928902] flags: 0x7fffe008100(slab|head)
> [29844.929215] raw: 07fffe008100 7e0003535e08 7e00024a9408 
> 8000d8402600
> [29844.929217] raw:  000f000f 0001 
> 
> [29844.929219] page dumped because: kasan: bad access detected
> [29844.929219]
> [29844.929221] Memory state around the buggy address:
> [29844.929223]  80002c0b8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [29844.929225]  80002c0b8e80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [29844.929227] >80002c0b8f00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [29844.929228]   ^
> [29844.929230]  80002c0b8f80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [29844.929232]  80002c0b9000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb 
> fb fb
> [29844.929232] 
> ==
> [29844.929234] Disabling lock debugging due to kernel taint
> [29844.969534] scsi host2: iSCSI Initiator over TCP/IP
> 
> Fixes: a79af8a64d39 ("[SCSI] iscsi_tcp: use iscsi_conn_get_addr_param 
> libiscsi function")
> Signed-off-by: Wu Bo 
> Signed-off-by: WenChao Hao 
> ---
>  drivers/scsi/iscsi_tcp.c | 23 +--
>  1 file changed, 21 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index 93ce990..579aa80 100644

Re: [PATCH] iscsi: Do Not set param when sock is NULL

[Michael Christie]

> On Nov 4, 2020, at 11:40 PM, Gulam Mohamed  wrote:
> 
> Description
> =
> 1. This Kernel panic could be due to a timing issue when there is a race 
> between the sync thread and the initiator was processing of a login response 
> from the target. The session re-open can be invoked from two places
>  a.   Sessions sync thread when the iscsid restart
>  b.   From iscsid through iscsi error handler
> 2. The session reopen sequence is as follows in user-space 
> (iscsi-initiator-utils)
>  a.   Disconnect the connection
>  b.   Then send the stop connection request to the kernel which 
> releases the connection (releases the socket)
>  c.   Queues the reopen for 2 seconds delay
> d.Once the delay expires, create the TCP connection again by 
> calling the connect() call
> e.Poll for the connection
>  f.   When poll is successful i.e when the TCP connection is 
> established, it performs
>   i. Creation of session and connection data structures
>   ii. Bind the connection to the session. This is the place where we 
> assign the sock to tcp_sw_conn->sock
>   iii. Sets the parameters like target name, persistent address etc .
>   iv. Creates the login pdu
>   v. Sends the login pdu to kernel
>   vi. Returns to the main loop to process further events. The kernel then 
> sends the login request over to the target node
>   g. Once login response with success is received, it enters into full 
> feature phase and sets the negotiable parameters like max_recv_data_length, 
> max_transmit_length, data_digest etc .
> 3. While setting the negotiable parameters by calling 
> "iscsi_session_set_neg_params()", kernel panicked as sock was NULL
> 
> What happened here is
> 
> 1.Before initiator received the login response mentioned in above point 
> 2.f.v, another reopen request was sent from the error handler/sync session 
> for the same session, as the initiator utils was in main loop to process 
> further events (as 
>   mentioned in point 2.f.vi above). 
> 2.While processing this reopen, it stopped the connection which released 
> the socket and queued this connection and at this point of time the login 
> response was received for the earlier one


To make sure I got this you are saying before iscsi_sw_tcp_conn_stop calls 
iscsi_sw_tcp_release_conn that the recv path has called iscsi_recv_pdu right?


> 3.The kernel passed over this response to user-space which then sent the 
> set_neg_params request to kernel
> 4.As the connection was stopped, the sock was NULL and hence while the 
> kernel was processing the set param request from user-space, it panicked
> 
> Fix
> 
> 1.While setting the set_param in kernel, we need to check if sock is NULL
> 2.If the sock is NULL, then return EPERM (operation not permitted)
> 3.Due to this error handler will be invoked in user-space again to 
> recover the session
> 
> Signed-off-by: Gulam Mohamed 
> Reviewed-by: Junxiao Bi 
> ---
> diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
> index df47557a02a3..fd668a194053 100644
> --- a/drivers/scsi/iscsi_tcp.c
> +++ b/drivers/scsi/iscsi_tcp.c
> @@ -711,6 +711,12 @@ static int iscsi_sw_tcp_conn_set_param(struct 
> iscsi_cls_conn *cls_conn,
>struct iscsi_tcp_conn *tcp_conn = conn->dd_data;
>struct iscsi_sw_tcp_conn *tcp_sw_conn = tcp_conn->dd_data;
> 
> +   if (!tcp_sw_conn->sock) {
> +   iscsi_conn_printk(KERN_ERR, conn,
> +   "Cannot set param as sock is NULL\n");
> +   return -ENOTCONN;
> +   }
> +

I think this might have 2 issues:

1. It only fixes iscsi_tcp. What about other drivers that free/null 
resources/fields in ep_disconnect that we layer need to access in the set_param 
callback (the cxgbi drivers)?

2. What about drivers that do not free/null fields (be2iscsi, bnx2i, ql4xxx and 
qedi) so the set_param calls end up just working. What state will userspace be 
in where we have logged in, but iscsid also thinks we are in the middle of 
trying to login?

I think we could do:

1. On ep_disconnect and stop_conn set some iscsi_cls_conn bit that indicates 
set_param calls for connection level settings should fail. scsi_transport_iscsi 
could set and check this bit for all drivers.
2. On bind_conn clear the bit.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/open-iscsi/05277786-2E1F-432D-AE73-F39565C6BEA4%40oracle.com.

Re: Performance issues when logging into a large number of targets

[Michael Christie]

Wait to test with Chris's patches. If he does not reply I will dig them up from 
the list. His fixes should provide the best boost and I think he was saying 
there are some other patches that are needed.

> On Jun 8, 2016, at 2:05 PM, Syed Mushtaq  wrote:
> 
> Thanks for the patch Mike. Will test it with this and let you know if I see 
> some improvement. And yes the gmon output is for iscsiadm and not iscsid. 
> 
> 
> -Syed
> 
>> On Wed, Jun 8, 2016 at 1:36 PM, Mike Christie  wrote:
>> Hey,
>> 
>> Chris Leech has been working on this problem. He has some patches which
>> help, but I do not see them. Chris?
>> 
>> I am also attaching a hacky patch to remove another problem source with
>> lots of targets. Could you run that with Chris's patches when he responds?
>> 
>> On 06/07/2016 02:24 PM, Syed Mushtaq wrote:
>> >
>> >
>> > I am attaching the gmon output here
>> >
>> 
>> This was taken on iscsiadm right? Not on iscsid?
>> 
>> --
>> You received this message because you are subscribed to a topic in the 
>> Google Groups "open-iscsi" group.
>> To unsubscribe from this topic, visit 
>> https://groups.google.com/d/topic/open-iscsi/XzT3IXcHlcs/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 https://groups.google.com/group/open-iscsi.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.

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

Re: login times when scaling out targets (Re: ISID uniqueness)

[Michael Christie]

> On Feb 9, 2016, at 8:53 PM, Chris Leech  wrote:
> 
> On Tue, Feb 09, 2016 at 03:24:04PM -0800, Chris Leech wrote:
>> But there may be more straightforward gains to be had in cleaning up the
>> sysfs code.  Every attribute read ends up in 
>> sysfs_lookup_devpath_by_subsys_id
>> which does a bunch of string ops and stats trying to find the device
>> path.  Even keeping the subsystem location general as it is, if we find
>> things once and remember the path for all the attribute reads it should
>> help a lot.
> 
> On the right track but that still wasn't exactly the big issue.
> It's the attribute cache.  It grows without bounds, and the lookup is
> just a linear walk through a linked list with a strcmp against each
> node.

Make sure to check if the udev sysfs code already fixed the issue. I had just 
grabbed that code a long time ago. Since then, they made a real lib, which we 
should look into using, and lots of other changes.

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

Re: login times when scaling out targets (Re: ISID uniqueness)

[Michael Christie]

> On Feb 4, 2016, at 7:00 PM, Chris Leech  wrote:
> 
> 
> So increasing the ISID space gets this working, but the described setup
> here (4 sessions x 256 targets) takes a _long_ time to connect to all
> the targets.  In a virtual setup I'm seeing up to 10 minutes, and with
> higher network latencies and busy targets I can imagine it being worse.
> 
> Just an FYI that I'm looking at it, as there seems to be a lot of
> overhead in repeatedly reading in sysfs data.  Both iscsiadm and iscsid
> spend most of their time in strcmp.  Once this many sessions are active,
> given an additional login command just counting them up to decide if
> more sessions are needed or not takes up to 5 seconds.
> 
> Hacking out the session counting and session_is_running checks drops the
> time from 9-10 minutes to about 30 seconds.  Not a solution, but maybe
> an good indication of where the problem is.


For the session_is_running checks, we do not really need to check sysfs. I 
originally did this because I was worried other tools would be creating 
sessions using some other tools or accessing netlink. This never happened - 
ignore the possible qla4xxx case for now. If someone is using their tool and 
ours then I think it is ok. It is not a big deal.

1. We can remove the 
__session_login_task->session_is_running->iscsi_sysfs_for_each_session->iscsi_match_session.
2. I think we can also remove the iscsi_check_for_running_session call from 
update_sessions when discoveryd is used. If we just do the 
iscsi_login_portal_nowait call, the normal session_login_task check will figure 
things out like normal.
3. The iscsiadm iscsi_check_for_running_session calls in verify_node_params, 
delete_node, and exec_iface_op are not issues right? They happen pretty rarely.

For the session counting checks, can we track the counts in iscsid too? If the 
login request put us over the limit, just fail it.


> 
> - Chris
> 
> On Thu, Jan 28, 2016 at 12:19:39PM -0800, shiva krishna merla wrote:
>> Hi All, 
>> 
>> We are seeing an issue with Redhat 6.7 where ISID's are repeated for 
>> different sessions to same target (volume level target). Our array target 
>> has to close the existing sessions with same ISID before accepting new 
>> connections. This causes repeated login retry attempts by iscsid and 
>> overall system discovery process is too slow. From the code i see that ISID 
>> is determined as below. With this many sessions above 256 can have repeated 
>> ISID. Is this a design flaw?. Can this be avoided?.
> 
> -- 
> 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 https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.

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

Re: iscsiadm didn't discovery the LUNs when LUN0 is removed

[Michael Christie]

> On Feb 3, 2016, at 1:11 PM, RenShu Xiao  wrote:
> 
> Hi 
> 
> in the target server, I have 2 luns in one host and I removed LUN0 and using 
> iscsiadm log in fine but the disks won't be discovered. Hence can't be 
> mounted.
> 
> The following listed the network trace. Target responded check condition for 
> LUN0 inquiry and expect report all from initiator.
> 
> Do we miss something here? or is this a known issue of open-iscsi?
> 

It’s not a iscsi or open-iscsi issue.

What target are you using? I do not think illegal request as a response to a 
inquiry to LUN 0 is normal return value. The linux scsi mid layer handles this 
by completely failing the scanning.


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

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

Re: ISID uniqueness

[Michael Christie]

> On Jan 29, 2016, at 4:50 PM, Chris Leech  wrote:
> 
> On Thu, Jan 28, 2016 at 06:11:28PM -0800, shiva krishna merla wrote:
>> Thanks Mike, Yes, we have one LUN per target and testing with large
>> number of LUN's. 100 - 1024. With this each LUN will have a volume
>> level target. I think the reason other vendors have not seen this
>> issue till now may be because they use single target multiple luns
>> model and will have least number of sessions per target.
> 
> I've sent a patch that should increase the used ISID space from 8 to 24
> bits. I'll continue to get additional testing on it.
> 
> But, I was also reading through the RFC 7143 about ISID use and from
> what I can tell isn't an Initiator Name + ISID pair only required to be
> unique within a single target portal group?  If you have many targets,
> or many portal groups, reuse of the same ISID should not be an error.

You are correct for non multipath use. We should never hit the problem.

For multiparth use we create N sessions to the same target port group. If the 
user does not specify a different initiator name (this is common when the user 
was just binding a session to a nic port), then we need your patch because the 
isid has to be unique.

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

Re: Do you prefer pull requests or patches submitted?

[Michael Christie]

> On Jan 15, 2016, at 1:49 PM, The Lee-Man  wrote:
> 
> Hi Mike:
> 
> I see you have taken some pull requests using the github issue/pull-request 
> mechanism. Do you prefer this over the mailing list? I know I kind of prefer 
> it, myself, from both directions, since it makes the workflow a touch easier 
> and faster. What's your preference?
> — 


Post patches to the list, so everyone can see them.

I try to only take github pull requests from non normal developers sending the 
single simple patch that does not require any review like doc stuff or simple 
cleanups.

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

Re: [PATCH 1/1] iscsi: fix regression caused by session lock patch

[Michael Christie]

> On Nov 15, 2015, at 4:10 AM, Or Gerlitz  wrote:
> 
> On Fri, Nov 13, 2015 at 6:51 PM, Mike Christie  wrote:
>> On 11/13/2015 09:06 AM, Or Gerlitz wrote:
 The patch has caused multiple regressions, did not even compile when
> sent to me, and was poorly reviewed and I have not heard from you guys
> in a week. Given the issues the patch has had and the current time, I do
> not feel comfortable with it anymore. I want to re-review it and fix it
> up when there is more time.
>>> Mike (Hi),
>>> 
>>> It's a complex patch that touches all the iscsi transports, and yes,
>>> when it was send to you the 1st time, there was build error on one of
>>> the offload transports (bad! but happens) and yes, as you pointed, one
>>> static checker fix + one bug fix for it went upstream after this has
>>> been merged, happens too.
>> 
>> A patch should not cause this many issues.
>> 
>>> What makes you say it was poorly reviewed?
>> 
>> I just did not do a good job at looking at the patch. I should have
>> caught all of these issues.
>> 
>> - The bnx2i cleanup_task bug should have been obvious, especially for me
>> because I had commented about the back lock and the abort path.
>> 
>> - This oops, was so basic. Incorrect locking around a linked list being
>> accessed from 2 threads is really one of those 1st year kernel
>> programmer things.
> 
> Mike, Chris
> 
> After the locking change, adding a task to any of the connection
> mgmtqueue, cmdqueue, or requeue lists is under the session forward lock.
> 
> Removing tasks from any of these lists in iscsi_data_xmit is under
> the session forward lock and **before** calling down to the transport
> to handle the task.
> 
> The iscsi_complete_task helper was added by Mike's commit
> 3bbaaad95fd38ded "[SCSI] libiscsi: handle cleanup task races"
> and is indeed typically called under the backward lock && has this section
> 
> +   if (!list_empty(>running))
> +   list_del_init(>running);
> 
> which per my reading of the code never comes into play, can you comment?


I had sent this to Sagi and your mellanox email the other day:


> The bug occurs when a target completes a command while we are still
> processing it. If we are doing a WRITE and the iscsi_task
> is on the cmdqueue because we are handling a R2T. The target shouldn't
> send a Check Condition at this time, but some do. If that happens, then
> iscsi_queuecommand could be adding a new task to the cmdqueue, while the
> recv path is handling the CC for the task with the outsanding R2T.  The
> recv path iscsi_complete_task call sees that task it on the cmdqueue and
> deletes it from the list at the same time iscsi_queuecommand is adding a new
> task.
> 
> This should not happen per the iscsi spec. There is some wording about
> waiting to finish the sequence in progress, but targets goof this up.




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

Re: Possible issue in commit 659743b02c41 ("libiscsi: Reduce locking contention in fast path")

[Michael Christie]

> On Nov 5, 2015, at 6:56 PM, Chris Leech  wrote:
> 
> On Thu, Nov 05, 2015 at 02:33:44PM -0200, Guilherme G. Piccoli wrote:
>> Hello Shlomo and Or,
>> 
>> I'm Guilherme Piccoli from LTC/IBM - firstly, sorry to bother you.
>> 
>> 
>> We are running some tests with iSCSI and we found an issue caused possibly
>> by commit 659743b02c41 ("libiscsi: Reduce locking contention in fast path").
>> 
>> After some time (+/- 1 hour) of testing with a hardware target (using fio
>> benchmark tool), we got a kernel oops; the following link is a pastebin of
>> the error message (we got lots of these messages, since our system has
>> multiple cores): http://codepad.org/KS2C9Jjt
> 
> Interesting. From the trace, the list debugging code is detecting
> corruption when removing a task from some list.  Could be the connection
> mgmtqueue, cmdqueue, or requeue.
> 
> After the locking change adding a task to any of those lists is under
> the session fwrd_lock, but the call to iscsi_complete_task which deletes
> the task from whatever list it's on is under the back_lock.
> 
> Am I missing something, or is splitting a linked list across two locks a
> major failing of this change?

You are right. Patch is really wrong. Not sure what I was thinking when I 
merged it. It has had multiple issues now,

Or and Shlomo, I am going to just revert the patch for now until I can do some 
performance testing with a patch to add back correct locking and also 
re-rerview the patch. Maybe instead of locks I can just use some kfifos too.

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

Re: Updated iscsi timeout and retry values in iscsi.conf file are not getting effective

[Michael Christie]

Sorry. I thought I replied to the original. Basically, iscsiadm is racey. For 
the operations you listed, the behavior is not defined.


On Aug 23, 2015, at 11:53 PM, Manish Singh  wrote:

> Hi All,
> 
> Can anyone reply on above queries?? It will be really helpful if someone 
> explains the behavior.
> 
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.

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

Re: [PATCH 0/2] Remove local open-isns, using system-installed version

[Michael Christie]

On Jul 14, 2015, at 4:01 PM, leeman.dun...@gmail.com wrote:

 From: Lee Duncan ldun...@suse.com
 
 This set of patches tells open-iscsi to use the system-resident
 open-isns files instead of the ones in utils/open-isns.
 
 This patch *requires* that you've installed open-isns (from
 g...@github.com:gonzoleeman/open-isns.git).
 
 The first patch tells open-iscsi to use the system-resident
 include files and library from open-isns. The second patch
 removes the local copy of same.
 
 Questions:
 - Should the documentation be updated? I didn't
  find anything that referenced open-isns
 - Is it perhaps time to bump the minor version
  of open-iscsi? It's been a while.
 
 Note: it is my intention to create an open-isns package
 for SUSE. I assume other platforms will have to do the
 same before they could incorporate this patch.
 
 
 Lee Duncan (2):
  Use system-wide open-isns, not internal version.
  Remove local copy of open-isns.


Thanks again for taking this on! Patches merged and pushed.

Note: I dropped the 2/2 patch because of patching conflicts and just did a git 
rm and then updated the README.

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

Re: Setting firmware/offload engine parameter Large_Frames on QLogic HBAs

[Michael Christie]

On Aug 5, 2015, at 3:33 PM, Frank Fegert fra.nospam...@gmx.de wrote:

 achieved with the iscsiadm -m fw [...] or a similar command.

You want the iscsiadm host flashnode mode, and  I think the setting is the 
iface mtu one. I do not have a qlogic card handy, but I think the command would 
be something like:

iscsiadm -m $host_number -C flashnode -A ipv4 -x flashnode_index -o update -n 
iface.mtu -v 8192


for 8192 replace with whatever frame size you wanted that the card supports. 
For -A the possible settings are ipv4 or ipv6.

For the -X flashnode_index setting then you do

iscsiadm -m host_number -C flashnode

This will print out the targets stored in the card. The number after qla4xxx 
will be the index of each entry in flash that you would use for -x.


I think there is also a way to set it as the default for all targets on a 
host/iface  by using the iscsiadm -m iface mode, but I cannot remember.

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

Re: recovering from a ping timeout, gracefully

[Michael Christie]

On Jun 21, 2015, at 8:55 AM, Brian J. Murrell br...@interlinx.bc.ca wrote:

 So, clearly I have some kind of temporary/intermittent issues with my
 network, unfortunately.  :-(  Fortunately they do seem to be
 infrequently intermittent and most of the time things work.  But every
 now and then I well get a spate of this:
 
 Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082655665, last ping 
 5082660665, now 5082665665
 Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection17:0: detected 
 conn error (1011)
 Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082655834, last ping 
 5082660834, now 5082665834
 Jun 19 15:08:39 eagle-4.eagle.hpdd.intel.com kernel: connection24:0: detected 
 conn error (1011)
 Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 17:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:40 eagle-4 iscsid: Kernel reported iSCSI connection 24:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082656608, last ping 
 5082661608, now 508208
 Jun 19 15:08:40 eagle-4.eagle.hpdd.intel.com kernel: connection23:0: detected 
 conn error (1011)
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082657189, last ping 
 5082662189, now 5082667189
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection19:0: detected 
 conn error (1011)
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082657235, last ping 
 5082662235, now 5082667235
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection21:0: detected 
 conn error (1011)
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082657253, last ping 
 5082662253, now 5082667253
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection18:0: detected 
 conn error (1011)
 Jun 19 15:08:41 eagle-4 iscsid: Kernel reported iSCSI connection 23:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082657666, last ping 
 5082662666, now 5082667666
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection22:0: detected 
 conn error (1011)
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: ping 
 timeout of 5 secs expired, recv timeout 5, last rx 5082657674, last ping 
 5082662674, now 5082667680
 Jun 19 15:08:41 eagle-4.eagle.hpdd.intel.com kernel: connection20:0: detected 
 conn error (1011)
 Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 19:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 21:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 18:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 22:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 Jun 19 15:08:42 eagle-4 iscsid: Kernel reported iSCSI connection 20:0 error 
 (1011 - ISCSI_ERR_CONN_FAILED: iSCSI connection failed) state (3)
 
 and then my ISCSI target it offline.  The network will recover very
 shortly thereafter though and I can ping the tgtd server, etc.
 
 What I wonder is, what is the most graceful way to tell the above
 machine that things are repaired and to consider the target back in
 service?  Currently after the above happens and even after the network
 recovers, accessing the target returns an EIO, despite connectivity
 being restored.  I'm assuming that this error state is persisted until
 an operator can tell ISCSI otherwise.  But how does the operator do
 that?

It should be done automatically.

For the initiator/open-iscsi side of things, when you see the above error,  it 
will drop the connection, then try to reconnect and relogin to the target. 
After the above errors you should see messages from iscsid about how it cannot 
reach the target or it cannot connect to it (depending on the network issue it 
will be slightly different messages). When the network issue is resolved, we 
automatically relogin and allow you to access the target/disks.

When we reconnect and relogin, you should see a message like:

connection1:0 is operational after recovery (8 attempts)

in /var/log/messages from iscsid.

You should then be able to access the disks again.


-- 
You received this 

Re: [PATCH 0/4] Assorted fixes

[Michael Christie]

Hey Christian,

I was trying to email you about this patch set, but I keep getting bounce backs 
when sending mail to christ...@iwakd.de.

Email me off list. Thanks.


On May 28, 2015, at 11:33 AM, Christian Seiler christ...@iwakd.de wrote:

 Hi,
 
 I've been going through Debian's packaging of open-iscsi and I've
 noticed that a couple of fixes that should go upstream (with some
 improvements I'll make to Debian's package this will bring the number
 of patches in Debian down to zero). I've polished them a bit and am
 forwarding them here.
 
 Summary of the patches:
 
 1. make clean is now idempotent (can be called multiple times
   without failing) and also does make distclean in iscsiuio.
 
 2. CFLAGS and LDFLAGS set on the outside are now respected.
 
 3. remove debian/
   This is really outdated (was added 10 years ago and never
   changed since), is better maintained downstream.
 
 4. Some speilling fixes that have been in the Debian package for
   quite a while. This patch is not by me, so I've set the git
   author accordingly.
 
 (I can also create a github pull request if you prefer that.)
 
 Best regards,
 Christian
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to open-iscsi+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.
 For more options, visit https://groups.google.com/d/optout..

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

Re: Reconnects and I/O errors with Synology iSCSI targets

[Michael Christie]

On May 7, 2015, at 7:06 AM, Ancoron Luciferis 
ancoron.lucife...@googlemail.com wrote:

 Hi,
 
 I currently have some trouble with LUNs exposed by Synology boxes.
 
 As of Linux kernel 3.19, the max_sectors_kb value always is 32767 for
 any LUN, which results into errors on the Synology target side and
 reconnects on the Linux initiator side:
 


As you saw, in the newer kernel the block/scsi layer will now send requests up 
to the size the target or initiator say they can handle. In your case, because 
the target is reporting zeros, the scsi layer is only using the initiator limit 
which is that 32K.

It seems there is a bug with lio based targets. In this patch for Qnap targets 
which used lio, we just added a new black list flag so we use the old default 
value because we could not contact the vendor to get more info as it is not 
always as simple as just matching the max_hw_sectors/max_sectors on the target 
side:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/scsi?id=35e9a9f93994d7f7d12afa41169c7ba05513721b

You can normally manually override the max sectors setting, but that is broken 
under some conditions. It is fixed with this patch

http://marc.info/?l=linux-scsim=142864974021809w=3

Could you send me the vendor/product info, so we can add your target to the 
blacklist?

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

Re: [Lsf-pc] [LSF/MM TOPIC] iSCSI MQ adoption via MCS discussion

[Michael Christie]

On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote:

 On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
 On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
 On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
 On Thu, 2015-01-08 at 14:16 -0800, Nicholas A. Bellinger wrote:
 
 SNIP
 
 The point is that a simple session wide counter for command sequence
 number assignment is significantly less overhead than all of the
 overhead associated with running a full multipath stack atop multiple
 sessions.
 
 I don't see how that's relevant to issue speed, which was the measure we
 were using: The layers above are just a hopper.  As long as they're
 loaded, the MQ lower layer can issue at full speed.  So as long as the
 multipath hopper is efficient enough to keep the queues loaded there's
 no speed degradation.
 
 The problem with a sequence point inside the MQ issue layer is that it
 can cause a stall that reduces the issue speed. so the counter sequence
 point causes a degraded issue speed over the multipath hopper approach
 above even if the multipath approach has a higher CPU overhead.
 
 Now, if the system is close to 100% cpu already, *then* the multipath
 overhead will try to take CPU power we don't have and cause a stall, but
 it's only in the flat out CPU case.
 
 Not to mention that our iSCSI/iSER initiator is already taking a session
 wide lock when sending outgoing PDUs, so adding a session wide counter
 isn't adding any additional synchronization overhead vs. what's already
 in place.
 
 I'll leave it up to the iSER people to decide whether they're redoing
 this as part of the MQ work.
 
 
 Session wide command sequence number synchronization isn't something to
 be removed as part of the MQ work.  It's a iSCSI/iSER protocol
 requirement.
 
 That is, the expected + maximum sequence numbers are returned as part of
 every response PDU, which the initiator uses to determine when the
 command sequence number window is open so new non-immediate commands may
 be sent to the target.
 
 So, given some manner of session wide synchronization is required
 between different contexts for the existing single connection case to
 update the command sequence number and check when the window opens, it's
 a fallacy to claim MC/S adds some type of new initiator specific
 synchronization overhead vs. single connection code.

I think you are assuming we are leaving the iscsi code as it is today.

For the non-MCS mq session per CPU design, we would be allocating and binding 
the session and its resources to specific CPUs. They would only be accessed by 
the threads on that one CPU, so we get our serialization/synchronization from 
that. That is why we are saying we do not need something like 
atomic_t/spin_locks for the sequence number handling for this type of 
implementation.

If we just tried to do this with the old code where the session could be 
accessed on multiple CPUs then you are right, we need locks/atomics like how we 
do in the MCS case.

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

Re: iscsi_tcp bound to network interface issues after iscsid: retry login for ISCSI_ERR_HOST_NOT_FOUND

[Michael Christie]

On Jan 6, 2015, at 6:40 PM, Chris Leech cle...@redhat.com wrote:

 Hi all,
 
 It looks to me that the changes in iscsid: retry login for
 ISCSI_ERR_HOST_NOT_FOUND have broken interface binding for iscsi_tcp
 (and iser, assuming interface bindin

iser does not do binding.

Is this a regression with the patch:

commit c0e509e7535372cd5d655bc5a20d3d2bae45df84
Author: Mike Christie micha...@cs.wisc.edu
Date:   Wed May 7 14:38:13 2014 -0500

iscsid: retry login for ISCSI_ERR_HOST_NOT_FOUND

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

Re: Could not logout of all requested sessions when working with centos 7

[Michael Christie]

Thanks for reporting back.

If this happens again, give us the /var/log/messages and the output of

iscsiadm -m session -P 3

when the iscsiadm ….. —logout command is returning the errors you pasted below.



On Nov 30, 2014, at 12:08 AM, Shay Katz shak...@gmail.com wrote:

 Hi,
 
 during the last week i have tried to reproduce the problem without success.
 
 I guess it is false alarm.
 
 Shay
 
 On Monday, November 10, 2014 8:51:00 AM UTC+2, Mike Christie wrote:
 Could you attach your /var/log/messages for when you removed the portals and 
 when you ran the logout command?
 
 
 On Nov 7, 2014, at 12:56 AM, Shay Katz sha...@gmail.com wrote:
 
 Hi
 
 I have client (centos 7) with logged in sessions,
 
  
 [root@lgdrm1027 ~]# iscsiadm -m session
 
 tcp: [1] 10.206.12.5:3260,1 iqn.2008-05.com.xtremio:001e679efc4a (non-flash)
 
 tcp: [2] 10.205.12.5:3260,1 iqn.2008-05.com.xtremio:001e679efc4a (non-flash)
 
 tcp: [3] 10.206.12.6:3260,1 iqn.2008-05.com.xtremio:001e679efc4b (non-flash)
 
 tcp: [4] 10.205.12.6:3260,1 iqn.2008-05.com.xtremio:001e679efc4b (non-flash)
 
 tcp: [5] 10.206.12.15:3260,1 iqn.2008-05.com.xtremio:001e679efff6 (non-flash)
 
 tcp: [6] 10.205.12.15:3260,1 iqn.2008-05.com.xtremio:001e679efff6 (non-flash)
 
 tcp: [7] 10.206.12.16:3260,1 iqn.2008-05.com.xtremio:001e679efff7 (non-flash)
 
 tcp: [8] 10.205.12.16:3260,1 iqn.2008-05.com.xtremio:001e679efff7 (non-flash)
 
  
 After logging in the user remove the portals from the target, now when I am 
 trying to logged out the operation fails
 
 And I didn't find how to remove them (There is no force flag):
 
  
 [root@lgdrm1027 ~]# iscsiadm -m node -u
 
 Logging out of session [sid: 1, target: 
 iqn.2008-05.com.xtremio:001e679efc4a, portal: 10.206.12.5,3260]
 
 Logging out of session [sid: 2, target: 
 iqn.2008-05.com.xtremio:001e679efc4a, portal: 10.205.12.5,3260]
 
 Logging out of session [sid: 3, target: 
 iqn.2008-05.com.xtremio:001e679efc4b, portal: 10.206.12.6,3260]
 
 Logging out of session [sid: 4, target: 
 iqn.2008-05.com.xtremio:001e679efc4b, portal: 10.205.12.6,3260]
 
 Logging out of session [sid: 5, target: 
 iqn.2008-05.com.xtremio:001e679efff6, portal: 10.206.12.15,3260]
 
 Logging out of session [sid: 6, target: 
 iqn.2008-05.com.xtremio:001e679efff6, portal: 10.205.12.15,3260]
 
 Logging out of session [sid: 7, target: 
 iqn.2008-05.com.xtremio:001e679efff7, portal: 10.206.12.16,3260]
 
 Logging out of session [sid: 8, target: 
 iqn.2008-05.com.xtremio:001e679efff7, portal: 10.205.12.16,3260]
 
 iscsiadm: Could not logout of [sid: 1, target: 
 iqn.2008-05.com.xtremio:001e679efc4a, portal: 10.206.12.5,3260].
 
 iscsiadm: initiator reported error (9 - internal error)
 
 iscsiadm: Could not logout of [sid: 2, target: 
 iqn.2008-05.com.xtremio:001e679efc4a, portal: 10.205.12.5,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 3, target: 
 iqn.2008-05.com.xtremio:001e679efc4b, portal: 10.206.12.6,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 4, target: 
 iqn.2008-05.com.xtremio:001e679efc4b, portal: 10.205.12.6,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 5, target: 
 iqn.2008-05.com.xtremio:001e679efff6, portal: 10.206.12.15,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 6, target: 
 iqn.2008-05.com.xtremio:001e679efff6, portal: 10.205.12.15,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 7, target: 
 iqn.2008-05.com.xtremio:001e679efff7, portal: 10.206.12.16,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of [sid: 8, target: 
 iqn.2008-05.com.xtremio:001e679efff7, portal: 10.205.12.16,3260].
 
 iscsiadm: initiator reported error (2 - session not found)
 
 iscsiadm: Could not logout of all requested sessions
 
 [root@lgdrm1027 ~]#
 
 same scenario on centos 6.5 worked well.
 
 Shay
 
 -- 
 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+...@googlegroups.com.
 To post to this group, send email to open-...@googlegroups.com.
 Visit this group at http://groups.google.com/group/open-iscsi.
 For more options, visit https://groups.google.com/d/optout.
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 

Re: iSCSI request keep rejected by microsoft iSCSI target because of write_same check

[Michael Christie]

Hey Vaughan,

This was the issue we worked with Microsoft on wasn’t it? You guys figured out 
it was fixed in their target in a recent release right?

On Dec 1, 2014, at 3:01 AM, vaughan vaughan@oracle.com wrote:

 On 12/01/2014 03:25 PM, j...@deti74.ru wrote:
 I has some sproblem and only one ISCSI target - Microsoft SWT
 I disable write_same for iscsi by patching kernel (3.17.0)
 This method is not good.  Below is the answer from Mike when I asked if
 we can disable write_same in the template before.
 
 If you wanted to disable commands you would want to do it per device or
 target at the scsi layer, because there are or will be iscsi targets
 that support it.
 
 Also Martin suggests the target should return a check condition of
 ILLEGAL REQUEST if it doesn't support a specific command.
 It's a bug that only happens with Microsoft target, not others like tgtd.
 
 
 
 Patch is simple add .no_write_same = 1 param, into scsi_host_template
 struct.
 
 file drivers/scsi/iscsi_tcp.c :
 
 static struct scsi_host_template iscsi_sw_tcp_sht = {
  .module= THIS_MODULE,
  .name= iSCSI Initiator over TCP/IP,
  .queuecommand   = iscsi_queuecommand,
  .change_queue_depth= iscsi_change_queue_depth,
  .can_queue= ISCSI_DEF_XMIT_CMDS_MAX - 1,
  .sg_tablesize= 4096,
  .max_sectors= 0x,
  .cmd_per_lun= ISCSI_DEF_CMD_PER_LUN,
  .eh_abort_handler   = iscsi_eh_abort,
  .eh_device_reset_handler= iscsi_eh_device_reset,
  .eh_target_reset_handler = iscsi_eh_recover_target,
  .use_clustering = DISABLE_CLUSTERING,
 + .no_write_same= 1,
  .slave_alloc= iscsi_sw_tcp_slave_alloc,
  .slave_configure= iscsi_sw_tcp_slave_configure,
  .target_alloc= iscsi_target_alloc,
  .proc_name= iscsi_tcp,
  .this_id= -1,
  };
 
 
 суббота, 11 января 2014 г., 6:22:46 UTC+5 пользователь Vaughan Cao
 написал:
 
 
On 2014年01月11日 04:24, Mike Christie wrote:
 On 01/10/2014 02:09 AM, vaughan wrote:
 On 01/10/2014 03:41 PM, Mike Christie wrote:
 On 1/10/14 12:11 AM, vaughan wrote:
 I haven't figure out why it's rejected with bookmark
invalid(9)
 reason, rather than command not supported. IMO bookmark
invalid is
 used when minor protocol conflict such as final flag not set
with
 non-write command. However, I haven't find error of this kind in
 report_opcode, so I guess it's not supported on the target.
 
 Is it possible to get a wireshark/tcpdump trace? It does not
have to
 be during boot. We just need to see what commands are sent and
the
 response the target is returning.
 
 I forgot we know some microsoft iscsi target people. We can
just email
 them with the trace to confirm what is going on with the
target. The
 trace seems to be easier for them than them interpreting linux
kernel
 logs.
 I enabled debug_iscsi_tcp, here is a more detailed log in
normal connection.
 Does conn error (1020) mean it's target peer who disconnect the
 connection at the same time of reject report_opcode?
 Yes.
 
 If it is, I think iSCSI boot failure can't be avoided without
disable
 write_same check on OEL.
 Yes, you are right. Due to how more distros do boot, iscsid will
not be
 up and you will hang. If are talking about disablement though I
think it
 should not be done at the iscsi layer. It should be some sort of
 white/black list at the scsi device layer or something like that.
 
 However, I will ping Microsoft and cc you and we can see what is
up for
 sure. Maybe we will get lucky and they will have a release with
a fix on
 their side.
 
Target:
   Windows Server 2008 R2 DataCenter
   Microsoft iSCSI Software Target: 3.3.16563.
Initiator:
   kernel with write_same check in sd, such as Kernel
3.11.10-200.fc19.x86_64  
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.
 

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

Re: Current Portal vs Persistent Portal Question

[Michael Christie]

On Nov 28, 2014, at 5:51 PM, The Lee-Man leeman.dun...@gmail.com wrote:

 On Wednesday, November 26, 2014 1:31:30 PM UTC-8, Mike Christie wrote:
 On 11/25/2014 06:58 PM, The Lee-Man wrote: 
  Hi Mike: 
  
  I am dealing with a problem in Equallogic, and it looks like the Current 
  Portal and Persistent Portal are different. 
  
  As this is something I haven't seen before, I was hoping you could 
  explain what it is. 
  
  I see in the README: 
  
  ... 
  Current Portal: portal currently logged into 
  Persistent Portal: portal we would fall back to if we had got 
  redirected during login 
  
  Is this related to Equallogic's iSCSI login redirect? 
 
 Yes. 
 
  
  It sounds like the Persistent Portal is the one that we initially try to 
  log into, and the Current Portal is the one we get redirected to. Or is 
 
 Correct. Persistent portal is the one returned by the discovery command. 
 
 Excellent. I guessed correctly. :)
  
 
  that backwards? 
  
  What happens if we discover the main (group virtual) portal, and our 
  Node record reflects that, then we get redirected? It seems like the 
 
 Node record portal ip is the ip that the EQL box returns when you do 
 discovery, and it is the persistent ip value you see in sysfs and when 
 you run iscsiadm -m session. 
 
 Note that if a driver does not support persistent_address attr then the 
 persistent and current are both the currently logged into address. I 
 think just older qlogic driver did not export this, but does now. 
 
 Also, really old iser drivers did not export the non persistent address 
 so they were both the same, but that was a long time ago. 
 
 I noticed the code that filled in both current and persistent portal, as
 needed.
  
 
  Portal is going to differ between the Node record and the Session 
  record, which might explain what I'm seeing. 
 
 It should match. 
 
 No. If the current and persistent portals differ, then only one
 of them can match the current session.

Ah, I misunderstood what you meant by just “Portal”. Thought you were referring 
to the portal returned during discovery. Not the redirected one.

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

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

[Michael Christie]

On Nov 28, 2014, at 5:46 PM, The Lee-Man leeman.dun...@gmail.com wrote:

 On Wednesday, November 26, 2014 1:11:46 PM UTC-8, Mike Christie wrote:
 On 11/25/2014 05:15 PM, The Lee-Man wrote: 
  On Tuesday, November 25, 2014 2:00:22 PM UTC-8, Mike Christie wrote: 
  
  On 11/25/2014 12:49 PM, The Lee-Man wrote: 
   On Tuesday, November 25, 2014 9:42:59 AM UTC-8, Mike Christie wrote: 
   
   On 11/24/2014 11:04 AM, The Lee-Man wrote: 
Okay, I spent most the day yesterday playing with the 
code in question, i.e. the open-iscsi code that rescans 
the session list looking for the current session. 

In particular, I was looking at update_sessions(). 

One thing I noticed is that this code only gets executed 
if discovery.sendtargets.use_discoveryd is set to Yes for 
a particular target, by the way. 
   
   So how does your interconnect test come into play for this 
  issue? It 
   seems like you should be hitting this issue all the time even 
  when the 
   connection is ok, because that code polls every N seconds. 
   
   
   When the connections are being dropped and then reconnected, the 
   sessions (created by the kernel) are coming and going. And each time 
   a connection goes away and comes back, it gets a new session ID, 
   and a new symlink in /sys/class/iscsi_sessions, which of course 
   is not cached. (This is my theory, since I don't have a configuration 
   which can test this ATM.) 
  
  The session and/or connection id does not change if the connection is 
  just dropped and then relogged into by iscsid. It would only change if 
  you are removing a session by hand by doing iscsiadm ... --logout, then 
  readding it by doing iscsiadm  --login, or if maybe discoveryd is 
  causing sessions to be deleted then added due to getting different 
  portals back or due to a bug in that code. 
  
  Or, are you using eql's multipating software that might be dynamically 
  creating/deleting sessions? 
  
  
  Not using eql multipathing (I don't believe). 
  
  When I stop iscsid and restart it, I get a new session ID. 
  
 
 Any time a session is removed from the kernel then readded it can change. 
 
 So if a connection was removed, so that all of the sessions on that connection
 go into error handling, will they not be removed eventually, if retries do 
 not work?

If you just do something that causes the iscsi layer to go into recovery like a 
cable pull then no. The kernel and iscsid structures will stay in place and we 
will reuse them.


 
 How do you start and stop it? Are you just killing the daemon by doing a 
 sigkill and restarting it by running /sbin/iscsid? If so, it should not 
 change. 
 
 For my testing, on SLES 12, I was using sytsemctl (systemd) to start/stop 
 iscsi.

Did you mean iscsi or iscsid? Do you guys have just the one iscsi service? We 
have iscsi and iscsid in RHEL and they work much differently.


 I also was using discovered.

Don’t have SUSE handy. You will have to tell me what happens when you do the 
stop command.


 
 When you kill iscsid are you also removing the sessions then on restart 
 are you creating them again? If so, then yeah the session id will change 
 because you are removing the session like is done when you do --logout. 
 Maybe you are using some init/systemd type of script? 
 
 Yes. Again, this was just for my testing. The original testing done by a
 large hardware manufacturer instead just pulled cables.
 
 But it looks like update_sessions() logs out of stale sessions.

Stale here is supposed to mean portals that are longer returned by the target. 
If you are seeing something else then there is a bug. That is why I asked if 
the target was returning different targets. For a cable pull test or your test, 
it should be returning the same targets right.


For your test I think you are also hitting a bug where if iscsid is not being 
restarted too (you are just logging out and into sessions), then its discovered 
cache is messed up. Looks like there is bug where because discoveryd is caching 
sysfs info, if you were to run iscsiadm …logout then iscsiadm … login, 
discovered will have a /sys/class/iscsi_session entry for the old session as 
well as the new one. Not sure how badly that is messing your test up or at all. 
You should disable discoveryd caching.


  
 
 
  I have not learned the code enough to answer this question, so I'll ask 
  you, to make sure. 
  
  Is there nothing else that changes the session ID? 
 
 Just a complete removal from the kernel like is done when the --logout 
 command is run manually or when discoveryd does it. Look at 
 iscsi_add_session() in drivers/scsi/scsi_transport_iscsi.c for when it 
 gets set. It then never changes. 
 
 In older versions iscsid could also remove a session if during login we 

Re: open-isns repository moving, under new stewardship

[Michael Christie]

Thanks for doing this!

On Nov 21, 2014, at 6:52 PM, The Lee-Man leeman.dun...@gmail.com wrote:

 Hi All:
 
 Mike has generously been carrying the open-isns code under the utils 
 directory in open-iscsi for a while now.
 
 As one of the main users of this code, Mike asked if I wanted to take 
 ownership and I agreed.
 
 The new repository will be hosted at 
 https://github.com/gonzoleeman/open-isns.git.
 
 For now, since iSNS gets so little use, I would like to just continue 
 piggy-backing on open-iscsi for issues discovered, discussion, etc. So no 
 new/extra mailing list needs to be subscribed to or maintained.
 
 To start things off, after forking Mike's copy, I've added the following 
 changes:
 
 84905a025c7c Support install of systemd files
 5702d6d2ce9e Use DESTDIR instead of INSTALL_ROOT in Makefile
 213c0157185c Ignoring dot-o files
 997d219eff07 fixing configure warning: not using datarootdir
 b511e38470c3 Using INSTALL Macro in Makefile
 af60e767adf1 open-isns: systemd integration
 024925c372e5 open-isns: Read source name from /etc/iscsi/initiatorname.iscsi
 ea0e553fad81 open-isns: Implement 'IQNPrefix' configuration setting
 27a260b7cab6 open-isns: Make default IQN prefix configurable
 7e0288220b96 isnsadm: Allow server to be specified
 e30341671480 open-isns: add 'all' as valid option for debugging
 d931d111654b Remove unused variable 'type' in insnsadm
 f9717c82af21 open-isns: move config.h include
 
 These reflect the set of 11 patches I recently submitted to this mailing 
 list, with a couple of Makefile-cleanup patches added in.
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to open-iscsi+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.
 For more options, visit https://groups.google.com/d/optout.

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

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

[Michael Christie]

On Nov 18, 2014, at 3:35 PM, Lee Duncan leeman.dun...@gmail.com wrote:

 The following patch fixes a problem where the CPU becomes compute bound
 when rediscovering targets, when there are hundreds of sessions.
 
 When his occurs, most of the time is spent in the function
 iscsi_sysfs_for_each_session(). This function does a scandir(),
 sorted alphabetically, to get a list of sessions, then scans
 that list looking for a match. When there are hundreds of sesions
 this can take forever.
 
 This patch saves the current session and then ensures that this
 session sorted to the front of the list. Testing shows that
 CPU usage goes from near 100% to near 0% when running cable
 plug tests with hundreds of sessions.

When/how is iscsi_sysfs_for_each_session getting run during this test?

Is it iscsid during its relogin/eh handling or something else like a script
running iscsiadm commands?

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

Re: [PATCHES] Fixup iBFT and IPv6, some cleanup

[Michael Christie]

On Nov 13, 2014, at 5:56 PM, The Lee-Man leeman.dun...@gmail.com wrote:

 On Tuesday, November 11, 2014 8:25:56 PM UTC-8, Mike Christie wrote:
 On 10/30/2014 08:16 PM, The Lee-Man wrote: 
  0002-Represent-DHCP-origin-as-an-integer-not-string.patch 
  
  This just changes the origin attribute from a string, to a number, 
  which 
  is what it really is. 
  
 
 Could you send me a link to where origin is defined? In the doc I have 
 it is a dead link. 
 
 This is defined in the iBFT document, available here on the web here: iBFT 
 Layout - Microsoft
 (if my hper-link works)
 
 In section 3.6 NIC Structure, the table shows that origin 1 byte long at 
 offset 23 bytes. And table points at a C++ definition of the values here: 
 http://msdn.microsoft.com/en-us/library/aa366281.aspx
 
 It looks like:
 
 typedef enum  { 
   IpPrefixOriginOther= 0,
   IpPrefixOriginManual,
   IpPrefixOriginWellKnown,
   IpPrefixOriginDhcp,
   IpPrefixOriginRouterAdvertisement,
   IpPrefixOriginUnchanged= 16
 } IP_PREFIX_ORIGIN;
 The open-iscsi code current checks this for the value 3 (i.e. a string 
 representing the number 3), and our code already has a patch that instead 
 reads this value in as an integer, and then compares it with the number 3.

Could you add a enum for these values in fw_context.h and then check for it 
instead of the numerical value?

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

Re: Best way to create multiple TCP flows on 10 Gbps link

[Michael Christie]

On Aug 26, 2014, at 3:11 PM, Learner learner.st...@gmail.com wrote:

 Another related observation and some questions;
 
 I am using open iscsi on init with IET on trgt over a single 10gbps link
 
 There are three ip aliases on each side
 
 I have 3 ramdisks exported by IET to init
 
 I do  iscsi login 3 times, once using each underlying ip address and notice 
 that each iscsi session sees all 3 disks.
 
 Is it possible to restrict such that each init only sees one separate disk?
 

There is no iscsi initiator or target setting for this. The default is to show 
all paths (each /dev/sdx is a path to the same device)..

You would have to manually delete some paths by doing

echo 1  /sys/block/sdX/device/remove

 When I run fio on each mounted disk, I see that only two underlying tcp 
 sessions are being used - that limits the perf.
 Any ideas on how to overcome this?

How are you matching sessions with devices? It should just be a matter of 
running fio on the right devices. If you run:

iscsiadm -m session -P 3

you can see how the sdXs match up with sessions/connections. If you run fio to 
a /dev/sdX from each session, you should be seeing IO to all 3 sessions.




 
 Thanks!
 
 
 Sent from my iPhone
 
 On Aug 26, 2014, at 12:53 PM, Mark Lehrer m...@knm.org wrote:
 
 On Tue, 26 Aug 2014 08:58:46 -0400 Alvin Starr al...@iplink.net wrote:
 
 I am trying to achieve10Gbps in my single initiator/single target
 env. (open-iscsi and IET)
 
 On a semi-related note, are there any good guides out there to
 tuning Linux for maximum single-socket performance?  On my 40 gigabit
 
 You are likely getting hit by the bandwidth-delay product.
 Take a look at http://en.wikipedia.org/wiki/Bandwidth-delay_product
 and http://www.kehlet.cx/articles/99.html
 
 Thanks that helped get my netcat transfer up over 500MB/sec using IPoIB. 
 Unfortunately that is still only about 10% of the available bandwidth.
 
 I'll keep on tweaking and see how far I can take it.
 
 Thanks,
 Mark
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

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

Re: Best way to create multiple TCP flows on 10 Gbps link

[Michael Christie]

On Aug 26, 2014, at 6:49 PM, Michael Christie micha...@cs.wisc.edu wrote:

 
 On Aug 26, 2014, at 3:11 PM, Learner learner.st...@gmail.com wrote:
 
 Another related observation and some questions;
 
 I am using open iscsi on init with IET on trgt over a single 10gbps link
 
 There are three ip aliases on each side
 
 I have 3 ramdisks exported by IET to init
 
 I do  iscsi login 3 times, once using each underlying ip address and notice 
 that each iscsi session sees all 3 disks.
 
 Is it possible to restrict such that each init only sees one separate disk?
 
 
 There is no iscsi initiator or target setting for this. The default is to 
 show all paths (each /dev/sdx is a path to the same device)..
 
 You would have to manually delete some paths by doing
 
 echo 1  /sys/block/sdX/device/remove
 
 When I run fio on each mounted disk, I see that only two underlying tcp 
 sessions are being used - that limits the perf.
 Any ideas on how to overcome this?
 
 How are you matching sessions with devices? It should just be a matter of 
 running fio on the right devices. If you run:
 
 iscsiadm -m session -P 3
 
 you can see how the sdXs match up with sessions/connections. If you run fio 
 to a /dev/sdX from each session, you should be seeing IO to all 3 sessions.
 

How are you determining if a session is being used or not? Are you running the 
iscsiadm -m session --stats command, watching with wireshark/tcpdump or 
something else?

If you have all three IPs on the same subnet, then it is going to be a little 
more complicated than what I described above.

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

Re: Any help or hint to compile open-iscsi-2.0-870.2 for kernel 2.6.18 ?

[Michael Christie]

What distro are you running and what version?

Why are you using such a old kernel? Is this a RHEL 5 based distro? If so, it 
is best to use the tools/kernel modules that come with it. They are pretty up 
to date and stable.

On Aug 20, 2014, at 10:44 PM, loulang...@163.com wrote:

 Any help or hint to compile open-iscsi-2.0-870.2 for kernel 2.6.28 ?
 
 [root@SPA open-iscsi]# uname -a
 Linux SPA 2.6.18-194.17.1.b1.07 #12 SMP Wed Jun 18 15:22:13 CST 2014 x86_64 
 x86_64 x86_64 GNU/Linux
 
 [root@SPA open-iscsi]# gcc -v
 Using built-in specs.
 Target: x86_64-redhat-linux
 Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
 --infodir=/usr/share/info --enable-shared --enable-threads=posix 
 --enable-checking=release --with-system-zlib --enable-__cxa_atexit 
 --disable-libunwind-exceptions --enable-libgcj-multifile 
 --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk 
 --disable-dssi --enable-plugin 
 --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic 
 --host=x86_64-redhat-linux
 Thread model: posix
 gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)
 
 [root@SPA open-iscsi]# make
 make -C utils/open-isns
 make[1]: Entering directory `/home/colibri/repos/open-iscsi/utils/open-isns'
 make[1]: Nothing to be done for `all'.
 make[1]: Leaving directory `/home/colibri/repos/open-iscsi/utils/open-isns'
 make -C utils/sysdeps
 make[1]: Entering directory `/home/colibri/repos/open-iscsi/utils/sysdeps'
 make[1]: Nothing to be done for `all'.
 make[1]: Leaving directory `/home/colibri/repos/open-iscsi/utils/sysdeps'
 make -C utils/fwparam_ibft
 make[1]: Entering directory 
 `/home/colibri/repos/open-iscsi/utils/fwparam_ibft'
 cc -O2 -g -fPIC -Wall -Wstrict-prototypes -I../../include -I../../usr 
 -D_GNU_SOURCE   -c -o ../../usr/iscsi_net_util.o ../../usr/iscsi_net_util.c
 In file included from ../../usr/iscsi_net_util.c:32:
 ../../usr/ethtool-copy.h:24: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h: In function 'ethtool_cmd_speed_set':
 ../../usr/ethtool-copy.h:44: error: 'struct ethtool_cmd' has no member named 
 'speed_hi'
 ../../usr/ethtool-copy.h: In function 'ethtool_cmd_speed':
 ../../usr/ethtool-copy.h:49: error: 'struct ethtool_cmd' has no member named 
 'speed_hi'
 ../../usr/ethtool-copy.h: At top level:
 ../../usr/ethtool-copy.h:76: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:90: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:99: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:251: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:278: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:304: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:311: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:317: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:322: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:333: error: expected specifier-qualifier-list before 
 '__u8'
 ../../usr/ethtool-copy.h:349: error: expected specifier-qualifier-list before 
 '__u8'
 make[1]: *** [../../usr/iscsi_net_util.o] Error 1
 make[1]: Leaving directory `/home/colibri/repos/open-iscsi/utils/fwparam_ibft'
 make: *** [user] Error 2
 
 
 Thanks for your help?
 
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to open-iscsi+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.
 For more options, visit https://groups.google.com/d/optout.

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

Re: iscsi over RBD performance tips?

[Michael Christie]

Are you using linux for the initiator? If so, what is the throughput you get 
from just using this open-iscsi initiator connected to tgt with a ram disk?

I just installed RBD here for work, so let me check it out. What io tool are 
using and if it is something like fio could you post the arguments you used to 
run it?


On Aug 21, 2014, at 4:10 PM, Wyllys Ingersoll wyl...@gmail.com wrote:

 
 Im looking for suggestions about maximizing performance when using an RBD 
 backend (Ceph) over a 10GB Ethernet link.  In my testing, I see the read 
 throughput max out at about 100Mbyte/second for just about any block sizes 
 above 4K (below 4K it becomes horribly slow) and write operations are about 
 40Mbyte/second.
 
 Using librados directly to read from the same backend pool/image yields much 
 higher numbers, so the issue seems to be in the iscsi/bs_rbd backend.  
 Regardless of the data sizes being read, the max thruput I am seeing is about 
 80% slower than using librados directly.
 
 Any suggestions would be much appreciated.
 
 thanks,
   Wyllys
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

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

Re: Best way to create multiple TCP flows on 10 Gbps link

[Michael Christie]

On Aug 22, 2014, at 12:07 PM, Redwood Hyd redwood...@gmail.com wrote:

 Hi All,
 I am trying to achieve10Gbps in my single initiator/single target env. 
 (open-iscsi and IET)
 
 I exported 3 Ramdisks, via 3 different IP aliases to initator, did three 
 iscsi logins , 3 mounts points and then 3 fio jobs in parallel (256K block 
 size each).
 
 Question 1) Is above a real use case where from same iscsi initiator i did 3 
 iscsi logins to same target (via different IP addresses) ? Anything pros/cons 
 with this.

This seems normal.

 
 Question 2) What are the other best ways to create parallel TCP flows 
 (because it seems open-iscsi does'nt have MC/S support)

Multiple sessions to different portals then use dm-multipath over all those 
paths/sessions to the LU.

 Question 3) In this scenario can I use dm-multipath - can someone suggest 
 most common way so that at TCP level i get multiple flows.
 

What you described above, when you run

/sbin/multipath
/sbin/multipath -ll

Do you see each device having 3 paths? Did you set it up to do round robin for 
dm multipath path selection? If so, each path is going to be a different tcp 
socket connection which the iscsi initiator and dm-multipath will use to send 
IO on.

At my last job, fusion-io/sandisk, we sold a high performance target, and to 
get the highest throughput when using linux we had to create extra 
sessions/connections to avoid some bottlenecks in the linux block/scsi layer.

Above you would have a session to each target portal/ip. We would set 
node.session.nr_sessions in iscsid.conf to greater than one so each portal 
would have nr_sessions sessions/connections. When you run iscsiadm -m node -T 
target -p ip -l, iscsiadm would then create nr_session to that portal. iscsiadm 
-m session would show the extra sessions when logged in and multipath -ll 
should show the extra paths.

You can also just do

iscsiadm -m session -R SID -o new

to dynamically add another session/connection.

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

Re: Correlating TCP connections with iSCSI connections

[Michael Christie]

Hey,

I made patches for this a while back. I am in the middle of finishing up some 
work release stuff then changing jobs. I should be able to get back to this 
next week. 

On Aug 6, 2014, at 4:20 PM, abhinav.srivast...@gmail.com wrote:

 
 Hi Mike,
 
 I am trying to extract the same information i.e. local IP and port 
 combination corresponding to a iscsi connection. Do you know how to extract 
 this information? iscsiadm -m session still only prints the local IP. Any 
 help would appreciated.
 
 Thanks.
 Abhinav
 
 On Thursday, August 30, 2012 3:58:05 PM UTC-4, Mike Christie wrote:
 Ok. Let me try to get to this over the weekend. 
 
 On 08/28/2012 07:29 PM, Jeffrey Caughel wrote: 
  That is exactly what I am looking for... peresently I can see something 
  like this: 
  
  # netstat -anpt 
  snip 
  tcp0 48 192.168.0.155:60480 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60452 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0 48 192.168.0.155:60448 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60460 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60458 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60466 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60420 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60422 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  tcp0  0 192.168.0.155:60434 192.168.0.35:3260   
  ESTABLISHED 5658/iscsid 
  snip 
  
  I would want to associate that with a specific connection so I can analyze 
  tcpdump output for just that one connection that is seemingly 
  underperforming.  The host has dozens of active connections and only this 
  one is causing a problem.  Without being able to identify the source port, 
  it is difficult to determine which stream to follow. 
  
  Thanks, 
  Jeff 
  
  On Tuesday, August 28, 2012 5:02:41 PM UTC-7, Mike Christie wrote: 
  
  
  On Aug 28, 2012, at 5:39 PM, Jeffrey Caughel 
  jcau...@gmail.comjavascript: 
  wrote: 
  
  In order to further dig into performance issues we're seeing, I am 
  trying to correlate individual iSCSI connections with specific TCP 
  connections.  I don't want to negatively impact performance more than it 
  already is so I was hoping to find a means for this that didn't require 
  increasing the log level.  I haven't found this recorded under 
  /sys/class/iscsi_connection/connection[number] or under 
  /var/lib/iscsi/nodes/[IQN]/[target_ip:port]/[interface].  I would expect 
  it 
  to be fairly simple and hopefully it's just eluding me - ultimately I 
  would 
  like to correlate this specific connection with an entry in `netstat 
  -anvpt` that is itself associated with iscsid. 
  
  
  I don't think we have anything. 
  
  If you run iscsiadm -m session -P 2 you will see a Iface IPaddress 
  value. This is the address that the iscsi connection uses on the local 
  side, so it matches the ip address in the Local Address value in 
  netstat. 
  I could also print out the local port the iscsi connection is using so you 
  could use both those values to match the address:port tuple you see in 
  netstat Local Address field. Is that what you need? 
  
 
 
 -- 
 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.
 For more options, visit https://groups.google.com/d/optout.

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

Re: [PATCH] fix login_timeout timer handling when retrying connect/login

[Michael Christie]

On Jul 24, 2014, at 4:46 PM, Eddie Wai eddie@broadcom.com wrote:

 On Thu, 2014-07-24 at 12:50 -0500, Mike Christie wrote:
 Hey Roi, Vikas and Eddie,
 
 The attached patch fixes the issue Roi reported where the login_timer
 was not deleted and so we end up with a infinite loop. Roi, could you
 test your failure case?
 
 Vikas and Eddie, I ccd you guys because it modifies the bnx2i iscsiuio
 code. There was a issue where iscsiuio was not ready (or the host was
 not yet ready) and so iscsid would poll iscsiuio for a second or two and
 it would use the login_timer as a watchdog. A couple weeks ago we hit a
 issue with be2iscsi where the host was not ready to go so iscsid got
 code to poll the iscsi/scsi_host. So this patch removes the iscsiuio
 login_timer use and then also has it use this new common setup polling.
 
 For the iscsiuio related changes, it looks like it will actually change
 the iscsid to iscsiuio re-engagement behavior after the initial 3 failed
 communication attempts.  The old code would delay and re-schedule the
 login timer actor to retry the iscsiuio communication while the new code
 would simply failed the entire login attempt.

Ah ok, I misread the intention of the code. Let me rework my patch.

Should there be a retry limit or timeout to control how long we retry? I was 
thinking that there could be cases where iscsiuio could not respond and we 
would want to give up eventually, or for this case that the code was handling 
should iscsiuio general always be up? If we want the retry/timeout tracking, 
how long should we be waiting for? How long did the problem we were fixing take 
to resolve itself?

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

Re: ISCSI error in centos 6

[Michael Christie]

On Mar 16, 2014, at 4:20 AM, Muthu Kumaran muthu86@gmail.com wrote:

 
 Hi,
 
 I am trying to configure ISCSI storage in my vm ware, But when tried to login 
 to the ISCSI target from the client it throws the following errors.
 
 [root@localhost ~]# iscsiadm --mode discoverydb --type sendtargets --portal 
 192.168.40.130 --discover
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: cannot make connection to 192.168.40.130: No route to host
 iscsiadm: connection login retries (reopen_max) 5 exceeded
 iscsiadm: Could not perform SendTargets discovery: encountered connection 
 failure
 [root@localhost ~]# 
 
 
 #iscsiadm -m node -L all
 Logging in to [iface: default, target: iqn.2014-03.sharedstorage:target1, 
 portal: 192.168.40.130,3260] (multiple)
 iscsiadm: Could not login to [iface: default, target: 
 iqn.2014-03.sharedstorage:target1, portal: 192.168.40.130,3260].
 iscsiadm: initiator reported error (8 - connection timed out)
 iscsiadm: Could not log into all portals

Were you at one point able to do discovery? I am not sure how discovery above 
failed, but here we see you have found targets?


These errors indicated the initiator cannot even do a tcp ip connection to the 
target. This is normally due to a network problem or because the target is not 
setup properly to accept connections on those portals from the specific 
initiator being used, or ip tables might be preventing us from reaching the 
target.

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

Re: iscsi login failure ubuntu 12.04

[Michael Christie]

On Jan 30, 2014, at 7:40 PM, ianil.ir...@gmail.com wrote:
 root@Blade15:~# iscsid -f -d 8
 iscsid: sysfs_init: sysfs_path='/sys'
 
 iscsid: sysfs_attr_get_value: open '/module/scsi_transport_iscsi'/'version'
 
 iscsid: sysfs_attr_get_value: new uncached attribute 
 '/sys/module/scsi_transport_iscsi/version'
 
 iscsid: sysfs_attr_get_value: add to cache 
 '/sys/module/scsi_transport_iscsi/version'
 
 iscsid: sysfs_attr_get_value: cache 
 '/sys/module/scsi_transport_iscsi/version' with attribute value '2.0-870'
 
 iscsid: transport class version 2.0-870. iscsid version 2.0-871
 iscsid: Can not bind IPC socket
 iscsid: in ctldev_close


You should kill all the iscsid instances then run that command. The above 
message means iscsid did not start.
Without iscsid nothing will work. It could be it was already started.


 
 
 
 root@Blade15:~# iscsiadm -m node -T 
 iqn.1986-03.com.hp:storage.p2000g3.13351a9162 -p 10.10.30.1:3260 --login
 Logging in to [iface: iface2, target: 
 iqn.1986-03.com.hp:storage.p2000g3.13351a9162, portal: 10.10.30.1,3260]
 Logging in to [iface: iface4, target: 
 iqn.1986-03.com.hp:storage.p2000g3.13351a9162, portal: 10.10.30.1,3260]
 iscsiadm: Could not login to [iface: iface2, target: 
 iqn.1986-03.com.hp:storage.p2000g3.13351a9162, portal: 10.10.30.1,3260]: 
 iscsiadm: initiator reported error (5 - encountered iSCSI login failure)
 iscsiadm: Could not login to [iface: iface4, target: 
 iqn.1986-03.com.hp:storage.p2000g3.13351a9162, portal: 10.10.30.1,3260]: 
 iscsiadm: initiator reported error (5 - encountered iSCSI login failure)
 


When you run that command send the /var/log/messages and also the iscsid output.

Also run iscsiadm with -d 8.

And does it work with just the defaults iface? Does it just not work when 
trying to setup your own faces?

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: PDU digests and discovery sessions

[Michael Christie]

On Dec 3, 2013, at 10:59 AM, wireis...@gmail.com wrote:

 I have discovered that open-iscsi treats discovery and normal sessions 
 differently with respect to login parameters. Regardless of the PDU digest 
 settings in the /etc/iscsid.conf configuration file, open-iscsi _always_ 
 attempts to establish discovery sessions with digests disabled. Is this by 
 design?
 
 For example, my configuration file contains:
 node.conn[0].iscsi.HeaderDigest = CRC32C,None

open-iscsi does not support header/data digests during discovery sessions. That 
is why there is no setting to config it and it is always None. The above 
setting is just for normal sessions.

What target are you using? I think you are the first person to ask about digest 
support for discovery sessions. I do not think I have seen a target with it 
supported (or if I did I never noticed it), so we never implemented it.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: iscsid: Kernel reported iSCSI connection 8:0 error (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error recovery) state (3)

[Michael Christie]

On Dec 8, 2013, at 8:39 PM, w00ste...@gmail.com wrote:

 I have a Synology DS1511+ NAS where I have 4 logical volumes shared via iscsi.
 2 of these are OCFS2 partitions, 2 are truecrypt encrypted partitions.
 
 I have lately started seeing errors such as :
 iscsid: Kernel reported iSCSI connection 8:0 error (1021 - 
 ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of SCSI error 
 recovery) state (3)
 followed by:
 kernel: [  121.788507]  connection7:0: detected conn error (1020)
 iscsid: conn 0 login rejected: target error (03/01)


Something is going wrong on the target side. Check its logs. The iscsi 
initiator 1021 error means that scsi commands took longer than the disk command 
timeout. The scsi error layer error handler ran and it could not fix the 
problem. We then tried to religion o the target but the target is returning 
03/01 which means the iscsi service/target is not operational.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: iscsi device created but disappears (mount: special device /dev/sdb1 does not exist)

[Michael Christie]

On Nov 18, 2013, at 9:21 AM, cputt...@gmail.com wrote:

 Hi
 
 Having an odd issue with a iscsi volume, following a forced reboot on the 
 server that uses it.
 
 Using iscsiadm to login to the target successfully (it has always been 
 manually attached and mounted for historic reasons). Logs indicate success 
 and expected device of /dev/sdb created:
 
 Nov 18 14:27:33 mail kernel: [28459.041132] scsi32 : iSCSI Initiator over 
 TCP/IP
 Nov 18 14:27:34 mail kernel: [28459.841119] scsi 32:0:0:0: Direct-Access 
 EQLOGIC  100E-00  4.3  PQ: 0 ANSI: 5
 Nov 18 14:27:34 mail kernel: [28459.841362] sd 32:0:0:0: [sdb] 1048596480 
 512-byte hardware sectors (536881 MB)
 Nov 18 14:27:34 mail kernel: [28459.842480] sd 32:0:0:0: [sdb] Write Protect 
 is off
 Nov 18 14:27:34 mail kernel: [28459.842490] sd 32:0:0:0: [sdb] Mode Sense: ad 
 00 00 00
 Nov 18 14:27:34 mail kernel: [28459.842633] sd 32:0:0:0: [sdb] Write cache: 
 disabled, read cache: enabled, doesn't support DPO or FUA
 Nov 18 14:27:34 mail kernel: [28459.842788] sd 32:0:0:0: [sdb] 1048596480 
 512-byte hardware sectors (536881 MB)
 Nov 18 14:27:34 mail kernel: [28459.843620] sd 32:0:0:0: [sdb] Write Protect 
 is off
 Nov 18 14:27:34 mail kernel: [28459.843630] sd 32:0:0:0: [sdb] Mode Sense: ad 
 00 00 00
 Nov 18 14:27:34 mail kernel: [28459.843765] sd 32:0:0:0: [sdb] Write cache: 
 disabled, read cache: enabled, doesn't support DPO or FUA
 Nov 18 14:27:34 mail kernel: [28459.843770]  sdb: sdb1
 Nov 18 14:27:34 mail kernel: [28459.844284] sd 32:0:0:0: [sdb] Attached SCSI 
 disk
 Nov 18 14:27:34 mail kernel: [28459.844319] sd 32:0:0:0: Attached scsi 
 generic sg8 type 0
 
 Running the usual command to mount it however returns:
 
 mount: special device /dev/sdb1 does not exist


Is there a /dev/sdb1 node and does iscsiadm -m session -P 3 show that the 
session is correctly (check that the state
in the command output is logged in) relogged into the target for that device?

What distro is this with?

You might be hitting a issue where udev deletes the node when there is a error 
on the disk but then does not add
the /dev/sdb1 node back when the problem is fixed because it does not know that 
the disks is back. I have seen this
with RHEL.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Distro network scripts and root-on-iscsi interface: what is the recommended practice?

[Michael Christie]

On Aug 11, 2013, at 8:39 AM, ppcner8x8x ascanio.al...@gmail.com wrote:

 What is the recommended behaviour of distro network scripts with the 
 root-on-iscsi interface?
 

If sessions are logged in then when iscsid is started from the init 
scripts/systemd the network interfaces that iscsi uses must be up.


 My CentOS root-on-iscsi systems seems to configure all network interfaces 
 like a regular disk installation
 (controlled by /etc/sysconfig/network-scripts/ifcfg-ethX). This always seems 
 to cause a hiccup in init scripts:
 
  connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
 4294682021, last ping 4294687024, now 4294692032
  connection1:0: detected conn error (1011)
  connection2:0: detected conn error (1020)
  connection3:0: detected conn error (1020)
 

What version of Centos is this and did you setup root on iscsi using their 
install to iscsi option in the installer? When using the RHEL 6 iscsi root 
install path I did not hit that problem in the past. I assume Centos did not 
change any of the iscsi startup stuff.


 
 Won't this behaviour break the root disk session? Or is it supposed to be 
 tolerable: if the network scripts do the right thing
 there will be a route to a portal and the session will be reestablished?

As long as iscsid is up and the network eventually comes back up the session 
will be reestablished.


 
 Fedora 19 does something even more drastic: if rewrites the network 
 configuration with stuff obtained from the initramfs boot;
 this safe behaviour practically guarantees that the network configuration 
 will be compatible with that in the initramfs so finding 
 the target should be a no-brainer; nevertheless the interfaces are brought up 
 again (redundantly?).
 
 
 
 
 
 -- 
 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.
 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: for help

[Michael Christie]

You probably did not setup the target correctly. Take a tcpdump/wireshark trace 
and when you login look at the REPORT_LUNS and INQUIRY command results. Do they 
indicate disks there?

On Aug 11, 2013, at 8:20 AM, cxywms cxy...@163.com wrote:

 Hi,
 OPEN-ISCSI TEAM
 I have a problem that there is two iscsi disks and I can discovery them,I 
 login in the disks ,the two disks indicate that login in successfull.But,When 
 I take the order
 fdisk -l .only one disk can find in the direction /dev.so what's wrong with 
 my problem?
 the iscsiadm tools I modified it with a funciton ,and I use the function in 
 my program
 much helply you can help me.thank you very much!
  
  
 2013-08-11
 cxywms
 
 -- 
 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.
 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH RFC] SCSI/libiscsi: Reduce locking contention in fast path

[Michael Christie]

 Tomorrow. Reviewing the qlogic net ones then have this on my todo.

On Aug 12, 2013, at 5:00 PM, Or Gerlitz or.gerl...@gmail.com wrote:

 On Thu, Aug 8, 2013 at 4:25 PM, Or Gerlitz ogerl...@mellanox.com wrote:
 Replace the session lock with two locks, a forward lock and
 a backwards lock named frwd_lock and back_lock respectively.
 
 The forward lock protects resources that change while sending a
 request to the target, such as cmdsn, queued_cmdsn, and allocating
 task from the commands' pool with kfifo_out.
 
 The backward lock protects resources that change while processing
 a response or in error path, such as cmdsn_exp, cmdsn_max, and
 returning tasks to the commands' pool with kfifo_in.
 
 Under a steady state fast-path situation, that is when one
 or more processes/threads submit IO to an iscsi device and
 a single kernel upcall (e.g softirq) is dealing with processing
 of responses without errors, this patch eliminates the contention
 between the queuecommand()/request response/scsi_done() associated
 with iscsi sessions.
 
 Using this patch in an accelerated version of the iser initiator we were
 able to gain large improvements in IOPS rate in a situation where the burning
 bottle-neck was the session lock.
 
 Hi Mike and Co.
 
 Any feedback on this patch?
 
 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.
 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH V1] IB/iser: Add Discovery support

[Michael Christie]

On Jul 31, 2013, at 5:35 AM, Or Gerlitz ogerl...@mellanox.com wrote:

 To run discovery over iSER we need to advertize the CAP_TEXT_NEGO capability
 towards user space. Also need to make sure the login RX buffer is posted when
 SendTargets TEXT PDUs are sent. For that end, we use a setting of the
 ISCSI_PARAM_DISCOVERY_SESS iscsi param as an indication that this is 
 discovery 
 session.
 
 Signed-off-by: Or Gerlitz ogerl...@mellanox.com
 ---
 
 changes from V0:
 
 - applied feedback from Mike
 -- moved the iscsi_set_param part to libiscsi.c
 -- advertize ISCSI_PARAM_DISCOVERY_SESS too in iser_attr_is_visible
 
 To apply this patch need to pick these two patches
 
 [PATCH V1 1/4] scsi_transport_iscsi: Exporting new attrs for iscsi session 
 and connection in sysfs
 http://marc.info/?l=linux-scsim=137225028829588w=2
 
 [PATCH V1 2/4] libiscsi: Exporting new attrs for iscsi session and connection 
 in sysfs
 http://marc.info/?l=linux-scsim=137225028829588q=raw

Patch looks ok to me. Did you intend for me to pass this along to 
linux-scsi/James or did you mean to cc that list or were you going to resend to 
that list? Let me know what you prefer. It does not matter to me.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] IB/iser: Add Discovery support

[Michael Christie]

On Jul 2, 2013, at 4:59 PM, Or Gerlitz or.gerl...@gmail.com wrote:

 that's too bad, he wrote Linus that this pull request is the 1st for
 the 3.11 merge window, so if there's another one, the patches of Vikas
 deserve to be there

It might still make it then.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] IB/iser: Add Discovery support

[Michael Christie]

On Jun 27, 2013, at 2:57 PM, Or Gerlitz or.gerl...@gmail.com wrote:

 On Thu, Jun 27, 2013 at 7:25 PM, Mike Christie micha...@cs.wisc.edu wrote:
 
 On 06/27/2013 08:46 AM, Or Gerlitz wrote:
 @@ -501,6 +503,18 @@ iscsi_iser_set_param(struct iscsi_cls_conn
 *cls_conn,
  return -EPROTO;
  }
  break;
 + case ISCSI_PARAM_DISCOVERY_SESS:
 + sscanf(buf, %d, value);
 + conn = cls_conn-dd_data;
 + session = conn-session;
 + if (value) {
 + session-discovery_sess = 1;
 + iser_err(session is discovery!\n);
 + } else {
 + session-discovery_sess = 0;
 + iser_err(session is normal!\n);
 + }
 + break;
  default:
 
 This should go into libiscsi.c iscsi_set_param() since it is the same
 for all drivers.
 
 I see, are you OK with this being still one patch that touches iser
 but also adds this case to iscsi_set_param()? do we have any evidence

That is fine with me although as you know some other reviewers prefer the one 
patch per change. So you can risk it if you want.



 that the two patches this one depends on are going to be merged for
 3.11?


James tried to merge it for 3.11, but it got dropped due to a merging conflict, 
so next release.

 
 You also need to add ISCSI_PARAM_DISCOVERY_SESS in iser_attr_is_visible
 so that the transport class will setup the sysfs file stuff for it.
 
 thanks, BTW what happens if I don't do that, is set_param for this
 item from user-space not going to reach the kernel, or something else.

Right. If you do not set it then the sysfs file to read it will not get set and 
the kernel code will not call into the driver/lib/class to set it.


-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] iscsid: Fix strlen parameter

[Michael Christie]

On Jun 26, 2013, at 7:45 AM, Jan Vesely jves...@redhat.com wrote:

 From: Jan Vesely jves...@redhat.com
 
 The target socket name is passed as parameter, don't use the hardwired
 one.


Thanks. Merged in commit b0ba4d6288f87d33508add1b680cf22d2c3dbfe4.

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [PATCH] iscsiuio: Change socket bind to use the same struct size as iscsid

[Michael Christie]

On Jun 26, 2013, at 8:55 AM, Jan Vesely jves...@redhat.com wrote:

 From: Jan Vesely jves...@redhat.com
 
 Without this patch connections to iscsiuio fail, and strace prints:
 
 connect(8, {sa_family=AF_FILE, path=@ISCSID_UIP_ABSTRACT_NAMESPACE}, 32) = 
 -1 ECONNREFUSED (Connection refused)
 
 Note that updating mgmt_ipc_listen and ipc_connect to use sizeof(addr) instead
 of the precomputed values also fixes the issue.
 Looks like (Null bytes in the name have no special significance.) [man 7 
 unix] is the culprit here.
 

I think I like that idea better since we would not have to worry about this 
issue all the time. However, I merged your patch in commit id 
3d7df63cc2978abf33733234ddbc50d075039ce3 for now. I will loom into the sizeof 
addr suggestion when I get time. 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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: How to contribute changes?

[Michael Christie]

Do you have a kernel driver too? Are you going to get that upstream?

I do not care if it closed source or if you are not going to get it upstream. 
Just wondering what other iscsi hardware is out there. I will merge the patch 
either way.

Can you say what ocs stands for?

On May 14, 2013, at 5:48 PM, Chris Moore cmoore...@gmail.com wrote:

 Sorry for the delayed reply.  Here's the change I'd like to see about getting 
 in:
 
 Thanks,
 
 Chris
 
 
 diff --git a/usr/transport.c b/usr/transport.c
 index e6e3dfc..83483c6 100644
 --- a/usr/transport.c
 +++ b/usr/transport.c
 @@ -97,6 +97,13 @@ struct iscsi_transport_template qla4xxx = {
   .ep_disconnect  = ktransport_ep_disconnect,
  };
  
 +struct iscsi_transport_template ocs = {
 + .name   = ocs,
 + .ep_connect = ktransport_ep_connect,
 + .ep_poll= ktransport_ep_poll,
 + .ep_disconnect  = ktransport_ep_disconnect,
 +};
 +
  static struct iscsi_transport_template *iscsi_transport_templates[] = {
   iscsi_tcp,
   iscsi_iser,
 @@ -105,6 +112,7 @@ static struct iscsi_transport_template 
 *iscsi_transport_templates[] = {
   bnx2i,
   qla4xxx,
   be2iscsi,
 + ocs,
   NULL
  };
 
 
 
 On Wed, May 1, 2013 at 8:28 AM, Mike Christie micha...@cs.wisc.edu wrote:
 On 04/25/2013 06:06 PM, Chris Moore wrote:
  I'm working on adding open-isci support to a driver.  How would I go
  about getting changes accepted?
 
 Just post the changes to this list?
 
 We prefer the code in patch format, so you would something like
 
 git diff  some-name.patch
 
 or
 
 git format-patch some args
 
 or
 
 diff -aurp open-iscsi.original open-iscsi.work
 
 
 
 
  The only thing I'd need to change within open-iscsi is to add a new
  transport to usr/transport.c
 
  Thanks,
 
  Chris
 
  --
  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.
  
  

-- 
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: open-iscsi kernel

[Michael Christie]

I am not sure what the second sentence about it really being about the 
initiator means.

The kernel dir in the open-iscsi dir is not used any more for newer kernels. If 
you have a older supported kernel then you can use the kernel modules by doing

make kernel

They are not updated any more though. They are for older setups.

For newer kernels you should use the iscsi modules that come with a stable 
kernel.org kernel or a distro kernel.


On Apr 4, 2013, at 9:17 PM, Xianghua Xiao xiaoxiang...@gmail.com wrote:

 does the kernel sub directory in the source tree matter any more these days? 
 considering open-iscsi is really about the initiator these days?
 
 thanks,
 xianghua
 
 -- 
 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.

Re: iscsiadm documentation on sendtargets/st inexact

[Michael Christie]

On Feb 18, 2013, at 1:43 AM, Jan Engelhardt jeng...@inai.de wrote:

 
 iscsiadm(8) in open-iscsi-2.0.870 documents:
 
 -t, --type=type
   type must be sendtargets (or abbreviated as st), slp, isns or fw.
 
 However, sendtargets and st seem to work differently, in that st
 autocreates an entry, while sendtargets does not. Their output is
 also different.
 
 linux-d9i5:~ # iscsiadm -m discovery -t SendTargets -p 10.10.7.115

You know too much about the iSCSI spec :)

See the formatting you quoted from the man page. It works the same if you pass 
in sendtargets and not SendTargets like how it is described in the iSCSI 
pec. The code uses getopt_long which seems to check the case.



 iscsiadm: discovery record [10.10.7.115,3260] not found!
 linux-d9i5:~ # iscsiadm -m discovery -t st -p 10.10.7.115
 10.10.7.115:3260,1 iqn.2003-01.org.linux-iscsi.rtsnode1.x8664:sn.c4678a837b19
 linux-d9i5:~ # iscsiadm -m discovery -t SendTargets -p 10.10.7.115

Because of the mixed case SendTargets is hitting the unknown discovery type 
code paths, and tries to look for discovery records with the ip passed in. The 
first time you ran the command there were none so it reported error. Here you 
did a successful discovery command above, so it printed the discovery record 
info. that was setup when you ran the successful discovery command.

-- 
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: Antw: Re: iscsiadm documentation on sendtargets/st inexact

[Michael Christie]

On Feb 19, 2013, at 3:07 AM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de 
wrote:

 Michael Christie micha...@cs.wisc.edu schrieb am 19.02.2013 um 06:42 in
 Nachricht 75829b62-f5b7-4a3e-9adb-b1e888a31...@cs.wisc.edu:
 
 On Feb 18, 2013, at 1:43 AM, Jan Engelhardt jeng...@inai.de wrote:
 [...]
 
 iscsiadm: discovery record [10.10.7.115,3260] not found!
 linux-d9i5:~ # iscsiadm -m discovery -t st -p 10.10.7.115
 10.10.7.115:3260,1 
 iqn.2003-01.org.linux-iscsi.rtsnode1.x8664:sn.c4678a837b19
 linux-d9i5:~ # iscsiadm -m discovery -t SendTargets -p 10.10.7.115
 
 Because of the mixed case SendTargets is hitting the unknown discovery type 
 code paths, and tries to look for discovery records with the ip passed in. 
 The first time you ran the command there were none so it reported error. 
 Here 
 you did a successful discovery command above, so it printed the discovery 
 record info. that was setup when you ran the successful discovery command.
 
 Mike,
 
 what about a warning like this:
 Warning: using unknown discovery type \%s\...
 
 I don't know the internals, but if the code gets lost anyway for an unknown 
 discovery type, the warning should be an error. It's a bad idea to let the 
 code get lost for unexpected input.


You are right. There are a couple places where we go down the default path when 
bad input is passed in. I am going to fix that in a bit. I am having hard drive 
issues right now, so will probably get to it later this week.

-- 
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: Antw: Re: iscsiadm documentation on sendtargets/st inexact

[Michael Christie]

On Feb 19, 2013, at 3:07 AM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de 
wrote:

 Michael Christie micha...@cs.wisc.edu schrieb am 19.02.2013 um 06:42 in
 Nachricht 75829b62-f5b7-4a3e-9adb-b1e888a31...@cs.wisc.edu:
 
 On Feb 18, 2013, at 1:43 AM, Jan Engelhardt jeng...@inai.de wrote:
 [...]
 
 iscsiadm: discovery record [10.10.7.115,3260] not found!
 linux-d9i5:~ # iscsiadm -m discovery -t st -p 10.10.7.115
 10.10.7.115:3260,1 
 iqn.2003-01.org.linux-iscsi.rtsnode1.x8664:sn.c4678a837b19
 linux-d9i5:~ # iscsiadm -m discovery -t SendTargets -p 10.10.7.115
 
 Because of the mixed case SendTargets is hitting the unknown discovery type 
 code paths, and tries to look for discovery records with the ip passed in. 
 The first time you ran the command there were none so it reported error. 
 Here 
 you did a successful discovery command above, so it printed the discovery 
 record info. that was setup when you ran the successful discovery command.
 
 Mike,
 
 what about a warning like this:
 Warning: using unknown discovery type \%s\...
 
 I don't know the internals, but if the code gets lost anyway for an unknown 
 discovery type, the warning should be an error. It's a bad idea to let the 
 code get lost for unexpected input.


You are right. There are a couple places where we go down the default path when 
bad input is passed in. I am going to fix that in a bit. I am having hard drive 
issues right now, so will probably get to it later this week.

-- 
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: iscsiadm logging off and back on to initiator during reboot HOWTO please?

[Michael Christie]

On Feb 16, 2013, at 11:18 PM, David Hostetler dbhostte...@gmail.com wrote:

 Okay still learning. Sorry about the dumb newb questions on this subject. The 
 only docs I have found so far are the man pages... So let's get down to brass 
 tacks shall we?
 
 I have 3 CentOS 6.3 64 bit boxes, one running an eSATA RAID array and acting 
 as an iSCSI target, the other two are iSCSI initiators. The initiators share 
 a file a GFS2 filesystem, and everything works great, until either the 
 target, or one of the initiators is rebooted for something like a kernel 
 patch...
 
 If an initiator gets rebooted, it has to be logged off of the target, the 
 session rescanned, and then logged back in, THEN it all seems to work well 
 again. This is true for both initiators, if the target gets rebooted for the 
 same kernel patch, well BOTH initiators need the procedure done to bring 
 storage back online…

When a initiator box is rebooted then when the box starts up again the 
initiators should be getting logged back in automatically when the iscsid and 
iscsi init scripts run. Make sure the node.startup setting is set to automatic 
for sessions you want to auto login. Check out the 
/usr/share/docs/iscsi-initiator-utils-*/README for more info.

When the target reboots, then you should not have to run anything on the 
initiator side if it was logged in when you reboot the target. The initiator 
should try to relogin while the target is down and then the target is back they 
will login and rescan. They will not remove old luna though, so if you need to 
do that then you would need to run something like the scsi rescan bus script 
(it is in the sg3_utils rpm) that comes with Centos.

-- 
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: Controlling ISID values

[Michael Christie]

On Feb 17, 2013, at 11:01 AM, אייל בן דוד bde...@gmail.com wrote:

 Hi,
 
 Thanks for your answer.
 
 2013/2/14 Mike Christie micha...@cs.wisc.edu
 On 02/13/2013 08:38 AM, bde...@gmail.com wrote:
  Hello all,
 
  In order to test a storage device I would like to set ISID in advance
  (e.g same ISID for two different sessions, same ISID after for reconnect
  etc)
 
  Is it possible to set the ISID values?
 
 No.
 
  Who actually determines these values?
 
 The iscsi initiator. See open-iscsi/usr/initiator.c:__session_create().
 
 session-isid[0] = DRIVER_ISID_0;
 session-isid[1] = DRIVER_ISID_1;
 session-isid[2] = DRIVER_ISID_2;
 session-isid[3] = 0;
 session-isid[4] = 0;
 session-isid[5] = 0;
 
 That code inits the first couple bits. Then in session_conn_poll() we
 set the last couple bits based on kernels id for the session.
 
 session-isid[3] = session-id;
 
 
 Yup, I understood from this line that the ISID has a kernel part too, which 
 makes my request more complicated to implement.
  

It does not. You can stick whatever you want in that isid value. The initiator 
does not care. We use the kernel's sid for part of the iSID, but there is 
mapping/lookup between the values. We set the value and we never look at it 
again. We just needed a unique value and so we use the kernel's sid value for 
that. You can set it to whatever makes you happy. Do not worry about the kernel 
code.

-- 
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: Meaning of SCSI return codes?

[Michael Christie]

#define DID_TRANSPORT_FAILFAST  0x0f /* Transport class fastfailed the io */

It means the replacement/recovery timeout fired and the iscsi/scsi layer failed 
the IO.


On Feb 18, 2013, at 12:26 PM, yying...@gmail.com wrote:

 what sd 5:0:0:0: SCSI error: return code = 0x000f means?
 
 
 On Thursday, September 13, 2007 2:48:45 PM UTC-5, Mike Anderson wrote:
 Mike Christie mich...@cs.wisc.edu wrote:
  DID_ABORT if the scsi error handler asked us to abort a command and it 
  was successfully aborted we fail it with this.
  
   kernel: sd 2:0:0:1: SCSI error: return code = 0x0600
  
  Not sure, but I will look deeper.
 
 DRIVER_TIMEOUT.
 You had a timeout on your IO.
 
 -andmike
 --
 Michael Anderson
 and...@us.ibm.com
 
 
 
 -- 
 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.

Re: Software iSCSI Error Handler not getting enabled

[Michael Christie]

On Feb 13, 2013, at 1:23 PM, Gowrav Mahadevaiah gowrav...@gmail.com wrote:

 HI,
 
 I'm working on the a Software iSCSI configuration with IPv4 iSCSI session and 
 want to enable iscsi error handling debug flag  for analyzing an issue. Here 
 is the steps i followed to enable error handling debug --
 
 echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh
 
 The other 2 debug parameters debug_libiscsi_conn  and 
 debug_libiscsi_session are at value '0'. But, after enable 
 debug_libiscsi_eh flag, I do not see the iscsi verbose error handling 
 messages in the /var/log/message file. Am I missing any other setting here?
 

That is all you have to do.

How do you know you are running a test that exercises the scsi iscsi eh code 
paths? Are you seeing aborts/resets get sent by watching the wire with 
tcpdump/wrireshark or can you see them reach the target side?


 If I enable debug_libiscsi_conn or debug_libiscsi_session flags I see its 
 corresponding verbose iSCSI messages.
 
 I even tried increasing the iscsid debug level (iscsid -d 8), but it did not 
 help either. Please let me know if I missed configuration.
 
 I'm using software iSCSI pkg -- iscsi-initiator-utils-6.2.0.872-41, on kernel 
 -- 2.6.32.279.


Is that the kernel that comes with RHEL 6.3? If so, I just tried it here and it 
work ok for me.

-- 
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: iscsiadm returns 'This is not supported with software iSCSI (iscsi_tcp).' Now what?

[Michael Christie]

On Jan 24, 2013, at 4:03 AM, levi.govae...@gmail.com wrote:
 
 iscsiadm: iface_for_each_iface found iqn.2000-01.com.synology
 iscsiadm: looking for iface conf /etc/iscsi/ifaces/iqn.2000-01.com.synology
 iscsiadm: updated 'iface.iscsi_ifacename', 'iqn.2000-01.com.synology' = 
 'iqn.2000-01.com.synology'
 iscsiadm: updated 'iface.ipaddress', '' = '192.168.1.20'
 

This, iface.ipaddress, is not supported, and is why you get the error below and 
later connection failure.


 iscsiadm: Cannot bind 192.168.1.20 to net/scsi interface. This is not 
 supported with software iSCSI (iscsi_tcp).



-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
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: Initiator name missing

[Michael Christie]

You have a older version.

Just rm the old setup files:

rm /etc/iscsi/nodes
rm /etc/iscsi/send_targets

or your version/distro might put it in /var/lib

rm /var/lib/iscsi/nodes
rm /var/lib/iscsisend_targets


Also make sure that in iscsid.conf both the discovery username/password and 
node username/password settings are removed.




On Jan 4, 2013, at 6:37 PM, Jeff Bye jeff...@gogoluckey.com wrote:

 2.0-871 is what I'm running
 
 Jeff
 
 On Fri, Jan 4, 2013 at 4:17 PM, Jeff Bye jeff...@gogoluckey.com wrote:
 I tried all of the commands and none of them worked for me:
 
 deadlineserver@deadlineserver ~ $ iscsiadm -m discoverydb -t st -p 
 10.10.0.1:3260 -o delete
 iscsiadm -m discovery [ -hV ] [ -d debug_level ] [-P printlevel] [ -t type -p 
 ip:port -I ifaceN ... [ -l ] ] | [ -p ip:port ] [ -o operation ] [ -n name ] 
 [ -v value ]
 iscsiadm -m node [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -L 
 all,manual,automatic ] [ -U all,manual,automatic ] [ -S ] [ [ -T targetname 
 -p ip:port -I ifaceN ] [ -l | -u | -R | -s] ] [ [ -o  operation  ] [ -n name 
 ] [ -v value ] ]
 iscsiadm -m session [ -hV ] [ -d debug_level ] [ -P  printlevel] [ -r 
 sessionid | sysfsdir [ -R | -u | -s ] [ -o operation ] [ -n name ] [ -v value 
 ] ]
 iscsiadm -m iface [ -hV ] [ -d debug_level ] [ -P printlevel ] [ -I ifacename 
 ] [ [ -o  operation  ] [ -n name ] [ -v value ] ]
 iscsiadm -m fw [ -l ]
 iscsiadm -m host [ -P printlevel ] [ -H hostno ]
 iscsiadm -k priority
 
 
 I checked man iscsiadm and found:
  -m, --mode op
   specify the mode. op must be one of discovery, node, fw, host 
 iface or session.
 
   If  no  other  options are specified: for discovery and node, 
 all of their respective records
   are displayed; for session, all active sessions and connections 
 are displayed;  for  fw,  all
   boot  firmware  values are displayed; for host, all iSCSI hosts 
 are displayed; and for iface,
   all ifaces setup in /etc/iscsi/ifaces are displayed.
 
 Am I running the wrong version perhaps?
 
 Jeff
 
 
 
 On Thu, Jan 3, 2013 at 7:05 PM, Mike Christie micha...@cs.wisc.edu wrote:
 The iscsid.conf values are the defaults one used to setup the
 port/node/target db. If you clear the iscsid.conf values, you would
 still need to update the db ones for it to take effect on existing
 targets you have already setup.
 
 For the discovery values you can either delete the old discovery record:
 
 iscsiadm -m discoverydb -t st -p ip -o delete
 
 When you run the discovery command next, then it will use the
 iscsid.conf settings to create the discovery record.
 
 or if your tools does not support that command you can clear the chap
 settings
 
 iscsiadm -m discoverydb -t st -p ip -o update -n
 discovery.sendtargets.auth.username -v 
 iscsiadm -m discoverydb -t st -p ip -o update -n
 discovery.sendtargets.auth.password -v 
 iscsiadm -m discoverydb -t st -p ip -o update -n
 discovery.sendtargets.auth.authmethod -v none
 
 
 On 01/03/2013 01:46 PM, Jeff Bye wrote:
  Hey!  I've been out of town for a couple of weeks.  Hope you had a
  chance to take some time off as well :)
 
  It seems that the username and password I had initially set up is still
  being used, however in iscsid.conf CHAP is set to none and any other
  information has been commented.  Does this only affect the target side?
 
  Jeff
 
  When I had it running on a windows machine (a temporary setup) we kept
  it open and
  On Fri, Dec 21, 2012 at 1:32 AM, Mike Christie micha...@cs.wisc.edu
  mailto:micha...@cs.wisc.edu wrote:
 
  On 12/20/2012 06:54 PM, GGL wrote:
   deadlineserver@deadlineserver / $ sudo iscsiadm -m discovery -t
   sendtargets -p 10.10.0.1
   iscsiadm: Login authentication failed with target
 
  Yeah, this is a CHAP failure. Is it turned off on the target too?
 
  Could you run
 
   sudo iscsiadm -m discovery -t sendtargets -p 10.10.0.1 -d 8
 
  and send all the output?
 
  Also while running this command run:
 
  tcpdump -w iscsi.discovery.out -i your_eth_device
 
  and then send that iscsi.discovery.out file. It will show us what the
  target is sending on the wire too.
 
 
  Both of those files will have passwords in them if you have CHAP
  settings still being used, so send me them in private or edit out the
  values if you do not want them on the open.
 
 
 
 
  --
  Jeff Bye
  Graphics Coordinator
  Liberty Post
  12910 Culver Blvd. Suite G
  Los Angeles, CA 90066
  (310) 314-3900 x247
 
  --
  You received this message because you are subscribed to the Google
  Groups open-iscsi group.
  To post to this group, send email to open-iscsi@googlegroups.com.
  To unsubscribe from this group, send email to
  open-iscsi+unsubscr...@googlegroups.com.
  For more options, visit this group at
  http://groups.google.com/group/open-iscsi?hl=en.
 
 
 
 
 -- 
 Jeff Bye
 Graphics Coordinator
 Liberty Post
 12910 Culver Blvd. Suite G
 Los Angeles, 

Re: Limit iscsi drive 2TB in Centos 6.3 ??

[Michael Christie]

The iSCSI initiator layer does not control/manage this. It looks like it might 
be a target issue since we see both the scsi layer and sg utile reporting zero 
logical blocks.

Are you using SCST for the target, or did you buy a target from some vendor 
that is using SCST?


On Dec 30, 2012, at 8:41 AM, Didenko iru...@gmail.com wrote
 scsi5 : iSCSI Initiator over TCP/IP
 scsi 5:0:0:0: Direct-Access SCST_FIO BZ 200 PQ: 0 ANSI: 5
 sd 5:0:0:0: Attached scsi generic sg1 type 0
 sd 5:0:0:0: [sdb] 0 512-byte logical blocks: (0 B/0 B
 
 


 [root@localhost ~]# sg_readcap --16 /dev/sdb
 Read Capacity results:
 Protection: prot_en=0, p_type=0, p_i_exponent=0
 Thin provisioning: tpe=0, tprz=0
 Last logical block address=18446744073709551615 (0x), Number 
 of logical blocks=0
 Logical block length=512 bytes
 Logical blocks per physical block exponent=3
 Lowest aligned logical block address=0
 Hence:
 Device size: 0 bytes, 0.0 MiB, 0.00 GB
 
 


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Can I set up multiple initiators using open-iscsi?

[Michael Christie]

On Dec 5, 2012, at 10:36 PM, Lee Duncan leeman.dun...@gmail.com wrote:

 
 On Dec 5, 2012, at 8:12 PM, Mike Christie micha...@cs.wisc.edu wrote:
 
 On 12/04/2012 06:58 PM, Lee Duncan wrote:
 On Dec 4, 2012, at 4:51 PM, Mike Christie micha...@cs.wisc.edu wrote:
 
 On 12/04/2012 05:22 PM, Lee Duncan wrote:
 Hi Mike:
 
 I am trying to create a Persistent Reservations test suite for iSCSI 
 targets, and i was wondering if I could use open-iscsi on the initiator 
 side to do that.
 
 Part of the requirement is that I need to support multiple I_T Nexuses, 
 since Group Reservations are based on the I_T Nexus. If I can send from 
 multiple initiators on the same host, I could eliminate the current 
 requirement to test from multiple hosts.
 
 
 You can create multiple initiators. Just create ifaces with different
 initiator names. The problem though is that the iSID is not persistent
 across logins, so if you were to login/logout using iscsiadm from the
 target for any reason then the persistent reservations are going to get
 messed up.
 
 
 Would that be a problem for Persisting a reservation in general, then?
 
 Not sure what you mean exactly. If you are using the reservation for
 just the life of the session then no, but I do not think that is common.
 It seems like you are likely to reboot your box or login/logout of the
 target once in a while.
 
 
 
 The idea with Persistent Reservations is that they should persist across 
 target power outages.
 
 But if the iSID changes with a new connection, then when the target comes 
 back it might not recognize the

As long as you do not run iscsiadm ….  --logout then iscsiadm …. --login you 
are ok. The iSID is based on the session-id, and that only changes when a new 
session struct is allocated.  The session struct is only allocated a iscsiadm … 
-login time.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: open-iscsi - Cant reconnect after moving a VM - connection1:0: detected conn error (1021)

[Michael Christie]

On Dec 3, 2012, at 1:31 AM, Nico Visser nicolaas.vis...@gmail.com wrote:

 
 Environment:
 NETAPP SAN storage
 Hyper-V Cluster
 OS: Cloud Linux 6.3
 
 Im in the process of moving individual VM's off to a separate Hyper-V cluster 
 as we are having some stability issues.
 The VM connects fine to iscsi, but when I've copied the VHD over to the new 
 cluster and power it on , I cant reconnect to the iscsi targets anymore.
 
 Even when attempting to connect to the a new lun with a different initiator 
 name the issue persists 
 
 Ive attempted to 
 
 stop iscsi 
 log out of the session 
 delete the session
 and to remove everything under /var/lib/iscisi
 
 When attempting to reconnect, I can see the session and even the /dev/sdc and 
 /dev/sdd drives that the session provisions
 
 
 iscsiadm --mode session
 tcp: [1] x.x.x.x:3260,7 iqn.1992-08.com.netapp:xxx
 
 
 root@lnxwebr02 [~]# iscsiadm --mode session -P 3
 ..
 ..….


Don't cut the part of the output that shows the session/connection state.



 
 
 Attached SCSI devices:
 
 Host Number: 4State: running
 scsi4 Channel 00 Id 0 Lun: 0
 Attached scsi disk sdcState: running
 scsi4 Channel 00 Id 0 Lun: 1
 Attached scsi disk sddState: running
 
 However the logs shows buffer io errors
 
 Dec  3 09:23:21 lnxwebr02 kernel: [ 1094.018336] Buffer I/O error on device 
 sdc, logical block 0
 Dec  3 09:24:18 lnxwebr02 kernel: [ 1151.062556] Buffer I/O error on device 
 sdd, logical block 0
 
 and connection errors
 
 Dec  3 09:12:05 lnxwebr02 kernel: [  418.382452] scsi4 : iSCSI Initiator over 
 TCP/IP
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.698600] scsi 4:0:0:0: Direct-Access  
NETAPP   LUN  8020 PQ: 0 ANSI: 5
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.700035] sd 4:0:0:0: Attached scsi 
 generic sg2 type 0
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.706815] scsi 4:0:0:1: Direct-Access  
NETAPP   LUN  8020 PQ: 0 ANSI: 5
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.706842] sd 4:0:0:0: [sdc] 1572990976 
 512-byte logical blocks: (805 GB/750 GiB)
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.708974] sd 4:0:0:1: Attached scsi 
 generic sg3 type 0
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.712961] sd 4:0:0:1: [sdd] 419430400 
 512-byte logical blocks: (214 GB/200 GiB)
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.713334] sd 4:0:0:0: [sdc] Write 
 Protect is off
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.714268] sd 4:0:0:0: [sdc] Write 
 cache: disabled, read cache: enabled, doesn't support DPO or FUA
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.715730] sd 4:0:0:1: [sdd] Write 
 Protect is off
 Dec  3 09:12:06 lnxwebr02 kernel: [  418.716605] sd 4:0:0:1: [sdd] Write 
 cache: disabled, read cache: enabled, doesn't support DPO or FUA
 Dec  3 09:12:06 lnxwebr02 iscsid: Connection1:0 to [target: 
 iqn.1992-08.com.netapp:wnlsfas3240b, portal: 10.11.52.12,3260] through 
 [iface: default] is operational now
 Dec  3 09:12:29 lnxwebr02 PAM-hulk[2881]: failed to connect stream socket
 Dec  3 09:12:52 lnxwebr02 kernel: [  418.719682]  sdc:
 Dec  3 09:12:52 lnxwebr02 kernel: [  464.704180]  connection1:0: detected 
 conn error (1021)
 Dec  3 09:12:52 lnxwebr02 iscsid: Kernel reported iSCSI connection 1:0 error 
 (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of 
 SCSI error recovery) state (3)
 Dec  3 09:13:00 lnxwebr02 iscsid: connection1:0 is operational after recovery 
 (1 attempts)
 Dec  3 09:13:45 lnxwebr02 kernel: [  517.704102]  connection1:0: detected 
 conn error (1021)
 Dec  3 09:13:45 lnxwebr02 iscsid: Kernel reported iSCSI connection 1:0 error 
 (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of 
 SCSI error recovery) state (3)
 Dec  3 09:13:51 lnxwebr02 iscsid: connection1:0 is operational after recovery 
 (1 attempts)
 
 


It looks like you connected fine, but for some unknown reason the target stops 
responding to IO or we experience a slowdown. For some reason it takes a longer 
than the scsi command timeout worth of seconds (30 or 60 depending on your 
kernel and udev), and so the scsi error handler runs. It ends up dropping the 
connection and we end up reconnecting ok.

It could be that if you just copied the VHD file and now had 2 hosts with the 
same /etc/initiatorname.iscsi then each host will cause logouts for the other. 
The value in that file must be unique.



The Hung task error below just means the IO is taking loner than what you have 
set for your hung task timeout setting which looks like the default of 2 
minutes.



 I'm also seeing the following kernel message
 
 
 Dec  3 09:14:36 lnxwebr02 kernel: [  568.704067]  connection1:0: detected 
 conn error (1021)
 Dec  3 09:14:36 lnxwebr02 iscsid: Kernel reported iSCSI connection 1:0 error 
 (1021 - ISCSI_ERR_SCSI_EH_SESSION_RST: Session was dropped as a result of 
 SCSI error recovery) state 

Re: [RFC_V2 PATCH 1/2] iscsi_flash_sysfs: Add flash target mgmt support through sysfs.

[Michael Christie]

On Nov 9, 2012, at 5:35 AM, vikas.chaudh...@qlogic.com wrote:

 From: Adheer Chandravanshi adheer.chandravan...@qlogic.com
 
 This patch allows iscsiadm to manage iSCSI target information stored on
 adapter flash on per host basis.
 
 The sysfs entries will look as cited below:
 /sys/firmware/iscsi_offload/host1/new
 /sys/firmware/iscsi_offload/host1/delete
 /sys/firmware/iscsi_offload/host1/tgt0/logout
 /sys/firmware/iscsi_offload/host1/tgt0/login
 /sys/firmware/iscsi_offload/host1/tgt0/apply
 /sys/firmware/iscsi_offload/host1/tgt0/Target attributes
 
 Here - new, delete, login, logout and apply are the operations which iscsiadm
 can perform on each target entry.

Hey,

One major issue I had with the patch is that I do not see why we need a new 
interface for this. It seems that all this can be done with the existing iscsi 
class interface and then we do not have to add yet another iscsi interface. 
Just add the new files you need to the existing one.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: iscsi connection error 1020

[Michael Christie]

On Nov 6, 2012, at 9:54 AM, guidry.m...@gmail.com wrote:
 [root@holly ~]# iscsiadm -m node -p 172.16.50.1 -T 
 iqn.2001-05.com.equallogic:0-8a0906-172228806-45a001b4e1a50980-workflow-software-6
  --login
 Logging in to [iface: eth1, target: 
 iqn.2001-05.com.equallogic:0-8a0906-172228806-45a001b4e1a50980-workflow-software-6,
  portal: 172.16.50.1,3260] (multiple)
 iscsiadm: Could not login to [iface: eth1, target: 
 iqn.2001-05.com.equallogic:0-8a0906-172228806-45a001b4e1a50980-workflow-software-6,
  portal: 172.16.50.1,3260].
 iscsiadm: initiator reported error (8 - connection timed out)
 iscsiadm: Could not log into all portals
 
 [root@holly ~]# tail /var/log/messages
 Nov  6 10:21:22 holly kernel: session55: session recovery timed out after 120 
 secs
 Nov  6 10:21:26 holly iscsid: semop down failed 22
 Nov  6 10:25:05 holly kernel: scsi64 : iSCSI Initiator over TCP/IP
 Nov  6 10:25:14 holly kernel: connection56:0: detected conn error (1020)
 Nov  6 10:25:42 holly kernel: connection56:0: detected conn error (1020)
 Nov  6 10:26:09 holly kernel: connection56:0: detected conn error (1020)
 Nov  6 10:26:36 holly kernel: connection56:0: detected conn error (1020)
 Nov  6 10:27:03 holly kernel: connection56:0: detected conn error (1020)
 Nov  6 10:27:15 holly kernel: session56: session recovery timed out after 120 
 secs
 Nov  6 10:27:19 holly iscsid: semop down failed 22

So are some sessions getting setup ok and some are not?

Could you send all of the /var/log/messages?

When you see the 1020 errors above, what is in the target's log?

Did you try changing the rp_filter value? See the iscsi README and your kernel 
documentation.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Retry of failed I/O

[Michael Christie]

On Nov 6, 2012, at 8:49 AM, Suresh Rajagopalan r.raj...@gmail.com wrote:

 I'd like to find out what SAM codes in Tgtd notify open-iscsi  block
 layer to
 retry a failed
 I/O.
 
 To clarify, in the current tgtd backing store code (bs_rdwr.c), a
 failed read or writes
 sets the following:
 static void set_medium_error(int *result, uint8_t *key, uint16_t *asc
 {
*result = SAM_STAT_CHECK_CONDITION;
*key = MEDIUM_ERROR;
*asc = ASC_READ_ERROR;
 }
 
 
 While this retries failed reads, failed writes are not retried.   Is
 there a
 particular code that will notify the open-iscsi / client block layer
 to retry the
 I/O operation?

open-iscsi passes this to the scsi layer. See 
driver/scsi/scsi_error.c:scsi_decide_disposition(), sd.c:sd_done() and 
scsi_lib.c:scsi_io_completion() for your kernel.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Timeout settings not working?

[Michael Christie]

On Nov 2, 2012, at 4:35 PM, Ian Pilcher arequip...@gmail.com wrote:
 
 Checkout 8. Advanced Configuration of the readme in
 /usr/share/docs/iscsi-intiator-utils-$VERSION/REAMDE
 
 Believe me, I read that before posting.
 
 Ultimately, I just didn't realize that changes to the settings in
 iscsid.conf would not affect already discovered targets. 

Ok. I think that is a common mistake, because the tools are odd in that way. I 
will add some more notes in the README about that. Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Automatic deleting of LUNs possible? [WORKS w/PATCH]

[Michael Christie]

On Nov 3, 2012, at 10:51 AM, Amit amit.ut...@gmail.com wrote:

 Mike Christie michaelc@... writes:
 
 Regarding dev_loss_tmo, this has to be implemented at the kernel level
 correct? Since this feature is important to me, I can go ahead and try
 to implement that.
 
 
 Ok. Here is some info on the current status:
 
 Implement iSCSI dev loss support.
 
 Currently if a session is down for longer than replacement/recovery_timeout
 seconds, the iscsi layer will unblock the devices and fail IO. Other
 transport, like FC and SAS, will do something similar. FC has a
 fast_io_fail tmo which will unblock devices and fail IO, then it has a
 dev_loss_tmo which will delete the devices accessed through that port.
 
 iSCSI needs to implement dev_loss_tmo behavior, because apps are beginning
 to expect this behavior. An initial path was made here:
 http://groups.google.com/group/open-iscsi/msg/031510ab4cecccfd?dmode=source
 
 Since all drivers want this behavior we want to make it common. We need to
 change the patch in that link to add a dev_loss_tmo handler callback to the
 scsi_transport_template struct, and add some common sysfs and helpers
 functions to manage the dev_loss_tmo variable.
 
 
 Looked at the patch and with a little modification I was able to apply
 it to kernel 3.2.14. It works as advertised, thank you so much! The
 device gets removed after a certain number of seconds and I get a udev
 event that the device was removed.
 
 Any reason why this patch is not in the mainline? The only thing I
 noticed is that there are potential race conditions since the mutex was
 removed.


I have to retest. With the original code there was a hang/lockup due to some 
threading/workqueue issue. That code has not been rewritten in the upstream 
kernel and I think those changes fix my issue.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Automatic deleting of LUNs possible?

[Michael Christie]

On Nov 2, 2012, at 4:54 PM, Boaz Harrosh bharr...@panasas.com wrote:

 On 11/02/2012 12:47 PM, Mike Christie wrote:
 Yeah, I updated the iscsi dev loss tmo patch and posted it to the list.
 I think I hit some bugs with lots of sessions and lots of removals at
 the same time due to some workqueue/threading stuff or scsi locking
 issues. I did not get a chance to look into more.
 
 Before reposting I wanted to make the dev loss code generic and hook all
 transport into it since srp and sas wanted it too.
 
 
 Ha nice so you are already working on it? Nice that could come handy.
 Do you have some documentation on it? like what timeout/configuration
 controls when dev loss is triggered. Will it be a PM hot-unplug event
 or do we need new udev rules for it?


It will just work like the FC dev loss, but I wanted to move some of the code 
around. So there is just a timer that is set when the session/connection goes 
down. If the problem is not fixed within that timeout then the target and its 
devices are removed. That will send hot plug events like normal device 
deletion. Currently, tools like multipatthd handle this by removing the old 
paths.

I originally made this patch only for iscsi:

http://groups.google.com/group/open-iscsi/msg/031510ab4cecccfd?dmode=source

But at the last storage summit people were saying we should make it common code 
based off the core transport template, because SAS wanted it (and now SRP is 
adding it too).

Basically we just want to move the dev loss tmo and fast io fail callbacks to 
the scsi_transport and then move the timeout (setting of and handling) to 
common code. I also wanted to move some more handling of the command cleanup 
there too similar to how scsi_error.c handles cleanup/retry of commands.

I was working on this stuff for my old job (for the next RHEL), but since I 
have left I have not had a lot of time to work on iscsi initiator stuff.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: iSCSI timeouts on login with 32/64bit user/kernel

[Michael Christie]

On Nov 1, 2012, at 12:46 AM, Lisa Marie nullo...@sdf.org wrote:

 The problem with these type of patches has not been that we cannot find
 a solution that works on new setups with the patches. The problem is
 that we are not allowed to merge patches in the upstream kernel that
 break existing setups. For example if the user has only upgraded the
 kernel or only upgraded userspace tools, then we cannot break their
 setups. This patch does not work on 32 bit kernels/userpsace if the
 users only updates the tools.
 
 Per your request I've written a patch to allow for 32bit machines to work 
 with un-patched 32bit and 64bit kernels. It should be trivial to sunset this 
 patch with a kernel version number check when the kernel has the previous 
 patch I submitted applied.
 
 I've tested this patch on 32/32 and 32/64 with an unpatched kernel.

Does it work if the kernel is updated but you are using old tools?

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Automatic deleting of LUNs possible?

[Michael Christie]

On Oct 30, 2012, at 7:31 PM, amit.ut...@gmail.com wrote:

 
 I apologize if this has been asked in the list before, I did some
 research but did not find a clear answer/recommendation.
 
 Currently, I use udev to monitor new devices added by the open-iscsi
 initiator. This works great. However, when the target is disconnected I
 get timeout messages in the kernel log but the device nodes in /dev/
 still exists. Thus, no udev events.
 
 As noted in a few of the messages in the archives, doing a rescan does
 not automatically delete the LUNs. So the following script was
 suggested:
 
 scsi_sz=`sg_readcap /dev/sdko | grep address | sed s'/.*blocks=//'`
 kernel_sz=`cat /sys/block/sdko/device/block\:sdko/size`
 
 if (($scsi_sz==$kernel_sz)); then
 echo Good.
 else
 echo Do the deletion of the block device.
 echo 1  /sys/block/sdko/device/delete
 fi
 
 This looks like it will do the trick. But I am wondering if this is still
 the recommended approach as the above suggestion was made in 2008.

I do not know about recommended, but it will work, and we have not implemented 
something like dev_loss_tmo FC behavior so it is one of the only options.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Slow copy from Initiator to Target

[Michael Christie]

On Oct 18, 2012, at 11:51 PM, Muthuraman viv.mr...@gmail.com wrote:

 Hi Groups,
 
 I am also facing the same problem when I was read and write. The write 
 performance was bad. 
 Is there any workaround for this problem.
 

How bad? What is your setup? How are you driving IO? What tool? What arguments 
to that tool? What have you tried so far? What version of open-iscsi are you 
running? What kernel? What FS or are you doing direct IO?

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: XenServer - LUN iscsci

[Michael Christie]

On Oct 19, 2012, at 6:23 AM, pascal.roland...@gmail.com wrote:

 Hi,
 I'm running Xencenter on a r520.
 Got a Debian squeeze VM as file server.
 Just got a md1200 with 12*2Tb SAS drives that I attached to XenServer.
 How can I use this iscsi storage on the debian ? 

Not sure what you want to do. I think the md1200 is SAS only right? You cannot 
do iscsi directly to it. You would have to run a iscsi target on the box 
connected to the md1200, then export that storage as iscsi disks. You need to 
contact the Xen people to see what target they support, or contact dell to see 
if they recommend something, or you can search in google. Some popular open 
source iscsi targets are tgt, IET, SCST and LIO. They may or may not be 
supported by xen. When you got your iscsi target situation figured out, then 
you would use a initiator like open-iscsi (this list) to connect to that target 
and access the storage that you are exporting.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Slow copy from Initiator to Target

[Michael Christie]

On Oct 17, 2012, at 3:53 AM, targol...@gmail.com wrote:

 hi,
 
 I have a question, about Target and Initiator, is it a norman when i do copy 
 on mounted iscsi FS on Initiator, to see these files on Target after 10 or 20 
 sec? I thinking that ISCSI do this realtime or may I wrong?


iSCSI does not control when files show up. It depends on caching on the 
target/initiator and how the filesystems work.

How are you detecting the files on the target side?

Are you also mounting the FS on the target side? If you are seeing the data get 
copied on the wire but do not see the file on the FS mounted on the target side 
then it probably depends on how your target is caching the data. iSCSI the 
protocol has nothing to do with this, and the iscsi initiator has not much 
control over there (if your target supports it you can control the caching 
using some tools like in sg utils).

Are you just saying that the data is not showing up on the target for 10 to 20 
seconds, how are you determining this? Are you watching it with wireshark or 
tcpdump? It could depend on the caching in your app or FS.

If you are just saying the actual copy is taking 10 or 20 seconds then you need 
to provide some data about the file size and hw being used. 

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: [PATCH 1/2] ISCSID: Fixed the syncing of ibft/iscsi_boot disk connections with vlan

[Michael Christie]

On Oct 8, 2012, at 7:47 PM, Eddie Wai eddie@broadcom.com wrote:

 For the case when iscsid is invoked for the first time after pivot root
 during iSCSI boot, the boot connection would fail to re-connect if the
 ibft/iscsi_boot sysfs entry contains tagged vlan.
 
 The problem was caused by the lack of such info in the iscsi_session sysfs
 for sync_session to inherit from.
 
 The proposed solution is as follows:
 1. Utilize unique ifacename identifier for boot specific connections:
   old iface.name for the boot connection: transport.MAC
   new iface.name for the boot connection: transport.MAC.boot
 
 2. Upon sync_session, the session's ifacename will then be used to compare
   against the MAC+'boot' ifacename as generated from the ibft/iscsi_boot
   sysfs entries.  Upon a match, the additional params from the boot nic will
   then get passed to the sync_session's iface record for the reconnection 
 request.
 
 Signed-off-by: Eddie Wai eddie@broadcom.com
 ---
 usr/iface.c  |2 +-
 usr/iscsid.c |   38 +-
 2 files changed, 38 insertions(+), 2 deletions(-)
 
 diff --git a/usr/iface.c b/usr/iface.c
 index c86892e..98b1aed 100644
 --- a/usr/iface.c
 +++ b/usr/iface.c
 @@ -956,7 +956,7 @@ int iface_setup_from_boot_context(struct iface_rec *iface,
   strcpy(iface-transport_name, t-name);
 
   memset(iface-name, 0, sizeof(iface-name));
 - snprintf(iface-name, sizeof(iface-name), %s.%s,
 + snprintf(iface-name, sizeof(iface-name), %s.%s.boot,


This will not work for qla4xxx/be2iscsi. We actually needed to change that so 
that it matches the kernel based iface naming.


iface-transport_name, context-mac);
   strlcpy(iface-hwaddress, context-mac,
   sizeof(iface-hwaddress));
 diff --git a/usr/iscsid.c b/usr/iscsid.c
 index b4bb65b..295a29e 100644
 --- a/usr/iscsid.c
 +++ b/usr/iscsid.c
 @@ -51,6 +51,7 @@
 #include discoveryd.h
 #include iscsid_req.h
 #include iscsi_err.h
 +#include fw_context.h
 
 /* global config info */
 struct iscsi_daemon_config daemon_config;
 @@ -186,6 +187,30 @@ setup_rec_from_negotiated_values(node_rec_t *rec, struct 
 session_info *info)
   }
 }
 
 +static int iscsi_match_boot(struct iface_rec *iface,
 + struct list_head *targets)
 +{
 + struct boot_context *context;
 + int rc = -ENODEV;
 +
 + if (!iface)
 + return rc;
 + if (!strstr(iface-name, .boot))
 + return rc;
 +
 + /* Find the matching boot nic */
 + list_for_each_entry(context, targets, list) {
 + if (strstr(iface-name, context-mac)) {
 + iface-vlan_id = atoi(context-vlan);
 + strlcpy(iface-gateway, context-gateway, NI_MAXHOST);
 + strlcpy(iface-subnet_mask, context-mask, NI_MAXHOST);
 + log_debug(1, iscsi_match_boot found\n);
 + return 0;
 + }
 + }
 + return rc;
 +}
 +
 static int sync_session(void *data, struct session_info *info)
 {
   node_rec_t rec, sysfsrec;
 @@ -193,6 +218,7 @@ static int sync_session(void *data, struct session_info 
 *info)
   iscsiadm_rsp_t rsp;
   struct iscsi_transport *t;
   int rc, retries = 0;
 + struct list_head *boot_targets = data;
 
   log_debug(7, sync session [%d][%s,%s.%d][%s]\n, info-sid,
 info-targetname, info-persistent_address,
 @@ -269,6 +295,12 @@ static int sync_session(void *data, struct session_info 
 *info)
* app.
*/
   strcpy(rec.iface.iname, info-iface.iname);
 +
 + /* In the case the session is from boot, extract the additional
 +boot iface info */
 + if (iscsi_match_boot(rec.iface, boot_targets))
 + log_debug(1, Could not get boot entry.\n);
 +
   memset(req, 0, sizeof(req));
   req.command = MGMT_IPC_SESSION_SYNC;
   req.u.session.sid = info-sid;
 @@ -348,6 +380,7 @@ int main(int argc, char *argv[])
   struct sigaction sa_new;
   int control_fd;
   pid_t pid;
 + LIST_HEAD(boot_targets);
 
   while ((ch = getopt_long(argc, argv, c:i:fd:nu:g:p:vh, long_options,
longindex)) = 0) {
 @@ -511,7 +544,10 @@ int main(int argc, char *argv[])
   if (pid == 0) {
   int nr_found = 0;
   /* child */
 - iscsi_sysfs_for_each_session(NULL, nr_found, sync_session);
 + fw_get_targets(boot_targets);
 + iscsi_sysfs_for_each_session(boot_targets, nr_found,
 +  sync_session);

You can boot from targets that are not in fw. For example with RHEL you can 
pass in the boot info on the command line or have it passed in the dhcp root 
option. You would want to rename some of the functions/vars to reflect this is 
only for the fw booted targets.



-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this 

Re: [PATCH 2/2] ISCSID: Fixed the syncing of non-boot sessions with tagged vlan

[Michael Christie]

On Oct 8, 2012, at 7:47 PM, Eddie Wai eddie@broadcom.com wrote:

 For the syncing of non-boot sessions, the vlan info would have to
 be extracted from the iface config file.  This patch adds such
 a call to retrieve the additional net params from the iface config
 file.
 
 Signed-off-by: Eddie Wai eddie@broadcom.com
 ---
 usr/iscsid.c |7 ++-
 1 files changed, 6 insertions(+), 1 deletions(-)
 
 diff --git a/usr/iscsid.c b/usr/iscsid.c
 index 295a29e..15926e7 100644
 --- a/usr/iscsid.c
 +++ b/usr/iscsid.c
 @@ -107,13 +107,18 @@ setup_rec_from_negotiated_values(node_rec_t *rec, 
 struct session_info *info)
   struct iscsi_session_operational_config session_conf;
   struct iscsi_conn_operational_config conn_conf;
   struct iscsi_auth_config auth_conf;
 + int rc;
 
   idbm_node_setup_from_conf(rec);
   strlcpy(rec-name, info-targetname, TARGET_NAME_MAXLEN);
   rec-conn[0].port = info-persistent_port;
   strlcpy(rec-conn[0].address, info-persistent_address, NI_MAXHOST);
 - memcpy(rec-iface, info-iface, sizeof(struct iface_rec));
   rec-tpgt = info-tpgt;
 +
 + rc = iface_conf_read(info-iface);
 + if (rc)
 + log_warning(iface %s configuration file not found (%d),
 + info-iface.name, rc);
   

For qla4xxx/be2iscsi this is not needed, because the kernel is exporting this 
info and the info-face that was getting memcpyd had it.



-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: [PATCH 0/2] ISCSID - Fixed sync_session

[Michael Christie]

On Oct 8, 2012, at 7:44 PM, Eddie Wai eddie@broadcom.com wrote:

 Upon the startup of iscsid in both the iSCSI boot and the non-boot
 environment, the sync_session procedure fails to recover the connection
 when the connection require additional net param setup for the sync.
 
 For boot, there are additional params from ibft.  Namely:
 vlan, gateway, subnet_mask.
 
 For non-boot, the additional net params are in the corresponding iface
 config file.
 
 For both cases, the info must be explicitly extracted from either
 the ibft/iscsi_boot sysfs, or from the iface config file correspondingly
 before the connection can be sync'd.
 
 Please review, thanks!

Would it be possible to make bnx2i to work like be2iscsi/qla4xxx where it 
exports the all the net info in sysfs in the iface did? I think that would take 
care of needing the net info.

I think we would just need to then fix up iface_setup_from_boot_context so that 
it used the newer kernel based iface naming that is done in 
iface_setup_binding_from_kern_iface when creating the default iface: 
transport_name.mac.ipv4-or-ipv6.some_num.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: RFC: Doc: FLASH DDB Management using iscsiadm

[Michael Christie]

On Oct 1, 2012, at 5:31 AM, Lalit Chandivade lalit.chandiv...@qlogic.com 
wrote:

 
 
 -Original Message-
 From: Mike Christie [mailto:micha...@cs.wisc.edu]
 Sent: Tuesday, August 07, 2012 10:25 PM
 To: open-iscsi@googlegroups.com
 Cc: Lalit Chandivade; Ravi Anand; Vikas Chaudhary; Manish Rangankar
 Subject: Re: RFC: Doc: FLASH DDB Management using iscsiadm
 
 On 08/06/2012 06:27 AM, Lalit Chandivade wrote:
 
 
 -Original Message-
 From: Mike Christie [mailto:micha...@cs.wisc.edu]
 Sent: Friday, August 03, 2012 2:03 PM
 To: Lalit Chandivade
 Cc: open-iscsi@googlegroups.com; Ravi Anand; Vikas Chaudhary; Manish
 Rangankar
 Subject: Re: RFC: Doc: FLASH DDB Management using iscsiadm
 
 On 07/12/2012 05:37 PM, Lalit Chandivade wrote:
 Hi Mike,
 
 We want to work on this solution that would enable qla4xxx users to
 manage the DDBs in FLASH and migrate the entries from FLASH to user
 space.
 
 Here is our initial thought, please review and let us know your feedback.
 
 
 This sounds ok to me. Just some minor comments/questions that I am
 guessing you just glossed over to make it easier to understand.
 
 
 Add support for FLASH DDB management in iscsiadm
 =
 
 1. Export normal target entries to /sys/class/iscsi_session from
 FLASH when the driver comes up
 /sys/class/iscsi_session/session2  - for the DDB at Flash DDB index
 1
 /sys/class/iscsi_session/session3 - for the DDB at Flash DDB index
 2
 /sys/class/iscsi_session/session4 - for  target at index 3 in the
 RAM DDB
 Note: This will need changes in the driver
 
 Are you are going to add a file on the session to indicate if it's
 flash or not or how can we tell?
 
 We already have the creator to differentiate.
 /sys/class/iscsi_session/session1/creator
 
 Also we are thinking if we should add the FLASH DDBs under
 /sys/firmware, something like
 
 /sys/firmware/iscsi_offload/host0/
 |--iscsi_target/tgt0
 |--iscsi_target/tgt0/iqn
 |--iscsi_target/tgt0/ip
 |--iscsi_target/tgt0/port
 
 As this will clearly distinguish between FLASH DDBs and user created node
 records.
 
 
 This seems ok.
 
 Mike,
 
 After doing some initial work on this we have come up with following 
 directory structure and iscsiadm operations to manage the targets stored in 
 the HBAs flash.
 Please review and let us know your comments.
 
 Display in Sysfs:
 ==
 /sys/firmware/iscsi_offload/host1/new
 /sys/firmware/iscsi_offload/host1/delete
 /sys/firmware/iscsi_offload/host1/tgt0/logout
 /sys/firmware/iscsi_offload/host1/tgt0/login
 /sys/firmware/iscsi_offload/host1/tgt0/apply
 /sys/firmware/iscsi_offload/host1/tgt0/Target attributes
 
 
 Example:
 /sys/firmware/iscsi_offload/host7/tgt1/address
 /sys/firmware/iscsi_offload/host7/tgt1/default_time2retain
 /sys/firmware/iscsi_offload/host7/tgt1/default_time2wait
 /sys/firmware/iscsi_offload/host7/tgt1/firmware_cmd_timeout
 /sys/firmware/iscsi_offload/host7/tgt1/first_burst_length
 /sys/firmware/iscsi_offload/host7/tgt1/ipaddress
 /sys/firmware/iscsi_offload/host7/tgt1/ip_options
 /sys/firmware/iscsi_offload/host7/tgt1/iscsi_alias
 /sys/firmware/iscsi_offload/host7/tgt1/iscsi_options
 /sys/firmware/iscsi_offload/host7/tgt1/isid
 /sys/firmware/iscsi_offload/host7/tgt1/is_persistent
 /sys/firmware/iscsi_offload/host7/tgt1/login
 /sys/firmware/iscsi_offload/host7/tgt1/logout
 /sys/firmware/iscsi_offload/host7/tgt1/max_burst_length
 /sys/firmware/iscsi_offload/host7/tgt1/max_outstanding_r2t
 /sys/firmware/iscsi_offload/host7/tgt1/max_recv_data_segment_length
 /sys/firmware/iscsi_offload/host7/tgt1/max_xmit_data_segment_length
 /sys/firmware/iscsi_offload/host7/tgt1/name
 /sys/firmware/iscsi_offload/host7/tgt1/noop_out_interval
 /sys/firmware/iscsi_offload/host7/tgt1/port
 /sys/firmware/iscsi_offload/host7/tgt1/target_options
 /sys/firmware/iscsi_offload/host7/tgt1/tcp_options
 /sys/firmware/iscsi_offload/host7/tgt1/tpgt
 /sys/firmware/iscsi_offload/host7/tgt1/tsid
 
 Operations using iscsiadm:
 =
 
 List all targets stored in the FLASH of the HBA
 
 # iscsiadm -m host -H hostno -C target -o show


What does -C stand for (why can't you use the existing -T)?

Looks ok though.

Sorry for the late response on this. Please in the future feel free to bug the 
heck out of me. Send me weekly reminders if needed.



-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: rejected pdu when doing discovery

[Michael Christie]

On Oct 8, 2012, at 3:38 AM, Jose Joaquin Anton Herrerias jan...@abserver.es 
wrote:
 As you can see there are an error before the pdu rejected. Oct  8 10:20:33 
 robin fe: 25043 (/usr/sbin/stunnel -fd 6) exitted with code 0

It's not helpful. We want to know why the target is returning this error. What 
is in the target logs? Could you get a tcpdump trace at this time, so we can 
see what the target is seeing?

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: rejected pdu when doing discovery

[Michael Christie]

What target are you using? What is the vendor and model?


On Oct 8, 2012, at 2:42 AM, Jose Joaquin Anton Herrerias jan...@abserver.es 
wrote:

 Hello,
 
 We are using xenserver 5.6 with open-iscsi-2.0.871-0.20.3.xs647, whe use the 
 xenserver tool for discover and attach the lun. The Kenerl version is 
 2.6.32.12-0.7.1.xs5.6.100.307.170586xen. And when I see this error in log I 
 seen the lost conectin with sdb.
 
 Oct  7 05:04:34 robin multipathd: sdb: tur checker reports path is down
 
 I look that anothers server when use multipath create a sdb , sdc and dm-0 
 disk, in this case only create sdb and sdc disk. Is normal?
 

I am not sure what you are asking.  Are you just saying dm-0 is not getting 
setup on one of the servers? Then no, that is not normal if you have multipathd 
setup and running properly.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

rejected pdu when doing discovery

[Michael Christie]

On Oct 6, 2012, at 2:08 AM, rok...@gmail.com wrote:

 Hello,
 
 I have similar error, when i try to discover another lun i lost the 
 connection to the current lun using multipath. The log say this:


Your error is nothing like what was being discussed in this thread. Changing 
subject for you :)

What target are you using?

What version of open-iscsi? What kernel what userspace tools?

When you see this, what is in the target's logs?

How are you discovering another LUN? What command are you running?


 
 Oct  6 07:56:21 robin kernel:  connection1:0: pdu (op 0x303d itt 0x1) 
 rejected. Reason code 0x4

 Oct  6 07:56:51 robin kernel:  connection1:0: pdu (op 0x304d itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 07:57:21 robin kernel:  connection1:0: pdu (op 0x3077 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 07:57:51 robin kernel:  connection1:0: pdu (op 0x3025 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 07:58:21 robin kernel:  connection1:0: pdu (op 0x3070 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 07:58:35 robin kernel:  connection2:0: pdu (op 0x107e itt 0x40) 
 rejected. Reason code 0x7
 Oct  6 07:58:51 robin kernel:  connection1:0: pdu (op 0x305a itt 0x1) 
 rejected. Reason code 0x4

The target did not like something we did. It is reporting a protocol error.

We have never seen this error before. The initiator just logs the error and 
does nothing.


 Oct  6 07:59:00 robin kernel:  connection2:0: ping timeout of 15 secs 
 expired, recv timeout 10, last rx 5477313, last ping 5477313, now 5479813

Target stopped responding to us.

 Oct  6 07:59:00 robin kernel:  connection2:0: detected conn error (1011)


We dropped the connection. The scsi eh eventually runs and we cannot recover 
the device.


 Oct  6 07:59:21 robin kernel:  connection1:0: pdu (op 0x3079 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 07:59:51 robin kernel:  connection1:0: pdu (op 0x3049 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 08:00:21 robin kernel:  connection1:0: pdu (op 0x3069 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 08:00:51 robin kernel:  connection1:0: pdu (op 0x306d itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 08:01:21 robin kernel:  connection1:0: pdu (op 0x302f itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 08:01:31 robin kernel:  connection1:0: pdu (op 0x3015 itt 0x40) 
 rejected. Reason code 0x7
 Oct  6 08:01:51 robin kernel:  connection1:0: pdu (op 0x3065 itt 0x1) 
 rejected. Reason code 0x4
 Oct  6 08:02:16 robin kernel:  connection1:0: ping timeout of 15 secs 
 expired, recv timeout 10, last rx 5496921, last ping 5494921, now 5499421
 Oct  6 08:02:16 robin kernel:  connection1:0: detected conn error (1011)
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: Device offlined - not ready after 
 error recovery
 Oct  6 08:02:16 robin last message repeated 8 times
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] Unhandled error code
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] Result: hostbyte=DID_ABORT 
 driverbyte=DRIVER_OK
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] CDB: Read(10): 28 00 0f c7 
 c6 48 00 00 40 00
 Oct  6 08:02:16 robin kernel: end_request: I/O error, dev sdb, sector 
 264750664
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] Unhandled error code
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] Result: hostbyte=DID_ERROR 
 driverbyte=DRIVER_OK
 Oct  6 08:02:16 robin kernel: device-mapper: multipath: Failing path 8:16.
 Oct  6 08:02:16 robin kernel: sd 13:0:0:0: [sdb] CDB: Write(10): 2a 00 24 27 
 24 10 00 00 08 00
 Oct  6 08:02:16 robin kernel: end_request: I/O error, dev sdb, sector 
 606544912
 
 And then i cant get access to the lun so i need to reboot the server, when is 
 rebooted the server works and the multipath connections are 2 of 2.
 
 Some ideas?
 
 Best Regards.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: iscsi connection errors

[Michael Christie]

On Oct 5, 2012, at 2:39 PM, squadra j...@internetx.de wrote:

 Hi,
 
 from time to time i see connection errors like this to our equallogic 6100xv 
 / 4100e stack.
 
 ct  5 21:22:20 xxx kernel: connection4:0: detected conn error (1020)


Do you see something before this? Maybe something about a nop/ping timing out, 
or as Paul mentioned something about the target wanting to logout or dropping 
the connections?

If not, on the target log, do you see something about the target closing the 
connection?

 Oct  5 21:22:21 xxx iscsid: Kernel reported iSCSI connection 4:0 error (1020 
 - ISCSI_ERR_TCP_CONN_CLOSE: TCP connection closed) state (3)

It means the target closed the connection.

 Oct  5 21:22:23 xxx kernel: connection4:0: detected conn error (1020)
 Oct  5 21:22:24 xxx iscsid: connection4:0 is operational after recovery (1 
 attempts)
 
 any ideas what this error code means?
 
 cheers,
 
 Juergen
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/open-iscsi/-/vggeBH8Nc_MJ.
 To post to this group, send email to open-iscsi@googlegroups.com.
 To unsubscribe from this group, send email to 
 open-iscsi+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/open-iscsi?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Open-iSCSI support of multiple connections per session (MC/S)

[Michael Christie]

On Sep 30, 2012, at 5:06 PM, Tom Gardner tom94...@comcast.net wrote:

 I’m a newbie to open-iscsi and have been poking various sites to see if 
 open-iscsi does, has or will support MC/S.  To date I have found no way to 
 configure the feature and have found a few tantalizing statements that it is 
 not supported as in “Software iscsi, like iscsi_tcp and iser, allocate a 
 scsi_host per session and does a single connection per session.” [Linux* 
 Open-iSCSI README, May 20, 2012, para. 5.1.1 at 
 http://www.open-iscsi.org/docs/README ]
  
 Am I correct as to current support?  If so, any published plans to add

Open iscsi does not support MC/s. The linux kernel maintainers feel MC/S is too 
similar to and/or does not provide enough benefits over block based multipath 
and prefer that instead.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: conn error 1011 1020

[Michael Christie]

On Sep 27, 2012, at 4:42 PM, iscsi developer man iscsidevel...@gmail.com 
wrote:

 2.6.32-37-generic
 
 
 if scsi commands are timing out, we would expect to see TASK ABORTS, correct?
 

Yes. Are you taking a tcpdump trace at this time and seeing task aborts?

With the 2.6.32 based kernel setup you can also turn on debugging

echo 1 /sys/module/libiscsi/paramters/debug_libiscsi_eh


 here is your reply with that patch.
 
 https://groups.google.com/forum/#!msg/open-iscsi/OnpdtuUCBCM/p6pdmTIoVdsJ
 
 
 it would help us greatly if we could figure out why the client is
 closing the connection on these conn errors.
 


I said in the previous mails you are probably over queueing. You need to 
decrease the queue_depth and increase the nop setting. If you are using cents 
5.3 you need to update your kernel.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Couldn't recognize text com.ardistech.avfs_server=192.168.216.2 on login

[Michael Christie]

On Sep 26, 2012, at 4:08 AM, HC henri.c...@gmail.com wrote:

 Hi all,
 
 I'm trying to connect to a third party piece of storage which is presenting 
 an iSCSI drive - it's made by DDP (Dynamic Drive Pool) which uses AVFS 
 technology and it looks like they're passing a custom header, I assume this 
 header means nothing and shouldn't influence the iSCSI operation but its 
 presence seems to crash my login process (there is no username/password/auth 
 type setup) based on these logs - is there any way i can just mark this line 
 to be ignored without building my own copy of the code and hard coding it in?
 

If you did not want to log into a specific portal than you can do

iscsiadm -m node -T yourtarget -p ip -o delete

or

iscsiadm -m node -T yourtarget -p ip -o update -n node.start -v manual

 Sep 26 09:58:13 UK-DEMO iscsid: Login negotiation failed, couldn't recognize 
 text com.ardistech.avfs_server=192.168.216.2
 Sep 26 09:58:13 UK-DEMO iscsid: Login error (Login status 0) on conn 4
 

Could you take a tcpdump/writeshark trace and send it?

tcpdump -w iscsi.out -i yournetdev_like_ethX


 I hope i've understood that correctly, the host system is OpenSuse and it's 
 the first time i've tried iSCSI from that OS
 
 I am contacting the vendor seperately but an iSCSI-based solution would be 
 appreciated as presumably this kind of thing gets more and more common with 
 all the storage vendors out there these days
 
 Best Regards,
 
 Henri
 
 -- 
 You received this message because you are subscribed to the Google Groups 
 open-iscsi group.
 To view this discussion on the web visit 
 https://groups.google.com/d/msg/open-iscsi/-/FCVWxd4AyAMJ.
 To post to this group, send email to open-iscsi@googlegroups.com.
 To unsubscribe from this group, send email to 
 open-iscsi+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/open-iscsi?hl=en.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Antw: Re: Q: Slow extraordinarily slow performance of dmraid -s -c -c -c

[Michael Christie]

From what I can tell, it is a dm raid issue or a target issue.

The len dm raid is using might not be right, but I am not sure. I do not know 
why the target does not like it.


On Sep 21, 2012, at 5:59 AM, Ulrich Windl ulrich.wi...@rz.uni-regensburg.de 
wrote
 # time sg_inq -e -p 80- /dev/sdc
 unrecognized multiplier
 Bad argument to '--page=', expecting 0 to 255 inclusive
 
 Modified:
 # time sg_inq -e -p 80 /dev/sdc

I goofed when I wrote the example. You need to pass it in hex so it should be

sg_inq -e -p 0x80 /dev/sdc

I think that will end up working ok though. sg_inq seems to use a different len 
than what dm raid does.

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Cannot do FITRIM

[Michael Christie]

On Aug 31, 2012, at 9:55 AM, Spelic spe...@shiftmail.org wrote:

 On 08/30/12 18:51, Michael Christie wrote:
 On Aug 30, 2012, at 11:49 AM, Michael Christie micha...@cs.wisc.edu wrote:
 
 On Aug 30, 2012, at 11:18 AM, Spelic spe...@shiftmail.org wrote:
 
 Hello all
 I am trying to fstrim a filesystem on an iSCSI disk through open-iscsi. 
 The target is on LIO .
 
 I am receiving:
 fstrim: /: FITRIM ioctl failed: Operation not supported
 
 At LIO side there is nothing in dmesg, so I am supposing it's a open-iscsi 
 problem (lack of feature?)
 The iscsi layer does not do anything special to support trim/discard. We 
 just pass whatever info we have to upper layers and passes commands down to 
 the target/disks.
 
 Does your disk support trim/discard? Are you doing passthrough to a disk 
 that support trim/discard or is lio emulating it?
 
 When you run fstrim what errors do you see in /var/log/messages? Do you see 
 something about a ILLEGAL_REQUEST maybe?
 
 
 
 Mike, thank you for your reply
 
 The only thing I see in dmesg is this:
 
[ 1166.338584] TARGET_CORE[iSCSI]: Unsupported SCSI Opcode 0x85, sending 
 CHECK_CONDITION.
 
 and it is at LIO side.
 I see it twice, but I don't think it's at the time I attempt the fstrim, I 
 think it's at node boot time (iSCSI boot)
 
 Nothing at initiator side.
 
 I confirm I can do fstrim if I map the device on the node which acts as 
 target. This device is an LVM Thin device and it definitely supports trim, 
 and one can even see the occupied space decreasing after a successful fstrim.
 
 LIO maps it as a backstores--iblock .
 
 Can this be a LIO problem / lack of feature?
 

I don't think LIO supports what you are trying to do. I do not think that it 
just automatically detects if a lvm device supports discards and then exports 
that. If you were using a passthrough scsi device that supports it then I think 
it would just work.  On the initiator side for the iscsi disk do:

cat /sys/class/scsi_disk/A:B:C:D/provisioning_mode
cat /sys/class/scsi_disk/A:B:C:D/provisioning

If provisioning is disabled then the target is not reporting that it supports 
it when the scsi layer sets up the disk.


-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Cannot do FITRIM

[Michael Christie]

On Aug 30, 2012, at 11:18 AM, Spelic spe...@shiftmail.org wrote:

 Hello all
 I am trying to fstrim a filesystem on an iSCSI disk through open-iscsi. The 
 target is on LIO .
 
 I am receiving:
 fstrim: /: FITRIM ioctl failed: Operation not supported
 
 At LIO side there is nothing in dmesg, so I am supposing it's a open-iscsi 
 problem (lack of feature?)

The iscsi layer does not do anything special to support trim/discard. We just 
pass whatever info we have to upper layers and passes commands down to the 
target/disks.

Does your disk support trim/discard? Are you doing passthrough to a disk that 
support trim/discard or is lio emulating it?

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.

Re: Cannot do FITRIM

[Michael Christie]

On Aug 30, 2012, at 11:49 AM, Michael Christie micha...@cs.wisc.edu wrote:

 
 On Aug 30, 2012, at 11:18 AM, Spelic spe...@shiftmail.org wrote:
 
 Hello all
 I am trying to fstrim a filesystem on an iSCSI disk through open-iscsi. The 
 target is on LIO .
 
 I am receiving:
 fstrim: /: FITRIM ioctl failed: Operation not supported
 
 At LIO side there is nothing in dmesg, so I am supposing it's a open-iscsi 
 problem (lack of feature?)
 
 The iscsi layer does not do anything special to support trim/discard. We just 
 pass whatever info we have to upper layers and passes commands down to the 
 target/disks.
 
 Does your disk support trim/discard? Are you doing passthrough to a disk that 
 support trim/discard or is lio emulating it?


When you run fstrim what errors do you see in /var/log/messages? Do you see 
something about a ILLEGAL_REQUEST maybe?

-- 
You received this message because you are subscribed to the Google Groups 
open-iscsi group.
To post to this group, send email to open-iscsi@googlegroups.com.
To unsubscribe from this group, send email to 
open-iscsi+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/open-iscsi?hl=en.