Hi Mike,
I'm just reviewing this for the iser disconnect change we're discussing,
and I noted that stop conn is called after ep_disconnect. I wasn't sure if
this is needed, or maybe bug or just something we can live with...
Here's the sequence of events I have collected with the RHEL 5.4
Mike Christie wrote:
The refcouning method sounds good. If iser has cleaned up what gets set
in iscsi_iser_conn_bind once its ep_disconnect has completed, then you
should be ok. So iser_conn-ib_conn has to be NULLd so later when
iscsi_iser_conn_bind is called for the new conn it can be set.
Or Gerlitz wrote:
Mike Christie wrote:
And we will have to watch out for a rmmod while there are ib_conns left
yes, I never was a big favor of rmmod flows, but, I admit they exist...
I do hit this -EEXIST race from time to time when running things like
stop/start sequence.
Now I get it
Mike Christie wrote:
So iser_conn-ib_conn has to be NULLd so later when
iscsi_iser_conn_bind is called for the new conn it can be set.
nullifying iser_conn-ib_conn in iser_conn_terminate is problematic since
i_c_terminate is called in the e_disconnect flow where i_c_stop is call later
and if
Remember that clients (especially Linux) doe cache blocks
locally
Doesn't kernel refresh the read cache for blocks at some intervals?
If I make a new file on target locally, and waiting for sometime,
hitting read command like ls on initiator side will read data from
block device, not from
Remember that clients (especially Linux) doe cache blocks
locally
Doesn't kernel refresh the read cache for blocks at some intervals?
If I make a new file on target locally, and waiting for sometime,
hitting read command like ls on initiator side will read data from
block device, not from
so is GFS the only option?
Is NFS an option?
--
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
Hello,
I'm new to SANs and iSCSI, and I'm lookin to a place to start from,
and I'm finding this place is such a great one, so please, can you
give me some links to tutorials or videos about it?
Regards,
Sci3ntist
--
You received this message because you are subscribed to the Google Groups
so is GFS the only option?
Is NFS an option?
--
Romeo Theriault
--
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
If you do not use ifaces, then IO will be routed based on the route table.
So I think probably, IO would go through the same NIC on the server. Is this
what you are seeing?
I don't actually have the env. setup yet. Right now I'm just trying to
determine what would be the best way to setup the
Hello,
The struct *iscsi_sw_tcp_conn* contains the field *struct iscsi_conn *conn*,
which is never initialized and never used.
I am currently working on a patch that will change the open-iscsi logging
mechanism (as was discussed between Mike, Erez and Ulrich). Some of the
logging is done in the
Hi all. I am going through some testing of my multipathed iSCSI
devices and I am seeing some longer than expected delays. I am
running the latest RHEL 5.4 packages as of this morning. I am seeing
the failure of the iSCSI sessions take about 67 seconds. After the
iSCSI failure the multipath
On 03/01/2010 05:38 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:51 PM, Mike Christiemicha...@cs.wisc.edu wrote:
On 02/03/2010 06:07 AM, Erez Zilber wrote:
On Wed, Feb 3, 2010 at 11:30 AM, Mike Christiemicha...@cs.wisc.edu
wrote:
On 02/03/2010 01:50 AM, Erez Zilber wrote:
It looks
On 02/02/2010 02:53 AM, Erez Zilber wrote:
I've attached 2 versions. One fixes only the 5.5 case and the other
one handles all RHEL versions that are6.0. I prefer the 2nd one
(assuming that there will be no API breakage until RHEL 6.0).
Merged the second one. Thanks!
--
You received this
On 03/01/2010 02:46 AM, Or Gerlitz wrote:
Mike Christie wrote:
Ah never mind. For some reason I thought you had to have a mask, but if
you give rdma_resolve_addr a addr then it will do the right thing and
use only the port you wanted right?
YES. providing rdma_resolve_addr a source address is
On 03/01/2010 04:33 AM, Avi Kaplan wrote:
Hello,
The struct *iscsi_sw_tcp_conn* contains the field *struct iscsi_conn *conn*,
which is never initialized and never used.
I am currently working on a patch that will change the open-iscsi logging
mechanism (as was discussed between Mike, Erez and
On 03/01/2010 08:15 AM, Or Gerlitz wrote:
Hi Mike,
I'm just reviewing this for the iser disconnect change we're discussing,
and I noted that stop conn is called after ep_disconnect. I wasn't sure if
this is needed, or maybe bug or just something we can live with...
ep_disconnect deals with
On 03/01/2010 06:29 PM, Mike Christie wrote:
If the device name and port do not change normally that seems better to
me since it works like the other drivers.
Oh yeah, just to be clear, I am saying I prefer above, but that is based
on what I understand today. As I said I did not understand
On 03/01/2010 09:15 AM, Or Gerlitz wrote:
Or Gerlitz wrote:
Mike Christie wrote:
And we will have to watch out for a rmmod while there are ib_conns left
yes, I never was a big favor of rmmod flows, but, I admit they exist...
I do hit this -EEXIST race from time to time when running
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 secs after you see
Mar 1 07:14:27 bentCluster-1 kernel: connection4:0: ping timeout of
5 secs expired, recv timeout 5, last rx 4884304, last ping
Mike Christie wrote:
On 03/01/2010 12:06 PM, bet wrote:
1. Based on my timeouts I would think that my session would time out
Yes. It should timeout about 15 secs after you see
Mar 1 07:14:27 bentCluster-1 kernel: connection4:0: ping timeout of
5 secs expired, recv timeout 5, last rx
Ok so I guess working with old versions of open-iscsi is not accepted
here :). So I upgraded to the latest and greatest semi-stable
release, 871. I no longer see the is not queued messages and my
login and logout work fine. However this is the only the case if I
don't have my flash device
22 matches
Mail list logo
