On Sunday, December 16, 2018 at 5:30:29 PM UTC-8, The Lee-Man wrote: > > On Friday, December 14, 2018 at 12:13:46 PM UTC-8, Satyajit Deshmukh wrote: >> >> Hello, >> >> An update on the issue. I could observe that the target entries were not >> populated under sysfs. >> >> This is for a session that has a valid block device: >> $ ls /sys/class/iscsi_session/session778/device >> connection778:0 iscsi_session power target162:0:0 uevent >> >> This is for a session that does not have a valid block device: >> $ls /sys/class/iscsi_session/session780/device >> connection780:0 iscsi_session power uevent >> >> As we can see, the target... directory is missing. >> So, an event responsible to create the sysfs entry could not get created. >> >> journalctl does not print this info. Is there a way to enable some >> debugging, to debug this? >> >> >> > It seems like the iscsi initiator code in the kernel is not creating the > target directory. I will have to look at the code to figure out why. Is > there any difference between the two targets? How many targets to you have? > What type of targets are they (i.e. hardware, software)? > > There is no difference between the two targets. We have 100s of iSCSI targets on a single VM. All of these are software targets. The target device does get created most of the times.
Another related issue we found is during log outs. In that scenario, the block device was not cleanly removed, during the iscsiadm logout command. I will share details about that shortly. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
