Steve Byan wrote: > On Jun 13, 2006, at 11:42 AM, Michael Reed wrote: > >> Treating fibre channel like removable storage is wrong. Fibre >> targets aren't >> generally supposed to go away. If they do, there's a significant >> chance >> that they'll be repaired and returned to service. It makes sense >> to keep >> the infrastructure in place just like scsi, sas, iscsi, ata. > > In both Fibre Channel SANs and iSCSI SANs, administrators in large > datacenters will re-zone devices with some regularity as they > redeploy applications among existing systems. Yes, they will. And don't they generally do this gracefully, i.e, shut down access to file systems or devices before rezoning? And when the target is rezoned to the host again don't they expect to be able to resume using it. This patch allows that to happen with no user intervention. > >> The kind of disruption the current code can cause to systems with >> multi-terabytes >> or petabytes of storage will be considered unacceptable in a >> production environment. > > Agreed; but Fibre Channel and SAN devices _will_ come and go > dynamically. My concern is when targets go in an uncontrolled manner. > >> So, I also wish to encourage a reconsideration of the position that >> dead targets >> should be removed. Removing removable storage targets like >> firewire and usb >> makes sense. I just don't believe that the same applies to fibre >> channel >> or other generally non-removable targets. > > Think of removing a Fibre Channel or iSCSI device as "removing access > authorization". You're correct that these devices are not often > physically removed from the SAN, but access authorization may change > frequently. When the target "self-removes" and "self-attaches" I want the existing user of the target to be able to resume use. By not removing the infrastructure in these situations less disruption to a production system occurs. The existing "user" has to be tolerant of errors during this period of absence if it wishs to resume use. This patch allows that to happen if the admin so desires. Mike > > Regards, > -Steve - : 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
