On 27.08.2005 19:38 James Bottomley <jejb@xxxxxxxxxxxx> wrote: > > this patch fixes a severe problem with 2.6.13-rc7. > > > > Due to recent SCSI changes it is not possible to add any > > LUNs to the zfcp device driver anymore. With registration > > of remote ports this is fixed. > > > > Please integrate the patch in the 2.6.13 kernel or if it > > is already too late for this release then please integrate it > > in 2.6.13.1 > > > > Thanks a lot. > Well, OK, but your usage isn't quite optimal. The fibre channel > transport class retains a list of ports per host, so your maintenance of > an identical list in zfcp_adapter duplicates this. I know what you mean. It would be better to store all "private" zfcp data at dd_data in fc_rport. Unfortunately it won't fit to zfcp's current behaviour. The rport depends on a specific host_id. Even the name of the rport in sys/class/fc_remote_port inherits this id. This means if the host is deregistered and registered again the old rport structure is useless because new host_ids are assigned. Or do I miss something here? The zfcp_port structure is thought to be persistent if once configured by the user, i.e. even if the host is deregistered and registered again the port structure is kept. I am not sure at the moment how this can be solved with the current fc_transport. I think it would have been better to use the WWPN of an rport as the name in sys/class/fc_remote_port. This would be a start to keep rport structures independent of the host_id. (Why should the transport depend on OS assigned ids anyway? The transport has already unique identifiers like WWPNs.) > However, we can put this in for now and worry about removing all of the > fc transport class duplication from zfcp later. > James In any case attributes provided by an rport should be removed from the zfcp_port structure. This is what I will do next. Regards, Andreas - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html