[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [multipath] SCSI device capacity mess
- From: Lars Marowsky-Bree <lmb suse de>
- To: device-mapper development <dm-devel redhat com>
- Cc: "linux-scsi vger kernel org" <linux-scsi vger kernel org>
- Subject: Re: [dm-devel] [multipath] SCSI device capacity mess
- Date: Tue, 2 Nov 2004 16:23:16 +0100
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]