From: Mike Snitzer <snitzer@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>, jens.axboe@oracle.com
Subject: Re: [PATCH v2] dm: add topology support
Date: Wed, 10 Jun 2009 10:00:29 -0400 [thread overview]
Message-ID: <20090610140028.GD25088@redhat.com> (raw)
In-Reply-To: <yq1ski860ok.fsf@sermon.lab.mkp.net>
On Wed, Jun 10 2009 at 2:51am -0400,
Martin K. Petersen <martin.petersen@oracle.com> wrote:
> >>>>> "Mike" == Mike Snitzer <snitzer@redhat.com> writes:
>
> Mike> Use blk_stack_limits() to stack block limits (including topology)
> Mike> rather than duplicate the equivalent within Device Mapper.
>
> Great! So how are the userland bits coming along?
They should be pretty well sorted out with the patches I posted to
lvm-devel early Monday morning (code review still needed):
https://www.redhat.com/archives/lvm-devel/2009-June/msg00037.html
As for the DM changes. Alasdair reviewed v2 of the patch and found an
issue that I need to get a final answer to.
Your change to dm-table.c:dm_table_set_restrictions() in linux-2.6-block
+for-next's ae03bf639a5027d27270123f5f6e3ee6a412781d introduced calls to
blk_queue_*() setters.
My v2 of the DM topology support patch does away with those and just
uses blk_stack_limits(). In the process we go back to _not_ using the
blk_queue_*() setters (note the additional checks that those setters
have).
So the question: is _not_ using the blk_queue_*() setters perfectly
fine? Given that DM has always _not_ used them the quick answer is
"seems fine".
But I need to dig a bit more to understand if the additional logic in
the blk_queue_*() setters is something DM shouldn't be circumventing.
But we're almost done with these DM/LVM2 topology bits.. really :)
Mike
next prev parent reply other threads:[~2009-06-10 14:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-09 5:14 [PATCH v2] dm: add topology support Mike Snitzer
2009-06-10 6:51 ` Martin K. Petersen
2009-06-10 14:00 ` Mike Snitzer [this message]
2009-06-10 14:36 ` Alasdair G Kergon
2009-06-10 17:58 ` Martin K. Petersen
2009-06-10 21:12 ` Mike Snitzer
2009-06-10 22:06 ` Martin K. Petersen
2009-06-10 23:08 ` Alasdair G Kergon
2009-06-11 2:21 ` Martin K. Petersen
2009-06-11 9:43 ` Alasdair G Kergon
2009-06-12 4:58 ` block: Introduce helper to reset queue limits to default values Martin K. Petersen
2009-06-15 14:56 ` Mike Snitzer
2009-06-15 18:44 ` Jens Axboe
2009-06-12 4:17 ` [PATCH v2] dm: add topology support Mike Snitzer
2009-06-12 8:45 ` Alasdair G Kergon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090610140028.GD25088@redhat.com \
--to=snitzer@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jens.axboe@oracle.com \
--cc=martin.petersen@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.