On Thu, Jan 20, 2005 at 10:27:54AM -0500, [EMAIL PROTECTED] wrote: > > What console messages do you see? Looks like we'd have to add another > > allowed state transition from BLOCKED? > > At one point we were seeing > Synchronizing SCSI cache for disk sdc: > FAILED > status = 0, message = 00, host = 1, driver = 00 > <5> > messages. However, at this point, the sequencing in the driver for unload, > scsi_host_removal, and datastructure teardown is such that we are avoiding > this condition and removals are clean.
That was a bug in the scsi device statemachine and showed up on all hosts, it has indeed been fixed for while. > > I meant fc_target_attrs actually, which is scsi_target transport-data. > > > > The point here is that the rport is a transport-class transport object > > that every driver fully converted to fc_transport needs, so > > it's better > > in transport data as well. > > If I understand you - it's the recommendation that the remote port be > part of the fc_target transport data. I disagree. If anything, it would > be the other way around. The port exists before any scsi target (thus it > can't be part of the target allocation). The port can also exist without > being a scsi target, so there's no scsi target structure at all. No, sorry for have been unclear. I want a pointer to the remote port structure in the fc_target transport data. Every driver needs the linkage of these two, and instead of everyone having it in their private data we'd better move it to the fc_transport data structure. > > Now looking at lpfc_target given that the rport goes away we only > > have the I/O counters left and the nodlist pointer. The I/O counters > > aren't really a driver thing and should probably move to the midlayer > > which only leaves the nodelist as private data in the scsi_device. > > > > Sounds like the way to go? > > Nope. The counters are a scsi-thing (not fc-thing), so they make sense > to go into the scsi_target. That's what I meant. In fact that way it's exposed in a driver-private attributes isn't good at all. What about dropping the counters temporarily for submission and submit a patch later that adds them (and their sysfs exposure) back at the midlayer? In fact the actual accounting is better done at the midlayer-level anyway. - To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
