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 05-05-2010, 11:19 PM
"Moger, Babu"
 
Default dm: Add no_abort_q feature flag to dm-mpath

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Mike Anderson
> Sent: Monday, May 03, 2010 11:01 PM
> To: dm-devel@redhat.com
> Cc: linux-scsi@vger.kernel.org
> 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.

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-06-2010, 01:39 AM
Mike Anderson
 
Default dm: Add no_abort_q feature flag to dm-mpath

Moger, Babu <Babu.Moger@lsi.com> wrote:
> > -----Original Message-----
> > From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> > owner@vger.kernel.org] On Behalf Of Mike Anderson
> > Sent: Monday, May 03, 2010 11:01 PM
> > To: dm-devel@redhat.com
> > Cc: linux-scsi@vger.kernel.org
> > 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@linux.vnet.ibm.com

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
 
Old 05-06-2010, 02:38 PM
"Moger, Babu"
 
Default dm: Add no_abort_q feature flag to dm-mpath

> -----Original Message-----
> From: Mike Anderson [mailto:andmike@linux.vnet.ibm.com]
> Sent: Wednesday, May 05, 2010 8:39 PM
> To: Moger, Babu
> Cc: dm-devel@redhat.com; linux-scsi@vger.kernel.org
> Subject: Re: [PATCH 0/2] dm: Add no_abort_q feature flag to dm-mpath
>
> Moger, Babu <Babu.Moger@lsi.com> wrote:
> > > -----Original Message-----
> > > From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> > > owner@vger.kernel.org] On Behalf Of Mike Anderson
> > > Sent: Monday, May 03, 2010 11:01 PM
> > > To: dm-devel@redhat.com
> > > Cc: linux-scsi@vger.kernel.org
> > > 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.


--
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 12:58 PM.

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