> -----Original Message----- > From: Mike Anderson [mailto:andmike@xxxxxxxxxxxxxxxxxx] > Sent: Wednesday, May 05, 2010 8:39 PM > To: Moger, Babu > Cc: dm-devel@xxxxxxxxxx; linux-scsi@xxxxxxxxxxxxxxx > Subject: Re: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath > > Moger, Babu <Babu.Moger@xxxxxxx> wrote: > > > -----Original Message----- > > > From: linux-scsi-owner@xxxxxxxxxxxxxxx [mailto:linux-scsi- > > > owner@xxxxxxxxxxxxxxx] On Behalf Of Mike Anderson > > > Sent: Monday, May 03, 2010 11:01 PM > > > To: dm-devel@xxxxxxxxxx > > > Cc: linux-scsi@xxxxxxxxxxxxxxx > > > Subject: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath > > > > > > This patch series contains two patches. > > > > > > 1.) The first patch adds a feature flags bit field to the multipath > > > structure for selected features. > > > > > > 2.) The second patch allows a user to set a feature flag for a dm- > mpath > > > device of "no_abort_q" to indicate that deactivate_path should not > call > > > blk_abort_queue. I tried to select a short feature name to feature > > > output > > > listed with multipath -l would not be too long "features='2 > > > queue_if_no_path > > > no_abort_q' > > > > Mike, > > In what special circumstances you recommend to use this feature? It > would be great if you could add that explanation in your patch > descriptions. > > Yes I will update the descriptions. > > To answer your question in general it would be circumstance where the > block_abort_queue during failover is leading to longer recovery instead > of > shorter. This could be because of aborting / transport / device > interactions (the work by others in the iSCSI and FC transports have > made > things better here). > > While there are case where abort makes a big difference (being able to > failover in less than max_retries * IO timeout value). The latency > numbers > for simple RDAC initiator failover show only small improvements on my > configurations (others may have better data). A assumption would be > that > there could be combinations of transports and devices out there where > this > might not give the fastest failover so the user may want control. > > On a historically note the call to block_abort_queue came in somewhat > sideways by me linked to the timeout movement from SCSI to blk so it > could > have integrated better. I should have had a way to disable / enable it > then and I am trying to provide that now so that the user has some > control. Thanks for the details. -- 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
