Re: Problem with iSCSI connected LTO-2 tape drive

[Lee Duncan]

> On Dec 28, 2016, at 4:48 AM, David C. Partridge 
> <david.partri...@perdrix.co.uk> wrote:
> 
> FWIW I still think the best solution is to suspend the NOP-Out polling (of 
> active) while a device command is being processed.  This way you get the best 
> of both worlds
>  
> However I do see the attraction of a documentation only fix J

LOL. It’s not (just) that I’m lazy. I honestly don’t think the code should 
change for this issue.

IMHO the NOP usage is a bad idea anyway, but it can be handy to detect a bad 
connection when no I/O is occurring.

The problem I think in this case is that open-iscsi does not treat tape and 
disc drives separately.

So if I send a command to a disc drive and don’t hear back for 8 minutes, I 
know that is not good. And for a disc drive, they always handle commands 
disconnected, i.e. the response for a read or write comes later, not when I 
request it. In that case, the disc brains does actually respond to PINGs while 
an operation is going on.

If we tried to add code that said “if any commands are outstanding don’t send 
PINGs”, then we could not catch the case where the disc server has gone away 
while a command was outstanding.

So unless you can come up with an idea that addresses this tape issue and 
regular usage, I don’t see any way to easily fix this.

But I’m open to suggestions. :)

>  
> Cheers
> Dave
>  
> From: open-iscsi@googlegroups.com <mailto:open-iscsi@googlegroups.com> 
> [mailto:open-iscsi@googlegroups.com <mailto:open-iscsi@googlegroups.com>] On 
> Behalf Of The Lee-Man
> Sent: 22 December 2016 16:51
> To: open-iscsi
> Subject: Re: Problem with iSCSI connected LTO-2 tape drive
>  
> Hi David:
> 
> I have created Issue#35 for this on github.
> 
> On Thursday, December 15, 2016 at 2:00:15 PM UTC-8, David C. Partridge wrote:
> You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as 
> well?
>  
> Dave
>  

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

RE: Problem with iSCSI connected LTO-2 tape drive

[David C. Partridge]

FWIW I still think the best solution is to suspend the NOP-Out polling (of 
active) while a device command is being processed.  This way you get the best 
of both worlds

 

However I do see the attraction of a documentation only fix J

 

Cheers

Dave

 

From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On 
Behalf Of The Lee-Man
Sent: 22 December 2016 16:51
To: open-iscsi
Subject: Re: Problem with iSCSI connected LTO-2 tape drive

 

Hi David:

I have created Issue#35 for this on github.

On Thursday, December 15, 2016 at 2:00:15 PM UTC-8, David C. Partridge wrote:

You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as well?

 

Dave

 

From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On 
Behalf Of Lee Duncan
Sent: 15 December 2016 19:41
To: open-iscsi@googlegroups.com
Subject: Re: Problem with iSCSI connected LTO-2 tape drive

 

On Dec 15, 2016, at 7:14 AM, david.partri...@perdrix.co.uk wrote:

 

Lee,

It would appear that the guilty party was:

node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

I changed both of these to 0 for the tape device and the problem went away.

 

Excellent.

 


Please note that the README.gz for open-scsi doesn't actually say that this is 
what you need to do to disable the NOP-out polling, so could I suggest that 
this be stated explicitly. 

 

My README says, in section 8.2:

 

For this setup, you can turn off iSCSI pings by setting:

 

node.conn[0].timeo.noop_out_interval = 0

node.conn[0].timeo.noop_out_timeout = 0

 

 

I must admit that I find it hard to imagine that an iSCSI target would reply to 
a NOP-out while it was processing a command such as a tape fsf or even tape 
erase (whose timeout is 6 * the long-timeout of 4 hours).  Should perhaps the 
NOP-out polling be suspended while a command is being processed?  Or 
alternatively maybe the NOP-out polling be completely disabled by default with 
something in the README.gz file that explains WHEN you might want it and how to 
enable it.   It's certainly clear that (at least) the MS iSCSI initiator 
doesn't send NOP-out polls.

 

open-iscsi is normally used to deal with discs. When it’s used with tape it’s 
not unusual to find bugs or design errors that we did not know were present.

 

Perhaps a small blurb in the README about dealing with tape, suggesting turning 
NOOP/ping off. Please feel free to post a pull request on github or suggest a 
patch on this list.

 

 


Regards
Dave

 

 

-- 

Lee Duncan

 

"Choice means saying no to one thing so you can say yes to another." -- Dan 
Millman

 

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "open-iscsi" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/open-iscsi/ViC-za8eHdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "open-iscsi" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/open-iscsi/ViC-za8eHdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

Hi David:

I have created Issue#35 for this on github.

On Thursday, December 15, 2016 at 2:00:15 PM UTC-8, David C. Partridge 
wrote:
>
> You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as 
> well?
>
>  
>
> Dave
>
>  
>
> *From:* open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] *On 
> Behalf Of *Lee Duncan
> *Sent:* 15 December 2016 19:41
> *To:* open-iscsi@googlegroups.com
> *Subject:* Re: Problem with iSCSI connected LTO-2 tape drive
>
>  
>
> On Dec 15, 2016, at 7:14 AM, david.partri...@perdrix.co.uk wrote:
>
>  
>
> Lee,
>
> It would appear that the guilty party was:
>
> node.conn[0].timeo.noop_out_interval = 5
> node.conn[0].timeo.noop_out_timeout = 5
>
> I changed both of these to 0 for the tape device and the problem went away.
>
>  
>
> Excellent.
>
>
>
>
> Please note that the README.gz for open-scsi doesn't actually say that 
> this is what you need to do to disable the NOP-out polling, so could I 
> suggest that this be stated explicitly. 
>
>  
>
> My README says, in section 8.2:
>
>  
>
> For this setup, you can turn off iSCSI pings by setting:
>
>  
>
> node.conn[0].timeo.noop_out_interval = 0
>
> node.conn[0].timeo.noop_out_timeout = 0
>
>  
>
>
>
> I must admit that I find it hard to imagine that an iSCSI target would 
> reply to a NOP-out while it was processing a command such as a tape fsf or 
> even tape erase (whose timeout is 6 * the long-timeout of 4 hours).  Should 
> perhaps the NOP-out polling be suspended while a command is being 
> processed?  Or alternatively maybe the NOP-out polling be completely 
> disabled by default with something in the README.gz file that explains WHEN 
> you might want it and how to enable it.   It's certainly clear that (at 
> least) the MS iSCSI initiator doesn't send NOP-out polls.
>
>  
>
> open-iscsi is normally used to deal with discs. When it’s used with tape 
> it’s not unusual to find bugs or design errors that we did not know were 
> present.
>
>  
>
> Perhaps a small blurb in the README about dealing with tape, suggesting 
> turning NOOP/ping off. Please feel free to post a pull request on github or 
> suggest a patch on this list.
>
>  
>
>
>
>
> Regards
> Dave
>
>  
>
>  
>
> -- 
>
> Lee Duncan
>
>  
>
> "Choice means saying no to one thing so you can say yes to another." -- 
> Dan Millman
>
>  
>
> -- 
> You received this message because you are subscribed to a topic in the 
> Google Groups "open-iscsi" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/open-iscsi/ViC-za8eHdc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

RE: Problem with iSCSI connected LTO-2 tape drive

[David C. Partridge]

You’re right, it is in section 8.2.  Maybe it needs to be said in 8.1.1 as well?

 

Dave

 

From: open-iscsi@googlegroups.com [mailto:open-iscsi@googlegroups.com] On 
Behalf Of Lee Duncan
Sent: 15 December 2016 19:41
To: open-iscsi@googlegroups.com
Subject: Re: Problem with iSCSI connected LTO-2 tape drive

 

On Dec 15, 2016, at 7:14 AM, david.partri...@perdrix.co.uk wrote:

 

Lee,

It would appear that the guilty party was:

node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

I changed both of these to 0 for the tape device and the problem went away.

 

Excellent.






Please note that the README.gz for open-scsi doesn't actually say that this is 
what you need to do to disable the NOP-out polling, so could I suggest that 
this be stated explicitly. 

 

My README says, in section 8.2:

 

For this setup, you can turn off iSCSI pings by setting:

 

node.conn[0].timeo.noop_out_interval = 0

node.conn[0].timeo.noop_out_timeout = 0

 





I must admit that I find it hard to imagine that an iSCSI target would reply to 
a NOP-out while it was processing a command such as a tape fsf or even tape 
erase (whose timeout is 6 * the long-timeout of 4 hours).  Should perhaps the 
NOP-out polling be suspended while a command is being processed?  Or 
alternatively maybe the NOP-out polling be completely disabled by default with 
something in the README.gz file that explains WHEN you might want it and how to 
enable it.   It's certainly clear that (at least) the MS iSCSI initiator 
doesn't send NOP-out polls.

 

open-iscsi is normally used to deal with discs. When it’s used with tape it’s 
not unusual to find bugs or design errors that we did not know were present.

 

Perhaps a small blurb in the README about dealing with tape, suggesting turning 
NOOP/ping off. Please feel free to post a pull request on github or suggest a 
patch on this list.

 






Regards
Dave

 

 

-- 

Lee Duncan

 

"Choice means saying no to one thing so you can say yes to another." -- Dan 
Millman

 

-- 
You received this message because you are subscribed to a topic in the Google 
Groups "open-iscsi" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/open-iscsi/ViC-za8eHdc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[david . partridge]

Lee,

It would appear that the guilty party was:

node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

I changed both of these to 0 for the tape device and the problem went away.

Please note that the README.gz for open-scsi doesn't actually say that this 
is what you need to do to disable the NOP-out polling, so could I suggest 
that this be stated explicitly. 

I must admit that I find it hard to imagine that an iSCSI target would 
reply to a NOP-out while it was processing a command such as a tape fsf or 
even tape erase (whose timeout is 6 * the long-timeout of 4 hours).  Should 
perhaps the NOP-out polling be suspended while a command is being 
processed?  Or alternatively maybe the NOP-out polling be completely 
disabled by default with something in the README.gz file that explains WHEN 
you might want it and how to enable it.   It's certainly clear that (at 
least) the MS iSCSI initiator doesn't send NOP-out polls.

Regards
Dave

Regards
Dave



On Wednesday, 14 December 2016 19:18:16 UTC, The Lee-Man wrote:
>
> >Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. 
> This is also discussed in the README file. I’d try setting them both >to 0 
> to get them out of the way. It looks like the tape drive does not respond 
> to the NOOP ping when it is busy for 80+ seconds skipping forward >one 
> file. 
>
> — 
> Lee Duncan 
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[david . partridge]

Ulrich is correct, the scsi timeouts for tape drives are a *lot* longer.  
The short timeout is 900 seconds and the long timeout is 14400 seconds (4 
hours).

The IOCTL error message is occurring after 15 seconds, which I think points 
at the iSCSI layer.

Cheers
Dave Partridge

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Antw: Re: Problem with iSCSI connected LTO-2 tape drive

[Ulrich Windl]

>>> Lee Duncan  schrieb am 14.12.2016 um 20:18 in
Nachricht <8286a277-f7fe-4c7d-a944-40034a0b5...@gmail.com>:
> On Dec 12, 2016, at 5:46 AM, Dave partridge 
wrote:
>> 
>> I just ran a Wireshark capture on the target system of the iSCSI session
for 
> a Windows initiator connecting the tape and then issuing an FSF.  I then did

> the same for the Ubuntu open-iscsi initiator.
>> 
>> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
>> 
>> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being

> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
>> 
>> Do any of the open-iscsi folk watch this forum or am I talking to myself?
>> 
>> Dave
> 
> Hi Dave:
> 
> I think you are right — the problem is the timeout.
> 
> The default timeout on many systems (like SUSE that I work on) is set to 60

> seconds for a SCSI command. And it looks like the tape drive took about 82 
> seconds to skip forward a file on your Windows trace.

AFAIK, 60s is the SCSI _disk_ timeout; for tapes the timeout should be
significantly longer (depending on the technology).

> 
> Try setting the timeout to 90 seconds? The open-iscsi README talks about how

> to manually set the system SCSI timeout to longer (since this isn’t an
iSCSI 
> thing).

15 minutes or so?

> 
> Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. 
> This is also discussed in the README file. I’d try setting them both to 0
to 
> get them out of the way. It looks like the tape drive does not respond to
the 
> NOOP ping when it is busy for 80+ seconds skipping forward one file.

Regards,
Ulrich


> 
> — 
> Lee Duncan
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "open-iscsi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to open-iscsi+unsubscr...@googlegroups.com.
> To post to this group, send email to open-iscsi@googlegroups.com.
> Visit this group at https://groups.google.com/group/open-iscsi.
> For more options, visit https://groups.google.com/d/optout.



-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[Lee Duncan]

On Dec 12, 2016, at 5:46 AM, Dave partridge  wrote:
> 
> I just ran a Wireshark capture on the target system of the iSCSI session for 
> a Windows initiator connecting the tape and then issuing an FSF.  I then did 
> the same for the Ubuntu open-iscsi initiator.
> 
> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
> 
> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
> 
> Do any of the open-iscsi folk watch this forum or am I talking to myself?
> 
> Dave

Hi Dave:

I think you are right — the problem is the timeout.

The default timeout on many systems (like SUSE that I work on) is set to 60 
seconds for a SCSI command. And it looks like the tape drive took about 82 
seconds to skip forward a file on your Windows trace.

Try setting the timeout to 90 seconds? The open-iscsi README talks about how to 
manually set the system SCSI timeout to longer (since this isn’t an iSCSI 
thing).

Also, you may want to disable the Ping/NOOPs that open-iscsi is setting. This 
is also discussed in the README file. I’d try setting them both to 0 to get 
them out of the way. It looks like the tape drive does not respond to the NOOP 
ping when it is busy for 80+ seconds skipping forward one file.

— 
Lee Duncan

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

I am looking at these, but I haven't gotten very far.

I've started examining the Unbuntu capture, and it seems normal so far.

On Monday, December 12, 2016 at 5:46:17 AM UTC-8, Dave partridge wrote:
>
> I just ran a Wireshark capture on the target system of the iSCSI session 
> for a Windows initiator connecting the tape and then issuing an FSF.  I 
> then did the same for the Ubuntu open-iscsi initiator.
>
> The capture for the WIndows initiator looks pretty much as I would expect 
> (given my limited knowledge of the iSCSI protocols).
>
> The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
> sent to the target every 15 seconds whle the FSF is being processed.  
> Definitely borked I think.
>
> Do any of the open-iscsi folk watch this forum or am I talking to myself?
>
> Dave
>
> On Sunday, December 11, 2016 at 11:55:15 AM UTC, Dave partridge wrote:
>>
>> Ubuntu 16.04.1 LTS with kernel 4.8.13.  Connected to target drive over 
>> 1GB ethernet.  Drive is HP Ultrium 460 (Ultrium 2), firmware is F63D - 
>> which is latest).
>>
>> Target is served by Starwind V8 running on Windows 10 x64
>>
>> Dave
>>
>> On Saturday, December 10, 2016 at 10:38:43 PM UTC, The Lee-Man wrote:
>>>
>>> What is your setup? What OS and version are you running on, what is your 
>>> transport, and what tape drive are you using?
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[Dave partridge]

I just ran a Wireshark capture on the target system of the iSCSI session 
for a Windows initiator connecting the tape and then issuing an FSF.  I 
then did the same for the Ubuntu open-iscsi initiator.

The capture for the WIndows initiator looks pretty much as I would expect 
(given my limited knowledge of the iSCSI protocols).

The Ubuntu/open-iscsi capture has all sorts of odd stuff like logins being 
sent to the target every 15 seconds whle the FSF is being processed.  
Definitely borked I think.

Do any of the open-iscsi folk watch this forum or am I talking to myself?

Dave

On Sunday, December 11, 2016 at 11:55:15 AM UTC, Dave partridge wrote:
>
> Ubuntu 16.04.1 LTS with kernel 4.8.13.  Connected to target drive over 1GB 
> ethernet.  Drive is HP Ultrium 460 (Ultrium 2), firmware is F63D - which is 
> latest).
>
> Target is served by Starwind V8 running on Windows 10 x64
>
> Dave
>
> On Saturday, December 10, 2016 at 10:38:43 PM UTC, The Lee-Man wrote:
>>
>> What is your setup? What OS and version are you running on, what is your 
>> transport, and what tape drive are you using?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.


Ubuntu iscsi.cap
Description: application/cap


Windows iscsi.cap
Description: application/cap

Re: Problem with iSCSI connected LTO-2 tape drive

[Dave partridge]

Ubuntu 16.04.1 LTS with kernel 4.8.13.  Connected to target drive over 1GB 
ethernet.  Drive is HP Ultrium 460 (Ultrium 2), firmware is F63D - which is 
latest).

Target is served by Starwind V8 running on Windows 10 x64

Dave

On Saturday, December 10, 2016 at 10:38:43 PM UTC, The Lee-Man wrote:
>
> What is your setup? What OS and version are you running on, what is your 
> transport, and what tape drive are you using?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem with iSCSI connected LTO-2 tape drive

[The Lee-Man]

What is your setup? What OS and version are you running on, what is your 
transport, and what tape drive are you using?

On Saturday, December 10, 2016 at 9:24:33 AM UTC-8, Dave partridge wrote:
>
> I did:
>
> root@Charon:/home/amonra# mt -f /dev/st0 fsf 1
>  mt: /dev/st0: rmtioctl failed: Input/output error root
> @Charon:/home/amonra#
>
>
> The rmtioctl message appeared after about 10-15 seconds, and the iSCSI 
> target showed that the session had dropped after another 10-15 seconds.
>
> When I was returned to the command line prompt, the target showed the 
> session as connected again.
>
> During most/all of this time the forward space file operation was still 
> running.
>
> root@Charon:/home/amonra# iscsiadm -m node --targetname 
> "iqn.2008-08.com.starwindsoftware:mercury-ultrium2" --portal 
> "192.168.129.77:3260" 
> # BEGIN RECORD 2.0-873node.name = 
> iqn.2008-08.com.starwindsoftware:mercury-ultrium2
> node.tpgt = -1
> node.startup = manual
> node.leading_login = No
> iface.hwaddress = 
> iface.ipaddress = 
> iface.iscsi_ifacename = default
> iface.net_ifacename = 
> iface.transport_name = tcp
> iface.initiatorname = 
> iface.bootproto = 
> iface.subnet_mask = 
> iface.gateway = 
> iface.ipv6_autocfg = 
> iface.linklocal_autocfg = 
> iface.router_autocfg = 
> iface.ipv6_linklocal = 
> iface.ipv6_router = 
> iface.state = 
> iface.vlan_id = 0
> iface.vlan_priority = 0
> iface.vlan_state = 
> iface.iface_num = 0
> iface.mtu = 0
> iface.port = 0node.discovery_address = 192.168.129.77
> node.discovery_port = 3260
> node.discovery_type = send_targets
> node.session.initial_cmdsn = 0
> node.session.initial_login_retry_max = 8
> node.session.xmit_thread_priority = -20
> node.session.cmds_max = 128
> node.session.queue_depth = 32
> node.session.nr_sessions = 1
> 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 = 15
> node.session.err_timeo.lu_reset_timeout = 30
> node.session.err_timeo.tgt_reset_timeout = 30
> node.session.err_timeo.host_reset_timeout = 60
> 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 = 192.168.129.77
> 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.noop_out_interval = 5
> node.conn[0].timeo.noop_out_timeout = 5
> node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
> node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
> node.conn[0].iscsi.HeaderDigest = None
> node.conn[0].iscsi.DataDigest = NoneThe return to the command prompt took a 
> while longer.
> node.conn[0].iscsi.IFMarker = No
> node.conn[0].iscsi.OFMarker = No
> # END RECORD
> root@Charon:/home/amonra#
>
> I'm guessing that the problem relates to iSCSI timeouts for tape devices.  
> Please can you guide me in baby steps what I need to do to resolve this 
> problem.
>
> Thanks
> Dave 
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Problem with iSCSI connected LTO-2 tape drive

[Dave partridge]

I did:

root@Charon:/home/amonra# mt -f /dev/st0 fsf 1
 mt: /dev/st0: rmtioctl failed: Input/output error root
@Charon:/home/amonra#


The rmtioctl message appeared after about 10-15 seconds, and the iSCSI 
target showed that the session had dropped after another 10-15 seconds.

When I was returned to the command line prompt, the target showed the 
session as connected again.

During most/all of this time the forward space file operation was still 
running.

root@Charon:/home/amonra# iscsiadm -m node --targetname 
"iqn.2008-08.com.starwindsoftware:mercury-ultrium2" --portal 
"192.168.129.77:3260" 
# BEGIN RECORD 2.0-873
node.name = iqn.2008-08.com.starwindsoftware:mercury-ultrium2
node.tpgt = -1
node.startup = manual
node.leading_login = No
iface.hwaddress = 
iface.ipaddress = 
iface.iscsi_ifacename = default
iface.net_ifacename = 
iface.transport_name = tcp
iface.initiatorname = 
iface.bootproto = 
iface.subnet_mask = 
iface.gateway = 
iface.ipv6_autocfg = 
iface.linklocal_autocfg = 
iface.router_autocfg = 
iface.ipv6_linklocal = 
iface.ipv6_router = 
iface.state = 
iface.vlan_id = 0
iface.vlan_priority = 0
iface.vlan_state = 
iface.iface_num = 0
iface.mtu = 0
iface.port = 0node.discovery_address = 192.168.129.77
node.discovery_port = 3260
node.discovery_type = send_targets
node.session.initial_cmdsn = 0
node.session.initial_login_retry_max = 8
node.session.xmit_thread_priority = -20
node.session.cmds_max = 128
node.session.queue_depth = 32
node.session.nr_sessions = 1
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 = 15
node.session.err_timeo.lu_reset_timeout = 30
node.session.err_timeo.tgt_reset_timeout = 30
node.session.err_timeo.host_reset_timeout = 60
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 = 192.168.129.77
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.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5
node.conn[0].iscsi.MaxXmitDataSegmentLength = 0
node.conn[0].iscsi.MaxRecvDataSegmentLength = 262144
node.conn[0].iscsi.HeaderDigest = None
node.conn[0].iscsi.DataDigest = NoneThe return to the command prompt took a 
while longer.
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No
# END RECORD
root@Charon:/home/amonra#

I'm guessing that the problem relates to iSCSI timeouts for tape devices.  
Please can you guide me in baby steps what I need to do to resolve this problem.

Thanks
Dave 


-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at https://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Re: Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[Pierre-Yves Langlois]

Hi Mike,

I made more test to debug my setup. My original setup uses a bond on 2 nic.
If I only use one nic to connect to the SAN, everything works fine. The
problem occurs when I use the bond... Does iscsi need a special
configuration with bond or is it transparent to him?

Thanks!


On Mon, Jan 17, 2011 at 4:44 PM, Mike Christie micha...@cs.wisc.edu wrote:

 On 01/17/2011 02:26 PM, Pierre-Yves Langlois wrote:

 After issuing the command  echo 1
 /sys/module/libiscsi/parameters/debug_libiscsi_eh,I didn't see any
 changes
 in
 /var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug.
 Do I look at the right place?


 Did you do the echo, then relogin to the target?


 echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh
 iscsiadm -m node -u
 iscsiadm -m node -l


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

Re: Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[Mike Christie]

On 01/18/2011 03:41 PM, Pierre-Yves Langlois wrote:

Hi Mike,

I made more test to debug my setup. My original setup uses a bond on 2 nic.
If I only use one nic to connect to the SAN, everything works fine. The
problem occurs when I use the bond... Does iscsi need a special
configuration with bond or is it transparent to him?



It is transparent. iscsi_tcp runs from a high level. It basically just 
opens a socket like other network apps then it does send()/recv() to 
send/recv IO (recv is a little more complicated).


If you are using iscsi iface hwardare/session binding with iscsi_tcp 
then it is more complicated. I am not sure if that combo would work.





Thanks!


On Mon, Jan 17, 2011 at 4:44 PM, Mike Christiemicha...@cs.wisc.edu  wrote:


On 01/17/2011 02:26 PM, Pierre-Yves Langlois wrote:


After issuing the command  echo 1
/sys/module/libiscsi/parameters/debug_libiscsi_eh,I didn't see any
changes
in
/var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug.
Do I look at the right place?



Did you do the echo, then relogin to the target?


echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh
iscsiadm -m node -u
iscsiadm -m node -l





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

Re: Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[Pierre-Yves Langlois]

After issuing the command  echo 1 
/sys/module/libiscsi/parameters/debug_libiscsi_eh,I didn't see any changes
in
/var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug.
Do I look at the right place?


On Sat, Jan 15, 2011 at 1:54 AM, Mike Christie micha...@cs.wisc.edu wrote:

 On 01/14/2011 02:40 PM, PYL wrote:

 I'm not able to connect to a iscsi lun. I use proxmox ve 1.7 but I
 have installed the kernel 2.6.36.2 to fix a bug with my network card
 drivers...

 What am I missing?

 Here is the output from /var/log/messages:

 [CODE]
 Jan 14 14:57:13 fl-vm01 kernel: vmbr1: received packet on bond0.222
 with own address as source address
 Jan 14 14:57:13 fl-vm01 kernel: scsi3 : iSCSI Initiator over TCP/IP
 Jan 14 14:57:13 fl-vm01 kernel: scsi 3:0:0:0: Direct-Access
 NETAPP   LUN  7330 PQ: 0 ANSI: 4
 Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: Attached scsi generic sg3
 type 0
 Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] 1258450944 512-byte
 logical blocks: (644 GB/600 GiB)
 Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write Protect is off
 Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write cache:
 disabled, read cache: enabled, doesn't support DPO or FUA
 Jan 14 14:57:23 fl-vm01 kernel: connection1:0: detected conn error
 (1011)
 Jan 14 14:57:37 fl-vm01 kernel: connection1:0: detected conn error
 (1011)
 Jan 14 14:57:52 fl-vm01 kernel: connection1:0: detected conn error
 (1011)
 Jan 14 14:58:07 fl-vm01 kernel: connection1:0: detected conn error
 (1011)


 We seem to be getting them around every 15 seconds, so I think a scsi
 command is timing out which is starting the scsi eh and we end up dropping
 the session and relogging in because TMFs do not work.

 You could do

 echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh

 then rerun your test to confirm this.

 I do not know why the command is timing out though. Is there anything in
 the target logs? If you create a smaller LU (just a couple gigs) does it
 work then?


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

Re: Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[Mike Christie]

On 01/17/2011 02:26 PM, Pierre-Yves Langlois wrote:

After issuing the command  echo 1
/sys/module/libiscsi/parameters/debug_libiscsi_eh,I didn't see any changes
in
/var/log/messages, /var/log/kern.log, /var/log/daemon.log, /var/log/debug.
Do I look at the right place?



Did you do the echo, then relogin to the target?

echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh
iscsiadm -m node -u
iscsiadm -m node -l

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

Re: Problem connecting iscsi lun: DID_TRANSPORT_DISRUPTED...

[Mike Christie]

On 01/14/2011 02:40 PM, PYL wrote:

I'm not able to connect to a iscsi lun. I use proxmox ve 1.7 but I
have installed the kernel 2.6.36.2 to fix a bug with my network card
drivers...

What am I missing?

Here is the output from /var/log/messages:

[CODE]
Jan 14 14:57:13 fl-vm01 kernel: vmbr1: received packet on bond0.222
with own address as source address
Jan 14 14:57:13 fl-vm01 kernel: scsi3 : iSCSI Initiator over TCP/IP
Jan 14 14:57:13 fl-vm01 kernel: scsi 3:0:0:0: Direct-Access
NETAPP   LUN  7330 PQ: 0 ANSI: 4
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: Attached scsi generic sg3
type 0
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] 1258450944 512-byte
logical blocks: (644 GB/600 GiB)
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write Protect is off
Jan 14 14:57:13 fl-vm01 kernel: sd 3:0:0:0: [sdb] Write cache:
disabled, read cache: enabled, doesn't support DPO or FUA
Jan 14 14:57:23 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:57:37 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:57:52 fl-vm01 kernel: connection1:0: detected conn error
(1011)
Jan 14 14:58:07 fl-vm01 kernel: connection1:0: detected conn error
(1011)


We seem to be getting them around every 15 seconds, so I think a scsi 
command is timing out which is starting the scsi eh and we end up 
dropping the session and relogging in because TMFs do not work.


You could do

echo 1  /sys/module/libiscsi/parameters/debug_libiscsi_eh

then rerun your test to confirm this.

I do not know why the command is timing out though. Is there anything in 
the target logs? If you create a smaller LU (just a couple gigs) does it 
work then?


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

[PATCH] cxgb3i: fixed connection problem with iscsi private ip

[kxie]

[PATCH] cxgb3i: fixed connection problem with iscsi private ip

From: Karen Xie k...@chelsio.com

fixed the connection problem when the private iscsi ipv4 address is provisioned 
on the interface.

Signed-off-by: Karen Xie k...@chelsio.com
---
 drivers/scsi/cxgbi/cxgb3i/cxgb3i.h |   18 ++
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h 
b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..bed14db 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,20 @@
 
 extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
 
-#define cxgb3i_get_private_ipv4addr(ndev) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+   return ((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+   unsigned int addr)
+{
+   struct port_info *pi =  (struct port_info *)netdev_priv(ndev);
+
+   pi-iscsic.flags = addr ? 1 : 0;
+   pi-iscsi_ipv4addr = addr;
+   if (addr)
+   memcpy(pi-iscsic.mac_addr, ndev-dev_addr, ETH_ALEN);
+}
 
 struct cpl_iscsi_hdr_norss {
union opcode_tid ot;

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

[PATCH v2] cxgb3i: fixed connection problem with iscsi private ip

[kxie]

[PATCH v2] cxgb3i: fixed connection problem with iscsi private ip

From: Karen Xie k...@chelsio.com

The last one seems to have some formatting problem. Regenerated the patch.

fixed the connection problem when the private iscsi ipv4 address is provisioned 
on the interface.

Signed-off-by: Karen Xie k...@chelsio.com
---
 drivers/scsi/cxgbi/cxgb3i/cxgb3i.h |   19 +++
 1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h 
b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..20593fd 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,21 @@
 
 extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];
 
-#define cxgb3i_get_private_ipv4addr(ndev) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+   return ((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+   unsigned int addr)
+{
+   struct port_info *pi =  (struct port_info *)netdev_priv(ndev);
+
+   pi-iscsic.flags = addr ? 1 : 0;
+   pi-iscsi_ipv4addr = addr;
+   if (addr)
+   memcpy(pi-iscsic.mac_addr, ndev-dev_addr, ETH_ALEN);
+}
 
 struct cpl_iscsi_hdr_norss {
union opcode_tid ot;

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

Re: [PATCH v2] cxgb3i: fixed connection problem with iscsi private ip

[Mike Christie]

On 01/10/2011 06:45 PM, k...@chelsio.com wrote:

[PATCH v2] cxgb3i: fixed connection problem with iscsi private ip

From: Karen Xiek...@chelsio.com

The last one seems to have some formatting problem. Regenerated the patch.

fixed the connection problem when the private iscsi ipv4 address is provisioned 
on the interface.

Signed-off-by: Karen Xiek...@chelsio.com
---
  drivers/scsi/cxgbi/cxgb3i/cxgb3i.h |   19 +++
  1 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h 
b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
index 5f5e339..20593fd 100644
--- a/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
+++ b/drivers/scsi/cxgbi/cxgb3i/cxgb3i.h
@@ -24,10 +24,21 @@

  extern cxgb3_cpl_handler_func cxgb3i_cpl_handlers[NUM_CPL_CMDS];

-#define cxgb3i_get_private_ipv4addr(ndev) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr)
-#define cxgb3i_set_private_ipv4addr(ndev, addr) \
-   (((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr) = addr
+static inline unsigned int cxgb3i_get_private_ipv4addr(struct net_device *ndev)
+{
+   return ((struct port_info *)(netdev_priv(ndev)))-iscsi_ipv4addr;
+}
+
+static inline void cxgb3i_set_private_ipv4addr(struct net_device *ndev,
+   unsigned int addr)
+{
+   struct port_info *pi =  (struct port_info *)netdev_priv(ndev);
+
+   pi-iscsic.flags = addr ? 1 : 0;
+   pi-iscsi_ipv4addr = addr;
+   if (addr)
+   memcpy(pi-iscsic.mac_addr, ndev-dev_addr, ETH_ALEN);
+}

  struct cpl_iscsi_hdr_norss {
union opcode_tid ot;



Looks ok to me, and it fixes my setup here. Thanks.

Reviewed-by: Mike Christie micha...@cs.wisc.edu

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

Re: Problem diagnosing iscsi failure on the initiator

[Michal Suchanek]

On 16 June 2010 05:31, Mike Christie micha...@cs.wisc.edu wrote:
 On 06/14/2010 08:52 AM, Michal Suchanek wrote:

 On 13 June 2010 21:01, Mike Christiemicha...@cs.wisc.edu  wrote:

 On 06/12/2010 06:31 AM, Michal Suchanek wrote:

 Hello

 I tried to get an iscsi setup working so I installed iscsitarget and
 open-iscsi and tried to export a file as an iSCSI lun.

 After doing so I could log in with iscsiadm but I would not get any
 disks on the initiator.

 Later I discovered that I had a typo in the ietd.conf file and the lun
 was simply not exported giving a target with no luns available for the
 initiator.

 While it is true that the error is logged in kernel logs on the target
 machine I could not find any way to list the available luns on the

 iscsiadm -m session -P 3

 Thanks, this command does print the luns if there are any.

 However, it is not obvious from the documentation that it should print
 these nor is it obvious from the output that there some part missing
 when no luns are available.

 In the README I will add more info on how -P X works for session mode.



 It also does not work when I just add -P 3 to the discovery and node
 commands which I use to log into the target and there is no obvious
 reason why it should not.


 Discovery mode just finds targets and portals. It has nothing to do with LUN
 discovery normally. And the node mode commands that print out the node db
 info also just prints the target and portal info, because it is only
 concerned with the targets.

 If for discovery and node mode, you are logging into the target (using the
 --login command) then I can print out the LUNs found if that is what you are
 asking for. But normally with the discovery and node mode commands that use
 the -P operator we are just working on the targets and portals and have not
 logged into the target so we do not know if there are LUNs.


The thing is that it is not documented what the -P option actually does.

Apparently it slightly changes the output format of discover and node
modes when nonzero but prints gobs of information in session mode when
nonzero and even more when it is 2 or3.

So I would really appreciate a short note in the man page what value
of P selects what information in what mode like:

When non-zero the output in discovery, node or session mode is printed
in tree-like format. In session mode 1 prints interfaces 2 also prints
parameters and 3 also prints devices.

Thanks

Michal

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

Re: Problem diagnosing iscsi failure on the initiator

[Mike Christie]

On 06/14/2010 08:52 AM, Michal Suchanek wrote:

On 13 June 2010 21:01, Mike Christiemicha...@cs.wisc.edu  wrote:

On 06/12/2010 06:31 AM, Michal Suchanek wrote:


Hello

I tried to get an iscsi setup working so I installed iscsitarget and
open-iscsi and tried to export a file as an iSCSI lun.

After doing so I could log in with iscsiadm but I would not get any
disks on the initiator.

Later I discovered that I had a typo in the ietd.conf file and the lun
was simply not exported giving a target with no luns available for the
initiator.

While it is true that the error is logged in kernel logs on the target
machine I could not find any way to list the available luns on the


iscsiadm -m session -P 3


Thanks, this command does print the luns if there are any.

However, it is not obvious from the documentation that it should print
these nor is it obvious from the output that there some part missing
when no luns are available.


In the README I will add more info on how -P X works for session mode.




It also does not work when I just add -P 3 to the discovery and node
commands which I use to log into the target and there is no obvious
reason why it should not.



Discovery mode just finds targets and portals. It has nothing to do with 
LUN discovery normally. And the node mode commands that print out the 
node db info also just prints the target and portal info, because it is 
only concerned with the targets.


If for discovery and node mode, you are logging into the target (using 
the --login command) then I can print out the LUNs found if that is what 
you are asking for. But normally with the discovery and node mode 
commands that use the -P operator we are just working on the targets and 
portals and have not logged into the target so we do not know if there 
are LUNs.


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

Re: Problem diagnosing iscsi failure on the initiator

[Michal Suchanek]

On 13 June 2010 21:01, Mike Christie micha...@cs.wisc.edu wrote:
 On 06/12/2010 06:31 AM, Michal Suchanek wrote:

 Hello

 I tried to get an iscsi setup working so I installed iscsitarget and
 open-iscsi and tried to export a file as an iSCSI lun.

 After doing so I could log in with iscsiadm but I would not get any
 disks on the initiator.

 Later I discovered that I had a typo in the ietd.conf file and the lun
 was simply not exported giving a target with no luns available for the
 initiator.

 While it is true that the error is logged in kernel logs on the target
 machine I could not find any way to list the available luns on the

 iscsiadm -m session -P 3

Thanks, this command does print the luns if there are any.

However, it is not obvious from the documentation that it should print
these nor is it obvious from the output that there some part missing
when no luns are available.

It also does not work when I just add -P 3 to the discovery and node
commands which I use to log into the target and there is no obvious
reason why it should not.

Thanks

Michal

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

Re: Problem diagnosing iscsi failure on the initiator

[Mike Christie]

On 06/12/2010 06:31 AM, Michal Suchanek wrote:

Hello

I tried to get an iscsi setup working so I installed iscsitarget and
open-iscsi and tried to export a file as an iSCSI lun.

After doing so I could log in with iscsiadm but I would not get any
disks on the initiator.

Later I discovered that I had a typo in the ietd.conf file and the lun
was simply not exported giving a target with no luns available for the
initiator.

While it is true that the error is logged in kernel logs on the target
machine I could not find any way to list the available luns on the


iscsiadm -m session -P 3

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

Problem diagnosing iscsi failure on the initiator

[Michal Suchanek]

Hello

I tried to get an iscsi setup working so I installed iscsitarget and
open-iscsi and tried to export a file as an iSCSI lun.

After doing so I could log in with iscsiadm but I would not get any
disks on the initiator.

Later I discovered that I had a typo in the ietd.conf file and the lun
was simply not exported giving a target with no luns available for the
initiator.

While it is true that the error is logged in kernel logs on the target
machine I could not find any way to list the available luns on the
initiator. Should the target be hard to access or a piece of dedicated
hardware rather than a software service it would be really hard to
diagnose. Even when it is possible to look at the target logs it is
generally good to have diagnostics on both sides so that any issues
are easier to discover. Also it should be possible to verify that the
reported state matches on both ends.

Thanks

Michal

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