Hi Mark, Mark A. Carlson wrote: > Peter Dunlap wrote: > > >> 2. From a networking and/or security standpoint does it make sense to >> have a discrete SMF service associated with this new COMSTAR iSCSI port >> provider? The COMSTAR facility itself has an associated SMF service >> (svc:system/device/stmf) that enables all COMSTAR components at once. >> So as things are implemented with our prototype today, if the user >> enables COMSTAR with "svcadm enable stmf" we will immediately start >> listening for connections on any TCP/IP ports which have been configured >> for iSCSI (default 3260). The same operation enables any other COMSTAR >> transports like Fibre Channel. >> >> > The other transports still need to be configured though, so you don't > just get FIbre Channel > by surprise. >
I'm not aware of any transport configuration that is explicitly required by the COMSTAR architecture. The FC transport requires configuration due to a quirk of its implementation since the device driver association for FC HBA devices must be changed in order to appear as target ports in COMSTAR. Since iSCSI is a purely software implementation any configured iSCSI target ports will immediately be available when COMSTAR/STMF is enable. >> Although this seems to satisfy a basic requirement that network services >> are disabled by default, it occurred to me that it is not at all clear >> to users that enabling STMF may conceivably also start up a network >> service at the same time. Would it be appropriate to have a separate >> SMF service specifically for iSCSI called >> svc:/network/iscsi/target:default? >> >> > If the LUN provider takes some time to become available (say waiting for > back end disks > to spin up), you actually don't want to make the targets available until > it's ready, right? > I don't see SMF capable of doing this... > COMSTAR instructs a specific target port to go online when it is ready, so it's OK for the transport to be available before the luns. In fact I would say this is typical in most network arrays -- you can often talk to the disk array at a time when it is not ready to transfer data to or from its back end physical media. Each configured iSCSI target will appear as a target port within COMSTAR, equivelant to a physical Fibre Channel port on an HBA. Currently we register any configured iSCSI targets with COMSTAR when the driver is attached and COMSTAR immediately asks those targets to go online at which point we begin listening for connections. If we had a separate SMF service we would register the configured iSCSI targets with COMSTAR when the iSCSI target service gets enabled -- that way COMSTAR could not bring the iSCSI target(s) online unless the service was enabled. This brings up an interesting point. Currently we use the sockfs API without regard to whether the networking subsystem is ready -- there is no way to have iSCSI wait for svc:/network/physical for example. This seems like another argument for a dedicated iSCSI service although it seems to work OK today. -Peter _______________________________________________ networking-discuss mailing list [email protected]
