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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox