On Wed, May 28, 2008 at 03:34:37PM +0300, Pasi Kärkkäinen wrote: > > Hello list! > > Unfortunately I had to upgrade a server running CentOS 4.6 (sfnet initiator) > to CentOS 5.1 (open-iscsi initiator) and now I have some problems with it > (then again I was expecting it.. I hate this Promise array). > > /var/log/messages: > > May 28 15:14:16 server1 multipathd: path checkers start up > May 28 15:15:39 server1 iscsid: Nop-out timedout after 10 seconds on > connection 14:0 state (3). Dropping session. > May 28 15:15:42 server1 iscsid: connection14:0 is operational after recovery > (2 attempts) > May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = > 0x00020000 > May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector > 190057296 > May 28 15:19:21 server1 kernel: device-mapper: multipath: Failing path 8:48. > May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = > 0x00020000 > May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector > 190057552 > May 28 15:19:21 server1 kernel: sd 16:0:0:0: SCSI error: return code = > 0x00020000 > May 28 15:19:21 server1 kernel: end_request: I/O error, dev sdd, sector > 190057560 > May 28 15:19:21 server1 multipathd: sdd: readsector0 checker reports path is > down > May 28 15:19:21 server1 multipathd: checker failed path 8:48 in map > promise_test1 > May 28 15:19:21 server1 multipathd: promise_test1: remaining active paths: 1 > May 28 15:19:21 server1 iscsid: Nop-out timedout after 10 seconds on > connection 14:0 state (3). Dropping session. > May 28 15:19:25 server1 iscsid: connection14:0 is operational after recovery > (2 attempts) > May 28 15:19:26 server1 multipathd: sdd: readsector0 checker reports path is > up > May 28 15:19:26 server1 multipathd: 8:48: reinstated > May 28 15:19:26 server1 multipathd: promise_test1: remaining active paths: 2 > May 28 15:19:26 server1 multipathd: promise_test1: switch to path group #1 > > $ iscsiadm -m node --targetname <name> | grep timeo > node.session.timeo.replacement_timeout = 15 > node.session.err_timeo.abort_timeout = 10 > node.session.err_timeo.reset_timeout = 30 > node.conn[0].timeo.logout_timeout = 15 > node.conn[0].timeo.login_timeout = 15 > node.conn[0].timeo.auth_timeout = 45 > node.conn[0].timeo.active_timeout = 5 > node.conn[0].timeo.idle_timeout = 60 > node.conn[0].timeo.ping_timeout = 5 > node.conn[0].timeo.noop_out_interval = 5 > node.conn[0].timeo.noop_out_timeout = 10 > node.session.timeo.replacement_timeout = 15 > node.session.err_timeo.abort_timeout = 10 > node.session.err_timeo.reset_timeout = 30 > node.conn[0].timeo.logout_timeout = 15 > node.conn[0].timeo.login_timeout = 15 > node.conn[0].timeo.auth_timeout = 45 > node.conn[0].timeo.active_timeout = 5 > node.conn[0].timeo.idle_timeout = 60 > node.conn[0].timeo.ping_timeout = 5 > node.conn[0].timeo.noop_out_interval = 5 > node.conn[0].timeo.noop_out_timeout = 10 > > Basicly those "Nop-out timedout" errors keep showing up all the time when > there is IO going on.. and if I have "dd if=/dev/mpath of=/dev/null" running
You can expand the timeout to a higher value? 30 seconds ? Also you might want to limit the node.session.queue_depth to a lower value as well. > IO rates seem to go down every 20 seconds or so and stay stalled (at 0) for > 5 seconds or so.. weird. That could be due to the NOP not getting its response and stalling the session until it receives the response. --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/open-iscsi -~----------~----~----~----~------~----~------~--~---
