Re: [dm-devel] [multipath] SCSI device capacity mess

[Lars Marowsky-Bree <lmb@suse.de>]

On 2004-10-30T09:21:10, christophe varoqui <christophe.varoqui@free.fr> 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@suse.de>

-- 
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company

-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html