Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Device-mapper Development (http://www.linux-archive.org/device-mapper-development/)
-   -   dm table: do not allow queue limits that will exceed hardware limits (http://www.linux-archive.org/device-mapper-development/704846-dm-table-do-not-allow-queue-limits-will-exceed-hardware-limits.html)

Alasdair G Kergon 09-17-2012 07:52 PM

dm table: do not allow queue limits that will exceed hardware limits
 
On Mon, Sep 17, 2012 at 03:44:29PM -0400, David Jeffery wrote:
> Instead of setting to defaults, how about maintaining previous limits?
> The initial queue setup sets defaults when a queue is first configured,
> and this maintains known, working limits if all paths are temporarly
> lost. For example, I have a test setup with a lower than normal max
> segment list. It can fail a test with the previous patch as the
> default limits exceed the hardware limits. But this setup will work if
> we leave queue limits unchanged in the special case of there being no
> target devices.

Firstly, the problem cannot be fixed completely - so let's make sure the
patch header doesn't claim that, and does explain how different
situations are handled and why.

Secondly, it's a mpath problem, so the solution should be a patch to
dm-mpath that does NOT change the way any non-mpath dm devices are handled.

Now my question is whether this can be fixed adequately within the existing
interface, or whether userspace needs the ability to control whether
limits are reset or not (either by message or ioctl flag).

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Alasdair G Kergon 09-17-2012 08:24 PM

dm table: do not allow queue limits that will exceed hardware limits
 
On Fri, Sep 14, 2012 at 04:41:33PM -0400, Mike Snitzer wrote:
> Add a safety net that will establish safe default limits, via
> blk_set_default_limits, in the event that a table temporarily doesn't
> have any component devices.

Under what circumstances is this a problem?

1) When a table part-way down a stack of devices is reloaded while bios
are already flowing through the upper parts.
- A general problem we're ignoring.

2) When queue_if_no_path is set, i/o is queued, a table is reloaded
with more restrictive limits than the i/o already in the system (that
gets pushed back).

a) There was not previously a table.
=> Use this patch to fix a better default limit?
- Needs an explanation why the limit is set in dm rather than block.

b) There was previously a table.
=> Retain the limits from that previous table as a better estimate
of what the limits might need to be, on the basis that disappeared
paths might reappear later.
- Needs a patch writing to do this.
- Does userspace need an option to reset this?
- Does it only apply if there is pushback?
- Does it apply in general to all target types if and only if there
is pushback?
- Or does it need a userspace flag to control whether or not it happens?

If queue_if_no_path is NOT set, there is no problem so neither case applies?

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Alasdair G Kergon 09-18-2012 11:40 AM

dm table: do not allow queue limits that will exceed hardware limits
 
On Mon, Sep 17, 2012 at 03:44:29PM -0400, David Jeffery wrote:
> @@ -2425,6 +2425,15 @@ struct dm_table *dm_swap_table(struct mapped_device *md, struct dm_table *table)

> + if (limits.max_sectors == UINT_MAX)

Specifically, I don't want dm.c to be peering directly into limits.

It just called calculate_queue_limits() above that.
Why is calculate_queue_limits getting the limits wrong?

Alasdair

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel


All times are GMT. The time now is 06:50 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.