Re: same volume two different hosts

[Boaz Harrosh]

On Fri, Jul 31, 2009 at 7:12 PM, nick  > wrote:
> 
> 
> Hi All,
> 
> I would like to knw if i can present same volume to two hosts?
> 
> I am using Stonefly Voyager as SAN and the host would be Xen.
> 
> Thanks in Advance
> Nick
> 
On 08/03/2009 11:30 PM, Donald Williams wrote:
> Hello Nick, 
> 
>  While an iSCSI SAN will not have any problem allowing multiple hosts to
> connect to the same volume, what it doesn't do is protect you from the
> resultant corruption.   Each host will believe it owns that volume
> exclusively.  Writes from one host won't be seen by the other host.  
> They will eventually overwrite blocks written by the other and corrupt
> the file allocation table.  The solution is to use a global or
> clustering fllesystem that will manage the cache and writes.
>  Filesystems like GFS, Polyserve, IBRIX, Tivoli, etc...   GFS is open
> source, the others are commercial filesystems that run many thousands of
> dollars. 
> 
>  -don
> 

In modern Kernels it's called GFS2
OCFS2 is also a cluster filesystem I think

Boaz

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

[PATCH] libiscsi: track Target Transfer Tags

[Hannes Reinecke]

For correct TMF handling we should keep track of outstanding
TTTs; some targets will drop the connections if outstanding
TTTs are not honoured.

Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/libiscsi.c |7 +++
 drivers/scsi/libiscsi_tcp.c |2 +-
 include/scsi/libiscsi.h |1 +
 3 files changed, 9 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 77b167a..e6204fc 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -444,6 +444,7 @@ static int iscsi_prep_scsi_cmd_pdu(struct iscsi_task *task)
return -EIO;
 
task->state = ISCSI_TASK_RUNNING;
+   task->ttt = RESERVED_ITT;
hdr->cmdsn = task->cmdsn = cpu_to_be32(session->cmdsn);
session->cmdsn++;
 
@@ -478,6 +479,7 @@ static void iscsi_free_task(struct iscsi_task *task)
  task->itt, task->state, task->sc);
 
session->tt->cleanup_task(task);
+   task->ttt = RESERVED_ITT;
task->state = ISCSI_TASK_FREE;
task->sc = NULL;
/*
@@ -590,6 +592,11 @@ static void fail_scsi_task(struct iscsi_task *task, int 
err)
else
state = ISCSI_TASK_ABRT_TMF;
 
+   if (task->ttt != RESERVED_ITT)
+   ISCSI_DBG_EH(conn->session,
+"task itt 0x%x ttt 0x%x sc %p still active\n",
+task->itt, task->ttt, task->sc);
+
sc->result = err << 16;
if (!scsi_bidi_cmnd(sc))
scsi_set_resid(sc, scsi_bufflen(sc));
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
index 2e0746d..0f33f11 100644
--- a/drivers/scsi/libiscsi_tcp.c
+++ b/drivers/scsi/libiscsi_tcp.c
@@ -575,7 +575,7 @@ static int iscsi_tcp_r2t_rsp(struct iscsi_conn *conn, 
struct iscsi_task *task)
return ISCSI_ERR_DATALEN;
}
 
-   r2t->ttt = rhdr->ttt; /* no flip */
+   r2t->ttt = task->ttt = rhdr->ttt; /* no flip */
r2t->datasn = 0;
r2t->sent = 0;
 
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 61afeb5..3a20dea 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -116,6 +116,7 @@ struct iscsi_task {
uint8_t lun[8];
 
int itt;/* this ITT */
+   int ttt;
 
unsignedimm_count;  /* imm-data (bytes)   */
/* offset in unsolicited stream (bytes); */
-- 
1.6.0.2


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

Lost active R2T transfers during reset

[Hannes Reinecke]

Hi Mike,

as you might've seen, I finally found the problem for the MSA dropping
the connection. It seems that it's follows this section from the RFC:

   For the LOGICAL UNIT RESET function, the target MUST behave as
   dictated by the Logical Unit Reset function in [SAM2].

where SAM2 says:
  When a logical unit is aborting one or more tasks from a SCSI
  initiator port with the TASK ABORTED status it should complete
  all of those tasks before entering additional tasks from that
  SCSI initiator port into the task set.

So the tasks must be _completed_ at the target. Which can be
interpreted as requiring the target to send an ABORT_TASK_SET
to each outstanding task, so that this section applies:

   For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST
   continue to respond to all valid target transfer tags (received via
   R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the
   affected task set, even after issuing the task management request.
   The issuing initiator SHOULD however terminate (i.e., by setting the
   F-bit to 1) these response sequences as quickly as possible.  The
   target on its part MUST wait for responses on all affected target
   transfer tags before acting on either of these two task management
   requests.  In case all or part of the response sequence is not
   received (due to digest errors) for a valid TTT, the target MAY treat
   it as a case of within-command error recovery class (see Section
   6.1.4.1 Recovery Within-command) if it is supporting
   ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
   complete the requested task set function.

This is clarified by RFC 5048 section 4.1.2:

The initiator iSCSI layer:
 a. MUST continue to respond to each TTT received for the affected
tasks

[ .. ]
The target iSCSI layer:
 a. MUST wait for responses on currently valid target-transfer tags
of the affected tasks from the issuing initiator.

Which is exactly what I've seen with the 'ttt tracking' patch:

Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset LU Reset [sc 
88005cf4ba80 lun 1]
Aug  4 13:58:10 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf set timeout
Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset dev reset result 
= SUCCESS
Aug  4 13:58:12 tyne kernel:  session2: iscsi_eh_device_reset LU Reset [sc 
88005cc12880 lun 2]
Aug  4 13:58:12 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf set timeout
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0xe ttt 
0xc5cf6a01 sc 8800378c9d80 still active
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x15 ttt 
0x2590d700 sc 88007a5c8980 still active
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x18 ttt 
0x4926d000 sc 880078d8da80 still active
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x1f ttt 
0x89ac9500 sc 88007a5de080 still active
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x27 ttt 
0x7d0d4201 sc 8800378c9680 still active
Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x28 ttt 
0x4e2c1b01 sc 8800724cf680 still active

[ .. ]

Aug  4 13:58:41 tyne kernel:  session2: fail_scsi_task task itt 0x34 ttt 
0xdccab00 sc 88007680 still active
Aug  4 13:58:41 tyne kernel:  session2: fail_scsi_task task itt 0x53 ttt 
0xa3f5bc01 sc 88005cc12380 still active
Aug  4 13:58:41 tyne kernel:  session2: fail_scsi_task task itt 0x71 ttt 
0x7018c701 sc 88006fcf1580 still active
Aug  4 13:58:41 tyne kernel:  session2: fail_scsi_task task itt 0x7c ttt 
0x9bc45001 sc 88007280 still active
Aug  4 13:58:41 tyne kernel:  session2: iscsi_eh_device_reset dev reset result 
= SUCCESS
Aug  4 13:58:42 tyne kernel:  connection2:0: detected conn error (1020)

So I guess the MSA uses a 30 seconds timeout here :-)
Nasty, that one.

But how to handle it?
The best course of action here would be to send an ABORT_TASK TMF for each 
outstanding task;
however, our current code wouldn't allow us to.
I tried to fiddle with introducing a 'TMF_QUIESCE' state during which we're 
issuing outstanding
R2Ts, but so far with very limited success.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

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

Re: [PATCH] decrease sndtmo

[Erez Zilber]

On Sat, Aug 1, 2009 at 6:34 AM, Mike Christie wrote:
> Mike Christie wrote:
>> On 07/31/2009 04:03 AM, Hannes Reinecke wrote:
>>> Mike Christie wrote:
 tcp_sendpages/tcp_sendmsg can wait sndtmo seconds
 if a connection goes bad. This then delays session
 recovery, because that code must wait for the xmit
 thread to flush. OTOH, if we did not wait at all
 we are less efficient in the lock management
 because we must reacquire the session lock every
 time the network layer returns ENOBUFS and runs
 iscsi_tcp's write_space callout.

 This tries to balance the two by reducing the
 wait to 3 seconds from 15. If we have waited 3 secs
 to send a pdu then perf is already taking a hit so
 grabbing the session lock again is not going to make a
 difference. And waiting up to 3 secs for the xmit thread
 to flush and suspend is not that long (at least a lot better
 than 15).

>>> :-)
>>>
>>> Cool. I'm running with 1 sec here, but the principle is
>>> the same. Especially for a multipathed setup you really
>>> want this.
>>>
>>> Oh, what about making this setting dependend on the
>>> transport class timeout?
>>> Worst case sendpages/sendmsg will take up to 3 seconds
>>> now before it even will return an error.
>>> So having a transport class timeout lower than that
>>> is pointless as we have no means of terminating
>>> a call being stuck in sendpages/sendmsg and the
>>> transport class will always terminate the command.
>>>
>>> So we should either limit the transport class timeout
>>> to not being able to be set lower than 3 seconds or
>>> make this timeout set by the transport class timeout.
>>>
>>
>> Good point! Let me backout my patch, and do some more digging on why I
>> cannot just do
>>
>> signal(xmit thread)
>>
>> to wake it from sendpage/sendmsg right away.
>>
>> If I cannot get that to work, then I will send a patch to implement what
>> you describe.
>
> I got the signal stuff working. I am attaching the patch here. I put it
> in my iscsi branch, because it is built over some other patches I sent
> Erez in his logout takes ~50 secs thread.
>

I'm running with open-iscsi.git HEAD + the check suspend bit patch +
the wake xmit on error patch. If I disconnect the cable on the
initiator side (even while not running IO), I see that after sending
the signal, the  iscsi_q_XX thread reaches 100% cpu. I ran it over
several 1GB/ 10 GB drivers and got the same results.

If I remove the  wake xmit on error patch, I don't see this behavior.

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 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

[PATCH] [RESEND] libiscsi: track Target Transfer Tags

[Hannes Reinecke]

For correct TMF handling we should keep track of outstanding
TTTs; some targets will drop the connections if outstanding
TTTs are not honoured.

Signed-off-by: Hannes Reinecke 
---
 drivers/scsi/libiscsi.c |8 
 drivers/scsi/libiscsi_tcp.c |2 +-
 include/scsi/libiscsi.h |1 +
 3 files changed, 10 insertions(+), 1 deletions(-)

diff --git a/drivers/scsi/libiscsi.c b/drivers/scsi/libiscsi.c
index 77b167a..c4d2c76 100644
--- a/drivers/scsi/libiscsi.c
+++ b/drivers/scsi/libiscsi.c
@@ -177,6 +177,7 @@ void iscsi_prep_data_out_pdu(struct iscsi_task *task, 
struct iscsi_r2t_info *r2t
hton24(hdr->dlength, left);
r2t->data_count = left;
hdr->flags = ISCSI_FLAG_CMD_FINAL;
+   task->ttt = RESERVED_ITT;
}
conn->dataout_pdus_cnt++;
 }
@@ -444,6 +445,7 @@ static int iscsi_prep_scsi_cmd_pdu(struct iscsi_task *task)
return -EIO;
 
task->state = ISCSI_TASK_RUNNING;
+   task->ttt = RESERVED_ITT;
hdr->cmdsn = task->cmdsn = cpu_to_be32(session->cmdsn);
session->cmdsn++;
 
@@ -478,6 +480,7 @@ static void iscsi_free_task(struct iscsi_task *task)
  task->itt, task->state, task->sc);
 
session->tt->cleanup_task(task);
+   task->ttt = RESERVED_ITT;
task->state = ISCSI_TASK_FREE;
task->sc = NULL;
/*
@@ -590,6 +593,11 @@ static void fail_scsi_task(struct iscsi_task *task, int 
err)
else
state = ISCSI_TASK_ABRT_TMF;
 
+   if (task->ttt != RESERVED_ITT)
+   ISCSI_DBG_EH(conn->session,
+"task itt 0x%x ttt 0x%x sc %p still active\n",
+task->itt, task->ttt, task->sc);
+
sc->result = err << 16;
if (!scsi_bidi_cmnd(sc))
scsi_set_resid(sc, scsi_bufflen(sc));
diff --git a/drivers/scsi/libiscsi_tcp.c b/drivers/scsi/libiscsi_tcp.c
index 2e0746d..0f33f11 100644
--- a/drivers/scsi/libiscsi_tcp.c
+++ b/drivers/scsi/libiscsi_tcp.c
@@ -575,7 +575,7 @@ static int iscsi_tcp_r2t_rsp(struct iscsi_conn *conn, 
struct iscsi_task *task)
return ISCSI_ERR_DATALEN;
}
 
-   r2t->ttt = rhdr->ttt; /* no flip */
+   r2t->ttt = task->ttt = rhdr->ttt; /* no flip */
r2t->datasn = 0;
r2t->sent = 0;
 
diff --git a/include/scsi/libiscsi.h b/include/scsi/libiscsi.h
index 61afeb5..3a20dea 100644
--- a/include/scsi/libiscsi.h
+++ b/include/scsi/libiscsi.h
@@ -116,6 +116,7 @@ struct iscsi_task {
uint8_t lun[8];
 
int itt;/* this ITT */
+   int ttt;
 
unsignedimm_count;  /* imm-data (bytes)   */
/* offset in unsolicited stream (bytes); */
-- 
1.6.0.2


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

Re: [RFC 0/2] new kfifo API

[Arnd Bergmann]

On Monday 03 August 2009, Stefani Seibold wrote:
> Am Montag, den 03.08.2009, 16:42 +0200 schrieb Arnd Bergmann:
> > My guess is that more importantly
> > 
> > - few people so far needed the functionality.
> 
> This is not true, that is only your view. Don't speak for other people.
> A lot of device driver developer has its own implement of a fifo. I have
> written a lot of device drivers for embedded system and i always missed
> a clean designed and implemented fifo API subsystem.

As I said, I was only guessing from the only evidence we both had, which
is the current use in the kernel. Your extrapolation was that it did
not get used much because of the quality of the existing API, my
extrapolation was that there is no need for it (at least I was
never looking for it in any of my drivers).

> > This sounds all nice, and your code looks clean and usable, but really,
> > what's your point?
> > 
> > If you have a new driver that will use all the new features, please
> > just tell us, that would make your point much clearer. Also, if
> > you can quantify an advantage ( bytes code size reduce, yy%
> > performance improvement on Y benchmark) that would be really
> > helpful.
> > 
> 
> Yes, i have some drivers where i use a former version of the kfifo API.
> But the real advantage is not benchmarking.
>
> First if we have a useable kfifo API i think other developer will use
> it. And this will save memory.

Being able to simplify code is obviously good, but the normal
approach of doing it is to make it obvious in what ways. Exchanging
a whole API at once makes it unobvious what changes you do for which
purpose. 

If you split out every logical change into a separate patch,
you can easily show how to subsequently make use of that.
That also avoids the problem of adding functions that end up
being unused.

Submitting patches would also make it easier to review than
a rewrite.

> Third: The old API did not have a kfifo_to_user oder a kfifo_from_user
> functionality, so everybody wo need to store userspace data must write
> it own version of this.

That sounds like a feature that can be easily separated from the
incompatible API changes.

> Fourth: We don't discus about a havy API change, it is more subtle. And
> it doesn't blow up the kernel, okay, a little little bit. But i am sure
> that this well be gained back, if/when developer use this new API.

Can you separate the incompatible API changes from the compatible
extensions?

Arnd <><

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

Re: [RFC 0/2] new kfifo API

[Stefani Seibold]

Am Montag, den 03.08.2009, 20:23 +0200 schrieb Arnd Bergmann:
> On Monday 03 August 2009, Stefani Seibold wrote:
> > Am Montag, den 03.08.2009, 16:42 +0200 schrieb Arnd Bergmann:
> > > My guess is that more importantly
> > > 
> > > - few people so far needed the functionality.
> > 
> > This is not true, that is only your view. Don't speak for other people.
> > A lot of device driver developer has its own implement of a fifo. I have
> > written a lot of device drivers for embedded system and i always missed
> > a clean designed and implemented fifo API subsystem.
> 
> As I said, I was only guessing from the only evidence we both had, which
> is the current use in the kernel. Your extrapolation was that it did
> not get used much because of the quality of the existing API, my
> extrapolation was that there is no need for it (at least I was
> never looking for it in any of my drivers).
> 

Maybe. 

> > > This sounds all nice, and your code looks clean and usable, but really,
> > > what's your point?
> > > 
> > > If you have a new driver that will use all the new features, please
> > > just tell us, that would make your point much clearer. Also, if
> > > you can quantify an advantage ( bytes code size reduce, yy%
> > > performance improvement on Y benchmark) that would be really
> > > helpful.
> > > 
> > 
> > Yes, i have some drivers where i use a former version of the kfifo API.
> > But the real advantage is not benchmarking.
> >
> > First if we have a useable kfifo API i think other developer will use
> > it. And this will save memory.
> 
> Being able to simplify code is obviously good, but the normal
> approach of doing it is to make it obvious in what ways. Exchanging
> a whole API at once makes it unobvious what changes you do for which
> purpose. 
> 

It is not a complete change of the API. There are two main things which
are different:

The kfifo_get and kfifo_put functions are extended by two new
parameters: flag and total. Setting both to there will result in the old
behavior.

And i remove the spinlock which is logical not a part of the fifo and
should be handled outside if necessary.

   
> If you split out every logical change into a separate patch,
> you can easily show how to subsequently make use of that.
> That also avoids the problem of adding functions that end up
> being unused.
> 

> Submitting patches would also make it easier to review than
> a rewrite.
> 

Agree, but the code is very tiny and the functionality depends on the
whole. Since many of the functions are inlines, which will not generate
any code until there are used. So the kernel will not be bloated.

> > Third: The old API did not have a kfifo_to_user oder a kfifo_from_user
> > functionality, so everybody wo need to store userspace data must write
> > it own version of this.
> 
> That sounds like a feature that can be easily separated from the
> incompatible API changes.
> 
> > Fourth: We don't discus about a havy API change, it is more subtle. And
> > it doesn't blow up the kernel, okay, a little little bit. But i am sure
> > that this well be gained back, if/when developer use this new API.
> 
> Can you separate the incompatible API changes from the compatible
> extensions?
> 

No, thats not makes not real sense. If i do this i have exactly the old
API. Again, the API is not really incompatible, the change is from the
view of the old API very tiny.
 
>   Arnd <><

Stefani



--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

[RFC 0/2] extended kfifo API V0.2

[Stefani Seibold]

This is a the second proposal of an extended and cleaned up generic kernel FIFO 
implementation.

Changes since V0.1:

 add kfifo_init()
 kfifo_put() and kfifo_get() restored to the original behavior (but without 
locking)
 introduce new kfifo_put_rec() and kfifo_put_rec() for FIFO record handling
 kfifo_alloc() does only allocate the FIFO buffer
 kfifo_free() does only release the FIFO buffer
 revert to power of two buffer sizes

Again the (modified) proposal:
-- 
 
The current kernel fifo API is not very widely used, because it has to many
constrains. Only 13 files in the current 2.6.30 used it. FIFO's are
like list are a very basic thing and a kfifo API which handles the most use
case would save a lot of time and memory resources.

I think there are the following reasons why kfifo is not in use.

- There is a need of a spinlock despite you need it or not
- A fifo can only allocated dynamically
- There is no support for data records inside a fifo
- The API is to tall, some important functions are missing

So i decided to extend the kfifo in a more generic way without blowing up
the API to much. This was my design goals:

- Generic usage: For kernel internal use or device driver
- Provide an API for the most use case
- Preserve memory resource
- Linux style habit: DECLARE_KFIFO, DEFINE_KFIFO and INIT_KFIFO Macros
- Slim API: The whole API provides 16 functions.
- Ability to handle variable length records. Three type of records are
  supported:
  - Records between 0-255 bytes, with a record size field of 1 bytes
  - Records between 0-65535 bytes, with a record size field of 2 bytes
  - Byte stream, which no record size field
  Inside a fifo this record types it is not a good idea to mix them together.
- Direct copy_to_user from the fifo and copy_from_user into the fifo.
- Single structure: The fifo structure contains the management variables and
  the buffer. No extra indirection is needed to access the fifo buffer.
- Lockless access: if only one reader and one writer is active on the fifo,
  which is the common use case, there is no additional locking necessary.
- Performance
- Easy to use

The API:


The struct kfifo is defined as following:

struct kfifo {
unsigned long size; /* the size of the allocated buffer */
unsigned long in;   /* data is added at offset (in&(size-1)) */
unsigned long out;  /* data is extracted from off. (out&(size-1)) */
unsigned char *buffer;  /* the buffer holding the data */
};

This structure is so short that an extra allocation for this is omitted in the
new implementation. Simple define a "struct kfifo" where it is needed.
 
void kfifo_init(struct kfifo *fifo, unsigned char *buffer, unsigned int size)
 Initialize a FIFO using a preallocated buffer
 @fifo: the fifo to assign the buffer
 @buffer: the preallocated buffer to be used.
 @size: the size of the internal buffer, this have to be a power of 2.


struct kfifo *kfifo_alloc(struct kfifo *fifo, unsigned long size, gfp_t 
gfp_mask)
 This function dynamically allocates a new fifo internal buffer
 @fifo: the fifo to assign then new buffer
 @size: the size of the internal buffer to be allocated.
 @gfp_mask: get_free_pages mask, passed to kmalloc()


void kfifo_free(struct kfifo *fifo)
 frees a dynamic allocated FIFO buffer
 @fifo: the fifo which buffer should be freed.


void kfifo_reset(struct kfifo *fifo)
 removes the entire FIFO contents
 @fifo: the fifo to be emptied.


unsigned long kfifo_used(struct kfifo *fifo)
 kfifo_used - returns the number of bytes currently used in the FIFO
 @fifo: the fifo to be used.


unsigned long kfifo_size(struct kfifo *fifo)
 returns the size of the fifo in bytes
 @fifo: the fifo to be used.


kfifo_empty(struct kfifo *fifo)
 returns true if the fifo is empty
 @fifo: the fifo to be used.


kfifo_is_full(struct kfifo *fifo)
 returns true if the fifo is full
 @fifo: the fifo to be used.


unsigned long kfifo_avail(struct kfifo *fifo)
 returns the number of bytes available in the FIFO
 @fifo: the fifo to be used.


unsigned long kfifo_put(struct kfifo *fifo, unsigned char *from, unsigned long 
n)
 puts some data into the FIFO without locking

 This function copies at most @n bytes from the @from into
 the FIFO depending and returns the number of copied bytes.

 Note that with only one concurrent reader and one concurrent
 writer, you don't need extra locking to use these functions.
 This function is for compatibility reasons due the old kfifo API
 @fifo: the fifo to be used.
 @from: the data to be added.
 @n: the length of the data to be added.


unsigned long kfifo_put_rec(struct kfifo *fifo,
unsigned char *from, unsigned long n, unsigned long recsize,
unsigned long flags, unsigned long *total)
 puts some record data into the FIFO without locking

 This function copies at most @n bytes from the @from into
 the FIFO depending @flags argument, and returns the number of
 bytes which cannot be copied.

[RFC 1/2] extended kfifo API V0.2

[Stefani Seibold]

/*
 * A generic kernel FIFO implementation.
 *
 * Copyright (C) 2009 Stefani Seibold/Munich/Germany 
 * Copyright (C) 2004 Stelian Pop 
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 */
#ifndef _LINUX_KFIFO_H
#define _LINUX_KFIFO_H

#include 
 
#define KFIFO_F_NOTRIM  1   /* do not cut of the record */

struct kfifo {
unsigned long size; /* the size of the allocated buffer */
unsigned long in;   /* data is added at offset (in&(size-1)) */
unsigned long out;  /* data is extracted from off. (out&(size-1)) */
unsigned char *buffer;  /* the buffer holding the data */
};

#define KFIFO_INIT(s, b) \
(struct kfifo) { \
.size   = s, \
.in = 0, \
.out= 0, \
.buffer = b \
}


#define DECLARE_KFIFO(name, size) \
union { \
struct kfifo name; \
unsigned char name##_buffer[size + sizeof(struct kfifo)]; \
} 

#define DEFINE_KFIFO(name, size) \
DECLARE_KFIFO(name, size) = KFIFO_INIT(name, size)

#define INIT_KFIFO(name) \
name = KFIFO_INIT(sizeof(name##_buffer) - sizeof(struct kfifo), \
name##_buffer)

/**
 * kfifo_init - initialize a FIFO using a preallocated buffer
 * @fifo: the fifo to assign the buffer
 * @buffer: the preallocated buffer to be used.
 * @size: the size of the internal buffer, this have to be a power of 2.
 *
 * The buffer will be release with kfifo_free().
 */
extern void kfifo_init(struct kfifo *fifo, unsigned char *buffer,
unsigned int size);

/**
 * kfifo_alloc - allocates a new FIFO internal buffer
 * @fifo: the fifo to assign then new buffer
 * @size: the size of the buffer to be allocated, this have to be a power of 2.
 * @gfp_mask: get_free_pages mask, passed to kmalloc()
 *
 * This function dynamically allocates a new fifo internal buffer
 */
extern int kfifo_alloc(struct kfifo *fifo, unsigned long size, gfp_t gfp_mask);

/**
 * kfifo_free - frees a dynamic allocated FIFO buffer
 * @fifo: the fifo which buffer should be freed.
 */
extern void kfifo_free(struct kfifo *fifo);

/**
 * kfifo_reset - removes the entire FIFO contents
 * @fifo: the fifo to be emptied.
 */
static inline void kfifo_reset(struct kfifo *fifo)
{
fifo->out = fifo->in;
}

/**
 * kfifo_used - returns the number of bytes currently used in the FIFO
 * @fifo: the fifo to be used.
 */
static inline __must_check unsigned long kfifo_used(struct kfifo *fifo)
{
return fifo->in - fifo->out;
}

/**
 * kfifo_size - returns the size of the fifo in bytes
 * @fifo: the fifo to be used.
 */
static inline __must_check unsigned long kfifo_size(struct kfifo *fifo)
{
return fifo->size;
}

/**
 * kfifo_empty - returns true if the fifo is empty
 * @fifo: the fifo to be used.
 */
static inline __must_check int kfifo_empty(struct kfifo *fifo)
{
return fifo->in == fifo->out;
}

/**
 * kfifo_is_full - returns true if the fifo is full
 * @fifo: the fifo to be used.
 */
static inline __must_check int kfifo_is_full(struct kfifo *fifo)
{
return kfifo_used(fifo) == kfifo_size(fifo);
}

/**
 * kfifo_avail - returns the number of bytes available in the FIFO
 * @fifo: the fifo to be used.
 */
static inline __must_check unsigned long kfifo_avail(struct kfifo *fifo)
{
return kfifo_size(fifo) - kfifo_used(fifo);
}

/**
 * __kfifo_add_out internal helper function for updating the out offset 
 */
static inline void __kfifo_add_out(struct kfifo *fifo,
unsigned long off)
{
smp_mb();
fifo->out += off;
}

/**
 * __kfifo_add_in internal helper function for updating the in offset 
 */
static inline void __kfifo_add_in(struct kfifo *fifo,
unsigned long off)
{
smp_wmb();
fifo->in += off;
}

/**
 * __kfifo_off internal helper function for calculating the index of a
 * given offeset
 */
static inline unsigned long __kfifo_off(struct kfifo *fifo, unsigned long off)
{
return off & (fifo->size-1);
}

/**
 * __kfifo_peek_n internal helper function for determinate the length of
 * the next record in the fifo
 */
static inline unsigned long __kfifo_peek_n(struct kfifo *fifo,
unsigned long recsize)
{
#define KFIFO_GET_MOD(fifo

[RFC 2/2] extended kfifo API V0.2

[Stefani Seibold]

/*
 * A generic kernel FIFO implementation.
 *
 * Copyright (C) 2009 Stefani Seibold/Munich/Germany 
 * Copyright (C) 2004 Stelian Pop 
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation; either version 2 of the License, or
 * (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU General Public License for more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program; if not, write to the Free Software
 * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
 *
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 

static void _kfifo_init(struct kfifo *fifo, unsigned char *buffer,
unsigned int size)
{
fifo->buffer = buffer;
fifo->size = size;
fifo->in = fifo->out = 0;
}

void kfifo_init(struct kfifo *fifo, unsigned char *buffer, unsigned int size)
{

/* size must be a power of 2 */
BUG_ON(!is_power_of_2(size));

_kfifo_init(fifo, buffer, size);
}
EXPORT_SYMBOL(kfifo_init);

int kfifo_alloc(struct kfifo *fifo, unsigned long size,
gfp_t gfp_mask)
{
unsigned char *buffer;

if (size & (size - 1)) {
BUG_ON(size > 0x8000);
size = roundup_pow_of_two(size);
}

buffer = kmalloc(size, gfp_mask);
if (!buffer)
return -ENOMEM;

_kfifo_init(fifo, buffer, size);

return 0;
}
EXPORT_SYMBOL(kfifo_alloc);

void kfifo_free(struct kfifo *fifo)
{
kfree(fifo->buffer);
}
EXPORT_SYMBOL(kfifo_free);

static inline unsigned long __kfifo_put_data(struct kfifo *fifo,
const unsigned char *from, unsigned long n, unsigned long off)
{
unsigned long   l;

/*
 * Ensure that we sample the fifo->out index -before- we
 * start putting bytes into the kfifo.
 */

smp_mb();

off += fifo->in;

/* first put the data starting from fifo->in to buffer end */
l = min(n, fifo->size - __kfifo_off(fifo, off));
memcpy(fifo->buffer + __kfifo_off(fifo, off), from, l);

/* then put the rest (if any) at the beginning of the buffer */
memcpy(fifo->buffer, from + l, n - l);

return 0;
}

/**
 * kfifo_put_notrim - puts data into the FIFO without cut off a record
 * @fifo: the fifo to be used.
 * @from: the data to be added.
 * @n: the size of the destination buffer.
 * @recsize: size of record field
 * @total: pointer where the total number of copied bytes should stored
 *
 * This function copies @n bytes from the @from into the FIFO
 * 
 * In case of an error, the function returns the number of bytes which cannot
 * be copied.
 */
unsigned long __kfifo_put_notrim(struct kfifo *fifo,
const unsigned char *from, unsigned long n, unsigned long recsize,
unsigned long *total)
{
if (kfifo_avail(fifo) < n + recsize) {
*total = n + 1;
return *total;
}

*total = n;

return __kfifo_put_data(fifo, from, n, recsize);
}
EXPORT_SYMBOL(__kfifo_put_notrim);

unsigned long __kfifo_put_trim(struct kfifo *fifo,
const unsigned char *from, unsigned long n, unsigned long recsize,
unsigned long *total)
{
unsigned long   l;

l = min(kfifo_avail(fifo), n + recsize);

if (l < recsize) {
*total = n + 1;
return *total;
}

*total = l - recsize;

return __kfifo_put_data(fifo, from, l - recsize, recsize);
}
EXPORT_SYMBOL(__kfifo_put_trim);

unsigned long __kfifo_put_generic(struct kfifo *fifo,
const unsigned char *from, unsigned long n, unsigned long recsize,
unsigned long flags, unsigned long *total)
{
if (!recsize)
return __kfifo_put(fifo, from, n, flags, total);
return __kfifo_put_n(fifo, from, n, recsize, flags, total);
}
EXPORT_SYMBOL(__kfifo_put_generic);

unsigned long kfifo_put(struct kfifo *fifo, unsigned char *from,
unsigned long n)
{
n = min(kfifo_avail(fifo), n);

__kfifo_put_data(fifo, from, n, 0);
__kfifo_add_in(fifo, n);

return n;
}
EXPORT_SYMBOL(kfifo_put);

static inline unsigned long __kfifo_get_data(struct kfifo *fifo,
unsigned char *to, unsigned long n, unsigned long off)
{
unsigned long l;

/*
 * Ensure that we sample the fifo->in index -before- we
 * start removing bytes from the kfifo.
 */

smp_rmb();

off += fifo->out;

/* first get the data from fifo->out until the end of the buffer */

Re: How many S/W iSCSI Initiators on same machine?

[Rainer Bläs]

Thanks for your answer!
Yes, by using "#iscsiadm -m iface -I ethN, N=1...6" we can have 6
iSCSI sessions.

But now there is the question "HOWTO assign an initiator name for EACH
session"?
For one iSCSI session it can be found in the /etc/iscsi/
initiatorname.iscsi File:

InitiatorName=iqn.1986-03.com.hp:Ethernet1

Can it be done by adding these 5 entries

InitiatorName=iqn.1986-03.com.hp:Ethernet2
InitiatorName=iqn.1986-03.com.hp:Ethernet3
InitiatorName=iqn.1986-03.com.hp:Ethernet4
InitiatorName=iqn.1986-03.com.hp:Ethernet5
InitiatorName=iqn.1986-03.com.hp:Ethernet6

or which syntax has to be used?

Rainer






On Aug 3, 10:36 pm, Donald Williams  wrote:
> Hello,
> I'm not sure what your question really is.  Yes, you can have 6x GbE
> interfaces on different subnets and run iSCSI over them. What target are you
> using?   Typically, your iSCSI SAN is on one subnet.  It avoids the need to
> do IP routing.   Which adds latency and can reduce performance.
>
>  -don
>
> On Fri, Jul 31, 2009 at 6:03 AM, Rainer Bläs
> wrote:
>
>
>
> > Dear all,
>
> > we are running a SLES 10SP2 system with 6 physical Ethernet ports.
> > For instance is it possible to have 6 iSCSI initiators onthis system
> > when each IP of these six ports are belonging to 6 different (Sub)
> > Lans?
>
> > THX, Rainer
>
> --
>
> Marie von 
> Ebner-Eschenbach
> - "Even a stopped clock is right twice a day."

--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

Can discovery be done without overwriting customizations?

[Ty! Boyack]

Folks,

I really fear this one is a FAQ somewhere, but I can't find the answer 
to it.

My problem is that discovering new targets overwrites any custom 
settings that have been applied to targets that already exist on a given 
portal.

Here is the sequence of events I'd like to do:

1) Create an iscsi target in our iscsi SAN (based on IET).
2) On the server that wants to use that target, do 'iscsiadm -m 
discovery...' to discover the target.
3) We use chap, so set the username/password with 'iscsiadm -m node 
-T... -o update...'
4) Log in and use that target.
(Up to here everything is great)
5) Sometime in the future (hours to months) add a new target in the 
iscsi SAN.
6) On the same server, do a discovery to discover this new target.
7) Set the username/password for the new target.
8) Log in to the new target and use the new target.

The problem is that when we do the discovery in step 6, it wipes out the 
username/password and any other customizations we've put in the record 
for the target that was discovered in step 2.  When we have only a few 
targets it's easy enough to reset all the username/passwords, but this 
is going to get cumbersome when we have quite a few targets.

Is there a way to discover a new target without overwriting the existing 
target database?

Thanks,

-Ty!

-- 
-===-
   Ty! Boyack
   NREL Unix Network Manager
   t...@nrel.colostate.edu
   (970) 491-1186
-===-


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

Re: Lost active R2T transfers during reset

[Mike Christie]

Hannes Reinecke wrote:
> Hi Mike,
> 
> as you might've seen, I finally found the problem for the MSA dropping
> the connection. It seems that it's follows this section from the RFC:
> 
>For the LOGICAL UNIT RESET function, the target MUST behave as
>dictated by the Logical Unit Reset function in [SAM2].
> 
> where SAM2 says:
>   When a logical unit is aborting one or more tasks from a SCSI
>   initiator port with the TASK ABORTED status it should complete
>   all of those tasks before entering additional tasks from that
>   SCSI initiator port into the task set.
>  
> So the tasks must be _completed_ at the target. Which can be
> interpreted as requiring the target to send an ABORT_TASK_SET
> to each outstanding task, so that this section applies:
> 
>For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST
>continue to respond to all valid target transfer tags (received via
>R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the
>affected task set, even after issuing the task management request.
>The issuing initiator SHOULD however terminate (i.e., by setting the
>F-bit to 1) these response sequences as quickly as possible.  The
>target on its part MUST wait for responses on all affected target
>transfer tags before acting on either of these two task management
>requests.  In case all or part of the response sequence is not
>received (due to digest errors) for a valid TTT, the target MAY treat
>it as a case of within-command error recovery class (see Section
>6.1.4.1 Recovery Within-command) if it is supporting
>ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
>complete the requested task set function.
> 
> This is clarified by RFC 5048 section 4.1.2:
> 
> The initiator iSCSI layer:
>  a. MUST continue to respond to each TTT received for the affected
> tasks




4.1.2 and the passage above it from 3720 applies to lu reset too right? 
That is my understanding. The comment about sending a ABORT_TASK_SET 
confused me.



> 
> [ .. ]
> The target iSCSI layer:
> a. MUST wait for responses on currently valid target-transfer tags
> of the affected tasks from the issuing initiator.
> 
> Which is exactly what I've seen with the 'ttt tracking' patch:
> 
> Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset LU Reset [sc 
> 88005cf4ba80 lun 1]
> Aug  4 13:58:10 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf set 
> timeout
> Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset dev reset 
> result = SUCCESS
> Aug  4 13:58:12 tyne kernel:  session2: iscsi_eh_device_reset LU Reset [sc 
> 88005cc12880 lun 2]
> Aug  4 13:58:12 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf set 
> timeout
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0xe ttt 
> 0xc5cf6a01 sc 8800378c9d80 still active
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x15 ttt 
> 0x2590d700 sc 88007a5c8980 still active
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x18 ttt 
> 0x4926d000 sc 880078d8da80 still active
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x1f ttt 
> 0x89ac9500 sc 88007a5de080 still active
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x27 ttt 
> 0x7d0d4201 sc 8800378c9680 still active
> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x28 ttt 
> 0x4e2c1b01 sc 8800724cf680 still active
> 


I think what is being checked in the ttt tracking patch and what is 
mentioned in the RFC are different.


I think we only need to respond to commands like r2t from the target in 
order to satisfy the ttt comment. If fast_abort is 0/No,  then when we 
get a R2T we will to send the data for it. This completes the sequence 
that the target is waiting for. We might slightly violate the RFC in 
that we send all the data for the r2t, and the RFC says to terminate the 
sequence quickly so maybe it wanted us to send a data-out with the F bit 
set but not all the data. I do not know. It probably does not matter. 
Once we send the data-outs for all the data that the r2t requested, then 
the target can send another r2t, send a response for the task (it can 
send a scsi cmd pdu indicating a error), or it can respond to the TMF 
that was affecting it.


You patch considers the TTT completed when the entire command/task is 
completed. So you are waiting for the initiator to get the task's status 
in a scsi cmd pdu (for writes). If we do not get status that the task is 
completed then your patch prints an error.

What your patch is expecting to happen with the current code is for the 
lu reset to be sent, then R2T responded to, then the target send a scsi 
cmd response pdu for the tasks affected by the TMF. I do not think this 
is right, because when the target sends the TMF response then the 
response applies to all the affected tasks and we do not need a response 
for each individua

Re: Can discovery be done without overwriting customizations?

[Mike Christie]

Ty! Boyack wrote:
> Folks,
> 
> I really fear this one is a FAQ somewhere, but I can't find the answer 
> to it.
> 
> My problem is that discovering new targets overwrites any custom 
> settings that have been applied to targets that already exist on a given 
> portal.
> 
> Here is the sequence of events I'd like to do:
> 
> 1) Create an iscsi target in our iscsi SAN (based on IET).
> 2) On the server that wants to use that target, do 'iscsiadm -m 
> discovery...' to discover the target.
> 3) We use chap, so set the username/password with 'iscsiadm -m node 
> -T... -o update...'
> 4) Log in and use that target.
> (Up to here everything is great)
> 5) Sometime in the future (hours to months) add a new target in the 
> iscsi SAN.
> 6) On the same server, do a discovery to discover this new target.
> 7) Set the username/password for the new target.
> 8) Log in to the new target and use the new target.
> 
> The problem is that when we do the discovery in step 6, it wipes out the 
> username/password and any other customizations we've put in the record 
> for the target that was discovered in step 2.  When we have only a few 
> targets it's easy enough to reset all the username/passwords, but this 
> is going to get cumbersome when we have quite a few targets.
> 
> Is there a way to discover a new target without overwriting the existing 
> target database?
> 

What version of open-iscsi are you using? In newer versions you can do:

iscsiadm -m discovery -t st -ip -o new -o delete

This will add new records for portals not in the db using iscsid.conf 
info and delete portals that are not returned by the target.


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

Re: [PATCH] decrease sndtmo

[Mike Christie]

Erez Zilber wrote:
> 
> I'm running with open-iscsi.git HEAD + the check suspend bit patch +
> the wake xmit on error patch. If I disconnect the cable on the
> initiator side (even while not running IO), I see that after sending
> the signal, the  iscsi_q_XX thread reaches 100% cpu. I ran it over
> several 1GB/ 10 GB drivers and got the same results.
> 
> If I remove the  wake xmit on error patch, I don't see this behavior.
> 

Shoot, I have been running the xmit wakeup and suspend bit patch here 
fine. Let me do some more testing.

Is this something you always hit? Could you send me the final patch you 
ended up using?


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

Re: [LIST:open-iscsi] Re: Can discovery be done without overwriting customizations?

[Ty! Boyack]

On 08/04/2009 11:04 AM, Mike Christie wrote:
> Ty! Boyack wrote:
>
>> Folks,
>>
>> I really fear this one is a FAQ somewhere, but I can't find the answer
>> to it.
>>
>> My problem is that discovering new targets overwrites any custom
>> settings that have been applied to targets that already exist on a given
>> portal.
>>
>> Here is the sequence of events I'd like to do:
>>
>> 1) Create an iscsi target in our iscsi SAN (based on IET).
>> 2) On the server that wants to use that target, do 'iscsiadm -m
>> discovery...' to discover the target.
>> 3) We use chap, so set the username/password with 'iscsiadm -m node
>> -T... -o update...'
>> 4) Log in and use that target.
>> (Up to here everything is great)
>> 5) Sometime in the future (hours to months) add a new target in the
>> iscsi SAN.
>> 6) On the same server, do a discovery to discover this new target.
>> 7) Set the username/password for the new target.
>> 8) Log in to the new target and use the new target.
>>
>> The problem is that when we do the discovery in step 6, it wipes out the
>> username/password and any other customizations we've put in the record
>> for the target that was discovered in step 2.  When we have only a few
>> targets it's easy enough to reset all the username/passwords, but this
>> is going to get cumbersome when we have quite a few targets.
>>
>> Is there a way to discover a new target without overwriting the existing
>> target database?
>>
>>  
>
> What version of open-iscsi are you using? In newer versions you can do:
>
> iscsiadm -m discovery -t st -ip -o new -o delete
>
> This will add new records for portals not in the db using iscsid.conf
> info and delete portals that are not returned by the target.
>
>

Thanks, Mike -- that is exactly what I needed!

For what it's worth, I had seen the 'new' option in the man page but 
hadn't used it, just because I misunderstood the man page.

The man page states that: 'new  creates a new database record for a 
given portal (IP address and port number). In discovery mode, iscsiadm 
will create new records for portals returned by the target.'

I wanted to keep my old records, so I didn't want it to create new 
records for me, hence my confusion.  After your explanation I can see 
that it really creates new records for any NEW targets on the portal, is 
that right?

(I know this means I should probably submit a patch on the man page if 
I'm making such suggestions, but I'd really prefer if someone more 
familiar with the details would look at that)

Thanks again,

-Ty!




-- 
-===-
   Ty! Boyack
   NREL Unix Network Manager
   t...@nrel.colostate.edu
   (970) 491-1186
-===-


--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---

memory usage per iscsi connection

[solidguy]

We're using open-iscsi to connect a large number of virtual machines
on a single host to the backend storage (in this case the hypervisor
is Xen). We need to figure out how much memory to allocate for the
management domain (dom0) -- and this is partly derived from the memory
usage per ISCSI connection. Does anybody know offhand how much this
would be for x86 and x86_64  kernel?

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

Re: Lost active R2T transfers during reset

[Mike Christie]

Mike Christie wrote:
> Note: if you are running with fast_abort=1/Yes, then we have that 
> problem I mentioned before where a task can get stuck at the head of the 
> requeue/cmd list and so tasks after it will not get run, and in that 
> case r2ts might not get answered.
> 

Oh yeah, make sure you are not using your cmdns window patch, because 
your patch will prevent data-outs from being sent in response to r2ts if 
the window is closed.

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

Re: [PATCH] decrease sndtmo

[Erez Zilber]

On Tue, Aug 4, 2009 at 8:17 PM, Mike Christie wrote:
>
> Erez Zilber wrote:
>>
>> I'm running with open-iscsi.git HEAD + the check suspend bit patch +
>> the wake xmit on error patch. If I disconnect the cable on the
>> initiator side (even while not running IO), I see that after sending
>> the signal, the  iscsi_q_XX thread reaches 100% cpu. I ran it over
>> several 1GB/ 10 GB drivers and got the same results.
>>
>> If I remove the  wake xmit on error patch, I don't see this behavior.
>>
>
> Shoot, I have been running the xmit wakeup and suspend bit patch here
> fine. Let me do some more testing.
>
> Is this something you always hit? Could you send me the final patch you
> ended up using?

I see this every time. Note that I'm not running with
linux-2.6-iscsi.git. I'm using the open-iscsi.git tree + the 2 patches
that I took without any change (using git-show) from the
linux-2.6-iscsi.git tree. Which tree did you test it on?

I added some printks to the code and saw that the signal does get sent
from iscsi_sw_tcp_conn_stop, but I didn't see that (rc == -EINTR || rc
== -EAGAIN) in  iscsi_sw_tcp_xmit (), even when I ran IO on that
session.

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 
open-iscsi+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~--~~~~--~~--~--~---

Re: How many S/W iSCSI Initiators on same machine?

[Donald Williams]

I don't know if there's a way to set unique initiator names for each NIC.  A
quick scan of the config file didn't show anything.  I *believe* iscsid has
the initiator name so it's a global parameter.
 Why do you want unique names for each initiator?   What do you think it
will gain you?

 -don

On Tue, Aug 4, 2009 at 4:16 AM, Rainer Bläs
wrote:

>
> Thanks for your answer!
> Yes, by using "#iscsiadm -m iface -I ethN, N=1...6" we can have 6
> iSCSI sessions.
>
> But now there is the question "HOWTO assign an initiator name for EACH
> session"?
> For one iSCSI session it can be found in the /etc/iscsi/
> initiatorname.iscsi File:
>
> InitiatorName=iqn.1986-03.com.hp:Ethernet1
>
> Can it be done by adding these 5 entries
>
> InitiatorName=iqn.1986-03.com.hp:Ethernet2
> InitiatorName=iqn.1986-03.com.hp:Ethernet3
> InitiatorName=iqn.1986-03.com.hp:Ethernet4
> InitiatorName=iqn.1986-03.com.hp:Ethernet5
> InitiatorName=iqn.1986-03.com.hp:Ethernet6
>
> or which syntax has to be used?
>
> Rainer
>
>
>
>
>
>
> On Aug 3, 10:36 pm, Donald Williams  wrote:
> > Hello,
> > I'm not sure what your question really is.  Yes, you can have 6x GbE
> > interfaces on different subnets and run iSCSI over them. What target are
> you
> > using?   Typically, your iSCSI SAN is on one subnet.  It avoids the need
> to
> > do IP routing.   Which adds latency and can reduce performance.
> >
> >  -don
> >
> > On Fri, Jul 31, 2009 at 6:03 AM, Rainer Bläs
> > wrote:
> >
> >
> >
> > > Dear all,
> >
> > > we are running a SLES 10SP2 system with 6 physical Ethernet ports.
> > > For instance is it possible to have 6 iSCSI initiators onthis system
> > > when each IP of these six ports are belonging to 6 different (Sub)
> > > Lans?
> >
> > > THX, Rainer
> >
> > --
> >
> > Marie von Ebner-Eschenbach<
> http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac>
> > - "Even a stopped clock is right twice a day."
>
> >
>


-- 

Pablo Picasso
- "Computers are useless. They can only give you answers."

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

Re: How many S/W iSCSI Initiators on same machine?

[Ulrich Windl]

On 4 Aug 2009 at 1:16, Rainer Bläs wrote:

> 
> Thanks for your answer!
> Yes, by using "#iscsiadm -m iface -I ethN, N=1...6" we can have 6
> iSCSI sessions.
> 
> But now there is the question "HOWTO assign an initiator name for EACH
> session"?

I think the concept is that one physical machine has one initiator name, maybe 
because you can access the same LUN via different sessions.
BTW: The documentation for the HP-UX iSCSI Initiator has a nice documentation 
that 
explains the basics of iSCSI. It can be found at http://docs.hp.com
I'm not sue about the exact title, but it's similar to "Software Initiator 
Support 
Guide"

> For one iSCSI session it can be found in the /etc/iscsi/
> initiatorname.iscsi File:
> 
> InitiatorName=iqn.1986-03.com.hp:Ethernet1
> 
> Can it be done by adding these 5 entries
> 
> InitiatorName=iqn.1986-03.com.hp:Ethernet2
> InitiatorName=iqn.1986-03.com.hp:Ethernet3
> InitiatorName=iqn.1986-03.com.hp:Ethernet4
> InitiatorName=iqn.1986-03.com.hp:Ethernet5
> InitiatorName=iqn.1986-03.com.hp:Ethernet6
> 
> or which syntax has to be used?
> 
> Rainer
[...]

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

Re: Lost active R2T transfers during reset

[Hannes Reinecke]

Mike Christie wrote:
> Hannes Reinecke wrote:
>> Hi Mike,
>>
>> as you might've seen, I finally found the problem for the MSA dropping
>> the connection. It seems that it's follows this section from the RFC:
>>
>>For the LOGICAL UNIT RESET function, the target MUST behave as
>>dictated by the Logical Unit Reset function in [SAM2].
>>
>> where SAM2 says:
>>   When a logical unit is aborting one or more tasks from a SCSI
>>   initiator port with the TASK ABORTED status it should complete
>>   all of those tasks before entering additional tasks from that
>>   SCSI initiator port into the task set.
>>  
>> So the tasks must be _completed_ at the target. Which can be
>> interpreted as requiring the target to send an ABORT_TASK_SET
>> to each outstanding task, so that this section applies:
>>
>>For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST
>>continue to respond to all valid target transfer tags (received via
>>R2T, Text Response, NOP-In, or SCSI Data-In PDUs) related to the
>>affected task set, even after issuing the task management request.
>>The issuing initiator SHOULD however terminate (i.e., by setting the
>>F-bit to 1) these response sequences as quickly as possible.  The
>>target on its part MUST wait for responses on all affected target
>>transfer tags before acting on either of these two task management
>>requests.  In case all or part of the response sequence is not
>>received (due to digest errors) for a valid TTT, the target MAY treat
>>it as a case of within-command error recovery class (see Section
>>6.1.4.1 Recovery Within-command) if it is supporting
>>ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
>>complete the requested task set function.
>>
>> This is clarified by RFC 5048 section 4.1.2:
>>
>> The initiator iSCSI layer:
>>  a. MUST continue to respond to each TTT received for the affected
>> tasks
> 
> 
> 
> 
> 4.1.2 and the passage above it from 3720 applies to lu reset too right?
> That is my understanding. The comment about sending a ABORT_TASK_SET
> confused me.
> 
> 
> 
>>
>> [ .. ]
>> The target iSCSI layer:
>> a. MUST wait for responses on currently valid target-transfer tags
>> of the affected tasks from the issuing initiator.
>>
>> Which is exactly what I've seen with the 'ttt tracking' patch:
>>
>> Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset LU Reset
>> [sc 88005cf4ba80 lun 1]
>> Aug  4 13:58:10 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf
>> set timeout
>> Aug  4 13:58:10 tyne kernel:  session2: iscsi_eh_device_reset dev
>> reset result = SUCCESS
>> Aug  4 13:58:12 tyne kernel:  session2: iscsi_eh_device_reset LU Reset
>> [sc 88005cc12880 lun 2]
>> Aug  4 13:58:12 tyne kernel:  session2: iscsi_exec_task_mgmt_fn tmf
>> set timeout
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0xe
>> ttt 0xc5cf6a01 sc 8800378c9d80 still active
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x15
>> ttt 0x2590d700 sc 88007a5c8980 still active
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x18
>> ttt 0x4926d000 sc 880078d8da80 still active
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x1f
>> ttt 0x89ac9500 sc 88007a5de080 still active
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x27
>> ttt 0x7d0d4201 sc 8800378c9680 still active
>> Aug  4 13:58:12 tyne kernel:  session2: fail_scsi_task task itt 0x28
>> ttt 0x4e2c1b01 sc 8800724cf680 still active
>>
> 
> 
> I think what is being checked in the ttt tracking patch and what is
> mentioned in the RFC are different.
> 
Might well be; it's not that I've understood the iscsi stack in all
its subtleties.

> 
> I think we only need to respond to commands like r2t from the target in
> order to satisfy the ttt comment. If fast_abort is 0/No,  then when we
> get a R2T we will to send the data for it. This completes the sequence
> that the target is waiting for.

Correct. My point here is that there might be still some Data-out PDUs
stuck in the queue, which will never get send as we break out on the
first non-eligible PDU.

> We might slightly violate the RFC in
> that we send all the data for the r2t, and the RFC says to terminate the
> sequence quickly so maybe it wanted us to send a data-out with the F bit
> set but not all the data. I do not know. It probably does not matter.
Don't know either, there is this section in the spec:

   An R2T MAY be answered with one or more SCSI Data-Out PDUs with a
   matching Target Transfer Tag.  If an R2T is answered with a single
   Data-Out PDU, the Buffer Offset in the Data PDU MUST be the same as
   the one specified by the R2T, and the data length of the Data PDU
   MUST be the same as the Desired Data Transfer Length specified in the
   R2T.  If the R2T is answered with a sequence of Data PDUs, the Buffer
   Offset and Length MUST be within the ra

Re: Lost active R2T transfers during reset

[Hannes Reinecke]

Mike Christie wrote:
> Mike Christie wrote:
>> Note: if you are running with fast_abort=1/Yes, then we have that
>> problem I mentioned before where a task can get stuck at the head of
>> the requeue/cmd list and so tasks after it will not get run, and in
>> that case r2ts might not get answered.
>>
> 
> Oh yeah, make sure you are not using your cmdns window patch, because
> your patch will prevent data-outs from being sent in response to r2ts if
> the window is closed.

Yes, did so. Nae bother.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke   zSeries & Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Markus Rex, HRB 16746 (AG Nürnberg)

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