On Mon, Nov 13, 2017 at 04:35:00PM -0800, The Lee-Man wrote: > I will review these patches individually (it might take an extra day), but > I have an initial question: will this change the sysfs interface for iscsi. > But I'm pretty sure the answer is yes. Which would mean we could > break other things. If this is true, perhaps we should bump the > major version number?
The flashnode sysfs stuff is the only breaking change, as it needs to switch from a bus to a class in order to gain the namespace filtering support. I don't know how widely that's used, it's only supported by one driver and I hardly ever hear anything about it. Having the subsystem move from /sys/bus to /sys/class shouldn't be a breaking change if the sysfs programming guidelines are followed, but of course they may not be and in this case the flashnode support in the Open-iSCSI tools doesn't and needs an update. > Are there any other interfaces that will change? Is there anything > that might depend on the single-namespace approach iscsi currently > uses? Currently, the sysfs objects are always visible but the netlink control interface only works from the initial network namespace. That's what prompted me down this path, as I've heard from people interested in running iscsid in a container. My line of thinking was, once you enable the netlink interface to run in multiple namespaces things need to be isolated. For iscsi_tcp we rely on the network configuration obvisouly, so you may want multiple instances of iscsid managing sessions from different namespaces? If so, the sysfs filtering is needed to prevent them from trying to manage the same resources. Happy to discuss different ideas of how iSCSI and namespaces should interact, especially this next bit bellow. Sorry about the late response, went off last week looking more closely at the namespace reference coutning with all of this. With this patch set, iscsid creates a TCP connection and then iscsi_tcp holds a reference to the socket. That keeps the file alive even when iscsid terminates, which in turn keeps the network namespace alive. The problem is that you can terminate all the processes and unlink any references to the namespace inode (bind mount created by ip-netns for example) and I have no idea how to "recover" that namespace then in order to shut down the iSCSI session. I've been looking at getting iscsi_tcp to interact directly with the TCP connection state (difference between socket and sock structs) and let the sockfd file close with iscsid. I was thinking that would let iscsi_tcp then shutdown cleanly when the network namespace is removed. That assumes that shutting down in the right thing, otherwise we probably want a kernel thread of some sort that could be used to reference the namespace if userspace terminates. All this namespace internals is new to me, so I'm trying to figure out what the right thing for iSCSI support even is. - Chris > On Tuesday, October 31, 2017 at 3:41:32 PM UTC-7, Chris Leech wrote: > > > > This series of changes makes the iSCSI netlink and sysfs control > > interfaces filtered by network namespace. This is required to run > > iscsid in any network namespace other than the initial default one. > > > > Currently the netlink communication will fail if iscsid is started in a > > non-default network namespace, as there is no kernel side socket. After > > fixing that, the rest of these changes are to filter visibility of the > > iSCSI transport objects by netns. This allows for multiple iscsid > > instances to be run, one per netns, each controlling it's own set of > > iSCSI sessions. > > > > The iSCSI transport objects are filtered, but not the SCSI or block > > layer devices. So while iSCSI hosts and sessions become limited to a > > network namespace, any attached devices remain visible system wide. > > > > This currently only supports iscsi_tcp running in a new namespace, as it > > creates a virtual host per session. Support could be added later to > > allow assignment of iSCSI HBAs to network namespace, much as is done for > > network interfaces. > > > > Chris Leech (9): > > iscsi: create per-net iscsi netlink kernel sockets > > iscsi: associate endpoints with a host > > iscsi: sysfs filtering by network namespace > > iscsi: make all iSCSI netlink multicast namespace aware > > iscsi: set netns for iscsi_tcp hosts > > iscsi: check net namespace for all iscsi lookups > > iscsi: convert flashnode devices from bus to class > > iscsi: rename iscsi_bus_flash_* to iscsi_flash_* > > iscsi: filter flashnode sysfs by net namespace > > > > drivers/infiniband/ulp/iser/iscsi_iser.c | 7 +- > > drivers/scsi/be2iscsi/be_iscsi.c | 6 +- > > drivers/scsi/bnx2i/bnx2i_iscsi.c | 6 +- > > drivers/scsi/cxgbi/libcxgbi.c | 6 +- > > drivers/scsi/iscsi_tcp.c | 7 + > > drivers/scsi/qedi/qedi_iscsi.c | 6 +- > > drivers/scsi/qla4xxx/ql4_os.c | 62 +-- > > drivers/scsi/scsi_transport_iscsi.c | 625 > > ++++++++++++++++++++++--------- > > include/scsi/scsi_transport_iscsi.h | 63 ++-- > > 9 files changed, 538 insertions(+), 250 deletions(-) > > > > -- > > 2.9.5 > > > > > > -- > 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.
