Question about /sys/class/iscsi_connection
Yangkook Kim
I am wondering why we have /sys/class/iscsi_connection for iscsi connection
in sysfs filesystem.
I understand that the one or more iscsi connection form a single iscsi session
and, in this sense, iscsi connection subordinates to iscsi session.
Then, it more makes sense if we have iscsi_connection/ under iscsi_session/.
Ex. /sys/class/iscsi_session/iscsi_connection/connectionXX:0
Can anybody give me an explanation?
Thanks
Kim,
P.S.
I also thought that connectionXX:0 is misleading. XX is supposed to be where
iscsi session number is put after binding connection and session.
Mike Christie
> Hi, Group,
>
> I am wondering why we have /sys/class/iscsi_connection for iscsi connection
> in sysfs filesystem.
>
> I understand that the one or more iscsi connection form a single iscsi session
> and, in this sense, iscsi connection subordinates to iscsi session.
> Then, it more makes sense if we have iscsi_connection/ under iscsi_session/.
>
> Ex. /sys/class/iscsi_session/iscsi_connection/connectionXX:0
Hey,
Sorry for the late reply.
We sort of have that. The reason we have
/sys/class/iscsi_connection and then
/sys/class/iscsi_session is due to how the kernel APIs work. For them we
are using transport classes and classes (see the kernel file
scsi_transport_iscsi.c), and this is just how they get laid out. We
could have just made the iscsi_connection a struct with a kobject and
then added that directly under the session, but at the time people did
not like the idea of messing with kobjects directly.
So if you look in the iscsi_session dir
/sys/class/iscsi_session/session1
ls
abort_tmo ifacename password tpgt
data_pdu_in_order immediate_data password_in uevent
data_seq_in_order initial_r2t power username
device initiatorname recovery_tmo username_in
erl lu_reset_tmo state
fast_abort max_burst_len subsystem
first_burst_len max_outstanding_r2t targetname
there is a device dir/link. When you follow that you see
ls
[root@max session1]# cd device/
[root@max device]# ls
connection1:0 iscsi_session power target6:0:0 uevent
how the connection is below the session1. So sort of what you would
expect but there is that device dir/link due to us using the
classes/transport_classes which use device structs instead f kobjects
directly.
>
> Can anybody give me an explanation?
>
> Thanks
> Kim,
>
> P.S.
> I also thought that connectionXX:0 is misleading. XX is supposed to be where
> iscsi session number is put after binding connection and session.
>
I did not get what you mean here. The XX is the session number.
Yangkook Kim
OK, now I see the history.
>> P.S.
>> I also thought that connectionXX:0 is misleading. XX is supposed to be
>> where
>> iscsi session number is put after binding connection and session.
>>
>
> I did not get what you mean here. The XX is the session number.
>
Probably I should have not to say "misleading". Instead, I should have said
it "confused" me.
It seemed to me a bit strange to say like "connectionXX:0" where XX is
session number.
I was wondering why you have to say session number to describe a connection...
But, I now came to a reason by myself. It is said so probably because
it is just useful to indentiy which connection you are talking about
in one-word, and this is useful in logging.
Or, is there any other reasons?
However, I still think it is misleading to say connectionXX:0 before binding
connection and session. In iscsid.c:session_conn_poll(), connectionXX:0 appears
before binding.
log_debug(3, "created new iSCSI session sid %d host "
"no %u", session->id, session->hostno);
snip....
log_debug(3, "created new iSCSI connection "
"%d:%d", session->id, conn->id);
snip....
log_debug(3, "bound iSCSI connection %d:%d to session %d",
session->id, conn->id, session->id);
Does it fit you very natural? Is it only me to worry about it?
2010/1/7, Mike Christie <mich...@cs.wisc.edu>:
Mike Christie
> Hi, Mike. Thank you for the reply.
>
> OK, now I see the history.
>
>>> P.S.
>>> I also thought that connectionXX:0 is misleading. XX is supposed to be
>>> where
>>> iscsi session number is put after binding connection and session.
>>>
>>
>> I did not get what you mean here. The XX is the session number.
>>
>
> Probably I should have not to say "misleading". Instead, I should have said
> it "confused" me.
>
> It seemed to me a bit strange to say like "connectionXX:0" where XX is
> session number.
> I was wondering why you have to say session number to describe a connection...
>
> But, I now came to a reason by myself. It is said so probably because
> it is just useful to indentiy which connection you are talking about
> in one-word, and this is useful in logging.
> Or, is there any other reasons?
That is pretty much it.
>
> However, I still think it is misleading to say connectionXX:0 before binding
> connection and session. In iscsid.c:session_conn_poll(), connectionXX:0 appears
> before binding.
>
> log_debug(3, "created new iSCSI session sid %d host "
> "no %u", session->id, session->hostno);
>
> snip....
>
> log_debug(3, "created new iSCSI connection "
> "%d:%d", session->id, conn->id);
>
> snip....
>
> log_debug(3, "bound iSCSI connection %d:%d to session %d",
> session->id, conn->id, session->id);
>
> Does it fit you very natural? Is it only me to worry about it?
I think the log/comments are wrong and that causes confusion. The
iscsi_connection is bound to the iscsi_session when the iscsi_connection
is created. That bind_conn() code is actually telling the kernel drivers
to bind the interconnect endpoint structs to the iscsi_connection
struct. **iscsi_conn_bind will also set up the session->leadconn
pointer, but that could be done in the create_conn callout.
But yeah, in general none of seems very natural because half the driver
is in userspace and the other half is in the kernel, so there is
sometimes a awkward flow. Note that sometimes the awkwardness is also
due to use trying to minimize the memory allocations, because we do not
want to have to allocate memory if we were trying to reconnect to a disk
that needs to have data written to it to free up memory.