From: Patrick Mansfield <patmans@us.ibm.com>
To: Lars Marowsky-Bree <lmb@suse.de>
Cc: device-mapper development <dm-devel@redhat.com>,
christophe varoqui <christophe.varoqui@free.fr>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [dm-devel] [multipath] SCSI device capacity mess
Date: Fri, 29 Oct 2004 17:41:32 -0700 [thread overview]
Message-ID: <20041030004131.GA29908@beaverton.ibm.com> (raw)
In-Reply-To: <20041028182154.GY32712@marowsky-bree.de>
On Thu, Oct 28, 2004 at 08:21:54PM +0200, Lars Marowsky-Bree wrote:
> On 2004-10-28T11:14:36, Patrick Mansfield <patmans@us.ibm.com> wrote:
>
> > > Can't we do a test-unit-ready before trying to read and then just not
> > > read the partition table w/o so much noise?
> > We already issue a TUR in sd_spinup_disk() prior to the READ CAPACITY and
> > partition reads.
>
> I'm just saying we should stop on the first failed command (TUR) and not
> retry to read all 64 sectors regardless. I can live with one error per
> passive path, but 64 really kills the logs.
That makes sense.
What is the result of the TUR? I did not see any information about it in other posts in this thread.
We should only send the READ CAPACTIY if the TUR says the device is
ready. Maybe the code in media_not_present() is wrong and causing a
problem.
This code in sd.c:
static int media_not_present(struct scsi_disk *sdkp, struct scsi_request *srp)
{
if (!srp->sr_result)
return 0;
if (!(driver_byte(srp->sr_result) & DRIVER_SENSE))
return 0;
if (srp->sr_sense_buffer[2] != NOT_READY &&
srp->sr_sense_buffer[2] != UNIT_ATTENTION)
return 0;
if (srp->sr_sense_buffer[12] != 0x3A) /* medium not present */
return 0;
set_media_not_present(sdkp);
return 1;
}
For example if we got sr_result of a DID_NO_CONNECT or other error that
does not end up setting DRIVER_SENSE, driver_byte(sr_result) could be
0, and then we would return 0.
Agree?
And then we allow a READ CAPACITY later on if media is present.
Maybe we have a similiar problem with the TUR to this device.
We should change state somehow if the TUR failed or was not ready, maybe
call set_media_not_present(), or maybe change the sdev state to
SDEV_OFFLINE - though that might cause extra logging.
We might not normally every hit this since the scan (INQUIRY failure)
would likely prevent the device from showing up at all.
Plus, we only call sd_spinup_disk() during discovery and not on open,
unlike the calls to sd_media_changed().
-- Patrick Mansfield
next prev parent reply other threads:[~2004-10-30 0:42 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-26 23:27 [multipath] SCSI device capacity mess christophe varoqui
2004-10-26 21:34 ` James Bottomley
2004-10-26 21:46 ` christophe varoqui
2004-10-27 8:17 ` [dm-devel] " Lars Marowsky-Bree
2004-10-27 8:42 ` Lars Marowsky-Bree
2004-10-27 18:51 ` Bryan Henderson
2004-10-29 14:12 ` Lars Marowsky-Bree
2004-10-29 16:48 ` Bryan Henderson
2004-10-27 19:02 ` christophe varoqui
2004-10-27 19:37 ` Eddie Williams
2004-10-27 20:19 ` christophe varoqui
2004-10-27 20:34 ` Greg Freemyer
2004-10-27 20:28 ` Philip R Auld
2004-10-27 21:57 ` James Bottomley
2004-10-28 11:37 ` Lars Marowsky-Bree
2004-10-28 18:14 ` Patrick Mansfield
2004-10-28 18:21 ` Lars Marowsky-Bree
2004-10-30 0:41 ` Patrick Mansfield [this message]
2004-10-30 1:01 ` Patrick Mansfield
2004-10-30 7:21 ` christophe varoqui
2004-10-30 8:22 ` christophe varoqui
2004-11-02 15:23 ` Lars Marowsky-Bree
2004-10-28 11:35 ` Lars Marowsky-Bree
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041030004131.GA29908@beaverton.ibm.com \
--to=patmans@us.ibm.com \
--cc=christophe.varoqui@free.fr \
--cc=dm-devel@redhat.com \
--cc=linux-scsi@vger.kernel.org \
--cc=lmb@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).