FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Device-mapper Development

 
 
LinkBack Thread Tools
 
Old 02-04-2008, 05:58 PM
James Bottomley
 
Default scsi_dh: Add support for SDEV_PASSIVE

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
it's not a valid SCSI state. If these patches can't work except by
mucking with the SCSI state model, there's some layering problem
elsewhere that needs sorting out.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-04-2008, 07:15 PM
Chandra Seetharaman
 
Default scsi_dh: Add support for SDEV_PASSIVE

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.

chandra
> it's not a valid SCSI state. If these patches can't work except by
> mucking with the SCSI state model, there's some layering problem
> elsewhere that needs sorting out.
>
> James
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--

----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-04-2008, 07:26 PM
Mike Anderson
 
Default scsi_dh: Add support for SDEV_PASSIVE

James Bottomley <James.Bottomley@HansenPartnership.com> 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
> it's not a valid SCSI state. If these patches can't work except by
> mucking with the SCSI state model, there's some layering problem
> elsewhere that needs sorting out.
>

It is actually a valid state for this device and a number of other
devices that have passive / active controller. There are differences in
response capability (i.e., media access commands) on certain sds until a
fail over command is given. The response behavior difference along with
all the partition scanning and other commands that get generated during
the probing of a device are what leads to the long boot times previously
mentioned by Chandra.

Since we have created a policy to remove the vendor specific multipath
drivers that handled the aggregation of the paths into a single device we
need some method to handle devices that are not fully capable, but are
still expose to the upper layers.

The patches are also addressing a long standing issue of sense data
processing, but that is not related to the SDEV_* state comment.

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-04-2008, 07:28 PM
James Bottomley
 
Default scsi_dh: Add support for SDEV_PASSIVE

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.

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.

James


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-04-2008, 08:19 PM
Chandra Seetharaman
 
Default scsi_dh: Add support for SDEV_PASSIVE

On Mon, 2008-02-04 at 14:28 -0600, 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.
>
> 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.

The device does send these error messages currently, but it takes some
time to get the check condition back, which adds up the time to boot
especially when the # of LUNS is huge.

For example, in my test configuration, I had 40 luns, and the time
difference (with this patch and without it) to boot is 171 seconds and
1426 seconds.

We thought we will get it short circuited so as to return the failure
back faster.

Also, we only short circuit REQ_TYPE_FS.


>
> James
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--

----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-05-2008, 07:04 PM
Mike Christie
 
Default 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
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?


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-05-2008, 08:56 PM
Mike Anderson
 
Default scsi_dh: Add support for SDEV_PASSIVE

Mike Christie <michaelc@cs.wisc.edu> wrote:
> 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?

The majority of the boot up delays is caused by the kernel partition
scanning and other kernel init code (Chandra please correct if that is not
true). Sysfs attributes would not help here. One option maybe to add
handling of the newer BLKERR_ codes in the generators of IO or some
similar solution with a rollout possibly focused at the top generators of
IO.

A number of user apps like lvm scanning that execute media access commands
already have filter capability to filter devices that one does not want to
scan. Another class of device scanners just use inquiries which are not
effected by the passive state (though some could probably use udevinfo and
reduce the amount of repeated SCSI inquiries execute on the system.

-andmike
--
Michael Anderson
andmike@linux.vnet.ibm.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-05-2008, 11:46 PM
Chandra Seetharaman
 
Default scsi_dh: Add support for SDEV_PASSIVE

On Tue, 2008-02-05 at 13:56 -0800, Mike Anderson wrote:
> Mike Christie <michaelc@cs.wisc.edu> wrote:
> > 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?
>
> The majority of the boot up delays is caused by the kernel partition
> scanning and other kernel init code (Chandra please correct if that is not

Yes, this is the case.

Some level of scanning happens at the rc scripts level too. That can be
reduced by what Mikec is suggesting. But, as andmike is suggesting, it
won't be a complete solution.

> true). Sysfs attributes would not help here. One option maybe to add
> handling of the newer BLKERR_ codes in the generators of IO or some
> similar solution with a rollout possibly focused at the top generators of

are you suggesting the partition scanners (kernel) and lvm(user space
scanner) should stop sending I/Os to a passive device once they realize
that the device is passive (thru BLKERR_ return codes) ?

> IO.
>
> A number of user apps like lvm scanning that execute media access commands
> already have filter capability to filter devices that one does not want to

Yes, it will help. But, it will lead to additional instructions to the
users which if they do not follow (due to not knowing it or some such)
will lead to a delayed boot.

IMO, It will be good if it works nicely out of the box.

> scan. Another class of device scanners just use inquiries which are not
> effected by the passive state (though some could probably use udevinfo and
> reduce the amount of repeated SCSI inquiries execute on the system.
>
> -andmike
> --
> Michael Anderson
> andmike@linux.vnet.ibm.com
--

----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-09-2008, 11:45 AM
Matthew Wilcox
 
Default scsi_dh: Add support for SDEV_PASSIVE

On Mon, Feb 04, 2008 at 01:19:30PM -0800, Chandra Seetharaman wrote:
> The device does send these error messages currently, but it takes some
> time to get the check condition back, which adds up the time to boot
> especially when the # of LUNS is huge.
>
> For example, in my test configuration, I had 40 luns, and the time
> difference (with this patch and without it) to boot is 171 seconds and
> 1426 seconds.

Was that with sync or async SCSI bus scanning?

--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 02-11-2008, 05:27 PM
Chandra Seetharaman
 
Default scsi_dh: Add support for SDEV_PASSIVE

On Sat, 2008-02-09 at 05:45 -0700, Matthew Wilcox wrote:
> On Mon, Feb 04, 2008 at 01:19:30PM -0800, Chandra Seetharaman wrote:
> > The device does send these error messages currently, but it takes some
> > time to get the check condition back, which adds up the time to boot
> > especially when the # of LUNS is huge.
> >
> > For example, in my test configuration, I had 40 luns, and the time
> > difference (with this patch and without it) to boot is 171 seconds and
> > 1426 seconds.
>
> Was that with sync or async SCSI bus scanning?

I didn't change anything, IOW, i did default scanning, which I would
guess sync ?!


>
--

----------------------------------------------------------------------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
----------------------------------------------------------------------


--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 

Thread Tools




All times are GMT. The time now is 09:30 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org