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 -~--~~~~--~~--~--~---
Re: [PATCH 1/2] libiscsi: Do not sent NOP when xmit is in progress
Mike Christie wrote:
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 Reineckeh...@suse.de
---
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)?
Hmm. Yes, indeed, this is a problem. But I think with your patch tracking
all xmits and recvs we don't need to apply that one as last_recv will
actually be last_xmit and hence a NOP will be sent if there is no traffic
at all.
Which as about what we want to achieve here.
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).
No, we don't need a lock here as it's already been taken
(On the libiscsi side).
And this will probably also take care of the eh_timeout problem
as this will also check last_xmit.
I'll give it a spin.
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
-~--~~~~--~~--~--~---
Foreigner in Indian Call Center - lol
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: do we need a new list for kernel patches
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. By my reckon of the e-mails about this, most people thought it best to keep it as is. Meaning one reflector for userspace+kernel issues/patches/etc. --~--~-~--~~~---~--~~ 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] libiscsi: use bh locking
Hey Hannes,
I found a couple more places where we should be disabling bottom halves.
1. We should now be disabling them in iscsi_eh_cmd_timed_out because
dm-mpath can call blk_abort_queue from process context. Previously, it
could only be called from timer context where the bottom halve for that
processor is already disabled.
2. iscsi_eh_abort. Not sure what happened, but when I fixed the locking
in device reset, I thought I fixed it here too, but I guess I did not.
--~--~-~--~~~---~--~~
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/libiscsi.c b/drivers/scsi/libiscsi.c
index c714bc5..2d37bc4 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -1758,7 +1758,7 @@ static enum blk_eh_timer_return
iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
ISCSI_DBG_EH(session, scsi cmd %p timedout\n, sc);
- spin_lock(session-lock);
+ spin_lock_bh(session-lock);
if (session-state != ISCSI_STATE_LOGGED_IN) {
/*
* We are probably in the middle of iscsi recovery so let
@@ -1828,7 +1828,7 @@ static enum blk_eh_timer_return
iscsi_eh_cmd_timed_out(struct scsi_cmnd *sc)
done:
if (task)
task-last_timeout = jiffies;
- spin_unlock(session-lock);
+ spin_unlock_bh(session-lock);
ISCSI_DBG_EH(session, return %s\n, rc == BLK_EH_RESET_TIMER ?
timer reset : nh);
return rc;
@@ -1974,10 +1974,10 @@ int iscsi_eh_abort(struct scsi_cmnd *sc)
* good and have never sent us a successful tmf response
* then sent more data for the cmd.
*/
- spin_lock(session-lock);
+ spin_lock_bh(session-lock);
fail_scsi_task(task, DID_ABORT);
conn-tmf_state = TMF_INITIAL;
- spin_unlock(session-lock);
+ spin_unlock_bh(session-lock);
iscsi_start_tx(conn);
goto success_unlocked;
case TMF_TIMEDOUT:
Re: Error while backing up mulitpath devices using CDP
On 06/25/2009 06:06 AM, jeet2k123 wrote:
Hi all,
We using R1soft CDP tool to backup Linux files. on centos 5.2
The Backup works fine for normal disk, but for multipath devices its
giving error while taking backup
I am using 11 iSCSI partition on a SAN device configured in multipath.
I am using 8 path in multipath.
My multipath is using 2 Intel NIC which are connected to dedicated
managed switch(HP)
I have configured multipath as per this doc.
http://wiki.r1soft.com/display/kb/Linux+Agent+Multipath+Workaround
my mount point is
/dev/dm-0 on /home11 type ext3 (rw)
The moment i start backup for above mount point, i get this error
{code}
Jun 23 12:21:24 mss-us2 kernel: connection8:0: ping timeout of 5 secs
expired, last rx 7739207452, last ping 7739212452, now 7739217452
Jun 23 12:21:24 mss-us2 kernel: connection8:0: detected conn error
(1011)
What kernel are you using?
--~--~-~--~~~---~--~~
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: Help with some iSCSI connect random errors
On 06/25/2009 06:33 AM, Santi Saez wrote: Hi, Randomly I get those iSCSI errors on a Linux box with CentOS 5.3, running default kernel (2.6.18) and using Open-iSCSI (6.2.0.868-0.18.el5_3.1): ping timeout of 5 secs expired, last rx (..) This indicates that the initiator sent a iscsi ping but we did not get a reply. When this happens the initiator will then drop the session and try to relogin and retry IO. connection1:0: iscsi: detected conn error (1011) Kernel reported iSCSI connection 1:0 error (1011) state (3) session1: iscsi: session recovery timed out after 120 secs iscsi: cmd 0x28 is not queued (8) This indicates that we tried to relogin for 2 minutes, but we could not log back in. At that time, we fail IO. sd 1:0:0:0: SCSI error: return code = 0x0001 end_request: I/O error, dev sdb, sector 226732039 sd 1:0:0:0: SCSI error: return code = 0x0001 end_request: I/O error, dev sdb, sector 187040175 Full log is available at: http://pastebin.com/f40472f99 After that, we need to reboot the server to recover read-write into ext3 fs. You might be able to avoid this problem by increasing the node.session.timeo.replacement_timeout in iscsid.conf (dont forget to rediscovery the storage so the new value gets picked up). However, if we are not able to reconnect for a couple minutes then something is wrong here. Maybe running iscsid by hand with debugging on will give us more info: iscsid -d 8 Or if you could run it by hand and make a test disk, then login and just pull the cable, so we can check that relogin is working it might be helpful. You should see: ping timeout of 5 secs expired, connection1:0: iscsi: detected conn error (1011) Kernel reported iSCSI connection 1:0 error (1011) state (3) When you see that you should plug the cable back in. Then instead of session1: iscsi: session recovery timed out after 120 secs you should see connection1:0 is operational after recovery Where use default Open-iSCSI config: http://pastebin.com/f9f15d82 More info about this device: # cat /sys/block/sdb/device/timeout 60 # cat /sys/class/iscsi_session/session1/recovery_tmo 120 There are more initiators conected to the same target and switch, and are not afectted by this situation, so we think that maybe changing some Open-iSCSI configuration parameter we can solve this.. any ideas? thanks!! 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 -~--~~~~--~~--~--~---
Re: [PATCH] fix conn context data pointer
On 06/25/2009 12:47 AM, shyam_i...@dell.com wrote: Establish a connection to an MD3000i (use CHAP and Rev. CHAP) - Disconnect the iSCSI session iscsiadm -m node -pip_addr -Tiqn -u - Reconnect the iSCSI session iscsiadm -m node -pip_addr -Tiqn -l -Fails because iscsid gets killed Signed-off-by: Thomas Chenaultthomas_chena...@dell.com Tested-by: Shyam Iyershyam_i...@dell.com 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); Does this fix your segfault with iscsistart too? Thomas, could you try this patch? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-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: Error while backing up mulitpath devices using CDP
2.6.18-128.1.6.el5
On Jun 25, 8:07 pm, Mike Christie micha...@cs.wisc.edu wrote:
On 06/25/2009 06:06 AM, jeet2k123 wrote:
Hi all,
We using R1soft CDP tool to backup Linux files. on centos 5.2
The Backup works fine for normal disk, but for multipath devices its
giving error while taking backup
I am using 11 iSCSI partition on a SAN device configured in multipath.
I am using 8 path in multipath.
My multipath is using 2 Intel NIC which are connected to dedicated
managed switch(HP)
I have configured multipath as per this doc.
http://wiki.r1soft.com/display/kb/Linux+Agent+Multipath+Workaround
my mount point is
/dev/dm-0 on /home11 type ext3 (rw)
The moment i start backup for above mount point, i get this error
{code}
Jun 23 12:21:24 mss-us2 kernel: connection8:0: ping timeout of 5 secs
expired, last rx 7739207452, last ping 7739212452, now 7739217452
Jun 23 12:21:24 mss-us2 kernel: connection8:0: detected conn error
(1011)
What kernel are you using?
--~--~-~--~~~---~--~~
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: solved compile the latest version debian ubuntu
Am Dienstag 23 Juni 2009 18:21:19 schrieb Mike Christie: ist seems that was really a kernel issue. I installed it then from repository linux image 2.6.29 and it its now working. With my own compiled kernel I did something wrong cause I used a config from an another kernel. hmm. deleting /etc/iscsi und copy from another location inistiatorname and iscsid.conf. edititing initaitorname, start Then there was a issue with login and I edit under nodes the password and I was then able to login!!! Thanks all for help 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 -~--~~~~--~~--~--~---
Re: Help with some iSCSI connect random errors
On 06/25/2009 10:17 AM, Mike Christie wrote: On 06/25/2009 06:33 AM, Santi Saez wrote: Hi, Randomly I get those iSCSI errors on a Linux box with CentOS 5.3, running default kernel (2.6.18) and using Open-iSCSI (6.2.0.868-0.18.el5_3.1): ping timeout of 5 secs expired, last rx (..) This indicates that the initiator sent a iscsi ping but we did not get a reply. When this happens the initiator will then drop the session and try to relogin and retry IO. connection1:0: iscsi: detected conn error (1011) Kernel reported iSCSI connection 1:0 error (1011) state (3) session1: iscsi: session recovery timed out after 120 secs iscsi: cmd 0x28 is not queued (8) This indicates that we tried to relogin for 2 minutes, but we could not log back in. At that time, we fail IO. sd 1:0:0:0: SCSI error: return code = 0x0001 end_request: I/O error, dev sdb, sector 226732039 sd 1:0:0:0: SCSI error: return code = 0x0001 end_request: I/O error, dev sdb, sector 187040175 Full log is available at: http://pastebin.com/f40472f99 After that, we need to reboot the server to recover read-write into ext3 fs. You might be able to avoid this problem by increasing the node.session.timeo.replacement_timeout in iscsid.conf (dont forget to rediscovery the storage so the new value gets picked up). Oh yeah, for config settings when not using dm-multipath you can just turn nops off by setting node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
