EARN $100-$250 per day
EARN $100-$250 per day work at ur spare time no experience needed SIMPLE ONLINE SURVEY CREATE UR ACCOUNT AND EARN IMMEDIATLY *** http://www.AWSurveys.com/HomeMain.cfm?RefID=kingraja666 http://www.AWSurveys.com/HomeMain.cfm?RefID=kingraja666 http://www.AWSurveys.com/HomeMain.cfm?RefID=kingraja666 *** --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Configuration question
On Aug 20, 1:39 am, Mike Christie <[EMAIL PROTECTED]> wrote: > v42bis wrote: > > Thank for the reply, Mike. > > No problem. > > > The iscsi connections failed about 1m13s after my iscsi target went > > down (timestamps that follow are synced from same ntp master, however > > clock skew may account for a few seconds difference [1m45sec seems > > very conspicuous - a multiplier of default 15sec timers?]). The target > > went down at Aug 19 13:33:33. > > Actually this looks like a different problem. What version of open-iscsi > are you using? Do a "iscsiadm -P 3". The top part should dump the > iscsiadm version. `iscsiadm -P 3` just spits out the usage/help information - no version. I know it is version open-iscsi-2.0-865.15, though. > > > Aug 19 13:36:42 ak1-vz2 kernel: iscsi: scsi conn_destroy(): host_busy > > 0 host_failed 0 > > This means that userspace decided to kill the iscsi session/connection > which means that we ignore the recovery/replacement timeout and just > kill everything which forces IO errors. We only did this for fatal > errors, but we should not do that anymore. What userspace process would have done that? > > > The above did not affect normal operation of my open-iscsi initiators. > > That is weirder. In this setup do you have multiple > sessions/connections? When you checked the machine were all the > session/connections running? There should have been two sessions that > were destroyed. Only one session per connection. One connection to each iscsi target. All of the filesystems and iscsi connections seemed fine, as far as I could tell. > > In older open-iscsi userspace tools there were certain errors the target > could send us and iscsid would consider it a fatal error and it would > kill the sessions like above. For example if a target was shutting down > it could tell us that it was not coming back, so we would kill the > session. There was also a case where iscsid got confused and thought it > was a fatal error and would kill the session. We now just retry forever > or until the user kills the session manually to avoid problems like this. To confirm: open-iscsi version 2.0-869.2 and above will never kill iscsi sessions unless the user explicitly tells iscsid to logout/kill the session? I want to make sure my open-iscsi initiators never return errors until replacement_timeout is reached. I'd rather have any processes accessing filesystems on iscsi hang forever than have the connections lost and journals aborted. Looking at the code, there is no problem with setting such a high replacement_timeout? > > Please tell me you were using a older version than open-iscsi-2.0-869.2 > :) If you were using open-iscsi-2.0-869.2 then we have a different > problem :( I am definitely running 2.0-865.15. I will upgrade to 2.0-869.2. It would be *very* convenient if the Changelog would include changes in every version and not just the current release. :) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Klemens Kittan wrote: > > Here is the whole log. > Thanks. In that log, are you doing io to both disks on both connections or just one disks? It looks like the initiator is not getting a response for the ping in time (within ping (node.conn[0].timeo.noop_out_timeout) timeout seconds)). It might be a driver bug and we are dropping it. To check that you would need to run ethereal or wireshark so we can see what the network layer is seeing, but I do not think this is the case given some of the other ping times in there. If the target is just so slow that it is useless to try sending the nop you could just run without nops on by setting node.conn[0].timeo.noop_out_timeout = 0 node.conn[0].timeo.noop_out_interval = 0 or turn node.conn[0].timeo.noop_out_timeout to a higher value like 45 and see if that helps. In the logs the responses to some other pings are around 9 seconds which is cutting it close when you have a timeout of 10 seconds, so you should definately try to increase the node.conn[0].timeo.noop_out_timeout. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSER login process
Mike Christie wrote:
> Jesse Butler wrote:
>
>> Erez Zilber wrote:
>>
>>> On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler <[EMAIL PROTECTED]> wrote:
>>>
>>>
Ok, I've tried the configuration and login now whilst specifying the
TPGT. I don't hit the same error now, but I do see this:
# iscsiadm -m node -T
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
10.8.0.6:3260 -l
Login session [iface: default, target:
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal:
10.8.0.6,3260]
iscsiadm: initiator reported error (14 - iSCSI driver does not support
requested capability.)
iscsiadm: Could not execute operation on all records. Err 107.
So, progress!
Here is the set of operations I performed.
Thanks
Jesse
# iscsiadm -m node -T
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
10.8.0.6:3260,1 -o new
New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default]
10.8.0.6,3260,1
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added
# iscsiadm -m node -T
iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
10.8.0.6:3260,1
node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346
node.tpgt = 1
node.startup = manual
iface.hwaddress = default
iface.iscsi_ifacename = default
iface.net_ifacename = default
iface.transport_name = tcp
node.discovery_address =
node.discovery_port = 0
node.discovery_type = static
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 4
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.auth.authmethod = None
node.session.auth.username =
node.session.auth.password =
node.session.auth.username_in =
node.session.auth.password_in =
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.FastAbort = Yes
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 2
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 10.8.0.6
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
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 = 10
node.conn[0].timeo.noop_out_timeout = 15
node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
node.conn[0].iscsi.HeaderDigest = None,CRC32C
>>> I think that this is the problem. iSER doesn't use
>>> HeaderDigest/DataDigest. I strongly suggest that you use
>>> iscsi_discovery which does all the work for you (including setting
>>> HeaderDigest/DataDigest to "None").
>>>
>>> Erez
>>>
>>>
>>>
>> Hello Erez-
>>
>> The HeaderDigest setting here indicates a list of options [None,
>> CRC32C]. If running on iSER, we'll negotiate to "None", and all will be
>> well.
>>
>> I would like to take your advice, but the distribution that I am using
>> does not have the iscsi_discovery with the "-t" option, so I just used
>> static. It could be that what I'm running just won't work (we have
>> discussed offline a known-to-work configuration, I will try that). As
>> an aside, I think it's kinda nutty that there's a chance that the RHEL
>> 5.2 config doesn't work... since, eh, well it's ship
>>
>> There may be something else in the config, though. I'm just trying to
>> figure out what this is:
>>
>> # iscsiadm -m node -T
>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
>> 10.8.0.6:3260 -l
>> Login session [iface: default, target:
>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal:
>> 10.8.0.6,3260]
>> iscsiadm: initiator reported error (14 - iSCSI driver does not support
>> requested capability.)
>> iscsiadm: Could not execute operation on all records. Err 107.
>> #
>>
>
> I think what Erez was saying, besides use iscsi_discovery, was that you
> should set this to None and it should work. In the /var/log/messages do
> you also see:
>
> log_error("transport '%s' does not support "
>"HeaderDigest != None", t->name);
>
> The iser driver does not support digests so we do not even try to
> negotiate. We do
Re: iSER login process
Jesse Butler wrote: > > > Erez Zilber wrote: >> On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler <[EMAIL PROTECTED]> wrote: >> >>> Ok, I've tried the configuration and login now whilst specifying the >>> TPGT. I don't hit the same error now, but I do see this: >>> >>> # iscsiadm -m node -T >>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >>> 10.8.0.6:3260 -l >>> Login session [iface: default, target: >>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal: >>> 10.8.0.6,3260] >>> iscsiadm: initiator reported error (14 - iSCSI driver does not support >>> requested capability.) >>> iscsiadm: Could not execute operation on all records. Err 107. >>> >>> So, progress! >>> >>> Here is the set of operations I performed. >>> >>> Thanks >>> Jesse >>> >>> >>> # iscsiadm -m node -T >>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >>> 10.8.0.6:3260,1 -o new >>> New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default] >>> 10.8.0.6,3260,1 >>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added >>> >>> # iscsiadm -m node -T >>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >>> 10.8.0.6:3260,1 >>> node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 >>> node.tpgt = 1 >>> node.startup = manual >>> iface.hwaddress = default >>> iface.iscsi_ifacename = default >>> iface.net_ifacename = default >>> iface.transport_name = tcp >>> node.discovery_address = >>> node.discovery_port = 0 >>> node.discovery_type = static >>> node.session.initial_cmdsn = 0 >>> node.session.initial_login_retry_max = 4 >>> node.session.cmds_max = 128 >>> node.session.queue_depth = 32 >>> node.session.auth.authmethod = None >>> node.session.auth.username = >>> node.session.auth.password = >>> node.session.auth.username_in = >>> node.session.auth.password_in = >>> node.session.timeo.replacement_timeout = 120 >>> node.session.err_timeo.abort_timeout = 10 >>> node.session.err_timeo.reset_timeout = 30 >>> node.session.iscsi.FastAbort = Yes >>> node.session.iscsi.InitialR2T = No >>> node.session.iscsi.ImmediateData = Yes >>> node.session.iscsi.FirstBurstLength = 262144 >>> node.session.iscsi.MaxBurstLength = 16776192 >>> node.session.iscsi.DefaultTime2Retain = 0 >>> node.session.iscsi.DefaultTime2Wait = 2 >>> node.session.iscsi.MaxConnections = 1 >>> node.session.iscsi.MaxOutstandingR2T = 1 >>> node.session.iscsi.ERL = 0 >>> node.conn[0].address = 10.8.0.6 >>> node.conn[0].port = 3260 >>> node.conn[0].startup = manual >>> node.conn[0].tcp.window_size = 524288 >>> node.conn[0].tcp.type_of_service = 0 >>> 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 = 10 >>> node.conn[0].timeo.noop_out_timeout = 15 >>> node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 >>> node.conn[0].iscsi.HeaderDigest = None,CRC32C >>> >> I think that this is the problem. iSER doesn't use >> HeaderDigest/DataDigest. I strongly suggest that you use >> iscsi_discovery which does all the work for you (including setting >> HeaderDigest/DataDigest to "None"). >> >> Erez >> >> > > Hello Erez- > > The HeaderDigest setting here indicates a list of options [None, > CRC32C]. If running on iSER, we'll negotiate to "None", and all will be > well. > > I would like to take your advice, but the distribution that I am using > does not have the iscsi_discovery with the "-t" option, so I just used > static. It could be that what I'm running just won't work (we have > discussed offline a known-to-work configuration, I will try that). As > an aside, I think it's kinda nutty that there's a chance that the RHEL > 5.2 config doesn't work... since, eh, well it's ship > I think users end up using the example in the README where the tpgt is passed in, so we did not hit the problem until recently. If you stick to the examples in there it should be fine. But yeah, slap us with fish for letting something simple slip through :( --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iSER login process
Jesse Butler wrote:
>
>
> Erez Zilber wrote:
>> On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler <[EMAIL PROTECTED]> wrote:
>>
>>> Ok, I've tried the configuration and login now whilst specifying the
>>> TPGT. I don't hit the same error now, but I do see this:
>>>
>>> # iscsiadm -m node -T
>>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
>>> 10.8.0.6:3260 -l
>>> Login session [iface: default, target:
>>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal:
>>> 10.8.0.6,3260]
>>> iscsiadm: initiator reported error (14 - iSCSI driver does not support
>>> requested capability.)
>>> iscsiadm: Could not execute operation on all records. Err 107.
>>>
>>> So, progress!
>>>
>>> Here is the set of operations I performed.
>>>
>>> Thanks
>>> Jesse
>>>
>>>
>>> # iscsiadm -m node -T
>>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
>>> 10.8.0.6:3260,1 -o new
>>> New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default]
>>> 10.8.0.6,3260,1
>>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added
>>>
>>> # iscsiadm -m node -T
>>> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
>>> 10.8.0.6:3260,1
>>> node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346
>>> node.tpgt = 1
>>> node.startup = manual
>>> iface.hwaddress = default
>>> iface.iscsi_ifacename = default
>>> iface.net_ifacename = default
>>> iface.transport_name = tcp
>>> node.discovery_address =
>>> node.discovery_port = 0
>>> node.discovery_type = static
>>> node.session.initial_cmdsn = 0
>>> node.session.initial_login_retry_max = 4
>>> node.session.cmds_max = 128
>>> node.session.queue_depth = 32
>>> node.session.auth.authmethod = None
>>> node.session.auth.username =
>>> node.session.auth.password =
>>> node.session.auth.username_in =
>>> node.session.auth.password_in =
>>> node.session.timeo.replacement_timeout = 120
>>> node.session.err_timeo.abort_timeout = 10
>>> node.session.err_timeo.reset_timeout = 30
>>> node.session.iscsi.FastAbort = Yes
>>> node.session.iscsi.InitialR2T = No
>>> node.session.iscsi.ImmediateData = Yes
>>> node.session.iscsi.FirstBurstLength = 262144
>>> node.session.iscsi.MaxBurstLength = 16776192
>>> node.session.iscsi.DefaultTime2Retain = 0
>>> node.session.iscsi.DefaultTime2Wait = 2
>>> node.session.iscsi.MaxConnections = 1
>>> node.session.iscsi.MaxOutstandingR2T = 1
>>> node.session.iscsi.ERL = 0
>>> node.conn[0].address = 10.8.0.6
>>> node.conn[0].port = 3260
>>> node.conn[0].startup = manual
>>> node.conn[0].tcp.window_size = 524288
>>> node.conn[0].tcp.type_of_service = 0
>>> 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 = 10
>>> node.conn[0].timeo.noop_out_timeout = 15
>>> node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072
>>> node.conn[0].iscsi.HeaderDigest = None,CRC32C
>>>
>> I think that this is the problem. iSER doesn't use
>> HeaderDigest/DataDigest. I strongly suggest that you use
>> iscsi_discovery which does all the work for you (including setting
>> HeaderDigest/DataDigest to "None").
>>
>> Erez
>>
>>
>
> Hello Erez-
>
> The HeaderDigest setting here indicates a list of options [None,
> CRC32C]. If running on iSER, we'll negotiate to "None", and all will be
> well.
>
> I would like to take your advice, but the distribution that I am using
> does not have the iscsi_discovery with the "-t" option, so I just used
> static. It could be that what I'm running just won't work (we have
> discussed offline a known-to-work configuration, I will try that). As
> an aside, I think it's kinda nutty that there's a chance that the RHEL
> 5.2 config doesn't work... since, eh, well it's ship
>
> There may be something else in the config, though. I'm just trying to
> figure out what this is:
>
> # iscsiadm -m node -T
> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p
> 10.8.0.6:3260 -l
> Login session [iface: default, target:
> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal:
> 10.8.0.6,3260]
> iscsiadm: initiator reported error (14 - iSCSI driver does not support
> requested capability.)
> iscsiadm: Could not execute operation on all records. Err 107.
> #
I think what Erez was saying, besides use iscsi_discovery, was that you
should set this to None and it should work. In the /var/log/messages do
you also see:
log_error("transport '%s' does not support "
"HeaderDigest != None", t->name);
The iser driver does not support digests so we do not even try to
negotiate. We do not even try to login because the driver said it does
not support them. I guess a better option would be to just drop the user
requested param and do None for the user - will do that later.
But you h
Re: Problem when logging out from specific interface
shreyas wrote: > Hi Mike, > > Thanks a lot for your help > It is working with version 2.0-870. I have some small queries, > > 1) whether open-iscsi version 2.0-870 is usable and well tested? ( i > know its development version but still thought of asking it to you) I was actually going to switch it to the semi-stable version next week. I am waiting to try and figure out what is going with the nops in some other thread (the nops problem is in semi-stable release: open-iscsi-2.0-869.2.tar.gz too). > > 2) As you told i did "whereis iscsiadm" before doing make && make > install of 2.0-870, it was present in /sbin/ and i just removed it and Do a whereis iscsid too > reinstalled new version. Is this sufficient or do i need to remove any > other files at other locations. Also, are u planning to provide make > uninstall which will remove required files of older version > automatically? > Yes, one day. I have not had time. There is one problem with detecting our older versions some distro version though. > 3)While starting open-iscsi service it sets up all targets by login to > all available targets, while if there are no targets available it says > "No records found!". where does it actually search for these targets? > In my case i installed this version on 2 machines on first i did > discovery and thenit logged in on all available targets when i do > service open-iscsi start. > while on sencond one it just said "No records found!". When you do discovery it stores the targets and portals found in /etc/iscsi/nodes. When you do "iscsiadm -m node" it prints those out what is in /etc/iscsi/nodes. > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[PATCH] iscsi: ‘err’ may be used uninitialized in iscsi_add_session
gcc 4.3.0 prints this warning:
drivers/scsi/scsi_transport_iscsi.c: In function ‘iscsi_add_session’:
drivers/scsi/scsi_transport_iscsi.c:703: warning:\
‘err’ may be used uninitialized in this function
I'm not sure how exactly this can happen with
ISCSI_MAX_TARGET currently defined as -1.
But if ISCSI_MAX_TARGET would be defined as 0 and the function would
be called with target_id==0 we end up going to release_host without
setting err.
This patch sets err to -ENOENT for this path.
Signed-off-by: Benny Halevy <[EMAIL PROTECTED]>
---
drivers/scsi/scsi_transport_iscsi.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 043c392..7d14228 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -706,6 +706,7 @@ int iscsi_add_session(struct iscsi_cls_session *session,
unsigned int target_id)
session->sid = atomic_add_return(1, &iscsi_session_nr);
if (id == ISCSI_MAX_TARGET) {
+ err = -ENOENT;
for (id = 0; id < ISCSI_MAX_TARGET; id++) {
err = device_for_each_child(&shost->shost_gendev, &id,
iscsi_get_next_target_id);
--
1.6.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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
Re: Reducing amount of logmessages openiscsi/multipath [with md3000i]
On Wed, Aug 20, 2008 at 12:57:24PM +0200, Kees Hoekzema wrote:
>
>
>
> > -Original Message-
> > He wants the RDAC hw handler and its path checker (rdac). The MD3000i
> > is an
> > LSI re-branded box and is the same as the IBM DS3300.
> >
> > >
> > > You also want to make sure that you are using the md3000i hw handler
> > or
> > > scsh_dh_module if you are not already. The dm-devel guys can help you
> > out.
> >
> > Here is the multipath.conf he should be using for MD3000i (or for the
> > DS3300
> > but will need to modify the vendor/model entry)
> >
> > # Note: The same as the IBM DS3300
> > #
> > device {
> > vendor "DELL"
> > product "MD3000i"
> > product_blacklist "Universal Xport"
> > features"1 queue_if_no_path"
> > path_grouping_policygroup_by_prio
> > hardware_handler"1 rdac"
> > path_checkerrdac
> > prio"rdac"
> > failbackimmediate
> > }
> >
> >
>
> This fixed the problem, although a simple flush was not enough to activate
Glad to hear that.
> the changes, so it took a bit longer to get the result I wanted. In the end
> I saw that it was still using the direction path_checker and noticed that
> you cannot change the 'path_checker' on the fly with just a multipath -F /
> -v 2, but that a reload of the modules was needed.
Ohh, you could also do: multipathd -k'reconfigure'
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: iSER login process
Erez Zilber wrote: > On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler <[EMAIL PROTECTED]> wrote: > >> Ok, I've tried the configuration and login now whilst specifying the >> TPGT. I don't hit the same error now, but I do see this: >> >> # iscsiadm -m node -T >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >> 10.8.0.6:3260 -l >> Login session [iface: default, target: >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal: >> 10.8.0.6,3260] >> iscsiadm: initiator reported error (14 - iSCSI driver does not support >> requested capability.) >> iscsiadm: Could not execute operation on all records. Err 107. >> >> So, progress! >> >> Here is the set of operations I performed. >> >> Thanks >> Jesse >> >> >> # iscsiadm -m node -T >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >> 10.8.0.6:3260,1 -o new >> New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default] >> 10.8.0.6,3260,1 >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added >> >> # iscsiadm -m node -T >> iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p >> 10.8.0.6:3260,1 >> node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 >> node.tpgt = 1 >> node.startup = manual >> iface.hwaddress = default >> iface.iscsi_ifacename = default >> iface.net_ifacename = default >> iface.transport_name = tcp >> node.discovery_address = >> node.discovery_port = 0 >> node.discovery_type = static >> node.session.initial_cmdsn = 0 >> node.session.initial_login_retry_max = 4 >> node.session.cmds_max = 128 >> node.session.queue_depth = 32 >> node.session.auth.authmethod = None >> node.session.auth.username = >> node.session.auth.password = >> node.session.auth.username_in = >> node.session.auth.password_in = >> node.session.timeo.replacement_timeout = 120 >> node.session.err_timeo.abort_timeout = 10 >> node.session.err_timeo.reset_timeout = 30 >> node.session.iscsi.FastAbort = Yes >> node.session.iscsi.InitialR2T = No >> node.session.iscsi.ImmediateData = Yes >> node.session.iscsi.FirstBurstLength = 262144 >> node.session.iscsi.MaxBurstLength = 16776192 >> node.session.iscsi.DefaultTime2Retain = 0 >> node.session.iscsi.DefaultTime2Wait = 2 >> node.session.iscsi.MaxConnections = 1 >> node.session.iscsi.MaxOutstandingR2T = 1 >> node.session.iscsi.ERL = 0 >> node.conn[0].address = 10.8.0.6 >> node.conn[0].port = 3260 >> node.conn[0].startup = manual >> node.conn[0].tcp.window_size = 524288 >> node.conn[0].tcp.type_of_service = 0 >> 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 = 10 >> node.conn[0].timeo.noop_out_timeout = 15 >> node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 >> node.conn[0].iscsi.HeaderDigest = None,CRC32C >> > > I think that this is the problem. iSER doesn't use > HeaderDigest/DataDigest. I strongly suggest that you use > iscsi_discovery which does all the work for you (including setting > HeaderDigest/DataDigest to "None"). > > Erez > > Hello Erez- The HeaderDigest setting here indicates a list of options [None, CRC32C]. If running on iSER, we'll negotiate to "None", and all will be well. I would like to take your advice, but the distribution that I am using does not have the iscsi_discovery with the "-t" option, so I just used static. It could be that what I'm running just won't work (we have discussed offline a known-to-work configuration, I will try that). As an aside, I think it's kinda nutty that there's a chance that the RHEL 5.2 config doesn't work... since, eh, well it's ship There may be something else in the config, though. I'm just trying to figure out what this is: # iscsiadm -m node -T iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p 10.8.0.6:3260 -l Login session [iface: default, target: iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal: 10.8.0.6,3260] iscsiadm: initiator reported error (14 - iSCSI driver does not support requested capability.) iscsiadm: Could not execute operation on all records. Err 107. # I have yet to find it in the code (but I do have my day job). If I don't hear anything, I'll just roll back to RHEL 5.2. Best Jesse --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Am Wednesday, 20. August 2008 11:52 schrieb Mike Christie: > Klemens Kittan wrote: > > Am Wednesday, 20. August 2008 09:43 schrieb Mike Christie: > >> Klemens Kittan wrote: > >>> Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie: > Klemens Kittan wrote: > > Am Monday, 18. August 2008 20:10 schrieb Mike Christie: > >> Klemens Kittan wrote: > >>> Am Friday, 15. August 2008 20:03 schrieb Mike Christie: > Mike Christie wrote: > > Klemens Kittan wrote: > >> Here is the configuration of my debian kernel (2.6.25-2). > > > > Thanks. It looks like your target is responding to other IO, but > > did not respond to the ping quick enough so it timed out. Let me > > make a patch for you to test. I should hopefully have it later > > today. > > Try the attached patch over open-iscsi-2.0-869.2 tarball modules. > > To apply the patch untar and unzip the source then cd to the dir. > Then do: > > patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch > > Then do the normal make and make install. You will probably want > to reboot the box to make sure you are using the new modules. > >>> > >>> Unfortunately I got the same errors. > >> > >> Could you send the log output? > > > > Here is the /var/log/syslog. > > Shoot. For some reason that nop is just not finishing in a decent > amount of time. Could you try the attached patch. It gives the nop > even more time to complete and it spits out a bunch of debug info to > make sure open-iscsi did not leak the task. > >>> > >>> Unfortunately, the attached file is empty. > >> > >> Oh yeah, if you just log into the target and do not do any IO to the > >> disks. Do you see any messages like this: > >> > >> Aug 14 09:52:23 baltrum kernel: [81064.665749] connection2:0: ping > >> timeout of > >> 10 secs expired, last rx 4315069195, last ping 4315067926, now > >> 4315070426 Aug 14 09:52:23 baltrum kernel: [81064.669756] > >> connection2:0: detected conn > >> error (1011) > > > > I get these messages all the time (with and without IO traffic): > > you should get these. I am just worried about getting these > > > Aug 20 09:56:10 baltrum kernel: [168687.391990] connection1:0: ping > > timeout > > > of 10 secs with recv timeout of 5 secs expired last rx 4336967839, > > last ping > > > 4336967081, now 4336970339 task 81003797aac0 > > Aug 20 09:56:10 baltrum kernel: [168687.396001] connection1:0: > > detected conn > > > error (1011) > > when there is no IO traffic. > > > Aug 20 09:49:13 baltrum kernel: [168482.943791] send 8100f9c541c0 > > Aug 20 09:49:13 baltrum kernel: [168483.026754] send 81003797adc0 > > Aug 20 09:49:13 baltrum kernel: [168483.026817] iscsi_free_mgmt_task > > 8100f9c541c0 > > Aug 20 09:49:13 baltrum kernel: [168483.031189] iscsi_free_mgmt_task > > 81003797adc0 > > Aug 20 09:49:18 baltrum kernel: [168487.772859] send 8100f9c54140 > > Aug 20 09:49:18 baltrum kernel: [168488.018304] iscsi_free_mgmt_task > > 8100f9c54140 > > Aug 20 09:49:18 baltrum kernel: [168488.018342] send 81003797aac0 > > Aug 20 09:49:18 baltrum kernel: [168488.026632] iscsi_free_mgmt_task > > 81003797aac0 > > > > With IO traffic I get these messages: > > Could you give me a large chunk of the log? I need the stuff that > happened before this part. > > > Aug 20 09:56:10 baltrum kernel: [168687.391990] connection1:0: ping > > timeout of 10 secs with recv timeout of 5 secs expired last rx > > 4336967839, last ping 4336967081, now 4336970339 task 81003797aac0 > > Aug 20 09:56:10 baltrum kernel: [168687.396001] connection1:0: detected > > conn error (1011) > > Aug 20 09:56:10 baltrum iscsid: Kernel reported iSCSI connection 1:0 > > error (1011) state (3) > > Aug 20 09:56:14 baltrum iscsid: connection1:0 is operational after > > recovery (1 attempts) > > > > Thanks, > > Klemens > Here is the whole log. Thanks, Klemens Aug 20 06:25:10 baltrum syslogd 1.5.0#5: restart. Aug 20 06:31:01 baltrum /USR/SBIN/CRON[17699]: (clamav) CMD ([ -x /usr/bin/freshclam ] && /usr/bin/freshclam --quiet >/dev/null) Aug 20 06:51:33 baltrum -- MARK -- Aug 20 07:11:33 baltrum -- MARK -- Aug 20 07:17:01 baltrum /USR/SBIN/CRON[19082]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Aug 20 07:31:01 baltrum /USR/SBIN/CRON[19505]: (clamav) CMD ([ -x /usr/bin/freshclam ] && /usr/bin/freshclam --quiet >/dev/null) Aug 20 07:51:33 baltrum -- MARK -- Aug 20 08:11:33 baltrum -- MARK -- Aug 20 08:17:01 baltrum /USR/SBIN/CRON[20887]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Aug 20 08:19:32 baltrum multipathd: ift_backup: stop event checker thread Aug 20 08:19:32 baltrum multipathd: ift_vz: stop event checker thread Aug 20 08:19:32 baltrum multipathd: ift_mail: stop event checker thread Aug 20 08:19:32 baltrum multipathd: ift_sql: stop ev
Re: Problem when logging out from specific interface
Hi Mike, Thanks a lot for your help It is working with version 2.0-870. I have some small queries, 1) whether open-iscsi version 2.0-870 is usable and well tested? ( i know its development version but still thought of asking it to you) 2) As you told i did "whereis iscsiadm" before doing make && make install of 2.0-870, it was present in /sbin/ and i just removed it and reinstalled new version. Is this sufficient or do i need to remove any other files at other locations. Also, are u planning to provide make uninstall which will remove required files of older version automatically? 3)While starting open-iscsi service it sets up all targets by login to all available targets, while if there are no targets available it says "No records found!". where does it actually search for these targets? In my case i installed this version on 2 machines on first i did discovery and thenit logged in on all available targets when i do service open-iscsi start. while on sencond one it just said "No records found!". --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: Debian Lenny; Kernel 2.6.26, Iser, Mellanox : iser_cma_handler:event: 3, error: -110
Hello Mike! Mike Christie schrieb: >> I used the following commands: >> >> tgtadm --lld iscsi --op new --mode target --tid 1 -T >> de.inqbus.poseidon:disk1 >> tgtadm --lld iscsi --op bind --mode target --tid 1 -I 10.6.0.1 >> tgtadm --lld iscsi --op new --mode logicalunit --tid 1 --lun 1 -b >> /dev/vg1/test >> > > Could you try a > tgtadm --lld fcoe --op bind --mode target --tid 1 -I ALL > ./tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL results in exactly the same behavior Aug 20 14:44:51 hades kernel: [97036.613263] iser: iser_connect:connecting to: 10.6.0.2, port 0xbc0c Aug 20 14:44:51 hades kernel: [97036.616516] iser: iser_cma_handler:event 0 conn 81000c513080 id 81000d8d1800 Aug 20 14:44:51 hades kernel: [97036.871932] iser: iscsi_iser_ep_poll:ib conn 81000c513080 rc = 0 Aug 20 14:44:51 hades kernel: [97037.179318] iser: iscsi_iser_ep_poll:ib conn 81000c513080 rc = 0 Aug 20 14:44:51 hades kernel: [97037.439327] iser: iscsi_iser_ep_poll:ib conn 81000c513080 rc = 0 Aug 20 14:44:52 hades kernel: [97037.663318] iser: iser_cma_handler:event 3 conn 81000c513080 id 81000d8d1800 Aug 20 14:44:52 hades kernel: [97037.663318] iser: iser_cma_handler:event: 3, error: -110 Aug 20 14:44:52 hades kernel: [97037.703064] iser: iscsi_iser_ep_poll:ib conn 81000c513080 rc = -1 Aug 20 14:44:55 hades kernel: [97041.675045] iser: iscsi_iser_ep_disconnect:ib conn 81000c513080 state 4 Aug 20 14:44:55 hades kernel: [97041.675076] iser: iser_conn_terminate:Failed to disconnect, conn: 0x81000c513080 err -22 Aug 20 14:44:55 hades kernel: [97041.675121] iser: iser_free_ib_conn_res:freeing conn 81000c513080 cma_id 81000d8d1800 fmr pool 0 000 qp Any other ideas ? Best regards Volker -- inqbus it-consulting +49 ( 341 ) 5643800 Dr. Volker Jaenisch http://www.inqbus.de Herloßsohnstr.12 0 4 1 5 5Leipzig N O T - F Ä L L E +49 ( 170 ) 3113748 --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
RE: Reducing amount of logmessages openiscsi/multipath [with md3000i]
> -Original Message-
> He wants the RDAC hw handler and its path checker (rdac). The MD3000i
> is an
> LSI re-branded box and is the same as the IBM DS3300.
>
> >
> > You also want to make sure that you are using the md3000i hw handler
> or
> > scsh_dh_module if you are not already. The dm-devel guys can help you
> out.
>
> Here is the multipath.conf he should be using for MD3000i (or for the
> DS3300
> but will need to modify the vendor/model entry)
>
> # Note: The same as the IBM DS3300
> #
> device {
> vendor "DELL"
> product "MD3000i"
> product_blacklist "Universal Xport"
> features"1 queue_if_no_path"
> path_grouping_policygroup_by_prio
> hardware_handler"1 rdac"
> path_checkerrdac
> prio"rdac"
> failbackimmediate
> }
>
>
This fixed the problem, although a simple flush was not enough to activate
the changes, so it took a bit longer to get the result I wanted. In the end
I saw that it was still using the direction path_checker and noticed that
you cannot change the 'path_checker' on the fly with just a multipath -F /
-v 2, but that a reload of the modules was needed.
$ multipath -ll
webdata (36001ec9000d16311067f484e260c) dm-0 DELL,MD3000i
[size=2.0T][features=0][hwhandler=1 rdac]
\_ round-robin 0 [prio=1000][active]
\_ 0:0:0:0 sda 8:0 [active][ready]
\_ round-robin 0 [prio=1][enabled]
\_ 1:0:0:0 sdb 8:16 [active][ready]
\_ round-robin 0 [prio=0][enabled]
\_ 2:0:0:0 sdc 8:32 [active][ghost]
\_ 3:0:0:0 sdd 8:48 [active][ghost]
That is the output of multipath now, and no more spam in my syslog or dmesg.
(The different priorities you see are because the second path (with a prio
of 1) is a longer path through 1 more switch, so I'd rather not give it a
high priority, and if the '1000' path fails, it just uses the '1' path.)
A big thanks to everyone who directed me on the right path ;)
-kees
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: iSER login process
On Wed, Aug 20, 2008 at 12:04 AM, Jesse Butler <[EMAIL PROTECTED]> wrote: > > > Ok, I've tried the configuration and login now whilst specifying the > TPGT. I don't hit the same error now, but I do see this: > > # iscsiadm -m node -T > iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p > 10.8.0.6:3260 -l > Login session [iface: default, target: > iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346, portal: > 10.8.0.6,3260] > iscsiadm: initiator reported error (14 - iSCSI driver does not support > requested capability.) > iscsiadm: Could not execute operation on all records. Err 107. > > So, progress! > > Here is the set of operations I performed. > > Thanks > Jesse > > > # iscsiadm -m node -T > iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p > 10.8.0.6:3260,1 -o new > New iSCSI node [tcp:[hw=default,ip=,net_if=default,iscsi_if=default] > 10.8.0.6,3260,1 > iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346] added > > # iscsiadm -m node -T > iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 -p > 10.8.0.6:3260,1 > node.name = iqn.1986-03.com.sun:02:aff22998-3466-4bf4-ee3c-958fd4b5d346 > node.tpgt = 1 > node.startup = manual > iface.hwaddress = default > iface.iscsi_ifacename = default > iface.net_ifacename = default > iface.transport_name = tcp > node.discovery_address = > node.discovery_port = 0 > node.discovery_type = static > node.session.initial_cmdsn = 0 > node.session.initial_login_retry_max = 4 > node.session.cmds_max = 128 > node.session.queue_depth = 32 > node.session.auth.authmethod = None > node.session.auth.username = > node.session.auth.password = > node.session.auth.username_in = > node.session.auth.password_in = > node.session.timeo.replacement_timeout = 120 > node.session.err_timeo.abort_timeout = 10 > node.session.err_timeo.reset_timeout = 30 > node.session.iscsi.FastAbort = Yes > node.session.iscsi.InitialR2T = No > node.session.iscsi.ImmediateData = Yes > node.session.iscsi.FirstBurstLength = 262144 > node.session.iscsi.MaxBurstLength = 16776192 > node.session.iscsi.DefaultTime2Retain = 0 > node.session.iscsi.DefaultTime2Wait = 2 > node.session.iscsi.MaxConnections = 1 > node.session.iscsi.MaxOutstandingR2T = 1 > node.session.iscsi.ERL = 0 > node.conn[0].address = 10.8.0.6 > node.conn[0].port = 3260 > node.conn[0].startup = manual > node.conn[0].tcp.window_size = 524288 > node.conn[0].tcp.type_of_service = 0 > 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 = 10 > node.conn[0].timeo.noop_out_timeout = 15 > node.conn[0].iscsi.MaxRecvDataSegmentLength = 131072 > node.conn[0].iscsi.HeaderDigest = None,CRC32C I think that this is the problem. iSER doesn't use HeaderDigest/DataDigest. I strongly suggest that you use iscsi_discovery which does all the work for you (including setting HeaderDigest/DataDigest to "None"). Erez --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Klemens Kittan wrote: > Am Wednesday, 20. August 2008 09:43 schrieb Mike Christie: >> Klemens Kittan wrote: >>> Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie: Klemens Kittan wrote: > Am Monday, 18. August 2008 20:10 schrieb Mike Christie: >> Klemens Kittan wrote: >>> Am Friday, 15. August 2008 20:03 schrieb Mike Christie: Mike Christie wrote: > Klemens Kittan wrote: >> Here is the configuration of my debian kernel (2.6.25-2). > Thanks. It looks like your target is responding to other IO, but > did not respond to the ping quick enough so it timed out. Let me > make a patch for you to test. I should hopefully have it later > today. Try the attached patch over open-iscsi-2.0-869.2 tarball modules. To apply the patch untar and unzip the source then cd to the dir. Then do: patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch Then do the normal make and make install. You will probably want to reboot the box to make sure you are using the new modules. >>> Unfortunately I got the same errors. >> Could you send the log output? > Here is the /var/log/syslog. Shoot. For some reason that nop is just not finishing in a decent amount of time. Could you try the attached patch. It gives the nop even more time to complete and it spits out a bunch of debug info to make sure open-iscsi did not leak the task. >>> Unfortunately, the attached file is empty. >> Oh yeah, if you just log into the target and do not do any IO to the >> disks. Do you see any messages like this: >> >> Aug 14 09:52:23 baltrum kernel: [81064.665749] connection2:0: ping >> timeout of >> 10 secs expired, last rx 4315069195, last ping 4315067926, now 4315070426 >> Aug 14 09:52:23 baltrum kernel: [81064.669756] connection2:0: detected >> conn >> error (1011) >> > > I get these messages all the time (with and without IO traffic): you should get these. I am just worried about getting these > Aug 20 09:56:10 baltrum kernel: [168687.391990] connection1:0: ping timeout > of 10 secs with recv timeout of 5 secs expired last rx 4336967839, last ping > 4336967081, now 4336970339 task 81003797aac0 > Aug 20 09:56:10 baltrum kernel: [168687.396001] connection1:0: detected conn > error (1011) when there is no IO traffic. > Aug 20 09:49:13 baltrum kernel: [168482.943791] send 8100f9c541c0 > Aug 20 09:49:13 baltrum kernel: [168483.026754] send 81003797adc0 > Aug 20 09:49:13 baltrum kernel: [168483.026817] iscsi_free_mgmt_task > 8100f9c541c0 > Aug 20 09:49:13 baltrum kernel: [168483.031189] iscsi_free_mgmt_task > 81003797adc0 > Aug 20 09:49:18 baltrum kernel: [168487.772859] send 8100f9c54140 > Aug 20 09:49:18 baltrum kernel: [168488.018304] iscsi_free_mgmt_task > 8100f9c54140 > Aug 20 09:49:18 baltrum kernel: [168488.018342] send 81003797aac0 > Aug 20 09:49:18 baltrum kernel: [168488.026632] iscsi_free_mgmt_task > 81003797aac0 > > With IO traffic I get these messages: Could you give me a large chunk of the log? I need the stuff that happened before this part. > Aug 20 09:56:10 baltrum kernel: [168687.391990] connection1:0: ping timeout > of 10 secs with recv timeout of 5 secs expired last rx 4336967839, last ping > 4336967081, now 4336970339 task 81003797aac0 > Aug 20 09:56:10 baltrum kernel: [168687.396001] connection1:0: detected conn > error (1011) > Aug 20 09:56:10 baltrum iscsid: Kernel reported iSCSI connection 1:0 error > (1011) state (3) > Aug 20 09:56:14 baltrum iscsid: connection1:0 is operational after recovery > (1 > attempts) > > Thanks, > Klemens > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Am Wednesday, 20. August 2008 09:43 schrieb Mike Christie: > Klemens Kittan wrote: > > Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie: > >> Klemens Kittan wrote: > >>> Am Monday, 18. August 2008 20:10 schrieb Mike Christie: > Klemens Kittan wrote: > > Am Friday, 15. August 2008 20:03 schrieb Mike Christie: > >> Mike Christie wrote: > >>> Klemens Kittan wrote: > Here is the configuration of my debian kernel (2.6.25-2). > >>> > >>> Thanks. It looks like your target is responding to other IO, but > >>> did not respond to the ping quick enough so it timed out. Let me > >>> make a patch for you to test. I should hopefully have it later > >>> today. > >> > >> Try the attached patch over open-iscsi-2.0-869.2 tarball modules. > >> > >> To apply the patch untar and unzip the source then cd to the dir. > >> Then do: > >> > >> patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch > >> > >> Then do the normal make and make install. You will probably want to > >> reboot the box to make sure you are using the new modules. > > > > Unfortunately I got the same errors. > > Could you send the log output? > >>> > >>> Here is the /var/log/syslog. > >> > >> Shoot. For some reason that nop is just not finishing in a decent amount > >> of time. Could you try the attached patch. It gives the nop even more > >> time to complete and it spits out a bunch of debug info to make sure > >> open-iscsi did not leak the task. > > > > Unfortunately, the attached file is empty. > > Oh yeah, if you just log into the target and do not do any IO to the > disks. Do you see any messages like this: > > Aug 14 09:52:23 baltrum kernel: [81064.665749] connection2:0: ping > timeout of > 10 secs expired, last rx 4315069195, last ping 4315067926, now 4315070426 > Aug 14 09:52:23 baltrum kernel: [81064.669756] connection2:0: detected > conn > error (1011) > I get these messages all the time (with and without IO traffic): Aug 20 09:49:13 baltrum kernel: [168482.943791] send 8100f9c541c0 Aug 20 09:49:13 baltrum kernel: [168483.026754] send 81003797adc0 Aug 20 09:49:13 baltrum kernel: [168483.026817] iscsi_free_mgmt_task 8100f9c541c0 Aug 20 09:49:13 baltrum kernel: [168483.031189] iscsi_free_mgmt_task 81003797adc0 Aug 20 09:49:18 baltrum kernel: [168487.772859] send 8100f9c54140 Aug 20 09:49:18 baltrum kernel: [168488.018304] iscsi_free_mgmt_task 8100f9c54140 Aug 20 09:49:18 baltrum kernel: [168488.018342] send 81003797aac0 Aug 20 09:49:18 baltrum kernel: [168488.026632] iscsi_free_mgmt_task 81003797aac0 With IO traffic I get these messages: Aug 20 09:56:10 baltrum kernel: [168687.391990] connection1:0: ping timeout of 10 secs with recv timeout of 5 secs expired last rx 4336967839, last ping 4336967081, now 4336970339 task 81003797aac0 Aug 20 09:56:10 baltrum kernel: [168687.396001] connection1:0: detected conn error (1011) Aug 20 09:56:10 baltrum iscsid: Kernel reported iSCSI connection 1:0 error (1011) state (3) Aug 20 09:56:14 baltrum iscsid: connection1:0 is operational after recovery (1 attempts) Thanks, Klemens pgpKoS5RiKNwU.pgp Description: PGP signature
Re: iscsi errors with debian-kernel 2.6.24-3-686
Klemens Kittan wrote: > Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie: >> Klemens Kittan wrote: >>> Am Monday, 18. August 2008 20:10 schrieb Mike Christie: Klemens Kittan wrote: > Am Friday, 15. August 2008 20:03 schrieb Mike Christie: >> Mike Christie wrote: >>> Klemens Kittan wrote: Here is the configuration of my debian kernel (2.6.25-2). >>> Thanks. It looks like your target is responding to other IO, but did >>> not respond to the ping quick enough so it timed out. Let me make a >>> patch for you to test. I should hopefully have it later today. >> Try the attached patch over open-iscsi-2.0-869.2 tarball modules. >> >> To apply the patch untar and unzip the source then cd to the dir. Then >> do: >> >> patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch >> >> Then do the normal make and make install. You will probably want to >> reboot the box to make sure you are using the new modules. > Unfortunately I got the same errors. Could you send the log output? >>> Here is the /var/log/syslog. >> Shoot. For some reason that nop is just not finishing in a decent amount >> of time. Could you try the attached patch. It gives the nop even more >> time to complete and it spits out a bunch of debug info to make sure >> open-iscsi did not leak the task. >> > > Unfortunately, the attached file is empty. > Oh yeah, if you just log into the target and do not do any IO to the disks. Do you see any messages like this: Aug 14 09:52:23 baltrum kernel: [81064.665749] connection2:0: ping timeout of 10 secs expired, last rx 4315069195, last ping 4315067926, now 4315070426 Aug 14 09:52:23 baltrum kernel: [81064.669756] connection2:0: detected conn error (1011) --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Klemens Kittan wrote:
> Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie:
>> Klemens Kittan wrote:
>>> Am Monday, 18. August 2008 20:10 schrieb Mike Christie:
Klemens Kittan wrote:
> Am Friday, 15. August 2008 20:03 schrieb Mike Christie:
>> Mike Christie wrote:
>>> Klemens Kittan wrote:
Here is the configuration of my debian kernel (2.6.25-2).
>>> Thanks. It looks like your target is responding to other IO, but did
>>> not respond to the ping quick enough so it timed out. Let me make a
>>> patch for you to test. I should hopefully have it later today.
>> Try the attached patch over open-iscsi-2.0-869.2 tarball modules.
>>
>> To apply the patch untar and unzip the source then cd to the dir. Then
>> do:
>>
>> patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch
>>
>> Then do the normal make and make install. You will probably want to
>> reboot the box to make sure you are using the new modules.
> Unfortunately I got the same errors.
Could you send the log output?
>>> Here is the /var/log/syslog.
>> Shoot. For some reason that nop is just not finishing in a decent amount
>> of time. Could you try the attached patch. It gives the nop even more
>> time to complete and it spits out a bunch of debug info to make sure
>> open-iscsi did not leak the task.
>>
>
> Unfortunately, the attached file is empty.
>
Sorry here 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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---
--- open-iscsi-2.0-869.2/kernel/libiscsi.c 2008-05-08 19:53:48.0
-0500
+++ open-iscsi-2.0-869.2.nop/kernel/libiscsi.c 2008-08-19 12:13:38.0
-0500
@@ -319,8 +319,10 @@ void iscsi_free_mgmt_task(struct iscsi_c
if (conn->login_mtask == mtask)
return;
- if (conn->ping_mtask == mtask)
+ if (conn->ping_mtask == mtask) {
+ printk(KERN_ERR "iscsi_free_mgmt_task %p\n", mtask);
conn->ping_mtask = NULL;
+ }
__kfifo_put(conn->session->mgmtpool.queue,
(void*)&mtask, sizeof(void*));
}
@@ -501,6 +503,7 @@ static void iscsi_send_nopout(struct isc
/* only track our nops */
if (!rhdr) {
+ printk(KERN_ERR "send %p\n", mtask);
conn->ping_mtask = mtask;
conn->last_ping = jiffies;
}
@@ -628,6 +631,7 @@ static int __iscsi_complete_pdu(struct i
conn->exp_statsn = be32_to_cpu(hdr->statsn) + 1;
if (conn->ping_mtask != mtask) {
+ printk(KERN_ERR "userspace nop\n");
/*
* If this is not in response to one of our
* nops then it must be from userspace.
@@ -1367,19 +1371,28 @@ static void iscsi_check_transport_timeou
recv_timeout *= HZ;
last_recv = conn->last_recv;
+ /*
+* Don't fire the eh if the ping timed out but we are getting
+* other IO responses. Just give it more time.
+*/
if (conn->ping_mtask &&
time_before_eq(conn->last_ping + (conn->ping_timeout * HZ),
- jiffies)) {
+ jiffies) &&
+ time_before_eq(last_recv + (recv_timeout * 2), jiffies)) {
iscsi_conn_printk(KERN_ERR, conn, "ping timeout of %d secs "
- "expired, last rx %lu, last ping %lu, "
- "now %lu\n", conn->ping_timeout, last_recv,
- conn->last_ping, jiffies);
+ "with recv timeout of %d secs expired "
+ "last rx %lu, last ping %lu, now %lu "
+ "task %p\n",
+ conn->ping_timeout, conn->recv_timeout,
+ last_recv, conn->last_ping, jiffies,
+ conn->ping_mtask);
spin_unlock(&session->lock);
iscsi_conn_failure(conn, ISCSI_ERR_CONN_FAILED);
return;
}
- if (time_before_eq(last_recv + recv_timeout, jiffies)) {
+ if (!conn->ping_mtask &&
+ time_before_eq(last_recv + recv_timeout, jiffies)) {
/* send a ping to try to provoke some traffic */
debug_scsi("Sending nopout as ping on conn %p\n", conn);
iscsi_send_nopout(conn, NULL);
Re: Configuration question
v42bis wrote: > Thank for the reply, Mike. > No problem. > The iscsi connections failed about 1m13s after my iscsi target went > down (timestamps that follow are synced from same ntp master, however > clock skew may account for a few seconds difference [1m45sec seems > very conspicuous - a multiplier of default 15sec timers?]). The target > went down at Aug 19 13:33:33. Actually this looks like a different problem. What version of open-iscsi are you using? Do a "iscsiadm -P 3". The top part should dump the iscsiadm version. > Aug 19 13:36:42 ak1-vz2 kernel: iscsi: scsi conn_destroy(): host_busy > 0 host_failed 0 This means that userspace decided to kill the iscsi session/connection which means that we ignore the recovery/replacement timeout and just kill everything which forces IO errors. We only did this for fatal errors, but we should not do that anymore. > > The above did not affect normal operation of my open-iscsi initiators. > That is weirder. In this setup do you have multiple sessions/connections? When you checked the machine were all the session/connections running? There should have been two sessions that were destroyed. In older open-iscsi userspace tools there were certain errors the target could send us and iscsid would consider it a fatal error and it would kill the sessions like above. For example if a target was shutting down it could tell us that it was not coming back, so we would kill the session. There was also a case where iscsid got confused and thought it was a fatal error and would kill the session. We now just retry forever or until the user kills the session manually to avoid problems like this. Please tell me you were using a older version than open-iscsi-2.0-869.2 :) If you were using open-iscsi-2.0-869.2 then we have a different problem :( --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: iscsi errors with debian-kernel 2.6.24-3-686
Am Tuesday, 19. August 2008 19:15 schrieb Mike Christie: > Klemens Kittan wrote: > > Am Monday, 18. August 2008 20:10 schrieb Mike Christie: > >> Klemens Kittan wrote: > >>> Am Friday, 15. August 2008 20:03 schrieb Mike Christie: > Mike Christie wrote: > > Klemens Kittan wrote: > >> Here is the configuration of my debian kernel (2.6.25-2). > > > > Thanks. It looks like your target is responding to other IO, but did > > not respond to the ping quick enough so it timed out. Let me make a > > patch for you to test. I should hopefully have it later today. > > Try the attached patch over open-iscsi-2.0-869.2 tarball modules. > > To apply the patch untar and unzip the source then cd to the dir. Then > do: > > patch -p1 -i where-the-patch-is-saved/relax-ping-timer.patch > > Then do the normal make and make install. You will probably want to > reboot the box to make sure you are using the new modules. > >>> > >>> Unfortunately I got the same errors. > >> > >> Could you send the log output? > > > > Here is the /var/log/syslog. > > Shoot. For some reason that nop is just not finishing in a decent amount > of time. Could you try the attached patch. It gives the nop even more > time to complete and it spits out a bunch of debug info to make sure > open-iscsi did not leak the task. > Unfortunately, the attached file is empty. Thanks, Klemens pgpiyh0rkEpvI.pgp Description: PGP signature
Re: Configuration question
On Aug 20, 12:46 am, Mike Christie <[EMAIL PROTECTED]> wrote: > v42bis wrote: > > I have changed the timeouts in iscsid.conf as directed in the iSCSI > > Root section 8.2 of the README so that in case the open-iscsi > > initiator loses connection or has other communications problems with > > my OpenSolaris target then the open-iscsi initiator will wait for up > > to 24 hours before it fails to the SCSI layer: > > > node.session.timeo.replacement_timeout = 86400 > > node.conn[0].timeo.login_timeout = 15 > > node.conn[0].timeo.logout_timeout = 15 > > node.conn[0].timeo.noop_out_interval = 0 > > node.conn[0].timeo.noop_out_timeout = 0 > > > My OpenSolaris target recently core dumped and came back online in > > about 5 minutes. By that time, all of my ext3 partitions mounted over > > iscsi had aborted their journals. Shouldn't iscsi wait for 24 hours > > before I see any failures on my SCSI layer affecting my ext3 > > partitions? > > It should have. Do you have the logs? Do you see something about the > replacement or recovery timeout timing out. It would have the correct > 86400 value, but when you look at the log it would say that it failed a > lot quicker like the 5 minutes you mention. If this happens you may be > hitting a bug where the kernel cannot support long timeouts and > basically what is happening is the kernel's timer is rolling over and > not caching it self right or maybe we are not supposed to be setting > that high. We are still investigating to see who is at fault. Thank for the reply, Mike. The iscsi connections failed about 1m13s after my iscsi target went down (timestamps that follow are synced from same ntp master, however clock skew may account for a few seconds difference [1m45sec seems very conspicuous - a multiplier of default 15sec timers?]). The target went down at Aug 19 13:33:33. >From /var/log/messages of one of my open-iscsi clients with two sessions active and ext3 filesystems mounted from each at the time of target failure: Aug 19 13:34:46 ak1-vz2 kernel: connection2:0: iscsi: detected conn error (1011) Aug 19 13:35:47 ak1-vz2 kernel: connection1:0: iscsi: detected conn error (1011) Aug 19 13:36:38 ak1-vz2 kernel: sd 6:0:0:0: scsi: Device offlined - not ready after error recovery Aug 19 13:36:38 ak1-vz2 kernel: sd 6:0:0:0: scsi: Device offlined - not ready after error recovery Aug 19 13:36:38 ak1-vz2 kernel: sd 6:0:0:0: SCSI error: return code = 0x0002 Aug 19 13:36:38 ak1-vz2 kernel: end_request: I/O error, dev sdc, sector 4063233 Aug 19 13:36:38 ak1-vz2 kernel: lost page write due to I/O error on sdc1 Aug 19 13:36:38 ak1-vz2 kernel: sd 6:0:0:0: SCSI error: return code = 0x0002 Aug 19 13:36:38 ak1-vz2 kernel: end_request: I/O error, dev sdc, sector 4157905 Aug 19 13:36:38 ak1-vz2 kernel: lost page write due to I/O error on sdc1 Aug 19 13:36:39 ak1-vz2 kernel: iscsi: scsi conn_destroy(): host_busy 0 host_failed 0 Aug 19 13:36:39 ak1-vz2 kernel: lost page write due to I/O error on sdc1 Aug 19 13:36:39 ak1-vz2 last message repeated 2 times Aug 19 13:36:41 ak1-vz2 kernel: sd 7:0:0:0: scsi: Device offlined - not ready after error recovery Aug 19 13:36:41 ak1-vz2 kernel: sd 7:0:0:0: scsi: Device offlined - not ready after error recovery Aug 19 13:36:41 ak1-vz2 kernel: sd 7:0:0:0: SCSI error: return code = 0x0002 Aug 19 13:36:41 ak1-vz2 kernel: end_request: I/O error, dev sdd, sector 126137 Aug 19 13:36:41 ak1-vz2 kernel: lost page write due to I/O error on sdd1 Aug 19 13:36:41 ak1-vz2 last message repeated 4 times Aug 19 13:36:41 ak1-vz2 kernel: sd 7:0:0:0: SCSI error: return code = 0x0002 Aug 19 13:36:41 ak1-vz2 kernel: end_request: I/O error, dev sdd, sector 33214121 Aug 19 13:36:42 ak1-vz2 kernel: iscsi: scsi conn_destroy(): host_busy 0 host_failed 0 Aug 19 13:36:42 ak1-vz2 kernel: sd 7:0:0:0: SCSI error: return code = 0x0001 Aug 19 13:36:42 ak1-vz2 kernel: end_request: I/O error, dev sdd, sector 33216097 Aug 19 13:36:42 ak1-vz2 kernel: __journal_remove_journal_head: freeing b_committed_data Aug 19 13:36:45 ak1-vz2 kernel: reading directory #1245317 offset 0 I have seen the following logs in the past when my iscsi target machine fails over to a multipath/bonded NIC within about 30 seconds: Jul 29 08:20:09 ak1-vz3.aktiom.net iscsid: received iferror -38 Jul 29 08:20:09 ak1-vz3.aktiom.net iscsid: connection8:0 is operational now The above did not affect normal operation of my open-iscsi initiators. This is the only debug info I have. I didn't install open-iscsi with debug enabled. -- Dave --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
