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

[dm-devel] Re: [PATCH 7/9] scsi_dh: Add support for SDEV_PASSIVE

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 us ibm com>

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
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 (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?

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