[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]