James Bottomley wrote:
On Mon, 2008-02-04 at 12:15 -0800, Chandra Seetharaman wrote:
On Mon, 2008-02-04 at 12:58 -0600, James Bottomley wrote:
On Wed, 2008-01-23 at 16:32 -0800, Chandra Seetharaman wrote:
Subject: scsi_dh: Add support for SDEV_PASSIVE
From: Chandra Seetharaman <sekharan@xxxxxxxxxx>
This patch adds a new device state SDEV_PASSIVE, to correspond to the
passive side access of an active/passive multipathed device.
Really, no; this isn't right. The state field of a SCSI device is for
the SCSI state model. Passive might be a valid device mapper state, but
Hi James,
It is not the "device mapper state", it is the state of the device
itself. These devices have active/passive paths, the passive paths will
be represented by SDEV_PASSIVE device state in SCSI.
Yes, it is .. you're killing commands on the basis of being in this
state, which nothing in SCSI ever sets.
SCSI does set this. See below.
A proper return from a passive path is the SCSI standard NOT_READY
LOGICAL UNIT NOT READY, INITIALIZING COMMAND REQUIRED. We expect to see
this, not the command being killed.
I think this part of the patch is trying to implement and detect the
Target port asymetric access states from spc3 section 5.8.2.4 (it does
not follow it exactly because devices like RDAC or old clarrions did not
implement the spec), and then use that info to fail commands before they
are even sent to the device to avoid start up delays from when programs
like udev, hal, kernel partition scanning probe the device.
For the LSI patch it works like the following:
When IO is sent to a path that cannot execute IO optimally, the scsi hw
handler hook for sense processing (see rdac_check_sense in "[PATCH 8/9]
scsi_dh: add lsi rdac device handler" and the scsi_error.c hook in in
"scsi_dh: add skeleton for SCSI Device Handlers") will detect this and
set the state to passive so future IO is not execute on the path
(SG_IO/passthrough is allowed).
I am not sure about alternatives. If we just exported the port access
state in sysfs, but did not fail IO from scsi_prep_state_check, then the
users could still check the state before sending IO. Would it be
horrible to convert apps to do this?
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
