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. -andmike -- Michael Anderson andmike@xxxxxxxxxxxxxxxxxx -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
