[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [dm-devel] [PATCH v2] dm mpath: add feature flag to control call to blk_abort_queue
- From: Mike Snitzer <snitzer redhat com>
- To: Mike Anderson <andmike linux vnet ibm com>
- Cc: dm-devel redhat com, Mike Christie <michaelc cs wisc edu>, linux-scsi vger kernel org
- Subject: Re: [dm-devel] [PATCH v2] dm mpath: add feature flag to control call to blk_abort_queue
- Date: Thu, 18 Nov 2010 10:48:08 -0500
On Thu, Nov 18 2010 at 2:20am -0500,
Mike Anderson <andmike linux vnet ibm com> wrote:
> Mike S,
>
> Thanks for doing the refresh / update of the patch.
> I just did a quick test and did not see any issues but did have a couple
> of questions.
>
> Two questions:
>
> 1.) Should we bump the multipath targets version for this change?
Yes, not doing so was an oversight. I'll bump the version and post v3.
> 2.) A general question on the length of the feature name
> "abort_queue_on_failure" while the descriptive name is nice I noticed if
> I have two features that the multipath output line starts wrapping. I
> guess we could make the feature name shorter, but eventually if we added
> more features the line would eventually wrap so a shorted name will just
> stop wrapping now.
I'm open to other suggestions for the feature name.
I agree that we don't want feature names to get too long. But they do
need to be descriptive. So we need to have some balance. I could've
used "abort_q_on_failure" but I went for "queue" to maintain symmetry
with "queue_if_no_path". Similarly, abbreviating "failure" to "fail"
seemed like it didn't buy much (less clear?). *shrug* Maybe
"abort_queue_on_fail" offers a better balance?
As for the wrapping, I don't think there is anything we can do to avoid
it (given the current interface).
Thanks,
Mike
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]