Banned MasterCard Commercial - Extremely Funny
Click Here to Watch This Video --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] fix conn context data pointer
Establish a connection to an MD3000i (use CHAP and Rev. CHAP) - Disconnect the iSCSI session iscsiadm -m node -p -T -u - Reconnect the iSCSI session iscsiadm -m node -p -T -l <-Fails because iscsid gets killed Signed-off-by: Thomas Chenault Tested-by: Shyam Iyer diff --git a/usr/initiator.c b/usr/initiator.c index 8e4ea6b..c29f5fb 100644 --- a/usr/initiator.c +++ b/usr/initiator.c @@ -127,7 +127,7 @@ struct iscsi_conn_context *iscsi_conn_co sizeof(struct actor)); conn_context->allocated = 1; /* some callers abuse this pointer */ - conn_context->data = conn_context + + conn_context->data = (void *)conn_context + sizeof(struct iscsi_conn_context); log_debug(7, "get conn context %p", &conn_context->actor); --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~--- fix_conn_context_data_pointer Description: fix_conn_context_data_pointer
Re: What gives with the spam.
On Wednesday 24 June 2009, FUJITA Tomonori wrote: > > On Wed, 24 Jun 2009 14:46:23 -0500 > Mike Christie wrote: > > > > > On 06/24/2009 12:31 PM, Alvin Starr wrote: > > > > > > There seems to be a lot of spam coming through the open-iscsi mail list. > > > > > > Any chance of getting something done about this? I directly wrote Google directly a few days ago - and previously had contacted Google Abuse at least 15 times. So far NO action. It's very frustrating. (I've attached the spam emails to all my requests). Looks like Google is "uninterested". Perhaps if a lot of folks contacted Google, they'd take action (?). The interesting thing is that I'm on a number of Google lists - and this is the only one which gets spammed. Regards, Lyle -- Lyle Bickley Bickley Consulting West Inc. http://bickleywest.com "Black holes are where God is dividing by zero" --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: do we need a new list for kernel patches
shyam_i...@dell.com wrote: >> -Original Message- >> From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] >> On Behalf Of shyam_i...@dell.com >> Sent: Thursday, June 11, 2009 11:39 PM >> To: open-iscsi@googlegroups.com >> Subject: RE: do we need a new list for kernel patches >> >> >>> -Original Message- >>> From: open-iscsi@googlegroups.com [mailto:open- >> is...@googlegroups.com] >>> On Behalf Of Mike Christie >>> Sent: Thursday, June 11, 2009 11:11 PM >>> To: open-iscsi >>> Subject: RFC: do we need a new list for kernel patches >>> >>> >>> Hey, >>> >>> It seems like we have a lot of members on the list that are not >> kernel >>> developers, but we now have 5 iscsi drivers (qla4xxx, bnx2i, cxgb3i, >>> iscsi_tcp and ib_iser) with another being written. So it seems like >> we >>> are going to have lots of patches. I would also like to start > sending >>> my >>> kernel patches out in a way that everyone can see them. Previously > to >>> avoid noise on this list, I have been pinging you guys privately >> which >>> just does not work so well now when we have so many people. >>> >>> What do you people think? >>> >>> Do other people on the list prefer to see everything here, so you > can >>> see what features are making progress? >> Does splitting the mailing list to userpace and kernel have merit? >> Thoughts ... >> > > > Was this mail stuck in moderation? > Yeah, not sure what happened, because you were using your dell account. I just saw it today in the list of mail that needed review. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: do we need a new list for kernel patches
> -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of shyam_i...@dell.com > Sent: Thursday, June 11, 2009 11:39 PM > To: open-iscsi@googlegroups.com > Subject: RE: do we need a new list for kernel patches > > > > -Original Message- > > From: open-iscsi@googlegroups.com [mailto:open- > is...@googlegroups.com] > > On Behalf Of Mike Christie > > Sent: Thursday, June 11, 2009 11:11 PM > > To: open-iscsi > > Subject: RFC: do we need a new list for kernel patches > > > > > > Hey, > > > > It seems like we have a lot of members on the list that are not > kernel > > developers, but we now have 5 iscsi drivers (qla4xxx, bnx2i, cxgb3i, > > iscsi_tcp and ib_iser) with another being written. So it seems like > we > > are going to have lots of patches. I would also like to start sending > > my > > kernel patches out in a way that everyone can see them. Previously to > > avoid noise on this list, I have been pinging you guys privately > which > > just does not work so well now when we have so many people. > > > > What do you people think? > > > > Do other people on the list prefer to see everything here, so you can > > see what features are making progress? > > Does splitting the mailing list to userpace and kernel have merit? > Thoughts ... > Was this mail stuck in moderation? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: What gives with the spam.
On Wed, 24 Jun 2009 18:40:36 -0500 Mike Christie wrote: > > FUJITA Tomonori wrote: > > On Wed, 24 Jun 2009 14:46:23 -0500 > > Mike Christie wrote: > > > >> On 06/24/2009 12:31 PM, Alvin Starr wrote: > >>> There seems to be a lot of spam coming through the open-iscsi mail list. > >>> > >>> Any chance of getting something done about this? > >>> > >> Right now only members can post and if a non member posts I have to > >> manually allow it. I guess that had worked ok for a while. Now the > >> spammers are making accounts and bypassing this. Unless google groups > >> has some spam filtering that I do not know of, I think I will have to > >> change the settings so that new members are moderated. > > > > How about moving the mailing list to vger.kernel.org? > > > > Did you find a way to migrate a bunch of people easily or did you add > everyone manually? When I moved stgt mailing list, I didn't either (you can't do either on vger.kernel.org, I think). I just asked everyone to subscribe to the new mailing list. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: What gives with the spam.
FUJITA Tomonori wrote: > On Wed, 24 Jun 2009 14:46:23 -0500 > Mike Christie wrote: > >> On 06/24/2009 12:31 PM, Alvin Starr wrote: >>> There seems to be a lot of spam coming through the open-iscsi mail list. >>> >>> Any chance of getting something done about this? >>> >> Right now only members can post and if a non member posts I have to >> manually allow it. I guess that had worked ok for a while. Now the >> spammers are making accounts and bypassing this. Unless google groups >> has some spam filtering that I do not know of, I think I will have to >> change the settings so that new members are moderated. > > How about moving the mailing list to vger.kernel.org? > Did you find a way to migrate a bunch of people easily or did you add everyone manually? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: What gives with the spam.
On Wed, 24 Jun 2009 14:46:23 -0500 Mike Christie wrote: > > On 06/24/2009 12:31 PM, Alvin Starr wrote: > > > > There seems to be a lot of spam coming through the open-iscsi mail list. > > > > Any chance of getting something done about this? > > > > Right now only members can post and if a non member posts I have to > manually allow it. I guess that had worked ok for a while. Now the > spammers are making accounts and bypassing this. Unless google groups > has some spam filtering that I do not know of, I think I will have to > change the settings so that new members are moderated. How about moving the mailing list to vger.kernel.org? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [RFC]iscsid to run in conjunction with uIP stack
On Tue, 2009-06-23 at 09:34 -0700, Mike Christie wrote: > Michael Chan wrote: > > > > On Mon, 2009-06-22 at 16:51 -0700, Benjamin Li wrote: > >> On Mon, 2009-06-22 at 05:59 -0700, Rakesh Ranjan wrote: > >>> 4. Get rid of ISCSI_NL_GRP_UIP netlink message and use > >>> ISCSI_NL_GRP_ISCSID instead. Move the netlink processing in nic_nl.c > >>> into netlink. > >> Correct, it is safe to remove ISCSI_NL_GRP_UIP because we could then > >> rely on ISCSI_NL_GRP_ISCSID instead. netlink.c::ctldev_handle() would > >> need to be modified to handle 'ISCSI_KEVENT_PATH_REQ' and > >> 'ISCSI_KEVENT_IF_DOWN' > > > > This will be an ABI change. The 2.6.31 kernel today is using the 2 > > multicast groups. If we decide a single multicast group is better, I > > think we need to change the kernel code now. > > > > Mike, how do we do this? > > > > The patch would just be something like the attached, right? If that is > what you agree on, then we can send it now. > > If you guys think we need to wait and make sure it is the right path, I > think we can wait and break ABI here though. bnx2i/open-iscsi is a odd > driver where a good chunk is in userspace and userspace is just not done > in my opinion (there is no code in the upstream open-iscsi package and > distros that add code that is not upstream take on this type of risk). I > think the scsi maintainer might allow the change. I am not sure about > Dave Miller though. He seems more strict. > > Let me know what you want to do and I will ping James to make sure it is ok. > I think we should wait and keep the 2 separate groups for now. This is how it will work until uIP is combined with iscsid. Even when they are combined, it's not a big problem to have to listen to 2 multicast groups. For performance or other reasons, we may still want to have two threads listening for these 2 message types. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH 1/2 2.6.30-rc] cxgb3i -- add a refcnt to track ddp usage
On Sat, 2009-06-13 at 14:29 -0700, k...@chelsio.com wrote: > [PATCH 1/2 2.6.30-rc] cxgb3i -- add a refcnt to track ddp usage > > From: Karen Xie > > The iscsi ddp functionality could be used by multiple iscsi entities, > add a refcnt to keep track of it, so we would not release it pre-maturely. The code is fine as it stands but, I wonder, would you consider using a kref for this? The reasons are twofold: 1. It's a well understood kernel paradigm that works ... this would be helpful for the far distant time when chelsio no longer wants to maintain this driver. 2. It includes useful and appropriate warnings for common bugs in refcounted code, such as use of a freed reference. James --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: do we need a new list for kernel patches
> -Original Message- > From: open-iscsi@googlegroups.com [mailto:open-is...@googlegroups.com] > On Behalf Of Mike Christie > Sent: Thursday, June 11, 2009 11:11 PM > To: open-iscsi > Subject: RFC: do we need a new list for kernel patches > > > Hey, > > It seems like we have a lot of members on the list that are not kernel > developers, but we now have 5 iscsi drivers (qla4xxx, bnx2i, cxgb3i, > iscsi_tcp and ib_iser) with another being written. So it seems like we > are going to have lots of patches. I would also like to start sending > my > kernel patches out in a way that everyone can see them. Previously to > avoid noise on this list, I have been pinging you guys privately which > just does not work so well now when we have so many people. > > What do you people think? > > Do other people on the list prefer to see everything here, so you can > see what features are making progress? Does splitting the mailing list to userpace and kernel have merit? Thoughts ... --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: LGPL for libiscsi?
Mike, Many thanks for seeking clarification on it. Hopefully it will be a favorable result :) Jon. Sent from my iPhone On 9 Jun 2009, at 17:20, Mike Christie wrote: dougee wrote: Coming in late on this one will there likely be any movement on this, would be really useful? Thanx in advance. I am not sure how to go about changing the license on the code that the userspace libiscsi code is using. It is GPL2. I am asking my work right now for advice. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: [PATCH 1/2] libiscsi: Do not sent NOP when xmit is in progress
On 06/24/2009 09:40 AM, Hannes Reinecke wrote:
> During heavy I/O we might hit a receive timeout as the
> xmitworker is still busy sending PDUs. Even as we strictly
> speaking didn't receive a reply during the receive timeout,
> we didn't actually gave the target a chance to reply as
> we're constantly hitting it with requests.
> So it's better to ensure that cmdqueue really is empty
> before start sending NOPs.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/libiscsi.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 716cc34..41bb177 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1862,7 +1862,9 @@ static void iscsi_check_transport_timeouts(unsigned
> long data)
> return;
> }
>
> - if (time_before_eq(last_recv + recv_timeout, jiffies)) {
> + if (time_before_eq(last_recv + recv_timeout, jiffies)&&
> + list_empty(&conn->cmdqueue)&&
> + list_empty(&conn->requeue)) {
> /* send a ping to try to provoke some traffic */
> ISCSI_DBG_CONN(conn, "Sending nopout as ping\n");
> iscsi_send_nopout(conn, NULL);
If the connection goes bad and the network layer stops sending IO (you
hit that wait in sendmsg/sendpage) but there are tasks in the cmdqueue
or requeue then how will we detect that the connection has gone bad
(tasks will not be removed from the queues at this time)?
With this patch will we have to wait until the scsi eh fires and the
tmfs also timeout and then the target reset code eventually gives up and
drops the session.
I think we want to change
if (time_before_eq(last_recv + recv_timeout, jiffies)) {
/* send a ping to try to provoke some traffic */
ISCSI_DBG_CONN(conn, "Sending nopout as ping\n");
iscsi_send_nopout(conn, NULL);
next_timeout = conn->last_ping + (conn->ping_timeout * HZ);
} else
next_timeout = last_recv + recv_timeout;
to account for xmits and recvs like is done with tasks, so if we have
been successfully sending or receiving data then do not send a ping.
Here is a patch. It is only compile tested. I think we need locking
around the last_xfer accesses or maybe make it an atomic or something
(is there a atomic that matches the size of jiffies on all archs that is
not expensive).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
diff --git a/drivers/scsi/cxgb3i/cxgb3i_pdu.c b/drivers/scsi/cxgb3i/cxgb3i_pdu.c
index 7091050..0ccbc4f 100644
--- a/drivers/scsi/cxgb3i/cxgb3i_pdu.c
+++ b/drivers/scsi/cxgb3i/cxgb3i_pdu.c
@@ -388,14 +388,15 @@ int cxgb3i_conn_xmit_pdu(struct iscsi_task *task)
if (err > 0) {
int pdulen = err;
- cxgb3i_tx_debug("task 0x%p, skb 0x%p, len %u/%u, rv %d.\n",
- task, skb, skb->len, skb->data_len, err);
+ cxgb3i_tx_debug("task 0x%p, skb 0x%p, len %u/%u, rv %d.\n",
+ task, skb, skb->len, skb->data_len, err);
if (task->conn->hdrdgst_en)
pdulen += ISCSI_DIGEST_SIZE;
if (datalen && task->conn->datadgst_en)
pdulen += ISCSI_DIGEST_SIZE;
+ tcp_conn->iscsi_conn->last_xfer = jiffies;
task->conn->txdata_octets += pdulen;
return 0;
}
diff --git a/drivers/scsi/iscsi_tcp.c b/drivers/scsi/iscsi_tcp.c
index 518dbd9..9253617 100644
--- a/drivers/scsi/iscsi_tcp.c
+++ b/drivers/scsi/iscsi_tcp.c
@@ -255,6 +255,7 @@ static int iscsi_sw_tcp_xmit_segment(struct iscsi_tcp_conn
*tcp_conn,
iscsi_tcp_segment_unmap(segment);
return r;
}
+ tcp_conn->iscsi_conn->last_xfer = jiffies;
copied += r;
}
return copied;
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 716cc34..c714bc5 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -928,7 +928,7 @@ int __iscsi_complete_pdu(struct iscsi_conn *conn, struct
iscsi_hdr *hdr,
struct iscsi_task *task;
uint32_t itt;
- conn->last_recv = jiffies;
+ conn->last_xfer = jiffies;
rc = iscsi_verify_itt(conn, hdr->itt);
if (rc)
return rc;
@@ -1738,7 +1738,7 @@ static void iscsi_start_tx(struct iscsi_conn *conn)
static int iscsi_has_ping_timed_out(struct iscsi_conn *conn)
{
if (conn->ping_task &&
- time_befor
Re: [PATCH 2/2] libiscsi: Check for empty cmdqueue in iscsi_eh_cmd_timed_out
On 06/24/2009 03:52 PM, Mike Christie wrote:
> On 06/24/2009 09:40 AM, Hannes Reinecke wrote:
>> During heavy I/O the scsi cmd might be stuck in the cmdqueue
>> and hasn't even been sent at the time the command timeout
>> strikes. So we should be resetting the command timer here
>> and not aborting the command.
>>
>> Signed-off-by: Hannes Reinecke
>> ---
>>drivers/scsi/libiscsi.c |8
>>1 files changed, 8 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
>> index 41bb177..e5b79cf 100644
>> --- a/drivers/scsi/libiscsi.c
>> +++ b/drivers/scsi/libiscsi.c
>> @@ -1795,6 +1795,14 @@ static enum blk_eh_timer_return
>> iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
>> goto done;
>> }
>>
>> +if (!list_empty(&conn->cmdqueue)) {
>
>
> I think you want to check for the task->state == ISCSI_TASK_PENDING. If
> we just check if there is any IO on the cmdqueue, could be that one IO
> is really stuck and new IO is getting added and we just happen to have
> bad luck and do the check above when new IO is getting added?
>
>
> I am still not sure how do we decide when to give the command to the
> scsi eh layer? If a task is stuck in ISCSI_TASK_PENDING for 5 minutes,
> can we say we give up and let the scsi layer have it eventually or did
> you really want to continue asking for more time?
>
>
> I added this code
> http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=d355e57d58193b89283b0c8153649f0427b0bdad
> to give a task more time if we have not got/send data or it during the
> scsi cmd timeuot second period. Then if on the second run, it still has
> not completed a pdu then we will let the scsi eh run. This still has
> problems. As you saw when the queue depth is high and/or the link or
> device is slow, then we can easily queue enough IO where a command does
> not get run for a couple scsi cmd timeout periods. I was also working on
> decreasing the queuedepth and host->can_queue, but am not done (I have
> just consolidated the QUEUE_FULL ramp down code so far as you saw on
> linux-scsi).
>
Oh yeah for the ramp down code I was going to decrease the scsi device
queue depth and/or the host->canqueue when we are getting scsi command
time outs, but know other commands are executing. But I think even with
that I am still not sure it will give us what we want.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: [PATCH 2/2] libiscsi: Check for empty cmdqueue in iscsi_eh_cmd_timed_out
On 06/24/2009 09:40 AM, Hannes Reinecke wrote:
> During heavy I/O the scsi cmd might be stuck in the cmdqueue
> and hasn't even been sent at the time the command timeout
> strikes. So we should be resetting the command timer here
> and not aborting the command.
>
> Signed-off-by: Hannes Reinecke
> ---
> drivers/scsi/libiscsi.c |8
> 1 files changed, 8 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
> index 41bb177..e5b79cf 100644
> --- a/drivers/scsi/libiscsi.c
> +++ b/drivers/scsi/libiscsi.c
> @@ -1795,6 +1795,14 @@ static enum blk_eh_timer_return
> iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
> goto done;
> }
>
> + if (!list_empty(&conn->cmdqueue)) {
I think you want to check for the task->state == ISCSI_TASK_PENDING. If
we just check if there is any IO on the cmdqueue, could be that one IO
is really stuck and new IO is getting added and we just happen to have
bad luck and do the check above when new IO is getting added?
I am still not sure how do we decide when to give the command to the
scsi eh layer? If a task is stuck in ISCSI_TASK_PENDING for 5 minutes,
can we say we give up and let the scsi layer have it eventually or did
you really want to continue asking for more time?
I added this code
http://git.kernel.org/?p=linux/kernel/git/jejb/scsi-misc-2.6.git;a=commitdiff;h=d355e57d58193b89283b0c8153649f0427b0bdad
to give a task more time if we have not got/send data or it during the
scsi cmd timeuot second period. Then if on the second run, it still has
not completed a pdu then we will let the scsi eh run. This still has
problems. As you saw when the queue depth is high and/or the link or
device is slow, then we can easily queue enough IO where a command does
not get run for a couple scsi cmd timeout periods. I was also working on
decreasing the queuedepth and host->can_queue, but am not done (I have
just consolidated the QUEUE_FULL ramp down code so far as you saw on
linux-scsi).
> + ISCSI_DBG_EH(session, "cmdqueue busy, reset timeout. "
> + "Last data recv at %lu. Last timeout was at "
> + "%lu\n", task->last_xfer, task->last_timeout);
> + rc = BLK_EH_RESET_TIMER;
> + goto done;
> + }
> +
> if (!conn->recv_timeout&& !conn->ping_timeout)
> goto done;
> /*
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: What gives with the spam.
On 06/24/2009 12:31 PM, Alvin Starr wrote: > > There seems to be a lot of spam coming through the open-iscsi mail list. > > Any chance of getting something done about this? > Right now only members can post and if a non member posts I have to manually allow it. I guess that had worked ok for a while. Now the spammers are making accounts and bypassing this. Unless google groups has some spam filtering that I do not know of, I think I will have to change the settings so that new members are moderated. If there is anyone that wants to help out on the list management let me know. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: linux-iscsi to open-iscsi upgrade
On 06/24/2009 06:41 AM, dushy wrote: > Hey guys, > > Iam usign linux-iscsi currently on a centos 4.5 box (kernel > 2.6.9-67.0.22.ELsmp). The target is a Hitachi WMS 100 with three > logical drives. Iam trying to find teh best upgrade path to open-isci > for the below setup. > > * So to upgrade to open-iscsi, i think i just have to stop linux- > iscsi, uninstall it, install latest open-iscsi and configure the > targets again. Iam assuming multipath settings, LVM VG's and LVs will > remain unchanged. > open-iscsi only works on newer kernels. You would have to probably upgrade to Centos 5.3. If you can run the Centos 5.3 kernel on centos 4.5 maybe it would work, but I do not know how safe it is. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: compile the latest version debian ubuntu
Am Mittwoch 24 Juni 2009 11:47:55 schrieb Boaz Harrosh: > > This is very old what Kernel is this ? > okay I copiled new kernel: 2.6.30 uname -a Linux willy 2.6.30 #1 SMP Wed Jun 24 15:18:23 CEST 2009 i686 GNU/Linux doing: /etc/init.d/open-iscsi stop Disconnecting iSCSI targets:. Stopping iSCSI initiator service:. r...@willy:/etc/iscsi# iscsistart -i iqn.lenny.org.open-iscsi:7e84634e3e00 -t iqn.fromlenny.com.openfiler:tsn.7480be2c6f3f -g 1 -a 10.100.100.30 iscsistart: Missing or Invalid version from /sys/module/scsi_transport_iscsi/version. Make sure a up to date scsi_transport_iscsi module is loaded and a up todate version of iscsid is running. Exiting... hmm, what to do? Im trying also make user... but version dont change: /etc/iscsi# /etc/init.d/open-iscsi start Starting iSCSI initiator service: iscsid. Setting up iSCSI targets:iscsiadm: No records found! . r...@willy:/etc/iscsi# iscsiadm -m discovery -t sendtargets -p 10.100.100.30 --login dont do nothing?! iscsiadm -m session -P 3 iscsiadm: No active sessions. dmesg: 264.156290] ip_tables: (C) 2000-2006 Netfilter Core Team [ 572.562666] Loading iSCSI transport class v2.0-870. [ 573.610875] iscsi: registered transport (tcp) [ 574.880785] iscsi: registered transport (iser) and its like before: no discover possible can someone help? tia stefan --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
What gives with the spam.
There seems to be a lot of spam coming through the open-iscsi mail list. Any chance of getting something done about this? -- Alvin Starr || voice: (416)585-9971x690 Interlink Connectivity|| fax: (416)585-9974 al...@iplink.net || --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Ghost Hunter Prank Calls - Hillarious
Click Here to Watch This Video --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH 2/2] libiscsi: Check for empty cmdqueue in iscsi_eh_cmd_timed_out
During heavy I/O the scsi cmd might be stuck in the cmdqueue
and hasn't even been sent at the time the command timeout
strikes. So we should be resetting the command timer here
and not aborting the command.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/libiscsi.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 41bb177..e5b79cf 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1795,6 +1795,14 @@ static enum blk_eh_timer_return
iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
goto done;
}
+ if (!list_empty(&conn->cmdqueue)) {
+ ISCSI_DBG_EH(session, "cmdqueue busy, reset timeout. "
+"Last data recv at %lu. Last timeout was at "
+"%lu\n", task->last_xfer, task->last_timeout);
+ rc = BLK_EH_RESET_TIMER;
+ goto done;
+ }
+
if (!conn->recv_timeout && !conn->ping_timeout)
goto done;
/*
--
1.5.3.2
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[PATCH 1/2] libiscsi: Do not sent NOP when xmit is in progress
During heavy I/O we might hit a receive timeout as the
xmitworker is still busy sending PDUs. Even as we strictly
speaking didn't receive a reply during the receive timeout,
we didn't actually gave the target a chance to reply as
we're constantly hitting it with requests.
So it's better to ensure that cmdqueue really is empty
before start sending NOPs.
Signed-off-by: Hannes Reinecke
---
drivers/scsi/libiscsi.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 716cc34..41bb177 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1862,7 +1862,9 @@ static void iscsi_check_transport_timeouts(unsigned long
data)
return;
}
- if (time_before_eq(last_recv + recv_timeout, jiffies)) {
+ if (time_before_eq(last_recv + recv_timeout, jiffies) &&
+ list_empty(&conn->cmdqueue) &&
+ list_empty(&conn->requeue)) {
/* send a ping to try to provoke some traffic */
ISCSI_DBG_CONN(conn, "Sending nopout as ping\n");
iscsi_send_nopout(conn, NULL);
--
1.5.3.2
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[PATCH 0/2] Check cmdqueue length for receive timeouts
Hi all, during heavy I/O the iSCSI initiator starts spitting out receive timeouts and connection failures, even though the connection itself is not faulty. I managed to trace it down to the way open-iscsi treats SCSI commands. During queuecommand we're just taking the scmd, add it to the cmdqueue, and kick the workqueue to transmit these commands. However, when the system is under heavy I/O load the times difference between queueing and processing the command on the workqueue might be quite considerable. In fact, it might be longer than the SCSI command timeout itself, causing the command to timeout. And to make matters worse, we're injecting NOPs now and again to detect the connection is still alive. However, currently we're only counting the time since we last received some data from the target. The time the NOP request is stuck on the queue is not being taken into account, causing erroneous connection failures. To remedy this I've created two patches, one for checking the cmdqueue before trying to send NOPs and the other for checking the cmdqueue when the SCSI command timeout has kicked in. They _do_ looks sane to me, and they certainly cause the spurious connection failures to drop quite considerably. However, as they interfere with error handling I'd like to have a second or third opinion here. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
David Blaine - Street Magic - Video
Click Here to Watch This Video --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
A fundamental question to iSCSI proponents;
Hi , First of all, please correct me if you can prove that i need more education !! My question is, is IP-SAN just a dream ? how far iSCSI reached that goal ? Whats features that iSCSI have, which force to call it a SAN ? I wish to argue that its just a client-server protocol that access block storage over an IP Network. Its just a SAN access protocol, not a SAN itself. Please beat me professionally, i would appreciate that...:-) Peter chacko, Principal technologist, Sciendix information systems Pvt.Ltd, Bangalore, India. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
World Record - 172 foot High Dive - [Must watch]
Click Here to Watch This Video --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
linux-iscsi to open-iscsi upgrade
Hey guys, Iam usign linux-iscsi currently on a centos 4.5 box (kernel 2.6.9-67.0.22.ELsmp). The target is a Hitachi WMS 100 with three logical drives. Iam trying to find teh best upgrade path to open-isci for the below setup. linux-iscsi connects to the WMS 100 over two different network paths and multipath is being used over this. hitachi03 (3643b8bff0002) [size=943 GB][features="0"][hwhandler="0"] \_ round-robin 0 [active] \_ 4:0:0:2 sdf 8:80 [active][ready] \_ 3:0:0:2 sdg 8:96 [active][ready] hitachi02 (3643b8bff0001) [size=2047 GB][features="0"][hwhandler="0"] \_ round-robin 0 [prio=2][active] \_ 4:0:0:1 sdd 8:48 [active][ready] \_ 3:0:0:1 sde 8:64 [active][ready] hitachi01 (3643b8bff) [size=2047 GB][features="0"][hwhandler="0"] \_ round-robin 0 [active] \_ 4:0:0:0 sdb 8:16 [active][ready] \_ 3:0:0:0 sdc 8:32 [active][ready] * These three multipath disks are added to a LVM volume group. LVs created from this VGs are targets in ietd and a few servers use this targets for storage. * So to upgrade to open-iscsi, i think i just have to stop linux- iscsi, uninstall it, install latest open-iscsi and configure the targets again. Iam assuming multipath settings, LVM VG's and LVs will remain unchanged. Will the device maps change and is there any possibility of problems with LVM VGs and LVs post moving to open-iscsi ? TIA Dushyanth --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
George Bush Funny Moments - Ultimate Collection
Click Here to Watch This Video --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: compile the latest version debian ubuntu
On 06/23/2009 11:11 AM, Stefan wrote: > Am Montag 22 Juni 2009 13:51:17 schrieb Stefan: > > Hello all, > > sorry, its half solved. Its now running on ubuntu jaunty but not on debian > lenny. > > I did what did on the ubuntu machine: > > aptitude install open-iscsi > > untar new package > make user > make install_user > /etc/init.d/open-iscsi start > > iscsiadm -m session -P 3 > iSCSI Transport Class version 2.0-869 This is very old what Kernel is this ? > iscsiadm version 2.0-870 > iscsiadm: could not read session targetname: 61 > iscsiadm: could not find session info for session1 > iscsiadm: Can not get list of active sessions (61) > > And I compile x.871 but its not shown?! > > > iscsiadm -m discovery -t sendtargets -p 10.100.100.30 --login > > and nothing happens then. I have look with tcpdump port 3260 on lenny and I > see that nothing is recorded. > > > Whats wrong? > try to make; make install this time. It looks like your Kernel is very old and the out-of-tree modules should be better. > Can someone help? > > tia > stefan > Boaz --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
