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@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. > > 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- ---------------------------------------------------------------------- Chandra Seetharaman | Be careful what you choose.... - sekharan@xxxxxxxxxx | .......you may get it. ---------------------------------------------------------------------- -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel