On Thu, Apr 04 2013 at 2:47am -0400, Hannes Reinecke <hare@xxxxxxx> wrote: > NACK. > > This kills multipath startup when scsi_dh_* modules are already loaded. You mean an incorrect scsi_dh is already attached. > After boot scsi_dh_* modules might already be loaded without > multipath running. > Multipath might have defined other hardware handlers in the > configuration file, and will re-attach them on startup. > > With this patch multipath cannot configure the devices properly and > will abort. In practice the scenario you describe is configuration error and can easily be avoided in a properly configured system. But that aside, Alasdair pointed out that it appears the heart of the problem which Mikulas described in his patch header is due the fact that the scsi_dh is switched, while IO may still be in-flight, during table load (multipath_ctr -> parse_priority_group -> parse_path) rather than deferring the switch until multipath_resume. I'll take a look at fixing this by deferring the scsi_dh switch until resume. This fix would assume multipath-tools is _not_ doing a noflush suspend/resume when it is switching the scsi_dh. Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
