On 2004-10-30T09:21:10, christophe varoqui <christophe.varoqui@xxxxxxx> wrote: > > What is the result of the TUR? I did not see any information about > > it in other posts in this thread. > > > the tur checker in multipath-tools report ghosts as failing. Note: This is about the kernel-internal "I'll try to read the partition table of every block device I see, no matter what errors I get, and NOTHING WILL STOP ME BWAHAHAHA", not about the multipath-tools. ;-) (A behaviour which tends to mess up the logfiles quite badly.) > > We might not normally every hit this since the scan (INQUIRY failure) > > would likely prevent the device from showing up at all. > scsi_id and INQUIRY succeed on ghost paths, which allow multipath to > group them with valid paths to the same LU. Yeah, multipath-tools et al are behaving quite correctly for these scenarios. > > Plus, we only call sd_spinup_disk() during discovery and not on open, > > unlike the calls to sd_media_changed(). > Would it be workable to add a scsi_devinfo flag for devices with ghosts. No. I think the kernel should simply notice that the TUR failed, or abort reading the partition table on the first error. This would at least automatically detect these cases w/o requiring explicit blacklisting. Sincerely, Lars Marowsky-Brée <lmb@xxxxxxx> -- High Availability & Clustering SUSE Labs, Research and Development SUSE LINUX AG - A Novell company