[dm-devel] [multipath] SCSI device capacity mess
Lars Marowsky-Bree
lmb at suse.de
Tue Nov 2 15:23:16 UTC 2004
On 2004-10-30T09:21:10, christophe varoqui <christophe.varoqui at 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 at suse.de>
--
High Availability & Clustering
SUSE Labs, Research and Development
SUSE LINUX AG - A Novell company
More information about the dm-devel
mailing list